ビッグデータの運用と管理（アリのビッグデータへの道：データ管理のまとめ）

アリババのビッグデータへの道のり：データ管理の概要

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

メタデータは、その用途に応じて、テクニカル メタデータとビジネス メタデータの 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 つの側面からデータを評価します。

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 プラットフォーム上のデータ ソースをサブスクライブし、検証する必要があるデータ ソースを取得します。
  ルールの記述: サブスクライブされたデータ ソースのルール、つまり検証ロジックを記述します。
• ルール/ロジック: これらは非常に重要であり、検証の中核となります。これらのルールが満たされた場合にのみ、記録は正しいとみなされます。
  たとえば、「注文の配置時間」を確認します。ロジック：注文の配置時間は、必ず当日の時間よりも長くなったり、Taobao が設立された時間よりも短くなったりすることはありません。

アラームを構成する: ルールごとに異なるアラーム フォームを構成します。

注: BCP は構成および運用コストが高いため、主にデータ資産レベルに基づいて監視されます。

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

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

• データ精度の監視

データの正確さはデータ品質の鍵となるため、データの正確さはデータ品質の最優先事項となり、すべてのオフライン システム処理の第一の保証要素となります。

方法: データの正確性は DQC を通じて監視されました。

DQC (データ品質センター): データ品質に重点を置き、データ品質検証ルールを構成することで、データ処理タスク中にデータ品質を自動的に監視します。

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

監視方法: データ品質検査ルールを設定することで、データ処理タスク中に自動監視が実行されます。

監視ルール:

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

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

弱いルール: 警告のみ行い、タスクの実行をブロックしません。

一般的な DQC 監視ルール: 主キー監視、テーブル データ量と変動監視、重要なフィールドの非 null 監視、重要な列挙フィールドの離散値監視、インジケータ値の変動監視、ビジネス ルール監視など。

ルール構成: データ資産レベルに基づいて監視ルールを決定します。

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

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

• データの適時性

データの正確性を確保することを前提として、データがタイムリーにサービスを提供できることをさらに保証する必要があります。そうしないと、データの価値が大幅に低下するか、まったく価値がなくなる可能性があります。

Alibaba のオフラインタスクのほとんど:

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

前日のデータの整合性を確保するため、毎日のタスクは深夜から実行を開始します。計算および処理タスクはすべて夜間に実行されるため、毎日のデータが時間どおりに生成され、重要なタスクが優先され、正しく生成されるようにするには、一連のアラームと優先順位の設定が必要です。

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

• タスクの優先度

Map および Reduce タスクの場合、スケジュールはツリー構造 (RelNode ツリー) になります。リーフ ノード (RelNode ノード) の優先度が設定されると、この優先度はすべての上流ノードに渡されます。そのため、優先順位の設定はリーフノードに与えられ、リーフノードはサービスビジネスの消費者ノードであることが多いです。

優先順位を設定する: まず、ビジネスの資産レベルを決定します。高レベルのビジネスに対応するコンシューマー ノードは当然高い優先度で構成されますが、高レベルのビジネスが時間どおりに生成されるように、一般的なビジネスには低い優先度が割り当てられます。

• ミッションアラーム

タスクアラームは優先度に似ており、リーフノードを通じて送信されます。

運用中にタスクが失敗する可能性は避けられません。したがって、タスクが効率的かつスムーズに実行されるようにするには、監視および警報システムが必要です。優先度の高いタスクの場合、タスク エラーまたは出力遅延の可能性が見つかったら、タスクとビジネス オーナーにアラームを送信する必要があります。

モサド：アリが独自に開発した監視・警報システム。

• モサド

Mossad: オフラインタスクの監視および警報システム。データの運用と保守に欠かせないツール。

オフライン タスクの実行ステータスに基づいて、アラームを発行するかどうか、いつ発行するか、どのように発行するか、誰にアラームを発行するかをリアルタイムで決定します。

2 つの主な機能: 強力なセキュリティ監視とカスタマイズされたアラーム。

強力なセキュリティ監視

強力なセキュリティ監視はモサドの中核機能であり、運用と保守の目標、つまりビジネスセキュリティのみを目的として設計されています。警告時間内に事業が脅かされる限り、モサドは必ず関係者に警報を発するでしょう。

強力なセキュリティ監視には主に次のものが含まれます。

監視範囲：強力な保証業務を設定するタスクとすべての上流タスクを監視します。

異常の監視: タスク エラー、タスクの速度低下、早期警告サービス遅延。

アラーム対象: デフォルトはタスク所有者ですが、特定の人物に担当リストを設定することもできます。

いつ警報を発するか: 企業が設定した警告時間に基づいて、いつ警報を発するかを決定します。

業務遅延警告とエラーアラームは、どちらも「出力警告時間」に基づいて決定されます。

出力警告時間: Mossad は、過去 7 日間の現在の業務のすべてのタスクの平均実行時間に基づいて、現在の業務のおおよその時間を出力警告時間として計算します。

アラーム方法: 業務の重要度と緊急度に応じて、電話、SMS、Wangwang、または電子メールでアラームを送信できます。

例：ビジネスアドバイザーサービス（業務遅延の警告）

資産レベルと要件: 定義されている資産レベルは A2 であり、出力データが午前 9 時にリストに表示可能である必要があります。

設定: ビジネス アドバイザー ビジネスに対して、ビジネス出力時間を 9:00、ビジネス警告時間を 7:00 として、強力なセキュリティ監視を定義します。

ここでの警告時間とは、モサドが現在の業務の出力時間が警告時間を超えていることを監視すると、当直中の人員に電話して警告することを意味します。

たとえば、モサドはビジネスアドバイザーの出力時間が 7:30 になると予測し、電話アラームを発し、当直担当者が出力を早める方法を決定します。出力時間推定（早期警告判定、つまり出力遅延判定）：Mossad は、過去 7 日間の現在の業務におけるすべてのタスクの平均実行時間に基づいて推定します。誤判断の可能性はあるものの、一般的には非常に正確で許容できるものである。

• カスタム監視

カスタム モニタリングは、Mossad の比較的軽量なモニタリング機能です。ユーザーは、主に以下の点を含め、自分のニーズに応じて設定できます。

1. エラーアラーム: アプリケーション、ビジネス、タスクの 3 つの監視オブジェクトに基づいてエラーアラームを設定できます。監視対象に異常が発生した場合、担当者/所有者/勤務スケジュールに警報が通知されます。
2. 完了アラーム: アプリケーション、ビジネス、タスクの 3 つの監視オブジェクトに基づいて、完了ステータス アラームを設定できます。監視対象が完了すると、担当者/所有者/勤務スケジュールにアラームが通知されます。
3. 未完了アラーム: アプリケーション、ビジネス、タスクの 3 つの監視対象に基づいて、未完了アラームの設定を行うことができます。監視対象が完了していない場合は、担当者/所有者/勤務スケジュールにアラームが送信されます。
4. 定期アラーム: 一定期間内の時間単位のタスクが特定の時間に完了しない場合は、担当者/所有者/勤務スケジュールにアラームが送信されます。
5. タイムアウトアラーム: タスクの実行時間に基づいてタイムアウトアラームを設定します。タスクが指定された時間より長く実行されると、担当者/所有者/勤務スケジュールにアラームが送信されます。

• モサド ガントチャート サービス

モサドは、事業の運営状況に基づいて、1日のクリティカルパス、つまり事業を完了するための最も遅いタスクチェーン図を提供します。各ビジネスには上流に何千ものタスクがある可能性があるため、このクリティカルパスはビジネス チェーンの最適化にとって非常に重要です。

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

• データ品質の翌日レート

通常、データ ウェアハウスのタスクは夜間に実行されます。問題が発生すると、当直の担当者は夜中に起きて対処する必要があります。

夜間覚醒率: 月ごとの夜間覚醒回数は、データ品質構築の完璧さを測る指標として使用されます。

• データ品質インシデント

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

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

機能: データ自体の品質だけでなく、アップストリームおよびダウンストリームのデータ リンクの品質を測定するために使用されます。これはデータ品質の重要な指標です。

1. データ品質の問題をフォローアップするプロセス。
2. データ品質の理由を要約および分析するために使用されます。
3. データ品質上の理由に基づいてギャップをチェックし、埋めます。データの問題の原因を見つけ出し、同様の問題に対するフォローアップの予防計画を提供します。

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

重大なデータ品質インシデントの場合は、障害にアップグレードされます。

失敗: 重大な影響を及ぼし、企業に資産の損失や広報上のリスクをもたらした問題を指します。

背景: データ収集から最終消費まで、チェーン全体で数十のシステムを経由する必要があります。いずれかのリンクに問題があると、データの出力に影響します。したがって、さまざまなチームを結び付けて共通の目標を形成し、協力して作業するためのメカニズムが必要です。断層システムはこのような背景から誕生しました。

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

1. 障害の定義

まず、重要なビジネスデータを識別し、システムに登録します。技術担当者、業務担当者、データ適用シナリオ、遅延やエラーの影響、資産損失の発生の有無など、関連する業務情報を入力します。完了すると、この部分のデータのタスクがプラットフォーム ベースラインに添付されます。遅延やエラーが発生すると、障害を形成するために障害チケットが自動的に生成されます。

2. 失敗レベル

障害が発生すると、障害の持続時間、顧客からの苦情、経済的損失などの特定の基準に基づいて障害レベルが決定されます。障害は P1 から P4 まで等級分けされます。各チームには障害点の概念があり、年末には障害点に基づいて年間の運用・保守の成果が判断されます。

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

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

トラブルシューティングの際は、トラブルシューティングの進行状況を関係者に通知し、業務への影響を最小限に抑えるよう努めます。

4. 障害レビュー

障害レビュー: 障害の原因の分析、処理プロセスのレビュー、およびその後の解決策の策定が含まれます。これらはすべて書面で詳細に記録され、過失の責任は通常特定の人物に割り当てられます。