著者について
Ctrip バックエンド開発の専門家である Chengrui は、リアルタイム データ処理、AI 基本プラットフォームの構築、およびデータ製品に重点を置いています。
この記事では主にCtripトラベルチームにおけるオフラインデータウェアハウス構築の実装と実践を紹介し、ビジネスペインポイント、ビジネス目標、プロジェクト構造、プロジェクト構築などの側面から始めます。
1. ビジネス上の課題
リアルタイム データの需要が高まるにつれて、オフライン データ ウェアハウスでは次のようなビジネス上の課題がますます明らかになってきています。
リアルタイムデマンド煙突開発モデル
中間データの再利用性が低い
オンラインデータ開発からの分離
データ生成 -> 長いサービスサイクル
リアルタイムのテーブル/タスクが乱雑で管理できない
リアルタイムの血統/基本情報/モニタリングなどの欠如
ツールを使用しないリアルタイムのデータ品質監視
リアルタイムタスクの運用保守の敷居や高品質なシステムが弱い
この種の典型的な問題は、人的効率、品質、管理などの側面に大きな課題をもたらすため、それらを解決するための体系的なプラットフォームが緊急に必要です。
2. ビジネス目標
既知のビジネスの問題点に焦点を当て、会社の既存のコンピューティング リソース、ストレージ リソース、オフライン データ ウェアハウス標準などに依存しながら、私たちの目標は、人的効率、品質、管理のレベルでシステムを構築することです。以下に示すように:
2.1 人間の効率レベル
標準化されたデータ処理、オフラインとオンラインのコード互換性、コンピューティング能力の統合など、オフラインとオンラインのデータ開発ソリューションの標準化を実現します。
分単位のデータ展開により、BI 学生レベルでのデータ インターフェイスの登録、公開、デバッグなどの視覚的な操作が可能になります。
2.2 品質レベル
データコンテンツの DQC (コンテンツが正しいか、不完全か、タイムリーか、オンラインと一致しているかなど)。
データ タスクの警告 (遅延、バック プレッシャー、スループットがあるかどうか、システム リソースが十分であるかどうかなど)。
2.3 管理レベル
フルリンクリネージュ、データテーブル/タスク、品質カバレッジ、その他の基本情報などの視覚的な管理プラットフォーム
データモデリング仕様、データ品質仕様、データガバナンス仕様、ストレージ選択仕様などの統合データウェアハウスの全プロセス仕様。
3. プロジェクトの構造
プロジェクト構造は以下の通りで、主にオリジナルデータ→データ開発→データサービス→データ品質→データ管理とその他のモジュールで構成されており、数秒でリアルタイムデータを処理し、データサービスを展開する機能を提供します。数分でリアルタイム データ開発が可能学生、バックエンド データ サービスの開発と使用。
さまざまなデータ ソースからのデータは、最初に標準化された ETL コンポーネントを通じて標準化され、トラフィック転送ツールによって前処理されます。フロー バッチ フュージョン ツールとビジネス データ処理モジュールは、階層型およびドメイン ベースの構築に使用されます。生成されたデータは直接処理されます。データサービスモジュールを利用し、データはデータAPIを通じてデプロイされ、最終的には業務アプリケーションで利用され、リンク全体に対応した品質と運用保守の保証体制が整備されます。
4. プロジェクトの構築
4.1 データ開発
このモジュールには主に、データ前処理ツールとデータ開発ソリューションの選択が含まれています。
4.1.1 トラフィック転送ツール
入口の数が多く、交通量も多いため、次のような主な問題が存在します。
同じディメンションに対して複数のデータ ソースと分析方法が存在する場合があります。
使用される埋め込み点データは全体の約 20% を占めており、リソースをすべて消費することは非常に無駄であり、下流側の操作が繰り返されることになります。
埋め込みポイントを追加した後、データ処理には開発介入が必要になります (極端な場合、すべてのユーザーが関与します)。
以下の図に示すように、トラフィック転送ツールは複数のデータ ソースに動的にアクセスし、簡単なデータ処理を実行し、有効なデータを標準化して下流に書き込むことができるため、上記の問題を解決できます。
4.1.2 ビジネスデータ処理ソリューションの進化
ソリューション 1 - オフライン データのシンプルな融合
背景
当初のビジネスニーズは、ユーザー履歴のリアルタイム注文量の計算や、ユーザーが購入したアトラクションの履歴情報の集計など、比較的単純なものでした。このような単純な要件は、数値の加算、減算、乗除算、文字の追加、重複排除の要約など、オフライン データとリアルタイム データの単純な集計に抽象化できます。
解決
以下の図に示すように、データ プロバイダーは、標準化された T+1 およびリアルタイム データ アクセスを提供します。データ処理：T+1 およびリアルタイム データ統合、一貫性検証、動的ルール エンジン処理など、データ ストレージ：集約データの水平展開をサポート、タグマッピングなど。
オプション 2 - SQL のサポート
背景
ただし、オプション 1 には次の利点があります。
シンプルなレイヤリングと強力なタイムリーさ
ルール設定は迅速に応答し、多数の複雑な UDF を処理できます。
ルールエンジンとその他の処理
Java エコシステム全体との互換性
しかし、明らかな欠点もあります。
BI SQL 開発者は基本的に介入できず、開発に強く依存します。
SQL シナリオは多数あり、Java を使用して開発するとコストがかかり、安定性も低くなります。
有効なデータ階層化がありません
プロセスデータは基本的に入手できないため、プロセスデータを保存したい場合は計算を繰り返す必要があり、計算リソースを無駄に消費します。
解決
以下の図に示すように、Kafka はデータ階層化機能、Flink SQL のコンピューティング エンジンを搭載し、OLAP はデータ ストレージと階層クエリを搭載し、典型的なデータ ウェアハウス システムの階層構造を完成させます。
ただし、kafka と olap のストレージ エンジンは 2 つのエンティティであるため、データの不整合が発生する可能性があり、たとえば、kafka が正常でデータベースが異常である場合、中間層のデータは異常になりますが、最終的な結果は正常になります。上記の問題を解決するために、以下に示すように、従来のデータベースで使用されている binlog モードが開発されました. Kafka データは DB データの変更に強く依存します. このように, 最終結果は中間層の結果に強く依存します. データ不整合の問題大きなコンポーネントによる影響は避けられませんが、規模が大きいため、いくつかのシナリオは基本的にすでに利用可能です。
オプション 3
背景
ただし、オプション 2 には次の利点があります。
SQL化
自然な階層クエリ
しかし、明らかな欠点もあります。
データの不整合の問題
挿入時はbinlogで問題ありませんが、更新や削除は難しく、更新時には多くの重複排除操作が必要でSQLにとって非常に不親切です。
長期的なデータ集約では、max、min などの一部の演算子はフリンク状態が大きく、不安定になる傾向があります。
また、kafka データの乱れによって引き起こされるデータ カバレッジの問題も考慮する必要があります。
解決
以下の図に示すように、ストレージ エンジンの計算能力を借用し、Kafka の binlog はデータ計算のトリガー ロジックとしてのみ使用され、Flink UDF は直接 DB クエリに使用されます。
アドバンテージ：
SQL化
自然な階層クエリ
データの一貫性
FLinkステータスが小さい
長期にわたる永続的なデータの集約をサポートできます
binlog の乱れやアップデートなどによる問題の心配はありません。
短所:
同時実行性はサポートされておらず、Olap エンジンのパフォーマンスに大きく依存しているため、データ ソースを使用する場合は、現在のウィンドウを制限するか、DB を水平に拡張します。
リトレースメント フローとの組み合わせは、グループ化などのシンク時に中断されます。これは実際には頭のない upsert です。udf の集約は、flink のネイティブ集約を置き換えることはできません。
各ソリューションには適用可能なシナリオがあり、ソリューションの選択は、さまざまなビジネス シナリオと遅延要件に基づいて行う必要があります。現時点では、シナリオの 86% がソリューション 3 を使用して実行できます。Flink 1.16 のさまざまなオフラインおよびオンライン統合機能により、将来的にはすべてのシナリオがカバーされる可能性があります。
4.2 データサービス
このモジュールは、データ同期 -> データ ストレージ -> データ クエリ -> データ サービスなどの機能を提供し、シンプルなシナリオで分単位のデータ サービス展開機能を実現し、開発時間を 90% 節約できます。オフライン データ DQC への強い依存を実現し、エンジニアリング側での DQC 例外、クライアント -> インターフェイス レベルのリソース分離/電流制限/サーキット ブレーク、およびフルリンク ブラッドライン (クライアント -> サーバー -> テーブル -> ハイブ テーブル -> hive bloodline) 管理などを提供し、さまざまなパフォーマンス要件に対応するオンデマンド インターフェイスの展開と運用およびメンテナンスのサポート機能を提供します。
アーキテクチャは次のとおりです。
4.3 データ品質
このモジュールは主にデータ コンテンツの品質とデータ タスクの品質に分かれています。
4.3.1 データの内容
正確性/適時性/安定性
この部分はさらに、データ操作の変更、データ内容の一貫性、データ読み取りの一貫性、データの正確性/適時性などに分かれています。以下の図に示すように、データは変化します。異常が発生した場合、そのデータは同社のヒックウォール警報センターに入力され、早期警報ルールに従って警報が発せられます。データの内容: ユーザー定義の SQL ステートメントを実行し、アラーム センターにデータを書き込むスケジュールされたタスクがあり、第 2 レベルおよび分レベルの警告を実現できます。
読み取りの一貫性
以下の図に示すように、データを読み取るときに、複数のテーブルにまたがる結合クエリがあり、いずれかのテーブルに問題がある場合、ほとんどの場合、間違ったデータは表示されず、履歴内の正しいデータのみが表示されます。が表示され、テーブルが復元された後に表示されます。すべて表示します。
例: 公開するには、表 1 と表 2 のデータを分割する必要があります (表 1/表 2)。表 2 のデータ生成が異常で、過去 2 時間にデータがない場合、ユーザーに公開するときに、企業は2 時間前のデータのみを表示する必要がありますが、異常なデータはフリンク ウォーターマークの概念に基づいてフロントエンド例外リマインダーを提供し、正しいデータを表示します。
オフラインでの一貫性
オフラインおよびリアルタイムのデータ整合性について。以下の図に示すように、比較的単純な方法を使用してリアルタイム データを hudi に直接同期し、hudi を使用してオフライン データとリアルタイム データを比較し、アラーム センターに入力します。
画像.png
4.3.2 データタスク
上流のタスク
同社のカスタマイズされた早期警告ポイント、アラームミドルプラットフォーム、コンピューティングプラットフォーム、その他のツールを利用して、アップストリームメッセージキューが遅延しているかどうか、ボリュームが異常であるかどうかなどの重要な指標を監視し、早期に警告することができます。
現在のタスク
データ処理タスクのスループット、遅延、バック プレッシャー、リソースなどの主要な指標を監視し、データ タスクの長期的な異常を回避するために警告を発することができます。
4.4 データ管理
このモジュールは、データ処理や品質などのさまざまなモジュールを直列に接続し、テーブルの血縁関係/基本情報、DQC 構成、タスクのステータス、モニタリングなどの視覚的な管理プラットフォームを提供します。
各データテーブルの上流と下流のデータ作成タスクの血縁関係を次の図に示します。
下の図は、データシートの品質情報の詳細を示しています。
次の図は、さまざまな UDF テーブルの基本情報をまとめたものです。
5. 今後の見通し
現時点では、基本的にチームのデータ開発ニーズのほとんどをシステムで処理できますが、今後は、データガバナンスシステム全体の改善や自動データリカバリの構築など、信頼性、安定性、使いやすさなどの側面を追求していきます。ツール、トラブルシューティング操作、インテリジェント コンポーネントのディメンション、サービス分析の統合探索など。
【おすすめの読書】
「Ctrip Technology」公開アカウント
共有、コミュニケーション、成長