Yifupayクラウドネイティブデータ開発およびガバナンスプラットフォームの実践

この共有セッションは 4 つのパートに分かれています。最初の部分では、Yifuzhi 社とその事業の概要、およびデータ ガバナンス プロセスで直面するシナリオ、目標、課題について説明します。第 2 部では、タスク開発とデュアル環境の展開および運用を含むデータ開発およびガバナンス プラットフォームについて説明します。第 3 部では、データ プラットフォームのアーキテクチャを紹介し、システム アーキテクチャ、スケジューリング エンジンの選択、データ バス、品質監視とリソースの分離、コンピューティングの最適化に関する実践的な経験を共有します。第 4 部では、今後直面する問題や最適化できる領域について全員で議論し、より良いプラットフォームの目標を展望します。

1. YiPayの会社と事業の紹介

天一電子商取引有限公司（以下、「天一支払」）は、中国電信グループ株式会社の傘下企業であり、国有資産監督管理委員会の「双百改革」と国家発展改革委員会の第四次混合所有制改革の「双パイロット」企業であり、「双パイロット」企業の中で唯一の金融テクノロジー企業である。同社はYiPay APPをキャリアとして利用し、月間アクティブユーザー7,000万人に公共福祉支払い、消費者ショッピング、財務管理などのサービスを提供しています。ブロックチェーン、クラウドコンピューティング、ビッグデータ、人工知能などのテクノロジーを活用し、1,000 万を超えるオフライン商店と 170 社を超える有名なオンライン電子商取引企業を支援しています。 Yifuzhiは「監督に応え、民生に奉仕し、資源を共有し、協力とウィンウィン」という理念を堅持し、「開放性、安全性、利便性」という製品の核心的な強みに焦点を当て、サービス投資と製品のアップグレードを通じてニーズを満たす管理業務システムの構築、コミュニケーションとビジネス慣行の統合を通じて業界各社のデジタル変革の推進に取り組んでいます。

データ開発およびガバナンス プラットフォームを構築するためのビジネス シナリオ: データ ウェアハウスのニーズへの対応、さまざまなビジネス部門の迅速な開発、オフライン コンピューティング、データ統合、リアルタイム データ開発、データ サービス、およびデータ開発とガバナンスの効率を向上させるその他の機能。

私たちの目標は、データ統合、オフラインコンピューティング、リアルタイムコンピューティング、データサービスを統合したパイオニアデータ開発およびガバナンスプラットフォームを構築し、データ開発者の研究開発ニーズをワンストップで満たす統合開発プラットフォームを提供することです。

私たちが直面している課題は、膨大なデータ処理、同時リクエスト数の増加、低レイテンシ、ビジネスの多様性、シナリオの複雑さです。

2. データ開発およびガバナンスプラットフォームの概要

1. タスク開発プロセス

タスク開発では、まずビジネスフローを作成する必要があります。ここでのビジネスフロー（フロー）は、タスクのグループを管理するために使用されます。タスクは主にデータ ウェアハウスのオフライン スケジューリングであり、データの統合、公開、SparkSQL オフライン タスクが含まれます。タスク スクリプトを開発した後、操作の優先キュー、タスクの相互依存性、操作パラメータなど、タスクのコア パラメータを設定します。パラメータを設定したら、タスクの実行をテストします。テストが正常に実行されたら、タスクをオンラインにすることができます。ここでは、ビジネスプロセス（フロー）単位でタスクが起動されます。起動後、タスクレビューのために管理者に引き渡されます。レビューでは主にタスクのリソース消費量、並列性、開発仕様などをチェックします。レビューに合格すると本番環境にリリースされます。実稼働環境にリリースされた後、毎日のスケジュール設定のためにスケジューリング エンジンに送信されます。

データ開発には、キャンバスでの新しいビジネス プロセスの作成、関連するタスク ノードのキャンバスへのドラッグ、タスク ノードの依存関係の構成などの機能が含まれます。業務分類に応じて、次の 5 つのタスク タイプを含む一連のタスク開発機能が提供されます。

① データ同期：Oracle、OceanBase、MySQL、SFTP、Hbaseなどのデータアクセスと公開を含む。

② Sparkタスク：SparkSQLオフラインコンピューティング。

③機械学習：AIモデルタスク

④ Kylin タスク: Kylin データ ウェアハウス ジョブをスケジュールします。

⑤ タスクのトリガー：外部プラットフォームのインターフェースが満たされ、データガバナンスプラットフォームがトリガーされ、外部システムがクラウド選択データをプッシュしたり、その他のデータ処理関連の作業などのデータタスクが開始されます。

SparkSQL タスク開発エディター ページには、次の機能が含まれています。

① 新しい SparkSQL タスクを作成する: ドラッグ アンド ドロップで SparkSQL タスク ノードを作成し、スクリプトを記述します。編集後、構文検証を使用して SQL 書き込みエラーを表示できます。

② 単一実行: Spark タスクは実行のためにクラスターに送信されます。テストに合格したら、送信して最終的に保存できます。タスクが確認された後、実行のために本番環境にデプロイできます。

③ タスク依存関係の自動構成: システムは、SQL 構文を使用してタスク ソース テーブルを自動的に解析します。データ ウェアハウスは、統一された開発仕様に従います。各タスクには固有の宛先テーブルがあり、タスク間の細分性を最も細かく設定して管理を容易にします。ソース テーブルは複数存在する場合があります。対応するソース テーブルは、SQL 解析によって取得されます。タスク解析により、上流ノードと下流ノードが検出され、エッジ関係が自動的に生成されます。

④ 依存関係を手動で追加する: タスクを手動で検索し、依存関係に追加します。

⑤ SparkSQL権限分析：メタデータから設定されたユーザー関連の権限に従って、ユーザーの対応するデータベーステーブル操作権限が実行されます。

⑥ 血縁関係：図は、タスクフロー下にあるすべてのタスクのクロスフロー血縁関係を示します。

初期のデータ開発およびガバナンス プラットフォームは単一環境のアーキテクチャでしたが、プラットフォーム タスクが開始されると、時折問題が発生しました。たとえば、オンライン タスクが緊急に修復されて起動されたときに、SQL スクリプトが確認されていなかったため、タスクが過剰なリソースを占有していました。非標準のSQL関連コードなどの問題もありました。そのため、スクリプト プロセスの標準化を解決するために、デュアル環境起動プロセスが使用されました。

すべてのフローには、開発環境に 1 つのコピーと本番環境に 1 つのコピーがあります。ミラーリング操作により、各フローおよびタスクには対応するコード識別子が設定されます。唯一の違いは、開発環境の Flow のコードに dev プレフィックスが付いていることです。たとえば、開発環境のタスク コードが dev0001 の場合、本番環境のタスク コードは 0001 に対応し、システムとユーザーが区別しやすくなります。

スケジューリング レベルでは、この区別により、基盤となるスケジューリング エンジンとデータ ウェアハウス レイヤーが上位レイヤーの変更を感知するのを防ぐことができます。たとえば、開発環境のフローでは関連タスクが実行されており、対応する本番タスクも実行されています。ただし、固有のタスク コードで区別することで、これらのタスクを両方の環境で同時に実行し、運用環境では通常のスケジュールで実行し、開発環境では並行して開発を行うことができます。

基礎となる設計レベルでは、プレフィックスを削除することで開発環境を運用環境のタスクにマッピングできます。同時に、アプリケーション層で統合ストレージを実現できます。つまり、本番環境と開発環境のフローおよびタスクをそれぞれフロー テーブルとタスク テーブルに保存できるため、設計が簡素化され、基盤となるデータ ウェアハウスおよびスケジューリング レイヤーが意識する必要がなくなります。

バージョン管理:データ ウェアハウス開発スクリプトのバージョン バックトラッキング、タスク間の依存関係、ビジネス プロセス構成、スケジュール変更のニーズを満たすために、すべてのタスクとフローでバージョン管理が実行され、その後、本番環境にリリースされ、開発環境に同期されます。リリースおよびロールバックには任意のバージョンを選択できます。

3. プラットフォーム技術アーキテクチャの実践

1. 全体的なアーキテクチャの概要

上の図はシステム全体のアーキテクチャを示しています。上部のモジュールはアプリケーション層、下部のモジュールはスケジューリング層です。

構成管理: ビジネス スペース管理、メンバー管理、ライブラリ マッピング管理が含まれます。スペースとメンバーの管理は、部門担当者間でリソースとデータ権限を分離することです。ライブラリ マッピング管理は、ソース ライブラリと宛先ライブラリ間のマッピング関係を解決するのに適しています。たとえば、データにアクセスするときに、そのデータがどのウェアハウスに分類されるかを構成によって管理できます。

データ開発: データ統合、オフライン開発、データ公開、リアルタイム ジョブ、FlinkSQL インジケーターの開発が含まれます。

タスク管理: ビジネス プロセス管理、タスクのオンラインおよびオフライン、タスクの再実行と再番号付け操作、およびタスク系統の依存関係管理が含まれます。

外部サービス: メタデータ機能。主に、ユーザーがテーブルを作成した後にテーブルの詳細を表示し、そこからすべてのテーブル、ライブラリ、および権限を取得するために使用されます。ユーザーセンター機能は、主に関連プラットフォームのユーザーアカウント管理と各サブプラットフォームの権限管理を構成するために使用されます。 AI サービス機能は、主に機械学習モデルのタスクを管理し、インターフェースを介して機械学習サービスを呼び出すために使用されます。品質操作機能は、主にデータタスク開発が完了した後にデータの品質を検証するために使用されます。

スケジューリング層: Airflow はスケジューリングのコア モジュールです。オレンジ色の部分は、タスク管理やカスタム Operator (SparkSQL およびデータ交換関連のタスク送信をサポート) など、Airflow 拡張機能を中心に開発されたコンポーネントです。

2. スケジューリングエンジン

スケジューリング エンジンに関しては、最初の比較には Zeus、Airflow、Azkaban が含まれていました。 Zeus は分散スケジューリングをサポートしていますが、Hadoop、Spark、データ交換のスケジューリングは完璧ではなく、コミュニティの活動は衰退しています。 Airflow の Python 拡張機能は便利で、機能が充実し安定しており、2.X はマルチマスター分散スケジューリングをサポートし、コミュニティも活発です。 Azkaban は Java で開発されていますが、タスクのスケジュール機能は比較的シンプルです。最終的に、生産オフライン スケジューリング エンジンとして Airflow1.10 が選択されました (テクノロジが選択されたとき、2.x バージョンはまだ安定していませんでした)。

Airflow は現在、Web インターフェース上で一部の管理操作のみを提供しており、関連する REST インターフェースは提供していません。ユーザーは Airflow の DAG ファイルを DAG ディレクトリに配置し、スケジューラは対応する DAG メタデータをスキャンして MetaData データベースに保存します。 DAG は上位アプリケーションのビジネス プロセス フローに対応し、タスクのグループを管理します。 Workers は、スケーラビリティと複数ノードの分散展開をサポートします。本番環境では、Airflow は主に CalaryExector を使用したデプロイメントに適しており、ローカル環境ではタスクのスケジュール設定に LocalExector を使用します。 Yifupay の運用では、タスクのスケジュール パフォーマンスを高速化するために、Redis が Celery タスク キャッシュ キューとして使用されます。

Airflow 1.10 では、比較的少数の WebAPI が提供されます。ネイティブ関数では、DAG ファイルの保存に Git または Ceph が使用されます。ユーザーは自分で DAG ファイルを生成し、クラスター ノードに配置する必要があります。プロセスの観点から見ると、対応するコンポーネントを導入すると複雑さが増します。ユーザー側は対応する DAG の生成に関与する必要があり、上位レベルのアプリケーションは DAG を生成してビジネス プロセスを管理する必要があります。これらの問題を解決するために、DAG および DAG タスク メタデータの生成を管理するために、Rest インターフェイス機能が拡張および開発されました。上のアプリケーション層は、それを Rest パラメータに渡して、基礎となるスケジューリング エンジンの関連作業を保護します。 DAG ファイルが対応するスケジューラ ノードとワーカー ノードにアップロードされると、スケジューラは 5 分周期でそれをスキャンします。タスク DAG がスキャンされた場合にのみ、タスクをオンラインで起動できます。次に、Dag online のコールバック アクションが実行されます。上位レベルのアプリケーションは、オンライン プロセスを完了するために最下位層を介してコールバックされ、上位レベルのアプリケーションがオンライン タスクのステータスを定期的にポーリングすることを回避します。 DagWorker は、DAG がオンラインで正常に起動されるのを待機し、その後コールバックを実行してタスクの起動を完了します。

DAG ファイルの生成は上図に示されています。

external_task: 外部タスクに対応し、task >> task2 となります。つまり、task 2 は task 1 に依存し、外部タスク ExternalTask​​1 にも依存します。 Python ファイル全体が、Airflow によってスケジュールされた DAG です。 AirFlow は DAG とその依存関係を解析して、スケジュール メタデータを生成します。

3. データバス

データバスのコアモジュールとして Datax を使用し、上記のテンプレート ファイルに基づいてタスクを実行します。スケジューリングはスタンドアロンですが、Datax は優れたスケーラビリティを備えており、ソース、シンク、データ変換ロジック、フィルタリング開発を拡張するためのタスク スケジューラ インターフェイスを用意しています。データバスのタスク管理機能は、Datax に基づいてカプセル化されます。ユーザーがページにパラメータを入力すると、Reader および Writer プラグインを使用して Datax テンプレート ファイルがレンダリングおよび生成されます。 Datahub モジュールは、Yarn API を介して対応する Yarn クラスターにファイルを送信します。 Yarn スケジューリングを選択する理由は、Datax が単一のマシンで実行され、マルチノード タスクをスケジュールできないためです。 YarnCluster と K8S を比較すると、オフライン コンピューティング タスクは現時点では K8S では完全にコンテナー化されていません。 Yarn の統合ビッグデータ オフライン スケジューリング タスクは、オフラインコンピューティングのために Yarn クラスターに送信するために使用されます。

4. リソースの分離とコンピューティングの最適化

リソースの分離は、主にリアルタイムのオフライン クラスターの分離と、ビジネス変換、データ プッシュ、データ ウェアハウス間のタスク分散などのさまざまなタスク間の分離を目的としています。

データ ウェアハウスのコア タスクは第 1 レベルのキューに配置され、他の部門はそれに基づいてサブタスク キューを分割し、コア、重要、通常の 3 つのレベルの優先キューでリソースを分離します。

低優先度のタスクを動的に制限することで、コア タスクの同時実行性が保証されます。タスク キューがいっぱいになると、通常のタスクは最初に送信されません。通常のタスクは主に早朝にスケジュールされます。新しいタスクを制限することで、通常のタスクの同時実行制限を確保し、通常のタスクに優先順位を付けてリソースを占有することを回避でき、コアタスクがコンピューティングリソースを待機する必要がなくなります。

共通タスクがスケジュールされる前にリソースが他の日常的なタスクによって占有されないように、深夜前に共通タスクを監視します。

Spark タスクの最適化には、小さなファイルの管理が含まれます。タスクの最適化には、主にリソースの最適化、データ スキュー、結合の最適化、およびタスクの分割が含まれます。

5. データ品質の監視

品質監視は、分析と改善のための適時性、正確性、完全性、一貫性、データの有効性の 5 つの側面に主に焦点を当てています。

データ品質監視のアーキテクチャを上の図に示します。関連する品質監視ルールと監視タスクが構成されます。品質ルールは強いルールと弱いルールに分けられます。強いルールに対してはタスク フューズが実行され、弱いルールに対しては事後分析と改善が実行されます。このルールは、SQL を通じてタスクのデータの一貫性を検証します。ルール タスク全体が SparkSQL ジョブとして送信され、計算用のルール レポートが生成され、最後にタスクが分析されて改善されます。

以上がジョブの操作詳細です。品質ジョブは、SQL テンプレートを通じてタスクとジョブ名を生成します。各テンプレートはルールとレコードを生成します。単一テーブルの検証、単一テーブルの複数フィールド検証、および出力ルールに対して複数のルールが開始されます。テーブルに 10 個のルールがあり、最初の優先ルールが満たされていない場合は、チェックが中断され、プロセスが直接返されます。

6. クラウドネイティブの実践

データ開発プラットフォーム プロセスには、リアルタイム、オフライン、データ バス、品質操作、監視、プロアクティブな AI モデルが含まれます。プラットフォーム サービスは、迅速なビジネス反復のニーズを満たすために、マイクロサービス アーキテクチャに基づいてさまざまなサブサービスに分割されます。初期開発から最終発売まで、複数のバージョンが開発されました。モジュールの変更は他のサービスに大きな影響を与えます。開発には従来の大規模バックエンドサービス開発モデルが採用されており、モジュールの結合が大きな影響を与えます。これらの問題は、各サービスを分割することでうまく解決されます。

同社の KCS CI/CD プラットフォームは、サービスの迅速なテスト、反復、展開を実現します。インフラストラクチャには、サービスの安定性を向上させるための統合監視およびアラーム機能と自動拡張機能が装備されています。

開発プラットフォーム全体の反復にはデータ ガバナンス プロセスも伴い、作業結果は非常に重要です。全体的なコンピューティング コストは 87% 削減され、モデル機能の計算時間は 7.5 時間短縮され、ダッシュボード データのクエリ時間は 40 倍改善されました。

IV.今後の展望

データ開発およびガバナンス プラットフォームには、オフライン スケジューリングと密接に関連し、より優れたパフォーマンスと拡張を必要とする多くの分割サービスがあります。

可観測性: サービスの不安定性の問題をタイムリーに発見できます。たとえば、タスクの数が増えると、タスクの状態間で同時競合が発生し、その結果生じるパフォーマンスの問題をタイムリーに解決する必要があります。

コンピューティング効率: 現在、専門家の経験と実際のシナリオに基づいてオフライン SQL を継続的に最適化する必要がある SparkSQL ジョブが多数あります。

リモート災害復旧: 今日のビッグ データ クラスターは、オフライン コンピューティングとリアルタイム コンピューティングを含め、同じコンピュータ ルームに展開されます。単一のコンピュータ ルームにオフサイト バックアップ要件がある場合、データ障害復旧のために複数のコンピュータ ルームが必要になるほか、クラスタ間のリアルタイム コンピューティングや、コンピュータ ルーム間の障害復旧を実現するオンライン データ サービス アプリケーションも必要になります。

5. 質疑応答

Q1: データ権限はどのように管理および実装されますか?

A1: データ権限は 2 つの部分に分かれています。プラットフォーム上でユーザーが所属する組織の権限は、スペース管理部分に部分的にバインドされます。ユーザーが所属する部門の操作権限によって、プラットフォームのデータ権限が制限されます。メタデータ モジュールでは、ライブラリ テーブルに対するユーザーの権限が設定されます。 UDF で暗号化および復号化する必要がある機密データもユーザーに関連付けられます。ユーザーが新しいタスクを作成すると、SQL は解析後に関連テーブルを対象とし、関連テーブルの操作権限が検証され、バインドされます。

Q2: データガバナンスはどのように行われ、その有効性を高めるにはどうすればよいですか?

A2: 初期のストーブパイプ開発では、コンピューティングコストが比較的高く、コンピューティングパフォーマンスが低かったです。データ ウェアハウスは、データ ウェアハウスのデータ ガバナンス プロセスとデータ ウェアハウスの開発プロセスのニーズを満たすために反復的に開発されてきました。このプラットフォームは、スケジューリング タスクとコンピューティング タスクのパフォーマンス最適化に関する適切なサポートを提供するため、全体的なコンピューティング リソースでより良い結果を達成できます。