前に書いてある
Didi の社内テクノロジースタックの継続的な統合、リアルタイム関連の技術コンポーネントリソースの継続的な統合、およびさまざまなビジネスラインにおけるリアルタイムデータ関連の開発経験の継続的な蓄積により、一連の最適なテクノロジーの選択と管理が実現します。企業のさまざまなビジネスシナリオが基本的に形成され、具体的な実行計画が策定されます。しかし同時に、リアルタイム開発を学ぶほとんどの学生は、一般にリアルタイム データ構築とリアルタイム データ構築の過程でのフリンク データ開発を同一視しており、他の関連コンポーネントをリアルタイム データ処理に組み込むことが多いこともわかりました。効率的に実装できないエッジでのプロセス データ処理コンポーネントを統合して、さまざまなビジネス シナリオのリアルタイム要件を満たす。この目的を達成するために、社内で現在一般的なリアルタイム データ開発ソリューションを起点として、さまざまなシナリオにおけるリアルタイム データ構築テクノロジの選択を整理し、全員がリアルタイム データ構築をより適切に実行し、継続的に高品質のデータを出力できるように支援します。ビジネス価値を生み出す高品質で安定したリアルタイム データ。
この記事は次のように分かれています。
1. 社内のリアルタイムデータ開発の主なビジネスシナリオ
2. 社内リアルタイムデータ開発の共通ソリューション
情報元
データチャネル
同期センター
リアルタイム開発プラットフォーム
データセット
リアルタイムデータアプリケーション
3. 特定のシナリオにおけるリアルタイム データ開発コンポーネントの選択
リアルタイム指標監視シナリオ
リアルタイムBI分析シナリオ
リアルタイムデータオンラインサービスのシナリオ
リアルタイム機能とラベル システム
4. 各コンポーネントのリソース使用原則
5. まとめと展望
1. 社内のリアルタイムデータ開発の主なビジネスシナリオ
現在、社内のさまざまな事業分野でリアルタイム データを使用するための主なシナリオは、次の 4 つの部分に分かれています。
リアルタイム指標監視：例えば、生産・研究面での指標安定性監視、ビジネス面でのリアルタイム指標の異常変動監視、運用市場での経営健全性監視など。このタイプのシナリオの主な特徴は、データの適時性に対する高い要件があり、時系列に大きく依存しており、主に分析尺度として時間軸に依存しており、データ分析の複雑さは平均的であることです。
リアルタイム BI 分析:主にデータ アナリストと運用学生向けに、企業の運用ダッシュボード、リアルタイム コア カンバン、展示ホールのリアルタイム大型スクリーンなどを含む、リアルタイム カンバンまたはリアルタイム レポートを構成します。このタイプのシナリオの主な特徴は、非常に高いデータ精度が必要であり、データの適時性にはある程度の遅れがあり、より複雑なデータ分析機能をサポートする必要があることです。
リアルタイム データ オンライン サービス:主に API インターフェイスの形式でリアルタイム インジケーターを提供し、主にデータ製品のリアルタイム データを提供するために使用されます。このタイプのシナリオでは、データの適時性と正確性、平均的なインデックス計算の複雑さ、およびインターフェイス クエリ QPS に対する非常に高い要件が求められます。リアルタイム データを提供しながら、サービス全体の高可用性を確保する必要があります。
リアルタイム機能:主に機械学習モデルの更新、推奨予測、推奨戦略、ラベル付けシステムなどに使用されます。このタイプのシナリオには、データの適時性、精度、クエリ QPS に関する一般的な要件がありますが、独自の実装ロジックにはリアルタイム コンピューティング エンジンの使用に対するより高い要件があり、リアルタイム コンピューティング エンジンには強力なリアルタイム データ処理が必要です。機能と強力な状態ストレージ機能、より豊富な外部コンポーネント ドッキング機能。
2. 社内リアルタイムデータ開発の共通ソリューション
同社のリアルタイム データ開発の一般的なプログラム コンポーネントは主に、リアルタイム データ取得、データ チャネル、データ同期、リアルタイム データ計算、リアルタイム データ セット ストレージ、およびリアルタイム データ アプリケーションの 6 つの部分で構成されます。現時点では、これら 6 つの部分で使用されるコンポーネントは基本的に安定しており、対応するプラットフォーム上で柔軟にコンポーネントを使用できます。
情報元
現在、同社の主なリアルタイム データ ソースは、MySQL によって生成される binlog ログと、ビジネス サーバーで生成される puliclog ログです。MySQL の binlog ログは、Ali のオープンソース収集ツール Canal を通じて完成されます。Canal の動作原理は、MySQL を偽装することです。スレーブと MySQL のシミュレート スレーブの対話プロトコルはダンプ プロトコルを MySQL マスターに送信し、MySQL マスターは Canal から送信されたダンプ リクエストを受信し、バイナリ ログを Canal にプッシュし始め、Canal はバイナリ ログを解析し、最後に結果を DDMQ に送信します。パブリック ログは企業 の 仕様で定義されたビジネス ログです。LogAgent をビジネス サーバーにデプロイすることで、Agent Manager が処理して収集構成を生成します。Agent が Agent Manager にアクセスして収集構成を生成した後、コレクションの構成が完了すると、コレクション タスクの実行が開始され、最終的にログが Kafka に送信されます。
データチャネル
同社の主流メッセージ チャネルは DDMQ と Kafka です。すべての binlog ログは DDMQ から取得されます。DDMQ は、2018 年末時点の Didi のオープン ソース製品です。メッセージの低レベル ストレージ エンジンとして RocketMQ と Kafka を使用しています。主な機能は次のとおりです。遅延およびトランザクション メッセージをサポートすると同時に、複雑なメッセージ転送およびフィルタリング機能もサポートします。パブリック ログは主にメッセージ チャネルとして Kafka を使用し、リアルタイム タスクの中間リンクの開発にも主に Kafka を使用します。その主な特徴は、高い拡張性と環境に配慮した完全性であり、Flink と協力して開発されており、効率が非常に高く、コンポーネントの運用と保守が非常に便利です。
同期センター
主な機能は、ビジネス ニーズに応じて、ソースから収集したデータをオフライン データとリアルタイム データに分離することです。オフライン シナリオのプラットフォームに必要なデータについては、DataX に基づいて開発されたデータ リンク同期機能により、エンドツーエンドのデータ同期が完了し、その結果が hdfs に配置されます。リアルタイム シナリオで必要なデータについては、組み込みリアルタイム コンピューティング エンジンを備えた Dsink タスクを使用してデータ収集構成を完了し、結果を Kafka メッセージ キューにプッシュします。同時に、データは hdfs に配置されます。オフラインの増分または完全な ods テーブルを構築します。
リアルタイム開発プラットフォーム
現在、社内のリアルタイム タスク開発は、flink jar と flink sql の 2 つのモードをサポートする Shumeng のリアルタイム開発プラットフォーム (ワンストップ データ開発プラットフォーム) に完全に統合されています。プラットフォーム 日常的なリアルタイム タスクの開発では、Flink 1.12 の SQL 構文を使用してリアルタイム タスクの開発を完了することをお勧めします。一方で、インジケーターの一貫性を確保でき、他方では、また、リアルタイム タスクの保守性も向上します。リアルタイムタスク開発プロセスにおけるエラーを可能な限り回避し、リアルタイムタスク起動の成功率を向上させるために、タスク開発プロセス中にローカルデバッグ機能を導入および使用することをお勧めします。通常、リアルタイム開発プラットフォームで完了する主な作業は、ETL 操作またはライト サマリー インジケーターの計算であり、その後、処理結果をダウンストリーム シンクに書き込みます。
写真はローカルデバッグ機能のフローチャートです
データセット
計算結果の下流シンクには通常、Kakfa、druid、Clickhouse、MySQL、Hbase、ES、fusion などが含まれます。リアルタイムタスクの中間結果やリアルタイムデータウェアハウスのdwd層のデータはkafkaに書き込み、指標の監視や警報に使用するデータはDruidに書き込み、その特性を利用します。 druid 時系列データベースにより、リアルタイム指標の監視パフォーマンスを向上; ビジネス Bi 分析のシナリオでは、データを Clickhouse に書き込み、多様な BI かんばんを構成できます; flink を使用した指標計算の結果データは、mysql に直接書き込むこともできます、Hbase、ES、または fusion ここでの具体的な選択については、次の章の具体的なビジネス シナリオで具体的な手順について説明します。現在、すべてのダウンストリーム シンクはプラットフォームに統合されており、druid を使用する場合は通常、 Woater (統合インジケーター監視プラットフォーム) にデータソースを設定する必要があり、Clickhouse を使用する場合は通常、 Shuyi (BI 分析プラットフォーム) 上のデータセット。
監視アラーム
リアルタイムBI分析
リアルタイムデータアプリケーション
リアルタイムの結果データの場合、一般的に使用される方法には、 Woater (統合インジケータ監視プラットフォーム)プラットフォーム上でリアルタイム インジケータを作成し 、ビジネス分レベルの結果インジケータの監視に対応する、対応するリアルタイム カンバンまたはリアルタイム監視アラームを設定することが含まれます。リアルタイムの曲線解析。Shumengflow テーブル(Druid のメタ テーブル) またはShuyi ( BI 分析プラットフォーム)上のClickHouse データ セットを使用して、ビジネス側のさまざまな BI 分析要件を満たすリアルタイム レポートを構成することもできます。
3. 特定のシナリオにおけるリアルタイム データ開発コンポーネントの選択
上記のリンクは、現在のリアルタイム タスク開発の主要な開発リンクです。リアルタイム開発のプロセスでは、ビジネスの特定のニーズと各プラットフォームの機能を組み合わせて特定の問題を分析する必要があります。さまざまなビジネス シナリオに応じて最適な開発オプションを選択します。
リアルタイム指標監視シナリオ
シナリオの特徴: 時系列への明らかな依存、インジケーターの適時性に対する高い要件、インジケーターの一般的な精度、クエリ QPS に対する高い要件、およびリアルタイム データ出力の安定性に対する高い要件。
特定のリンク:
このタイプのシナリオでは、 Woater (統合インジケーター監視プラットフォーム) 上で DataSource を構成し、監視要件に基づいて対応するインジケーター列とディメンション列を設定することをお勧めします。クエリ効率を向上させるには、集計粒度を構成する必要があります。 集計粒度は 30 秒または 1 分です。同時に、UV の計算のために、同様のインジケーターのシナリオでは、コンピューティングのパフォーマンスを向上させ、Druid の能力を向上させるために、対応するインジケーター列フィールドを hyperUnique タイプに設定する必要があります。 Druid の消費パーティションを設定してトピック データを消費するには、一般に、トピック パーティションの数を Druid パーティションの数の偶数倍にすることをお勧めします。DataSource を通じて構成されたリアルタイム インジケーターは、リアルタイム監視ダッシュボードとリアルタイム監視アラームを構成するために使用されます。
コア リンクの再保証:コア モニタリング シナリオでは、リアルタイム リンクの安定性と適時性を確保するために、デュアル リンク開発が必要です。
リアルタイム データ処理のデュアル リンクは、FLink タスクのアクティブ - アクティブ、結果トピックのアクティブ - アクティブ、および Druid テーブルのアクティブ - アクティブの 3 つの部分を含む元のデータ ソースから開始されます。同時に、アクティブ - アクティブをサポートする必要があります。リアルタイムのインデックス レベルで切り替えて安定したインデックス クエリを実現し、ダウンストリームの監視とアラームでの誤検知を回避します。
リアルタイムBI分析シナリオ
シナリオの特徴: 時系列に完全に依存せず、高精度のリアルタイム指標が必要で、一定の時間遅延を許容でき、クエリ QPS の一般要件があり、柔軟なディメンション + インデックスの組み合わせクエリをサポートする必要があります。
特定のリンク:
このタイプのシナリオの主な解決策は、flink タスクで必要なディメンション情報を可能な限りフラット化し、フラット化されたリアルタイム データのマイクロバッチを Clickhouse のローカル テーブルに書き込むことです。ClickHouse のローカル テーブルをボトム テーブルとして使用し、さまざまなビジネス ニーズに応じてダウンストリームでさまざまなマテリアライズド ビュー テーブルを構成します。主キーに基づくリアルタイムの重複排除が必要なシナリオでは、CK の ReplacingMergeTree エンジンを使用して実装し、リアルShuyi (BI 分析プラットフォーム) のデータ セットまたは Shulian (データ サービス プラットフォーム) のインターフェイスとしての時間重複排除マテリアライズド ビュー テーブル。クエリのパフォーマンスを向上させるには、 ClickHouse のローカル テーブルに基づくこともできます。 AggregatingMergeTree エンジンを使用して、ビジネスに必要なディメンション フィールドに基づいて集計ビュー テーブルを作成します。このようにして、カンバンの構成やデータ リンク インターフェイスの提供が容易になり、ダウンストリーム データのニーズを満たすことができます。最後のシナリオは、リアルタイムの重複排除や事前集計を必要とせず、データを書き込むことができる一般的なシナリオです。 fink 大画面または予備的に事前に集計されたデータを CK に送信し、分散テーブルで Shuyi データ セットを直接構成して、ユーザーがビジネスに必要なインジケーター ボードを構成できるようにします。
3 種類のテーブルを選択するための主な原則は次のとおりです。
非常に高い精度のビジネス指標が必要で、明確な重複排除主キーがあるビジネス シナリオの場合は、CK のリアルタイム ディエンファシス チャートを使用することをお勧めします。
ビジネス インジケーターの精度が高く、明確なディメンションとインジケーター定義があり、クエリ ロジックが複雑であるかクエリ QPS が高いシナリオの場合は、事前集計操作を実行し、CK の集計ビュー テーブルを使用することをお勧めします。
ビジネス量が大きくなく、ビジネス変更のロジックが頻繁に行われるシナリオの場合は、CK の分散共通テーブルを直接使用して、ビジネスの迅速な反復とデータ取得の要件を満たすために、初期段階で下流のカンバン構成を提供することをお勧めします。
リアルタイムデータオンラインサービスのシナリオ
シナリオの特徴:リアルタイム インジケーターの精度に対する高い要件、クエリ QPS に対する高い要件、データの適時性に関する一般的な要件
特定のリンク:
このタイプのシナリオの主な特徴は、必要なリアルタイム インジケーターのさまざまな前処理を実行する必要があることです。1 つの方法は、flink タスクで必要なリアルタイム インジケーターの計算を完了し、最終的な結果はリアルタイムで MySQL または Hbase に送信され、リアルタイムで更新されたストレージは、ダウンストリーム データ サービス プラットフォームによるインターフェイスのカプセル化に使用されます。このタイプのソリューションは、ビジネス ロジックがあまり変更されず、データ サービスを提供する必要があるシナリオに適しています。別の方法は、集計ロジックを下位に移動し、フリンク タスクは主にデータ コンテンツと単純な事前集計を拡張することです。メインのインジケーター統計作業はダウンストリームの OLAP エンジンの計算に引き渡され、データ サービス プラットフォームは OLAP エンジンをカプセル化することによってインターフェイス クエリ サービスを提供します。この利点は、OLAP の事前集計機能を使用して、ビジネス インジケーター ロジックが頻繁に変更される場合に、効率的なリアルタイム インジケーター サービスを提供できることです。欠点は、OLAP に対するクエリの負荷が比較的高く、より多くのリソースが必要になることです。サービスの高い QPS を確保するために、OLAP 消費のために提供されます。
リアルタイム機能とラベル付けシステム
シナリオの特徴: リアルタイム インジケーターの一般的な精度要件、クエリ QPS と大規模なリアルタイム状態計算の高い要件、およびリアルタイム インジケーターとオフライン インジケーターの統合をサポートする必要性。
特定のリンク:
このようなシナリオには通常、明確なインジケーター列とディメンション列があり、多数のリアルタイム機能またはインジケーター ラベルをプラットフォームに接続する必要があります。最初の解決策は、プラットフォームがトピックを通じてデータを直接消費できるようにすることです。パッケージ化後の機能サービスまたはラベル サービス 2 番目のソリューションは、Hbase と Fusion の強力な主キー更新機能に基づいて、リアルタイムのオフライン ラベルをそれに注ぎ込み、プラットフォームに接続して、ダウンストリーム アルゴリズムに機能サービスまたはラベル サービスを提供します。学生が使用します。
4. 各コンポーネントのリソース使用原則
リアルタイム データの開発には多くのコンポーネントが含まれますが、リアルタイム タスクの開発に対応することを前提として、リソースを最大限に活用し、不要なコストを大幅に削減するために、各コンポーネントの使用における基本原則に従うことをお勧めします。
データ収集：単一収集の原則により、ビジネスに必要なリアルタイム指標の開発には、リアルタイムとオフラインのODSレイヤーの統一性を確保するために、上流のデータソースを可能な限り再利用する必要があります。
ddmq : 1 つの flink タスクが 1 つの ddmq コンシューマ グループに対応し、複数のトピックが 1 つのコンシューマ グループを使用することがサポートされています。異なるリアルタイム タスクで同じコンシューマ グループを使用することは推奨されません。
kafka : 単一パーティションのトラフィック フローは 3MB/s を超えないようにすることをお勧めします。重要なリアルタイム タスクの Kafka の保存時間は 48 ～ 72 時間以内に制御する必要があり、少なくとも 2 日分の履歴データは保存できます。遡って辿れます。
Flink : 消費パフォーマンスが最高になるように、kafka と ddmq のソース同時実行性は、kafka と ddmq によって設定されたパーティションの数と厳密に一致する必要があります。社内の flink タスクの単一 TM リソースは、スロット = 2、taskmanagermemory = 4096、containers.vcores = 2 に固定されています。さまざまなビジネス シナリオに応じて適切に調整できます。純粋な ETL シナリオの場合、単一 TM スロットの数は、メモリ使用量が多いタスクでは、taskmanagermemory の値を適切に増やすことができます。通常のリアルタイム タスク開発プロセスでは、kafka タスクのグローバル同時実行数はソース同時実行数と一致することが推奨されます。ddmq 消費のグローバル同時実行数は、ddmq のフローに従って決定する必要があります。グローバル同時実行数は 3 に設定されます。トラフィックが (1000±500) の範囲にあるシナリオの場合、およびそれを超えるシナリオの場合、この比率の変換に加えて、ビジネス計算ロジックの最大時間消費演算子に従って推定する必要があります。
druid : druid テーブルを作成するときは、集計粒度を設定する必要があります。推奨される粒度は 30 秒または 1 分です。デフォルトのデータ保存期間は 3 か月です。特定のビジネス シナリオで作成された druid テーブルは、ディメンションとインデックス フィールドを指定する必要があります。 String 型、Druid は String 型に対してビットマップと転置インデックスを最適化し、ビジネス ニーズを満たすことを前提として、インジケーター フィールドは可能な限り推定された型を使用し、計算パフォーマンスを向上させます。リアルタイムインジケーター。
Clickhouse : Flink リアルタイム書き込みタスクのデフォルト間隔は 30 秒以上であり、書き込み並列度は可能な限り 10 秒以内に制御する必要があります。CK テーブルのデータ保存周期は約 1 か月で制御する必要があります。パーティション フィールドとして使用され、他のタイプのフィールドはパーティションとして使用できません。リアルタイム データ書き込みシナリオでは、Flink2CK ネイティブ コネクタ モードを使用して、リアルタイム書き込みの安定性を向上させ、CK の CPU 消費量を削減することをお勧めします。Flink2CK の書き込みスループットを 20M/s 以内に制御することをお勧めします。同時実行性) を使用して、CK クラスターの安定性を間接的に保証します。
5. まとめと展望
この記事は主に、Didi の現在の特定のビジネス シナリオに基づいた主流のリアルタイム タスク開発ソリューションとテクノロジー スタックを要約し、オフライン開発からリアルタイム データ開発までの一定の参入基盤をユーザーに提供すると同時に、より優れたサービスを提供します。製品および運用の学生向けのリアルタイム ソリューション リンク開発の普及により、リアルタイム データ構築の開発の敷居はある程度低くなりました。その後、リアルタイム指標監視、リアルタイム BI 分析、リアルタイム データ オンライン サービス、 Didi の 4 つの典型的なビジネス シナリオのリアルタイム機能を使用して、リアルタイム コンポーネントの選択と、それぞれのビジネスシナリオで従うべき原則。これは、ビジネス開発の学生が特定のデータ要件に従って合理的なリアルタイム開発計画を指定し、それを迅速に実装するのに役立ちます。最後に、この記事では、ユーザーのリアルタイム タスク開発の完了を前提として、開発コストを可能な限り削減し、全体的なリソース使用効率を確保するための、リアルタイム タスク開発プロセスの主要コンポーネントの構成提案を提供します。コストを削減し、効率を向上させるために改良されました。