統合データ ウェアハウスを使用してデータ サイロを解消: Apache Doris に基づく CDP

企業データ ソースがますます多様化するにつれて、データ サイロの問題が一般的になってきました。保険会社が顧客データ プラットフォーム (CDP) を構築する場合、コンポーネント集約型のコンピューティング レイヤーと、データ サイロによって引き起こされる分散したデータ ストレージの問題に直面します。これらの問題を解決するために、Apache Doris ベースの CDP 2.0 を採用し、Doris の統合データ ウェアハウス機能を使用してデータ サイロを打破し、データ処理パイプラインを簡素化し、データ処理効率を向上させました。

データ サイロ問題は、オンライン ビジネスにとって関節炎のようなものです。年齢を重ねると、ほぼすべての人がこの問題に遭遇するからです。企業は、Web サイト、モバイル アプリ、HTML5 ページ、エンド デバイスを通じて顧客とやり取りします。何らかの理由で、これらすべてのソースからのデータを統合するのは困難です。データは所定の位置に残り、さらなる分析のために相互に関連付けることはできません。これがデータサイロの形成方法です。ビジネスが大きくなるほど、顧客データのソースは多様化し、データサイロに閉じ込められる可能性が高くなります。

まさにそれが、この記事で取り上げる保険会社で起こったことです。 2023 年までに、同社は 5 億人以上の顧客にサービスを提供し、570 億件の保険契約を締結しました。このような大規模なデータに対応するために顧客データ プラットフォーム (CDP) の構築を開始したとき、複数のコンポーネントを使用しました。

CDP のデータ サイロ

ほとんどのデータ プラットフォームと同様、CDP 1.0 にはバッチ パイプラインとリアルタイム ストリーミング パイプラインの両方があります。オフライン データは Spark ジョブを介して Impala にロードされ、そこでラベルが付けられ、グループに分割されます。同時に、Spark は OneID 計算のためにそれを NebulaGraph に送信します (これについてはこの記事で後ほど説明します)。一方、リアルタイム データは Flink によってタグ付けされ、クエリのために HBase に保存されます。

これにより、CDP にはコンポーネント集中型のコンピューティング レイヤー (Impala、Spark、NebulaGraph、HBase) が誕生します。

その結果、オフライン ラベル、ライブ ラベル、グラフ データが複数のコンポーネントに分散されます。これらを統合してさらなるデータ サービスを提供すると、冗長ストレージと大量のデータ転送が発生するためコストがかかります。さらに重要なのは、ストレージの違いにより、CDH クラスターと NebulaGraph クラスターの規模を拡張する必要があり、リソースとメンテナンスのコストが増加したことです。

Apache Doris ベースの CDP

CDP 2.0 では、混乱を解消するための統合ソリューションを導入することにしました。 CDP 2.0 のコンピューティング層では、Apache Doris がリアルタイムおよびオフラインのデータ ストレージと計算を担当します。

オフライン データを取り込むために、ストリーム ロード方式を利用します。 30 スレッドの取り込みテストでは、1 秒あたり 300,000 を超える更新挿入を実行できることがわかりました。リアルタイム データをロードするには、Flink-Doris-Connector と Stream Load を組み合わせて使用​​しました。さらに、複数の外部データ ソースからデータを取得する必要があるリアルタイム レポートでは、フェデレーション クエリのマルチ カタログ機能を活用します。

この CDP における顧客分析のワークフローは次のとおりです。まず顧客情報を整理し、各顧客にラベルを付けます。よりターゲットを絞った分析とアクションを実現するために、タグに従って顧客をグループ化します。

次に、これらのワークロードを詳しく調べて、Apache Doris がどのようにワークロードを高速化するかを示します。

One ID

製品やサービスのユーザー登録システムが異なる場合に、このような状況に遭遇したことはありませんか?ある製品ページからユーザー ID A の電子メールを収集し、別の製品ページからユーザー ID B の社会保障番号を収集できます。その後、UserID A と UserID B は同じ電話番号を使用しているため、実際には同じ人物に属していることがわかります。

これが、OneID がアイデアとして浮上した理由です。すべての業種のユーザー登録情報を Apache Doris の大きなテーブルに収集して整理し、各ユーザーが固有の OneID を持つようにするためです。

これは、Apache Doris の機能を利用して、どの登録が同じユーザーに属しているかを判断する方法です。

タグ サービス

この CDP は、500 を超えるソース テーブルから得られる 5 億件の顧客情報に対応し、合計 2,000 を超えるタグが付けられています。

タグは適時性に応じて、リアルタイム タグとオフライン タグに分類できます。リアルタイム タグは Apache Flink によって計算され、Apache Doris のフラット テーブルに書き込まれます。一方、オフライン タグは、Doris のユーザー属性テーブル、ビジネス テーブル、およびユーザー行動テーブルから生成されるため、Apache Doris によって計算されます。データ ラベル付けにおける同社のベスト プラクティスは次のとおりです:

1. オフライン タグ

データ書き込みのピーク期間中は、データの規模が大きいため、更新は非常に難しく、OOM エラーが発生しやすいです。これを回避するために、Apache Doris の INSERT INTO SELECT 機能を活用し、部分的な列の更新を有効にしました。これにより、メモリ消費が大幅に削減され、データ読み込み中のシステムの安定性が維持されます。

enable_unique_key_partial_update=true を設定します。
tb_label_result(one_id, labelxx) に挿入
one_id、label_value を 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 を超える同時実行レベルでタグ クエリ リクエストを受信します。彼らは高いパフォーマンスを確保するために戦略を組み合わせて使用​​します。まず、Prepared Statement を使用して SQL をプリコンパイルし、事前実行します。次に、Doris バックエンドとテーブルのパラメーターを微調整して、ストレージと実行を最適化します。最後に、列指向の Apache Doris を補完するものとして行キャッシュが有効になります。

Doris のバックエンド パラメータを微調整する be.conf:

disable_storage_row_cache = false
storage_page_cache_limit=40%

テーブル作成時のテーブル パラメータの微調整:

enable_unique_key_merge_on_write = true
ストア行列 = 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 まで、保険会社は統合データ ウェアハウス Apache Doris を使用して Spark Impala HBase NebulaGraph を置き換えています。データサイロを打破し、データ処理パイプラインを簡素化することで、データ処理効率を向上させます。 CDP 3.0 では、リアルタイム タグとオフライン タグを組み合わせて顧客をグループ化し、より多様で柔軟な分析を実現したいと考えています。 Apache Doris コミュニティと VeloDB チームは、このアップグレード中もサポート パートナーであり続けます。

以上が統合データ ウェアハウスを使用してデータ サイロを解消: Apache Doris に基づく CDPの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。