データサービスとは
ビッグデータ開発の主なプロセスは、データ統合、データ開発、データ生成、データ返却の 4 つの段階に分かれています。データ統合により、ビジネス システム データがビッグ データ環境に入るチャネルが開かれ、通常、オフライン テーブルの定期的なインポート、インポートされたオフライン テーブルのリアルタイムの収集とクリーニング、対応するデータ ソースのリアルタイムの書き込みという 3 つの方法が含まれます。現在、Didi の内部同期センター プラットフォームは、MySQL、Oracle、MongoDB、Publiclog などの複数のデータ ソースからのデータ収集機能、データ開発/生産、ユーザーがリアルタイムおよびオフラインのデータ ウェアハウスを構築できる機能、およびさまざまなタスクに基づいたデータ モデリング機能を提供しています。 SQL、ネイティブ、シェルなどのメソッド; データ バックフローは、オフライン データを OLAP、RDBMS などにインポートすることでアクセス パフォーマンスを向上させ、ダウンストリーム サービスはデータ分析やデータ視覚化のためにデータ ソースに直接アクセスします。
Didi の社内データ ドリーム ファクトリーは、データ開発と生産リンクの効率、セキュリティ、安定性に重点を置き、ワンストップのデータ開発と生産ソリューションを提供することを目的としています。
データ開発プロセス
データをユーザーに体系的に届けるために、Shuyi、データインテリジェント質問応答ロボット、トランザクション分析などの一般的なデータ消費製品に加え、水平堆積コンテンツ製品Polarisやグループ展示を含む、ワンストップのデータ消費プラットフォームを構築しています。ホール。ワンストップの消費プラットフォームは、構造化および標準化されたデータをクエリすることにより、視覚化および分析機能を提供する必要があります。データ消費製品の技術アーキテクチャから、クエリ パフォーマンスには特定の要件があり、クエリ メソッドに従って適切な多次元分析ストレージ エンジンに返されます。最も一般的なものは、MySQL、ClickHouse、Druid、StarRocks です。したがって、多次元分析ストレージ エンジンのクエリ クロージャ、コンピューティング機能の拡張、パフォーマンスの最適化の実装、およびクエリの安定性の保証はすべて、消費者データ製品の公開および一般的な機能です。
さらに、他のパーソナライズされたデータ製品、オペレーティング プラットフォーム、B エンド/C エンド製品にもデータ アクセス機能が緊急に必要とされています。これは、データセンターの構築とデータ アクセス機能、つまりデータ サービス機能の統合の中核問題でもあります。
この能力開発は一朝一夕に達成できたものではなく、主に 3 つの段階に分かれています。
データ消費型製品の技術アーキテクチャ
フェーズ 1:
同期センターのデータ バックフロー機能を構築する
2019 年、滴滴出行はデータ システム 2.0 の構築を開始しました。データ ドリーム ファクトリーの核となる成果として、その第一段階の目標は、ワンストップのデータ開発および生産プラットフォームを構築することです。キー ノードは、ワンストップ データ システム 2.0 の完成です。マイルストーンとして同期センターの建設を中止する。自動プロセスの構築により、同期センターは、作業指示を送信してデータ ソース間の同期タスクを手動で構築する歴史に終止符を打ちました。その中心的な成果は、Hive リンクに入るデータの独立した管理機能の構築です。さらに、MySQL、ClickHouse、Druid、Hbase、ES への Hive バックフロー リンクを新たに構築し、データ バックフローでプラットフォームの構築を完了できるようにしました。
データ バックフローに基づくデータ サービス機能により、サービス ポイント、Polaris、Shuyi などの関連シナリオを体系的にカバーできます。このコアは、ビッグ データ環境へのビジネス アクセスのパフォーマンスの問題を解決します。Shuyi を例にとると、ClickHouse へのデータ バックフローにより、データ クエリのパフォーマンス P90 が 5 秒から 2 秒未満に低下しました。このパフォーマンスの向上により、Shuyi のユーザー エクスペリエンスの品質が向上しました。この段階のデータ製品、特にクエリ側の基本アーキテクチャは、次の図に示すものと同様で、データ返却ロジックとデータ取得ロジックの 2 つのモジュールが抽象化されています。
データ バックフローは、多次元分析ストレージ エンジンへのデータ エクスポートを実現し、タスク管理と運用保守機能を蓄積します。これらのデータ製品は、データ ドリーム ファクトリーを深く開き、データの強力なオフライン タスク運用保守機能に基づいています。ドリームファクトリーならデータの出力が保証されます。アクセス ロジックは特定のクエリ ロジックを維持します。Polaris を除く他の 2 つの製品は、InSight の QE (QueryEngine) や Shuyi のクエリ センターなど、クエリ抽象化に基づいた派生ミドルウェアを備えています。データ リターンとアクセス ロジックはデータ製品の中核機能であり、構築コストが非常に高いモジュールでもあります。したがって、この段階では、データインテリジェントな質問応答ロボット、データポータル、複雑なテーブルなどの製品と同様に、Shuyi データセットに基づくクエリおよびアクセラレーション機能を使用して、製品を迅速に検証します。
フェーズ 2:
デジタルチェーンプラットフォームを構築し、データサービスを統合する
フェーズ 1 では、データ バックフロー オンライン ストレージ機能を提供し、関連するシステム コールのパフォーマンスを向上させ、データ製品の開発に段階的に貢献します。ビジネスの発展に伴い、データテーブルの数が増加し、システムごとにデータアクセスロジックの分離・偏在が顕著になり、管理コストが増加し続けています。データ検索パフォーマンスを向上させるためには、多次元分析ストレージエンジンへの加速に加え、データを高度に集約し、より少ないデータでAPP層を構築する必要もあります。APP レイヤ テーブルとビジネス要件の間には強い相関関係があるため、要件の変更により、サービスをサポートするための APP テーブルの変更が生じることがよくあります。フェーズ 1 では、データ アクセス ロジックのシーンが異なるシステムに分散しており、異なるカンバンのデータ ソースの切り替えやカンバン品質の再承認など、APP テーブルの変更は比較的大きな作業負荷となり、そのプロセスは非常に複雑です。
データ リフローとアクセス ロジックはさまざまなデータ製品で繰り返されるため、データ製品構築の効率も向上します。効率を向上させるために、社内製品は基本的に、データインテリジェントな質問応答ロボットや複雑なテーブルなどの構築に Shuyi データセットに依存しています。
しかし、これは最適な解決策ではなく、問題は主に次の点に反映されています。
Shuyi データセットに基づく、加速、電流制限、絶縁などの対策の構築は非常に複雑で複雑です。特に Shuyi のデータセット高速化手法は、第 1 レベルの SQL タスク高速化と第 2 レベルの ClickHouse 高速化に分かれており、形式が固まっています。
Shuyi のクエリは MPP 構造に基づいており、比較的高い同時クエリとチェックをサポートするのは困難です。
運用・保守保証力が弱く、加速タスクもすべてプラットフォームが実行するため、ユーザーの認識が弱く、運用・保守ができない。
Shuyi のデータセットは Shuyi に強く依存しており、サービス指向の機能を売却して構築するのは困難ですが、当時、Shuyi にとってそれは最優先事項ではありませんでした。
要約すると、統合データ サービス プラットフォームを構築することは、ビジネスに大きなメリットをもたらします。2021年初頭から、時代の要請に応じてデジタルチェーンプラットフォームが台頭しており、その基本的な考え方は、アクセラレーションリンクとクエリロジックを一元管理し、統合された完全なクエリゲートウェイを提供することです。
デジタル チェーンの基本的な機能は次のとおりです。
多様なデータ ソース: ES、MySQL、ClickHouse、Hbase、Druid などのデータ ソースへのアクセスをサポートします。
マルチシナリオのデータ アクセス: キーと値のキーと値のペアの高度な同時クエリをサポートし、複雑な多次元分析をサポートし、データ ダウンロード機能をサポートします。
統合アクセス標準: 統合アクセス ゲートウェイ、統合データ アクセス プロトコル、統合データの運用と保守、および統合 API 管理機能。
データ セキュリティ制御: 機密データ アクセス、データ ダウンロード、アウトバウンド制御機能の監査をサポートします。
デジタルチェーンプラットフォームの構築後、データAPI構築時間が日単位から分単位に短縮され、ホワイトスクリーンAPI構築機能が実現しました。現在、デジタルチェーンのAPI数は4,000を超え、毎週アクティブなAPIの数も1,600を超え、200以上のアプリケーションに対応し、すべてのビジネスラインをカバーし、確立された構築目標を達成しています。
フェーズ 3:
デジタルチェーン標準インデックスサービスの構築
第2段階のプラットフォーム構築により得られるデータ製品は、主にモニタリング、ダッシュボード、ポータル、オペレーティングシステム、セキュリティ関連システムなどとなります。これらのシステムは、主に API 構築の効率化、API ビジネス ロジックの管理機能、API の運用保守機能に重点を置いています。ただし、Shuyi や Polaris などの初期の構築では、関連する機能を備えたクローズドループ製品を使用しているため、デジタル チェーンにアクセスするための突破口を見つけることは困難であり、メリットを確認することも困難です。
現在、ビッグデータのインジケーターは、長い間インジケーター管理ツールに保存されている Hive テーブルとインジケーターの説明を通じて提供されており、データ ウェアハウスはビジネス側に Hive テーブルと説明的な値のロジックを提供します。ビジネス側が Hive テーブルを使用してかんばんを構築し、一時的にデータを取得する場合、データ取得ロジックを繰り返し確認する必要があり、比較的非効率的です。同時に、Polaris、Shuyi などの製品でも同じインジケーターが表示されることがよくありますが、最も恥ずかしいのは、値に不一致が頻繁にあることであり、インジケーターの消費の一貫性が顕著であることを意味します。
インジケーター管理ツールは、インジケーター管理方法論に従って構築されたインジケーターおよびディメンションのメタデータ管理システムです。指標とディメンションを入力するために、データ チームは多額の費用を費やします。インデックス管理ツールはインデックスの入力と検索機能のみを提供し、インデックスの規範的な構築はトップダウン管理にのみ依存することができ、効果的に自己運用することはできません。インジケーターの一貫性を確保するには、インジケーターが 1 つのソースからのものであることのみを確認でき、配信方法は Hive テーブルではなくインジケーター自体にすることができます。インジケーターは直接消費機能を提供する必要があります。
第 2 段階におけるサービス指向構築のジレンマ、Polaris および Shuyi インジケーターの消費の曖昧さ、およびインジケーター管理ツール自体のジレンマにより、標準インジケーターのサービス指向構築が登場しました。基本的なアイデアは図に示されています。1 つは、インデックス管理ツールがモデル管理を提供し、インデックスを物理テーブルに関連付けることです。さらに、ナンバー チェーンは統合された消費ゲートウェイを提供し、Shuyi や Polaris などのデータ製品をオープンできるようにします。この消費チャネルを向上させます。
標準インジケーターをサービスベースで構築するには、メタデータ管理でインジケーターとディメンションの表現機能を拡張し、論理モデルを使用してインジケーター、ディメンション、および特定の物理テーブルの特定のフィールドを関連付ける必要があります。ダウンストリーム消費のロジックを簡素化するために、標準インジケーターのサービスは、ある程度の自動検索ロジック機能を提供する必要があります。通常、インデックスは異なる物理テーブルに実装され、異なる物理テーブル間のインデックスの整合性チェックにより、インデックスのあいまいさを効果的に回避できます。
「
メタデータ管理
標準インジケーター (インジケーター、ディメンション、論理モデル) のサービスにとって最も重要なメタデータ。以下、順次紹介していきます。
索引
指標管理方法論では、主に指標の意味能力を向上させるために導入された計算指標と複合指標が導入されています。派生インジケーターは、物理テーブル (Hive/Starrocks/ClickHouse) の開発後に外部で直接提供できるインジケーター、つまり、物理テーブルの対応するフィールドで実体化する必要があるインジケーターを指します。計算済みインジケーターは、登録された派生インジケーターに基づいて計算され、物理テーブル上のフィールドに対応するインジケーターとして実体化できない場合があります。現在の計算方法では、加算、減算、乗算、および除算の四則演算のみがサポートされています。例えば、回答後のキャンセル率＝回答後のキャンセル注文数／同日回答した注文数となります。複合インジケーターは、登録された派生複合ディメンションによって生成されるインジケーターを指しますが、物理テーブル上のフィールドに対応するインジケーターとして実体化されない場合があります。たとえば、「ネットフラワーアウトGMV」は、「openapiとスキャンコードを含む」インジケーターに基づいています。支払いGMV」、および複合ディメンション「注文集約ビジネスライン」の場合、ディメンション値は「ネットワーク + アウトバウンド + 花」によって生成されます。以下の図に示すように、複合インジケーターと計算インジケーターは互いにネストすることができますが、現在、複合インジケーターはネスト チェーン内に最大 1 回しか出現できません。
緯度
Latitude タイプ、現在 4 つのタイプが構築されています。
ディメンション テーブル ディメンション: 独立したディメンション テーブル。ディメンション テーブルには一意の主キーおよびその他の属性情報が含まれます。ディメンション テーブル ディメンションは、データ ウェアハウスのスター モデルを構築できます。外部キーがある場合は、多層ディメンション テーブルに依存するスノーフレーク モデルを構築できます。たとえば、都市ディメンション テーブルのディメンション Whole_dw.dim_city などです。
列挙次元: キー/値のキーと値のペア、キーと値のペアは一元的に管理されます。例: 性別ディメンション、対応するキーと値のペア男性 (M)/女性 (F)。
縮退ディメンション: ディメンション ロジックは集中管理できず、異なる物理テーブルは異なる実装を持ちますが、同じディメンションを表します。たとえば、Polaris のビジネス ライン ディメンションでは、さまざまなセクターのビジネス ライン ID から Polaris のビジネス ライン ID への変換ロジックが異なり、これは特定の実装で決定する必要があります。
派生ディメンション: 縮退ディメンションとは異なり、ディメンション ロジックは処理コードの一部として集中管理できます。
論理モデル
論理モデルにはさまざまな場所で異なる解釈があり、インジケーター管理ツールの論理モデルは、インジケーター、ディメンション、および物理テーブルのバインドのキャリアです。論理モデルは、派生インジケーター、計算インジケーター、複合インジケーターの 3 種類のインジケーターにバインドでき、また、ディメンション テーブル ディメンション、列挙ディメンション、派生ディメンション、縮退ディメンションの 4 つのディメンションにもバインドできます。論理モデルにバインドされたインジケーターとディメンションは、物理テーブルのフィールドに直接バインドすることも、物理テーブルのフィールドに基づいて構築された計算フィールドにバインドすることもできます。計算インジケーターと複合インジケーターは、計算ロジックまたは複合ロジックに従って非実体化することもできます。論理モデルは複数のインジケーターおよびディメンションにバインドでき、逆に、インジケーターまたはディメンションを複数の論理モデルにバインドできます。より一般的に言えば、インジケーターの複数の実装は論理モデルを通じて指定されます。
論理モデルで物理テーブルを指定すると、物理テーブルのストレージ エンジン、物理テーブルのデータ レイアウト、およびデータ ウェアハウス レベルも指定されます。現在、データ チェーンは 3 つのストレージ エンジン (Hive、SR、ClickHouse) をサポートし、データ レイアウトは一般的な APP テーブル、Cube テーブル、および GroupingSets テーブルをサポートし、データ ウェアハウス レベルは APP、DM、DWS、および DWD をサポートします。
「
データ取得ロジックの自動化
デジタルチェーン構築標準指標のサービス化では、データ検索ロジックの自動化により一元管理（Single Source of Truth）を実現できる一方で、効率性も向上します。データ取得ロジックの自動化は、主に標準インジケーターのサービスに反映されます。
インジケーターとディメンションを介したデータへのアクセスをサポートします。ユーザーは、必要なインジケーターとディメンションを提供し、アクセス インターフェイスを介してデータを取得するだけで済みます。論理モデルで前述したように、インジケーターと論理モデルには 1 対多の関係があります。自動化されたアクセス ロジックは、必要なインジケーター、ディメンション、パーティション範囲、および最高のパフォーマンスを備えたアクセス方法に基づいて、適切な論理モデルを選択します。計算されたインジケーターが依存する派生インジケーターが異なるモデルを通じてのみ取得できる場合、データ取得プロセスはフェデレーテッド クエリを通じて完了できることを指摘することが重要です。
複数のデータ レイアウトをサポートするテーブルは現在、一般的な APP テーブル、キューブ テーブル、および GroupingSets テーブルをサポートしています。フェッチでは、さまざまなデータ レイアウトのフェッチ ロジックがシールドされているため、ユーザーは元のテーブルのデータ レイアウトを気にする必要がありません。
さまざまなデータ ウェアハウス モデリング モデルがサポートされており、データ ウェアハウス モデリングの標準出力では、シングルトン、スター、スノーフレーク モデルが使用できます。スノーフレーク モデルおよびスター モデルの場合、自動アクセス ロジックは、必要なディメンション テーブルを自動的に関連付けることにより、ディメンション テーブル ディメンション内のさまざまなディメンション属性のロールアップなどの複雑なアクセス ロジックを実現できます。
日次、週次、月次、および四半期ごとの粒度のロールアップをサポートしています。以前は、異なる時間粒度のデータは、異なるテーブルを開発することによってのみ実現できました。クエリのパフォーマンスが保証されている場合、時間粒度のロールアップ機能を実現できるようになります。
「
一貫性チェック
データ検索ロジックの自動化によりデータ検索効率を実現することに加えて、インデックスの一貫性はデジタル チェーン構築の標準インデックス サービスの中核となる出発点でもあります。インデックスの一貫性は、一方では統合された消費インターフェイスを通じて行われ、他方ではインデックスの実際のステータスに基づいて受動的かつ自動検証を実行します。
パッシブ指標検証では、ユーザーはプラットフォーム上で必要な検証指標を設定します。下図に示すように、「過去 1 日のグループ全体の GMV」のように、複数の論理モデルで実装できます。したがって、検証ロジックは、複数の論理モデルを作成した後、定期的に検証を行うことになります。もう一つは、「グループ全体の最終日のGMV」は、「オンラインレンタカーの最終日のGMV」＋「二輪車の最終日のGMV」＋「貨物の最終日のGMV」で実現できる場合である。したがって、以下の図に示すように、検証ロジックは、左側の論理モデル_1、右側の論理モデル_1'、論理モデル_2'、論理モデル_3'を作成した後、定期検証することができます。
自動インデックス検証とパッシブインデックス検証の違いは、モデルの分解方法がシステムによって自動的に生成され、検証可能なインデックスもシステムによって選別されることです。
「
アクセスとクエリのプロセス
現在、デジタルチェーンの標準指標にアクセスするサービスとしては、Polaris、Shuyi、InSightなどがあり、これら3製品はDidiの中核データ製品でもあります。標準インジケーターのサービス化には、これら 3 つの製品を公開するときにさまざまな課題があります。これについては、他の学生が共有する記事で詳しく説明します。ここでは、データ製品へのアクセスとクエリの基本プロセスを簡単に紹介するだけです。
通常のプロセスでは、データBPはインジケーター管理ツールに従ってインジケーターとディメンションを順番に入力し、データ開発の学生はさまざまなデータアーキテクチャ手法に従ってデータウェアハウスを構築し、インジケーターとディメンションを関連付けてバインドするための論理モデルを作成します。管理されたメタデータはリアルタイムでデジタル チェーンに同期されます。
Shuyi、Polaris、および InSight は、メタデータ インターフェイスを通じてレポートとかんばんを構築します。データクエリが開始されるとリクエストがデータチェーンに送信され、モデルのスクリーニングと最適化を経て最終的な実行SQLが生成され、クエリされたデータがデータプロダクト側に返されます。
データサービスシステムの全体構造
デジタルチェーンプラットフォームは、ワンストップで標準化され、効率的で安定した安全なデータサービスプラットフォームを構築することを目指しています。現在のサービス ビジネス シナリオは、主にローカル データ サービス、オフライン データ サービス、フィーチャ サービス、および標準インデックス サービスに分かれています。デジタルチェーンプラットフォームはゲートウェイ層とエンジン層に分かれています。ゲートウェイは統合された入口を実装し、認証、電流制限、キャッシュ、ルーティング、監視などの機能を提供します。エンジン層は、実装シナリオをキー/値のキーと値のペアのシナリオ、多次元分析シナリオ、および標準インジケーター サービス シナリオに分割します。キー/値のキーと値のペアのシナリオは、主要なサービス機能、つまりブル シールドやマップ機能などのビジネス シナリオのサービスです。多次元分析シナリオは、主にローカル データ サービスとオフライン データ サービス (Horus、Jixiao、その他のビジネス シナリオ) に対応します。キー/値のキーと値のペアのシナリオと多次元分析シナリオはフェーズ 2 のコア機能であり、標準インジケーター サービス シナリオはフェーズ 3 のコア機能です。
多様で複雑なデータ クエリの要求をサポートするために、統合クエリ ミドルウェア DiQuery も構築しました。DiQuery は、MPP の強力なクエリ機能を利用して、Shulian や Shuyi などのデータ製品を提供するための統合クエリ機能を構築しました。DiQuery は、単一テーブル クエリ機能のサポートに加えて、フェデレーション クエリと LOD 複合関数クエリ機能もサポートします。DiQuery は、前年比や 4 週間平均などの拡張機能をサポートしており、これに基づいてロールアップする機能をサポートしています。
概要と展望
Didi のデータサービスシステムの開発は、独自のデータ返却タスク方式、統一データサービスプラットフォームの構築、標準インデックスサービスの構築を経て、より良いデータサービスシステムを段階的に構築しています。標準指標のサービス指向の構築は今年のハイライトであり、データウェアハウスの研究開発、製品およびプラットフォームの研究開発の全面的な協力のもとに急速に発展しています。
現在のデータ サービス システムは、データの生成とデータの消費の関係を切り離しています。次に、データ制作の標準化を推進し、指標の整合性の問題をさらに解決し、データウェアハウス構築の効率化と指標等の観点からのデータ品質の向上を図る必要がある。標準指標のサービス化は、段階的に推進されるデータプラットフォームの重要な進化であり、業界では徐々に幕が引かれつつあります。