データ サイロ問題は、オンライン ビジネスにとって関節炎のようなものです。年齢を重ねると、ほぼすべての人が罹患するからです。企業は、Web サイト、モバイル アプリ、H5 ページ、エンド デバイスを介して顧客とやり取りします。何らかの理由で、これらすべてのソースからのデータを統合するのは困難です。データはそのままの場所に留まり、相互に関連付けてさらなる分析を行うことはできません。こうしてデータサイロが形成されていきます。ビジネスが成長するほど、顧客データ ソースは多様化し、データ サイロに囚われる可能性が高くなります。 これはまさに、この記事でお話しする保険会社に起こっていることです。 2023 年までに、同社はすでに 5 億人以上の顧客にサービスを提供し、570 億件の保険契約を締結しました。このようなデータ サイズに対応する顧客データ プラットフォーム (CDP) の構築を開始したとき、複数のコンポーネントを使用しました。 CDP のデータサイロ ほとんどのデータ プラットフォームと同様に、CDP 1.0 にはバッチ処理パイプラインとリアルタイム ストリーミング パイプラインがありました。オフライン データは Spark ジョブ経由で Impala にロードされ、タグ付けされてグループに分割されました。一方、Spark は、OneID 計算のためにそれを NebulaGraph にも送信しました (この投稿の後半で詳しく説明します)。一方、リアルタイム データは Flink によってタグ付けされ、HBase に保存され、すぐにクエリできるようになりました。 これにより、Impala、Spark、NebulaGraph、HBase といった CDP 内のコンポーネントを多く使用する計算レイヤーが誕生しました。 その結果、オフライン タグ、リアルタイム タグ、グラフ データが複数のコンポーネントに分散されました。さらなるデータ サービスのためにそれらを統合するには、冗長ストレージと大量のデータ転送によりコストがかかりました。さらに、ストレージの不一致により、CDH クラスターと NebulaGraph クラスターのサイズを拡張する必要があり、リソースとメンテナンスのコストが増加しました。 Apache Doris ベースの CDP CDP 2.0 では、混乱を解消するための統合ソリューションを導入することを決定しました。 CDP 2.0 の計算レイヤーでは、 リアルタイムとオフラインの両方のデータ ストレージと計算を実行します。 Apache Doris が を取り込むには、 メソッドを利用します。 30 スレッドの取り込みテストでは、1 秒あたり 300,000 を超えるアップサートを実行できることが示されています。 をロードするには、 と Stream Load を組み合わせて使用します。さらに、複数の外部データ ソースからデータを抽出する必要があるリアルタイム レポートでは、 の 機能を利用します。 オフライン データ Stream Load リアルタイム データ Flink-Doris-Connector 統合クエリ マルチカタログ この CDP の顧客分析ワークフローは次のようになります。まず顧客情報を整理します。その後、各顧客にタグを付けます。タグに基づいて顧客をグループに分類し、より的を絞った分析と運用を実現します。 次に、これらのワークロードを詳しく調べて、Apache Doris がどのようにワークロードを高速化するかを示します。 ワンID 製品やサービスのユーザー登録システムが異なる場合に、このようなことが起こったことはありますか?ある製品 Web ページから UserID A の電子メールを収集し、その後別の製品 Web ページから UserID B の社会保障番号を収集する場合があります。次に、UserID A と UserID B は同じ電話番号を使用しているため、実際には同じ人物に属していることがわかります。 そこで、OneID がアイデアとして生まれました。それは、すべての業種のユーザー登録情報を Apache Doris の 1 つの大きなテーブルにプールし、整理して、1 人のユーザーが固有の OneID を持つようにすることです。 これは、Apache Doris の機能を利用して、どの登録情報が同じユーザーに属しているかを特定する方法です。 タグ付けサービス この CDP は、 から取得され、合計 に添付されている の情報に対応します。 500 を超えるソース テーブル 2,000 を超えるタグ 5 億人の顧客 適時性によって、タグはリアルタイム タグとオフライン タグに分類できます。リアルタイム タグは Apache Flink によって計算され、Apache Doris のフラット テーブルに書き込まれます。一方、オフライン タグは、Doris のユーザー属性テーブル、ビジネス テーブル、およびユーザー行動テーブルから派生するため、Apache Doris によって計算されます。データのタグ付けに関する同社のベスト プラクティスは次のとおりです。 1. オフラインタグ: データ書き込みのピーク時に、データの規模が大きいため、完全な更新を行うと簡単に OOM エラーが発生する可能性があります。これを回避するために、Apache Doris の 関数を利用し、 を有効にします。これにより、メモリ消費が大幅に削減され、データ読み込み中のシステムの安定性が維持されます。 INSERT INTO SELECT 部分的な列の更新 set enable_unique_key_partial_update=true; insert into tb_label_result(one_id, labelxx) select one_id, label_value as labelxx from ..... 2. リアルタイムタグ: リアルタイム タグはさまざまなペースで更新されるため、部分的な列の更新もリアルタイム タグで利用できます。必要なのは、 を に設定することだけです。 partial_columns true curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H "columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load 3. 同時実行ポイントの多いクエリ: 現在のビジネス規模では、同社は 5000 QPS を超える同時実行レベルでタグのクエリ リクエストを受信しています。彼らは高いパフォーマンスを保証するために戦略を組み合わせて使用します。まず、SQL の事前コンパイルと事前実行に を採用しています。次に、Doris Backend とテーブルのパラメーターを微調整して、ストレージと実行を最適化します。最後に、列指向の Apache Doris を補完するものとして 有効になります。 プリペアド ステートメント 行キャッシュが で Doris Backend パラメーターを微調整します。 be.conf disable_storage_row_cache = false storage_page_cache_limit=40% テーブル作成時にテーブルパラメータを微調整します。 enable_unique_key_merge_on_write = true store_row_column = true light_schema_change = true 4. タグの計算 (結合): 実際には、多くのタグ付けサービスは、データベース内の複数テーブルの結合によって実装されます。多くの場合、これには 10 を超えるテーブルが含まれます。最適な計算パフォーマンスを実現するために、Doris では 戦略を採用しています。 コロケーション グループ 顧客のグループ化 CDP 2.0 の顧客グループ化パイプラインは次のようになります。Apache Doris は顧客サービスから SQL を受け取り、計算を実行し、結果セットを SELECT INTO OUTFILE 経由で S3 オブジェクト ストレージに送信します。同社は顧客を 100 万のグループに分けました。 かかっていた顧客のグループ化タスクが、 しかかからなくなりました。 Impala では完了するまでに 50 秒 Doris では 10 秒 より詳細な分析を行うために顧客をグループ化する以外に、逆方向の分析を行う場合もあります。それは、ある顧客をターゲットにして、その顧客がどのグループに属しているかを調べることです。これは、アナリストが顧客の特徴や、さまざまな顧客グループがどのように重なっているかを理解するのに役立ちます。 Apache Doris では、これは BITMAP 関数によって実装されます。 顧客が特定のグループの一部であるかどうかを確認する高速な方法であり、 、 、および は相互分析の選択肢です。 BITMAP_CONTAINS BITMAP_OR BITMAP_INTERSECT BITMAP_XOR 結論 CDP 1.0 から CDP 2.0 まで、この保険会社は、Spark+Impala+HBase+NebulaGraph の代わりに統合データ ウェアハウスである Apache Doris を採用しました。これにより、データ サイロが解消され、データ処理パイプラインが合理化されるため、データ処理効率が向上します。今後の CDP 3.0 では、リアルタイム タグとオフライン タグを組み合わせて顧客をグループ化し、より多様で柔軟な分析を実現したいと考えています。 と チームは、このアップグレード中もサポート パートナーであり続けます。 Apache Doris コミュニティ VeloDB でも公開されています。 ここ
