データ運用作業概要（アリビッグデータ：データ管理概要）

Alibaba ビッグデータ: データ管理の概要

メタデータは、ソース データ、データ ウェアハウス、データ アプリケーションを接続し、データの生成から消費までのプロセス全体を記録します。メタデータは主に、データ ウェアハウス内のモデルの定義、各レベル間のマッピング関係を記録し、データ ウェアハウスのデータ状態と ETL タスクの実行状態を監視します。

詳細については、 「メタデータ管理を 1 つの記事で理解する」を参照してください。

メタデータは、その用途に応じて、テクニカル メタデータとビジネス メタデータの 2 つのカテゴリに分類できます。

• 技術メタデータ: データ ウェアハウス システムに関する技術的な詳細を保存し、データ ウェアハウスの開発と管理に使用されるデータです。分散コンピューティング システムは、テーブル、列、パーティションなどの情報などのメタデータを保存します。テーブル名が記録されます。パーティション情報、担当者情報、ファイルサイズ、テーブルタイプ、ライフサイクルのほか、列フィールド名、フィールドタイプ、フィールドのコメント、パーティションフィールドかどうかなどの情報も表示されます。分散コンピューティング システム操作メタデータ (MaxCompute 上のすべてのジョブ実行情報など)。Hive のジョブ ログに似ており、ジョブの種類、インスタンス名、入力と出力、SQL、実行パラメータ、実行時間、最も細かい FuxiInstance (MaxCompute での MR 実行の最小単位) 実行情報などが含まれます。データ開発プラットフォームにおけるデータ同期、コンピューティングタスク、タスクスケジューリングに関する情報。データ同期の入出力テーブルとフィールド、同期タスク自体のノード情報などが含まれます。コンピューティングタスクには主に入出力、タスク自体のノード情報が含まれます。タスクのスケジュール設定には、主にタスクの依存関係の種類、依存関係などのほか、さまざまな種類のスケジュールされたタスクの実行ログが含まれます。タスク監視、運用保守アラーム、データ品質、障害などのデータ品質および運用保守関連のメタデータ。タスク監視操作ログ、アラーム設定および操作ログ、障害情報などが含まれます。
• ビジネス メタデータ: データ ウェアハウス内のデータをビジネスの観点から説明します。ユーザーと実際のシステムの間にセマンティック レイヤーが提供されるため、コンピューター テクノロジーを理解していないビジネス担当者でも、データ ウェアハウス内のデータを「理解」できるようになります。

メタデータは重要なアプリケーション価値を持ち、データ管理、データ コンテンツ、およびデータ アプリケーションの基礎となります。

• データ管理の面では、コンピューティング、ストレージ、コスト、品質、セキュリティ、モデルなどのガバナンス領域でグループのデータに対するデータサポートを提供します。たとえば、コンピューティングでは、メタデータを使用して非常に長い時間実行されるノードを見つけることができ、これらのノードはベースライン出力時間を保証するために特別に管理できます。
• データ コンテンツに関しては、グループ データ ドメイン、データ テーマ、ビジネス属性などの抽出と分析のためのデータ マテリアルを提供します。たとえば、メタデータを使用してナレッジ グラフを構築し、データにラベルを付け、利用可能なデータを明確に把握できます。
• データ応用に関しては、製品とアプリケーションのリンクを公開し、製品データの正確かつタイムリーな出力を確保します。たとえば、MaxCompute とアプリケーション データを接続し、データ資産レベルを明確にして、製品データをより効果的に保護することができます。

メタデータの品質はデータ管理の精度に直接影響するため、メタデータを適切に構築する方法が重要な役割を果たします。メタデータ構築の目標は、データアクセスから処理、そしてデータ消費までのチェーン全体をオープンにし、メタデータシステムとモデルを標準化し、統一されたメタデータサービスのエクスポートを提供し、メタデータ出力の安定性と品質を確保することです。

価値: データに基づく意思決定、デジタル運用

• データ主導のアプローチを通じて、傾向を特定し、効果的なアクションを実行して問題を特定し、イノベーションやソリューションを推進することができます。
• データ ユーザーにとって、メタデータは必要なデータをすばやく見つけるのに役立ちます。
• ETL エンジニアにとって、メタデータは、モデル設計、タスクの最適化、タスクのオフラインなど、さまざまな日常的な ETL タスクのガイドとして使用できます。
• 運用および保守エンジニアは、メタデータを使用して、クラスター全体のストレージ、コンピューティング、システム最適化などの運用および保守タスクを実行することができます。

中心的なアイデア: 複雑なデータに対して明確な血統マップを確立する。グラフ コンピューティング、ラベル伝播アルゴリズム、その他のテクノロジを通じて、コンピューティング プラットフォームとストレージ プラットフォーム上のデータを体系的かつ自動的にラベル付け、整理、アーカイブします。私たちは実際にメタデータを「描写する」という作業に着手し、次の 4 種類のラベルを開発しました。

• 基本ラベル: 保存条件、アクセス条件、セキュリティ レベルなどに基づいてデータにラベルを付けます。
• データ ウェアハウスのラベル付け: データが増分か完全か、更新可能か、データのライフ サイクルに基づいてデータにラベルを付けます。
• ビジネス タグ: データが属する主題ドメイン、製品ライン、ビジネス タイプに基づいて、データに異なるタグを割り当てます。
• 潜在的なタグ: これらのタグは主に、ソーシャル、メディア、広告、電子商取引、金融など、データの潜在的なアプリケーション シナリオを説明するために使用されます。

• メタデータ ポータルは、ワンストップのデータ管理プラットフォームと効率的な統合データ市場の構築に取り組んでいます。
• 「フロントエンド」製品は、消費者市場の位置を特定し、データの取得やデータの理解などの「データ検索」ニーズを実現するデータマップです。
• 「バックエンド」製品はデータ管理であり、ワンストップのデータ管理として位置付けられ、コスト管理、セキュリティ管理、品質管理などを実現します。

アプリケーション リンク分析を通じて、テーブル レベルの系統、フィールドの系統、およびテーブル アプリケーションの系統が生成されます。テーブルレベルの親族関係を計算する主な方法は 2 つあります。

• 1 つは、MR タスク ログを解析することです。
• 1 つは、タスクの依存関係に基づいて解析することです。

一般的なアプリケーション リンク分析アプリケーションには、影響分析、重要度分析、オフライン分析、リンク分析、ルート トレース、トラブルシューティングなどがあります。

メタデータ駆動型データ ウェアハウス モデル構築を通じて、この問題をある程度解決し、データ ウェアハウス モデリングのデータに基づくガイダンスを改善し、モデリングの効率を向上させることができます。

• ダウンストリーム条件、クエリ数、関連付け数、集計数、出力時間などを含むテーブルの基本メタデータ。
• 関連テーブル、関連タイプ、関連フィールド、関連の数などを含む、テーブルの関連関係の数。
• フィールド名、フィールドコメント、クエリ数、関連付け数、集計数、フィルター数などを含むテーブル フィールドの基本メタデータ。
• ここで、クエリは SQL SELECT を参照し、関連付けは SQL JOIN を参照し、集計は SQL GROUP BY を参照し、フィルタリングは SQL WHERE を参照します。

スター モデルの設計では、使用されるメタデータ情報には次のものが含まれます。

• 下流での使用において、関連付け回数が一定のしきい値を超えたテーブルやクエリ回数が一定のしきい値を超えたテーブルなど、メタデータ情報に基づいてデータ モデル構築に使用するテーブルをフィルター処理します。
• フィールド内の時間フィールド、下流での使用時にフィールドがフィルタリングされる回数など、テーブルのフィールド メタデータに基づいてビジネス プロセス識別フィールドを選択します。
• マスター テーブルとスレーブ テーブルの関連付け関係と関連付け時間に基づいて、マスター テーブルに関連付けられているスレーブ テーブルを決定します。
• フィールド クエリ、フィルター処理、関連付け、集計の数など、マスター テーブルと詳細テーブルのフィールドの使用状況に基づいて、ターゲット モデルに入力するフィールドを決定します。

(履歴ベースのオプティマイザー)

タスクが安定している場合は、タスクの履歴実行に基づいてリソース評価を検討することができます。つまり、HBOを使用します。

• CPU使用率の向上
• メモリ使用率の向上
• 同時インスタンス数を増やす
• 実行時間を短縮

HBO は、データ量が劇的に増加する「ビッグセール」などのシナリオに対応するため、主にマップ内のデータ量の増加に基づいて、データ量に基づいてインスタンス数を動的に調整する機能も追加しました。

コストベース オプティマイザーは、収集された統計情報に基づいて各実行モードのコストを計算し、最適な実行モードを選択します。

JoinReorderとAutoMapJoinの最適化ルールを導入し、Volcanoモデルベースのオプティマイザーは検索幅を最大化して最適なプランを取得します。

ルールのホワイトリスト（使用する最適化ルール）とブラックリスト（閉じる最適化ルール）を設定できます。

オプティマイザーは PredicatePushDown 最適化を提供します。その主な目的は、述語フィルタリングをできるだけ早く実行して、後続の操作のデータ量を削減し、パフォーマンスを向上させることです。ただし、次の点に留意する必要があります。

• UDF: オプティマイザーは、UDF をプッシュダウンできるかどうかに制限を設定しました。ユーザーの意図により、そのような機能を恣意的にプッシュダウンすることはありません。これは主に、異なるユーザーによって記述された関数の意味が異なり、一般化できないためです。
• 不確実な関数: オプティマイザーは不確実な関数を恣意的にプッシュダウンしません。たとえば、ユーザーが where 句にサンプル関数を記述し、そのステートメントに Join が含まれている場合、オプティマイザーはそれを TableScan にプッシュダウンしません。
• 暗黙的な型変換: SQL ステートメントを記述するときは、結合キーの暗黙的な型変換を避けるようにしてください。

マップ側でデータを読み取る場合、読み取られたデータのファイル サイズが不均一に分散されているため、一部の MapInstances は大量のデータを読み取って処理しますが、一部の MapInstances はほとんどデータを処理せず、マップ側にロング テールが発生します。

特に上流テーブルファイルのサイズが不均一で、小さなファイルが多く存在するため、現在のテーブルマップエンドで読み取られるデータの分布が不均一になり、ロングテールが発生します。これに対処するには 2 つの方法があります。

• 上流の小さなファイルをマージし、このノード上の小さなファイルのパラメータを調整することで最適化します。
• 「rand()による分配」により、マップ側に分配されたデータはランダム値に従って再分配される。

マップ側のロングテールの根本的な原因は、読み取りファイル ブロックのデータ分散が不均一であることと、UDF 関数のパフォーマンス、結合、集計操作などが組み合わさって、大量のデータを含むマップ インスタンスの読み取りに長い時間がかかることです。開発プロセス中にマップ側でロングテールが発生した場合は、まずマップインスタンスによって読み取られるデータ量を十分に均一にする方法を検討し、次にマップインスタンスを遅くする操作を特定し、最後にこれらの操作をマップ側で完了する必要があるかどうか、および他の段階でより適切に実行できるかどうかを検討します。

データの偏りによって発生するロングテール現象は非常に一般的であり、タスクの実行時間に重大な影響を及ぼします。特に「ダブルll」のような大規模イベント時は、ロングテールが普段以上に深刻です。例えば、大型店舗のPVは一般店舗のPVを大きく上回っています。閲覧ログデータがセラーディメンションテーブルに関連付けられると、セラーIDに従って配布されます。

• MapJoin ソリューション: Join が傾いているときに、入力の 1 つが比較的小さい場合は、MapJoin を使用して傾きを回避できます。ただし、MapJoin の使用は制限されており、Join のスレーブ テーブルが比較的小さい場合にのみ使用できます。
• 結合によりnull値によるロングテールが発生する: null値をランダム値として扱う
• 結合によりホット値によるロングテールが発生します。まずホットキーを抽出し、ホットキーを使用してメインテーブルデータをホットデータと非ホットデータに分割し、個別に処理してから、最後にマージします。

Reduce 側のロングテールの主な理由は、キー データの不均一な分散です。

• ディメンションに従って同じテーブルの異なる列に対して Count Distinct 操作を実行すると、Map 側でデータが拡張され、下流の Join および Reduce リンクでロングテールが発生します。
• Map側が直接集計すると、キー値の分布が不均一になり、Reduce側がホットキーを個別に処理し、その後「UnionAll」を介してマージすることになります。
• 動的パーティションが多すぎると、小さなファイルが多くなりすぎて、Reduce 側で異なる条件を満たすデータが別のパーティションに配置される可能性があります。小さなファイルが多すぎる問題を解決するには、odps.sql.reshuffle.dynamicpt=true を設定します。
• SQL コードに複数の Distinct が同時に出現すると、データが複数回分散され、データが N 倍に拡張されるだけでなく、ロングテール現象も N 倍に拡大します (一般的な Group By)。Distinct を排除するために事前に Group By を使用します。つまり、GroupBy の指標を「元のテーブルのデータ粒度」に合わせてから Join 操作を実行します。出現する Distinct の数が少なく、テーブル内のデータ量が多くなく、テーブル内のデータ分布が比較的均一な場合は、Multi Distinct を使用しない計算効果も許容されます。

3コピーの圧縮ソリューション：アーカイブ圧縮方式、保存比率は約1：3から1：1.5に増加

• データブロックの回復にかかる時間は元の方法よりも長くなり、読み取りパフォーマンスもある程度低下します。
• コールドスタンバイデータとログデータの圧縮ストレージに適用されます。

• 列の格納方法によって各テーブルのデータ分布が異なり、データの挿入順序も異なるため、圧縮効果に大きな差が生じます。したがって、テーブルのデータの再配分を変更し、列のホットスポットを回避することで、一定量のストレージスペースが節約されます。
• データの再配布は主に、distributeby フィールドと sort by フィールドを変更することによって実行されます。
• 一般的に、再分配効果が 15% を超えるテーブルが最適化のために選択されます。

• 最適化項目には、管理されていないテーブル、空のテーブル、過去 62 日間にアクセスされていないテーブル、データ更新やタスクがないテーブル、データ更新やタスクがないテーブル、100GB を超える開発ライブラリ データやアクセスがないテーブル、長期テーブルなどが含まれます。

ライフサイクル管理の基本的な目的は、最小限のストレージ コストで最大のビジネス ニーズを満たし、データの価値を最大化することです。

1. 定期的な削除戦略
2. ポリシーを完全に削除する
3. 永久保存ポリシー
4. エクストリームストレージ戦略
5. コールドデータ管理戦略
6. 増分テーブルマージフルテーブル戦略: トランザクション増分データの場合、注文作成日または注文終了日をパーティションとして使用し、未完了の注文を最大のパーティションに配置します。保存の場合、テーブルには注文のコピーが 1 つだけ保持されます。ユーザーが使用する場合は、パーティション条件を通じて一定期間のデータを照会できます。

1. 履歴データの分類

• PO: トランザクション、ログ、グループ KPI データ、IPO 関連テーブルなど、回復不可能な非常に重要なサブジェクト ドメイン データと非常に重要なアプリケーション データ。
• P1: 重要な業務製品データなど、回復不可能な重要な業務データおよび重要なアプリケーションデータ。
• P2: トランザクションライン ETL によって生成された中間プロセスデータなど、回復可能な重要なビジネスデータと重要なアプリケーションデータ。
• P3: 一部の SNS 製品レポートなど、回復可能な重要でないビジネス データと重要でないアプリケーション データ。

データ コストを、ストレージ コスト、コンピューティング コスト、スキャン コストの 3 つの部分に定義すると、処理チェーンにおけるデータの上流と下流の依存関係を適切に反映できます。

• スキャンコスト: 上流データテーブルのスキャン
• ストレージコスト: 計測データテーブルによって消費されるストレージリソース
• 計算コスト: 測定データ計算処理中のCPU消費量

• 3.5によると、計算支払い、保管支払い、スキャン支払いに分かれています。
• コスト測定により、データ処理リンクにおけるコストをより合理的に評価できます。コストの観点からは、データ処理リンクに複雑な処理、長すぎるリンク、不合理な依存関係などの問題があるかどうかを反映することができ、間接的にデータモデルの最適化を支援し、データ統合の効率を向上させることができます。
• データ使用量課金により、下流ユーザーのデータ使用方法を標準化し、データ使用効率を向上させることで、企業に高品質のデータサービスを提供できます。

業界によってデータ品質を評価するための基準が異なります。 Alibaba は主に、完全性、正確性、一貫性、適時性の 4 つの側面からデータを評価します。

参照: データ品質管理のベストプラクティス 10 選

1. 完全性

データの整合性は、データに対する最も基本的な保証です。

• 整合性: データ記録と情報が完全であるかどうか、また欠落している項目がないかどうかを指します。
• データ損失: 主に、レコードの欠落とレコード内のフィールドの情報の欠落が含まれます。記録の損失: たとえば、トランザクションでは、毎日発行される注文の数が約 100 万件です。ある日突然支払指示件数が 10,000 件に減少した場合、記録が失われる可能性があります。
  レコード内のフィールドが欠落している: たとえば、注文の製品 ID と販売者 ID が存在する必要があり、これらのフィールドの null 値の数は 0 である必要があります。0 より大きい場合、整合性制約に違反します。

2. 正確性

• 正確性：データサマリーに記録された情報やデータが正確であるかどうか、異常な情報や誤った情報がないかどうかを指します。正確性: データ テーブルに記録される情報は、ビジネス プロセスにおける実際の事実と一致している必要があります。
  正確かどうかを判断する方法: チェックポイント監視 - 対応するルールを策定し、ルートに従ってデータを検証し、ルールを満たすデータは正確であるとみなされます。
  例えば、注文の確認済受領金額がマイナスであったり、注文が会社設立前に行われたものであったり、注文に購入者情報が含まれていなかったりする場合は、問題があるはずです。

3. 一貫性

• 一貫性: 一般的に、多くのビジネス データ ウェアハウス ブランチを持つ Alibaba のデータ ウェアハウスなど、スパンの広いデータ ウェアハウス システムに反映されます。同じデータについては一貫性を保証する必要があります。一貫性: これは、複数のビジネス データ ウェアハウス間のパブリック データが各データ ウェアハウスで一貫している必要があることを意味します。
  たとえば、ユーザー ID は、オンライン ビジネス データベース処理からデータ ウェアハウス、そして各消費ノードに至るまで、同じタイプで同じ長さである必要があります。
  そのため、アリババはデータ ウェアハウスを構築する際に、データの一貫性を確保するためにパブリック レイヤーを処理しました。

4. 適時性

• 適時性: データがタイムリーに出力されることを指します。主にデータの適用に反映され、需要者に対してタイムリーに提供されなければなりません。
• 一般的に、意思決定支援アナリストは、データ分析結果を確認するために 3 ～ 5 日待つのではなく、前日のデータを同じ日に確認したいと考えています。そうしないと、データの適時性の価値が失われます。例えば、アリババの「ダブル11」大画面上の取引データは数秒以内に更新されなければならない。

アリババのデータ品質構築システム：

アリババのデータ品質構築システム：

1. 排除シーンの認識

• 機能：消費者シナリオ認識の問題を分析し、解決する。
• 方法: データ資産レベルとメタデータベースのアプリケーション リンクを通じて、消費者シナリオ認識の問題を分析し、解決します。データ資産レベルの決定: アプリケーションの影響に応じてデータ資産のレベルを決定します。
• プロセス: データリンクの系統に従って、資産レベルがデータ生成および処理の各リンクにプッシュアップされ、リンクに含まれるすべてのデータの資産レベルが決定され、各処理リンクの異なる資産レベルに応じて異なる処理方法が採用されます。

2. データ生成と処理の各段階でのチェックポイント検証

主に 2 つの部分でデータ ポイントをチェックします。オンライン システムとオフライン システムのデータ生成および処理の各リンクでデータ ポイントをチェックします。

• オンラインシステム：OLTP（オンライントランザクション処理）システム。オンラインシステム生産・処理の各リンクのチェックポイント検証：1. 異なる資産レベルに応じて、対応する業務システムが変更された場合、下流に変更を通知するかどうかを決定します。
  2. 資産規模の大きい事業については、新たな事業データが発生した場合、それを統計に含めるか否かを承認する必要がある。
• オフラインシステム：OLAP（オンライン分析処理）システム。オフラインシステムの製造および処理の各リンクのチェックポイント検証。主に、コード開発、テスト、リリース、履歴またはエラーデータのフラッシュなどのチェックポイント検証が含まれます。
  コード開発フェーズおよびリリース前テストフェーズでの検証要件は、データ資産のレベルによって異なります。

3. リスクポイントの監視

リスクポイント監視: 主にデータ操作中に発生する可能性のあるデータ品質と適時性の問題を監視します。

リスクポイントは主に次の 2 つの側面で監視されます。

• オンラインデータのリスクポイント監視：主にオンラインシステムの日常的な運用によって生成されるデータに対するビジネスルールを検証します。
  主に「リアルタイムビジネス検知プラットフォーム BCP（Biz Check Platform）」を使用します。
• オフラインデータリスクポイント監視：主にオフラインシステムの日常業務出力データ、データ品質監視、適時性監視を対象とします。
  DQC: データ品質を監視します。
  モサド：データの適時性を監視する。

4. 品質測定

• 品質の測定: 事前測定: DQC カバレッジなど。
  死後測定:
  品質の問題を追跡し、原因、責任者、解決策などを特定し、それらをデータ品質レビューに使用して、同様のインシデントの再発を防ぎます。
  さまざまなレベルの資産に与える影響の度合いに基づいて、品質問題が影響の少ないイベントであるか、影響の大きい障害であるかを判断します。
• 品質スコア: 測定前と測定後のデータに基づくスコア。

5. 品質サポートツール

• 効率性を向上させるためにデータ品質のあらゆる側面を保証する関連ツールがあります。

• 消費シナリオで既知の問題: データの研究開発エンジニアにとって、数百 PB のデータがすべて重要であるかどうかを確認することは困難ですか?それらすべてを保護する必要がありますか?一部のデータは古くなっていますか?すべての要件は正確に品質保証されていますか?
• ソリューション: データ資産レベルのソリューション。
• 出力: データ製品とアプリケーションは資産レベルに分類され、影響に応じてラベルが付けられます。
  データリンク系統に従って、資産レベルがデータ生成および処理の各リンクにプッシュアップされ、リンクに関係するすべてのデータの資産レベルが決定され、タグ付けされます。 (レベル ラベルは対応するデータ製品/アプリケーションと一致します)

1. データ資産レベルの定義

背景: Alibaba には巨大なデータ ウェアハウスがあり、データ サイズは EB レベルに達しています。これほど大量のデータを一般化すると、集中力の欠如や不正確さが必然的に生じます。

5 つのデータ レベルがあり、プロパティごとに重要度が徐々に低下します。

• 破壊的な自然

つまり、データが間違っていると、大きな資産損失、大きな利益損失、そして大きな公共リスクが発生します。

• グローバルプロパティ

つまり、データは直接的または間接的に、グループの事業および業績の評価、重要なプラットフォームの運営と維持、外部データ製品の公開、およびアリババのウェブサイトにおけるユーザーの行動に影響を与えるために使用されます。

• ローカルプロパティ

つまり、データは、社内の一般データ製品や運用/製品レポートに直接的または間接的に使用されます。問題が発生すると、部門や業務ラインに影響が出たり、作業効率が低下したりします。

• 一般的なプロパティ

つまり、データは主に Xiaoer による日常的なデータ分析に使用され、問題が発生しても影響はほとんどないか、まったくありません。

• 未知の性質

データの適用シナリオを明確に説明できない場合は、不明としてマークされます。

1. さまざまなデータ資産レベルは、英語の単語 Asset でマークされます。

破壊性：A1レベル
グローバルな性質：A2レベル。
ローカルプロパティ：A3グレード。
一般的な特性: A4 グレード。
不明なプロパティ: A5 レベル。
重要度: A1 > A2 > A3 > A4 > A5;

データが複数のアプリケーション シナリオに表示される場合は、上位の原則に従います。

2. データ資産レベルの実装方法

解決すべき問題: 膨大な量のデータがある場合、各データにグレードのラベルを付けるにはどうすればよいでしょうか?

データ資産レベルを実装するための方法/手順:

データフロープロセス

• データはビジネス システムから生成され、同期ツールを通じてデータ ウェアハウス システムに入ります。データ ウェアハウスでは、一般的に、クリーニング、処理、統合、アルゴリズム、モデルなどの一連の操作が実行されます。
• 同期ツールを通じて消費するためのデータ製品への出力。

データは、ビジネス システムからデータ ウェアハウス、そしてデータ製品へとテーブルの形式で提示されます。フロー プロセスを次の図に示します。

データ ウェアハウス (Alibaba では MaxCompute プラットフォーム) に同期されるデータはすべてビジネス データベースの元のテーブルであり、主にビジネス ニーズを満たすために使用され、データ製品に直接使用されることはほとんどありません。 （一般的には、ODS レイヤーの全データ量です）

使用されるデータ製品はすべて、データ ウェアハウスによって処理される出力テーブルです。 （要求/報告に応じて処理）

1. データ資産を分類する
2. データフロープロセスに従って、データテーブルとデータ製品またはアプリケーション間の対応を記録するメタデータが確立されます。
3. 影響の度合いに基づいて、データ資産をデータ製品およびアプリケーションのさまざまなレベルに分類します。
4. ラベル付け: メタデータの上流と下流の系統に依存して、消費チェーン全体に特定のタイプのデータ資産のラベルが付けられます (つまり、消費チェーン データのラベル付け)。
リンク: ビジネス システムからデータ製品へのデータ フローのプロセスを指します。

要約:

上記の手順により、データ資産レベルが確認され、メタデータのサポートを必要とするデータごとに異なる重要度レベルが定義されます。

目的: データの正確性とオフライン データとの一貫性を確保する。

1. オンラインビジネスシステム カードポイント認証（データ出力リンク）

• オンラインシステムのデータ処理中のカードポイント検証とは、主にオンラインシステムのデータ生成プロセス中に実行されるカードポイント検証を指します。
• 目的: オフライン データとの一貫性を確保する。
• 背景/問題: オンライン ビジネスは複雑で、常に変化しています。すべての変更はデータの変更をもたらすため、次の 2 つのことを行う必要があります。
  1. データ ウェアハウスは、変化するビジネス展開に適応し、タイムリーにデータの正確性を確保する必要があります。
  2. オンライン業務における変更をオフラインデータウェアハウスに効率的に通知する必要がある。 Alibaba は、ツールと手作業の 2 つのアプローチで上記の 2 つの問題を解決します。ツールはすべてのビジネス変更を自動的にキャプチャする必要があり、開発者もビジネス変更を認識して自動的に通知する必要があります。

2. 道具

公開プラットフォーム: 大きな変更があった場合に通知を送信します。
通知内容: 変更理由、変更ロジック、変更テストレポート、変更時刻など。
データベース プラットフォーム: データベース テーブルの変更通知を送信します。
通知内容: 変更理由、変更ロジック、変更テストレポート、変更時刻など。

3. 出版プラットフォーム

機能: ビジネスに大きな変更が加えられた場合、サブスクリプション公開プロセスがオフライン開発者に提供され、変更の内容を通知します。
注意: ビジネス システムは忙しく、毎日無数の変更がリリースされます。すべてのビジネス変更をオフラインで行う必要はありません。これにより、不必要な無駄が発生し、オンライン ビジネスの反復の効率に影響します。

サブスクリプションコンテンツ: グループ全体の重要な高レベルのデータ資産については、データの処理に影響を与える変更を整理し、これらのコンテンツをサブスクリプションします。
たとえば、財務レポートは当然 A1 レベルの資産です。業務システムのリリース変更により合意された計算基準が変更されるなど、業務システムの変革が財務レポートの計算に影響を与える場合は、オフライン業務に通知する必要があります。オフライン開発者としては、このようなリリース変更情報にも積極的に注意を払う必要があります。

チェックポイント: リリース プラットフォームには通知機能が統合されており、重要なシーンのリリースにチェックポイントを設定します。通知が確認された後にのみリリースを完了できます。

4. データベーステーブルに対する認識を変える

データベースの拡張であれ、ビジネス開発によるテーブル DDL の変更であれ、オフライン開発者に通知する必要があります。

DDL (データ定義言語): データベース スキーマ定義言語。データベースに保存される現実世界のエンティティを記述するために使用される言語。

DDL (データベース スキーマ定義言語) は、SQL 言語 (構造化クエリ言語) のコンポーネントです。

例: CREATE DATABASE (データベースの作成)、CREATE TABLE (テーブルの作成)。

DML (データ操作言語): データ操作言語コマンド。ユーザーはデータベースを照会し、既存のデータベース内のデータを操作できます。

たとえば、挿入、削除、更新、選択などはすべて DML です。

背景/問題: データ ウェアハウスは、データを抽出するときに DataX ツールを使用するため、特定のデータベース テーブルが制限される可能性があります。データベースが拡張または移行された場合、DataX ツールはそれを認識せず、データ抽出エラーや欠落が発生し、一連の下流アプリケーションに影響を及ぼす可能性があります。

解決策: データベース プラットフォームを通じてデータベース テーブルの変更通知を送信します。

5. 開発者

データ資産レベルの上流と下流を接続する必要があります。このプロセスはオンライン開発者にも提供され、どれが重要なコアデータ資産で、どれが一時的に内部分析データとしてのみ使用されるかを開発者が把握できるようにする必要があります。

オンライン開発者の意識向上が必要です。トレーニングを通じて、オフライン データの要件、オフライン データの処理プロセス、データ製品の適用方法をオンライン ビジネス開発者に伝え、データの重要性を認識し、データの価値を理解できるようにします。同時に、エラーの結果も通知される必要があります。これにより、オンライン開発者はビジネス目標を達成する際にデータ目標に注意を払い、ビジネスエンドとデータエンドの間の一貫性を実現できます。

6. オフラインシステムカードポイント検証（データオフライン処理リンク）

背景/質問: オンライン ビジネス システムからデータ ウェアハウス、そしてデータ製品へのデータのプロセスでは、データ ウェアハウス レベルでデータのクリーニングと処理を完了する必要があります。データ処理のために、データ ウェアハウス モデルとデータ ウェアハウス コードが構築されます。データ処理の品質を確保する方法は、オフラインデータウェアハウスのデータ品質を確保するための重要な部分です。

目的：データ処理の品質（主にデータの精度）を確保する。

チェックポイントは2つの段階でチェックされます。

7. コードを送信する際のカードチェック

背景/理由：データの研究開発担当者は異なる品質とコーディング能力を持っているため、コードの品質を効率的に保証することは困難です。

解決策：オンラインで送信されたすべてのコードをスキャンしてリスクポイントを抽出するために、コードスキャンツールであるSQLSCANを開発します。

チェック方法：コードスキャンツールSQLSCANを使用してコードをスキャンし、リスクポイントを抽出します。

8. タスクがオンラインでリリースされたときのチェックポイント検証

オンラインデータの精度を確保するには、すべての変更をオンライン環境にリリースする前にオフラインでテストする必要があります。このリリースは、オンラインテストが通過した後にのみ成功したと見なされます。

チェックポイント方法：オンラインでリリースされる前後にタスク（変更されたビジネスを参照）をテストします。

9. プレリリーステスト：主にコードレビューと回帰テストが含まれます。

• コードレビュー：コードをレビューすることにより、コードの品質を改善するプロセスです。
• 回帰テスト：古いコードを変更した後の再テストを指し、変更が新しいエラーや他のコードにエラーが発生していないことを確認します。

回帰テストの目的：
新しいロジックの正しさを確保します。
この変更以外の論理が影響を受けないことを確認してください。

注：より高い資産レベルのタスクの変更の場合、反対側で回帰テストが完了した後にのみ強力なブロッキングが使用され、リリースが許可されます。

10. リリース後のテスト：実際の環境でのドライランテストまたはランニングテスト。

• ドライランテスト：

オンライン環境とオフライン環境間の矛盾によって引き起こされる構文エラーを回避するために、コードを実行せず、実行計画のみを実行します。

• 実際の環境操作テスト：

実際のデータでテストします。

• ノードの変更またはデータの更新前に通知を変更します

通知コンテンツ：理由の変更、ロジックの変更、テストレポートの変更、変更時間など。
プロセス：
通知センターを使用して、下流のユーザーに変更理由、変更ロジック、変更テストレポート、変更時間などを自動的に通知します。ダウンストリームユーザーが変更に異議を唱えないと、変更は合意された時間にリリースされ、ダウンストリームユーザーへの変更の影響が最小限に抑えられます。

リスクポイントモニタリング：主に、データの日々の操作で発生する可能性のあるリスクを監視し、アラームメカニズムを設定することを指します。
主に、オンラインデータとオフラインデータ操作リスクポイント監視が含まれます。

目的：データの正確性を確保する。

1。オンラインデータリスクポイント監視

• 目的：オンラインビジネスシステムによって生成された汚れたデータを削減し、データの精度を確保する。
  さらに、誤った情報に関するユーザーの苦情を減らし、オフラインデータエラーのロールバックを減らします。
• BCP：Alibabaのリアルタイムビジネス検出プラットフォーム。
• アイデア/監視プロセス：各ビジネスシステムでは、ビジネスプロセスが完了し、データがデータベースに保存されると、BCPは同じデータを購読し、事前に設定されたビジネスルールに従ってBCPシステムで論理検証を実行します。検証が失敗した場合、それはアラームの形で開示され、規則サブスクライバーに与えられてデータ校正を完了します。
• BCP検証プロセス：
  データソースの取得：ユーザーは、BCPプラットフォームのデータソースを購読し、検証する必要があるデータソースを取得します。
  ルールの作成：購読されたデータソース、つまり検証ロジックのルールを作成します。
• ルール/ロジック：それらは非常に重要であり、検証の中核です。これらのルールが合格した場合にのみ、レコードを正しいと見なすことができます。
  たとえば、「注文配置時間」を確認します。ロジック：注文配置時間は、間違いなく時刻よりも大きくなく、タオバオが設立された時期よりも少なくなります。

アラームの構成：異なるルールに対して異なるアラームフォームを構成します。

注：BCPの構成と操作コストが高いため、主にデータ資産レベルに基づいて監視されます。

• オフラインデータリスクポイント監視

オフラインデータのリスクポイント監視には、主にデータの精度とデータ出力の適時性の監視が含まれます。

• データの精度監視

データの精度はデータ品質の鍵であるため、データの精度がデータ品質の最優先事項になり、すべてのオフラインシステム処理の最初の保証因子です。

方法：データの精度はDQCを介して監視されました。

DQC（データ品質センター）：データの品質に焦点を当て、データの品質検証ルールを構成することにより、データ処理タスク中にデータの品質を自動的に監視します。

注：データの品質を監視し、アラームを発行しても、データ出力自体を処理しないため、アラームの受信者はそれを処理する方法を判断して決定する必要があります。

監視方法：データ品質検査ルールを構成することにより、データ処理タスク中に自動監視が実行されます。

監視ルール：

強力なルール：タスクの実行をブロックします。

タスクを失敗した状態に設定すると、その下流のタスクは実行されません。

弱いルール：タスクの実行をブロックしないでください。

一般的なDQCモニタリングルール：主キーモニタリング、テーブルデータのボリュームと変動監視、重要なフィールドの非ヌル監視、重要な列挙フィールドの個別の価値監視、インジケータ値の変動監視、ビジネスルール監視など。

ルール構成：データアセットレベルに基づいて監視ルールを決定します。

DQC Checkは実際にSQLタスクを実行しますが、このタスクはメインタスクにネストされています。チェックポイントが多すぎると、全体的なパフォーマンスが影響を受けます。したがって、ルールの構成は依然としてデータ資産レベルに依存します。

注：さまざまなビジネスにはビジネスルールが適用されます。これらのルールは、データ製品または消費者のビジネスニーズから派生しています。それらは消費者ノードで構成され、その後、ルールの影響を最小限に抑えるために監視するためにオフラインシステムの開始点にプッシュされます。

• データの適時性

データの正確性を確保することに基づいて、データがタイムリーにサービスを提供できるようにすることが必要です。それ以外の場合、データの値は大幅に削減されます。

アリババのオフラインタスクのほとんど：

時間間隔は通常1日で、「毎日のタスク」と呼ばれます。毎日のタスクの場合、データ製品またはデータ決定レポートは、通常、毎日9:00またはさらに早く作成する必要があります。

前日のデータの完全性を確保するために、毎日のタスクは真夜中から実行され始めます。コンピューティングおよび処理タスクはすべて夜間実行されるため、毎日のデータを時間通りに生成できるようにするために、一連のアラームと優先度の設定が必要であるため、重要なタスクが優先され、正しく生成されます。

重要なタスク：資産レベルが高いビジネス。

• タスクの優先順位

マップタスクとタスクの削減の場合、スケジューリングはツリー構造（再ノードツリー）です。リーフノード（Relnodeノード）の優先度が構成されている場合、この優先度はすべての上流ノードに渡されるため、優先度設定はリーフノードに与えられ、リーフノードは多くの場合、ビジネスにサービスを提供する消費ノードです。

優先順位を設定する：最初に、ビジネスの資産レベルを決定します。高レベルのサービスに対応する消費ノードは自然に優先順位に割り当てられますが、一般的なサービスは低優先度に対応して、高レベルのサービスが時間通りに出力されるようにします。

• タスクアラーム

タスクアラームは優先度に似ており、葉のノードにも渡されます。

操作中にタスクがエラーを発生させることは避けられません。したがって、タスクを効率的かつスムーズに実行できるようにするために、監視およびアラームシステムがあります。優先度の高いタスクの場合、タスクにエラーがあることがわかった場合、または出力の遅延がある可能性がある場合は、タスクとビジネスオーナーに呼び出されなければなりません。

Mossad：Alibabaによって独立して開発された監視および警報システム。

• モサド

Mossad：オフラインタスクの監視およびアラームシステム。これは、データの操作とメンテナンスのための不可欠な保証ツールです。

オフラインタスクの操作に基づいて、アラートする、いつ警告する、どのように警告するか、どのように警告するか、誰が警告するかなどを決定するかどうかを決定します。

2つの主な機能：強力な保護監視とカスタムアラーム。

強力な保護監視

強力なセキュリティ監視は、Mossadのコア機能です。運用とメンテナンスの目標、つまりビジネスセキュリティを中心に設計されています。ビジネス警告時間が脅かされている限り、モサドは間違いなく関連する人員に警告します。

強力なセキュリティ監視には主に含まれています。

監視範囲：ビジネスを強く保証するタスクを設定し、すべての上流のタスクが監視されます。

監視の例外：タスクエラー、タスクの減速、および早期警告ビジネスの遅延。

アラームオブジェクト：デフォルトはタスク所有者であり、特定の人にデューティテーブルを設定することもできます。

いつ警告するか：ビジネスが設定した早期警告時間に基づいていつ警告するかを決定する。

ビジネス遅延警告とエラーアラームはすべて、「出力警告時間」に基づいて判断されます。

出力警告時間：Mossadは、出力警告時間として実行するために、過去7日間のすべてのタスクの平均時間に基づいて、現在のビジネスに費やされたおおよその時間を計算します。

アラーム方法：ビジネスの重要な緊急性に基づいて、電話、テキストメッセージ、Wangwang、および電子メールアラートをサポートします。

例：ビジネスコンサルタントビジネス（早期警告ビジネスの遅延）

資産レベルと要件：定義された資産レベルはA2であり、出力データは午前9時に棚に与えられる必要があります。

設定：ビジネスコンサルタントビジネスの強力な保証監視を定義します。ビジネスの出力時間は9:00で、ビジネス警告時間は7:00です。

ここでの警告時間は、Mossadが現在のビジネスの出力時間が警告時間を超えることを監視することを意味します。

たとえば、Mossadは、ビジネスコンサルタントの出力時間が7:30に達し、電話アラームが発生し、勤務中の職員が出力を加速する方法を判断すると推測します。出力時間計算（早期警告判断、つまり出力遅延判断）：モサドは、過去7日間の現在のビジネスのすべてのタスクの平均時間に基づいて計算されます。誤判断の可能性はありますが、全体的には非常に正確であり、受け入れられます。

• カスタム監視

カスタム監視は、Mossadの比較的軽量監視機能です。ユーザーは、主に以下を含める必要に応じて構成できます。

1. エラーアラーム：アプリケーション、ビジネス、およびタスクの3つの監視オブジェクトに基づいて、エラーアラーム構成を実行できます。監視オブジェクトが故障した場合、アラームは個人/所有者/義務テーブルに与えられます。
2. 完全なアラーム：アプリケーション、ビジネス、およびタスクの3つの監視オブジェクトに従って、完了アラーム構成を実行できます。監視オブジェクトが完了すると、アラームが個人/所有者/義務テーブルに与えられます。
3. 未完成のアラーム：未完成のアラーム構成は、アプリケーション、ビジネス、およびタスクの3つの監視オブジェクトに基づいて実行できます。監視オブジェクトが完了していない場合、アラームは個人/所有者/義務テーブルに与えられます。
4. 周期アラーム：特定の期間の1時間ごとのタスクの場合、特定の時間に完了していない場合、人/所有者/義務テーブルにアラームが与えられます。
5. タイムアウトアラーム：タイムアウトアラーム構成は、タスクの実行時間に従って実行されます。タスクが指定された時間を超えて実行される場合、アラームは個人/所有者/義務テーブルに与えられます。

• ガントトモサドのサービス

ビジネスの運営を考慮して、モサドは1日の重要なパス、つまりビジネスを完了するための最も遅いタスクのリンクマップを提供します。各ビジネスには何千ものタスクがある可能性があるため、この重要なパスはビジネスリンクの最適化にとって非常に重要です。

データウェアハウスのデータ品質を確保するための多くのソリューションがあります。これらのソリューションの利点と短所を評価するには、一連の測定指標が必要です。

• データ品質の夜レート

一般に、データウェアハウスの操作タスクは夜間に実行されます。問題が発生したら、勤務中のスタッフは夜に起きて対処する必要があります。

開始された夜の数：データ品質構造の完全性を測定するためのインジケーターとして毎月開始された夜数を使用します。

• データ品質イベント

データ品質イベント：すべてのデータ品質の問題を記録します。

データ品質の問題ごとに、データ品質イベントが記録されます。

関数：データ自体の品質、およびデータリンクの上流と下流の品質を測定するために使用され、データの品質の重要なメトリックです。

1. データ品質の問題の処理についてフォローアップするために使用されます。
2. データ品質の理由を要約して分析するために使用されます。
3. 欠落を確認し、データ品質の理由に基づいてリークを入力します。データの問題の理由を見つけるだけでなく、同様の問題のフォローアップ予防計画も提供する必要があります。

• データ品質障害システム

深刻なデータ品質イベントの場合、障害にエスカレートされます。

失敗：問題によって引き起こされる深刻な影響を指し、それが資産の損失または広報のリスクを会社にもたらしました。

背景：コレクションから最終的なデータの消費まで、リンク全体が多数のシステムを通過する必要があります。リンクに問題がある場合、データの出力に影響します。したがって、チームを結び付け、同じ目標を持ち、共同力を形成するためにはメカニズムが必要です。この文脈で断層システムが現れました。

障害システムでは、障害が発生すると、障害システムが渡され、関連するチームは、影響を排除するためにできるだけ早く問題をフォローアップして解決する必要があります。

1. 障害の定義

まず、重要なビジネスデータを特定し、システムに登録し、担当者、担当者、ビジネスパーソン、データアプリケーションシナリオ、遅延またはエラーの影響、資産の損失が発生するかどうかなど、関連するビジネス状況を記入します。完了後、このデータのタスクはプラットフォームベースラインに配置されます。遅延またはエラーが遅れたら、障害チケットが自動的に生成され、障害が発生します。

2. 障害レベル

障害が発生した後、障害レベルは、障害の期間、顧客の苦情、資本損失などの特定の基準に基づいて判断され、障害はP1〜P4に従って等級付けされます。各チームには障害スコアの概念があり、今年の運用とメンテナンス効果は、年末の障害スコアに基づいて判断されます。

3. トラブルシューティング

障害が発生した後、障害の原因をすばやく特定し、それを迅速に解決して影響を排除する必要があります。

障害を処理する過程で、関連当事者は、ビジネスへの影響を最小限に抑えるために、障害の進捗状況を通知しようとします。

4. 障害レビュー

障害のレビュー：つまり、障害の原因を分析し、処理プロセスを確認し、後続の解決のためのアクションを形成し、障害の責任を割り当てるためにテキスト形式で詳細に記録され、一般に責任はその人に起因します。

注：障害責任の決定は、個人を罰することではなく、問題が再び起こらないように障害のレビューを通じて解決策を形成することです。