統合データウェアハウスを使用してデータサイロを解消: Apache Doris に基づく CDP-よくある問題-php.cn

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

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

データサイロ問題は、オンラインビジネスにとって関節炎のようなものです。年齢を重ねると、ほぼすべての人がこの問題に遭遇するからです。企業は、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 サイトの他の関連記事を参照してください。