トラフィックの配当が徐々に薄れていく中、ますます多くの広告会社や広告実務家が、これまでのトラフィックをフルに使って大規模な広告攻撃を行うやり方に代わって、洗練されたマーケティングの新たな道を模索し始めています。洗練されたマーケティングとは、何億人もの人々の中から最も潜在的なターゲット ユーザーを選択することを意味します。これは間違いなく、基本的なエンジン サポートを提供するデータ ウェアハウス機能に大きな技術的課題をもたらします。
この記事では、ByteDance の OLAP エンジン テクノロジーと実装経験に焦点を当て、ByteDance の内部シーンを例として、実装ロジックと広告ビジネスのビジネス効果を具体的に分解します。
広告の正確な広告シナリオ
一般的に広告のプロセスには、データ収集→データ統合→グループ選択→広告配信→フィードバック分析という重要なプロセスが含まれており、グループ選択は正確な広告を実現するための重要なステップであり、広告のターゲット層を決定するのに役立ち、広告のターゲット層を決定するのに役立ちます。広告収入を増やすために、さまざまな視聴者や広告目標に合わせて配信戦略を最適化することに基づく配信プラットフォーム。
混雑推定
混雑推定は主に特定のサークル選択条件に基づいて、ヒットしたユーザーの数を確認します。正確な広告配信のプロセスにおいて、広告主は現在選択されているグループのおおよその人数を把握する必要があり、これは配信状況の判断と配信予算の決定に役立ちます。 5秒。
広告
正確な広告配信のプロセスで遭遇する問題と課題:
1. データの見積もり:広告主は配信状況を判断し、配信予算を決定するために、選択したグループを推定する必要があります。ただし、クラウド パッケージには大量のデータと大きな基盤があります。プラットフォーム上のユーザー数は数億人、DouyinだけのDAUは数億人、DouyinとToutiaoに相当するクラウドは10億レベルに達する、初期の推定バージョンではElasticSearchを使用しているが、データが大きすぎるため、1/10 のサンプリング ストレージしか使用できないため、10% のエラーが発生し、ビジネスとして受け入れられません。
2. クエリのパフォーマンス:広告主は非常に複雑なサークル選択条件を設定することができ、その結果、複雑な計算が行われる可能性があり (1 回の計算に数百、さらには数千のクラウド パッケージが含まれる場合があります)、大量のデータを処理するときに Hive および ES プログラムがクエリ速度を低下させる可能性があります。広告主のすべてのユーザーをクエリする必要がある場合は、ユーザー ベース全体をスキャンする必要があり、このプロセスには数分から数時間かかる場合があり、リアルタイム要件を満たすことができません。
3. 大規模なストレージ スペース: Hive や ES などのソリューションでは追加のインデックス構造が必要となるため、ストレージ スペースが大きくなり、ストレージ コストが増加します。たとえば、ユーザー属性にインデックスを付ける必要がある場合、インデックス データを保存するために追加の記憶領域が必要になります。
4. 高い同時実行性をサポートしない: Hive や ES などのソリューションは、高い同時性のリクエストを処理するときにパフォーマンスの問題が発生しやすく、効率的な広告配信をサポートできません。たとえば、複数の広告主が同時にユーザー情報をクエリする必要がある場合、クエリのブロックや応答の遅延などの問題が発生する可能性があります。
5. データ クエリの効率: ClickHouse は推定をサポートするために使用されますが、データ量の増加に伴い、ClickHouse が現在のストレージ エンジンのサポートでクエリ時間を保証することが困難になります。これはデータ クエリの効率の問題を引き起こし、ユーザー エクスペリエンスに影響を与えます。
ByteHouse BitEngine ソリューション
プログラム紹介
新しいクエリエンジン
ClickHouse は、高性能の分散機能に基づいて、大規模データの分析とクエリの要件を満たすことができるため、研究開発チームは、オープンソースの ClickHouse に基づいて火山エンジンのクラウドネイティブ データ ウェアハウス ByteHouse を開発し、一連のカスタマイズを行いました。その中のモデルの処理 - BitEngine は、交差のパフォーマンス向上の問題を解決し、リアルタイム分析シナリオでセットの計算を補完するために使用されます。
広告群集推定ビジネス向けに開発された新しいクエリ エンジンは、ByteHouse が提供する MergeTree Family シリーズ エンジンをベースにしており、新しい bitmap64 タイプと一連の関連集計関数が追加されています。BitEngine が提供する bitmap64 型は、多数のユーザー ID 間の関係を格納および計算するのに適しており、広告群衆推定ビジネスでは、群衆パッケージ データを格納し、群衆間の交差と補数の計算に bitmap64 型が使用されます。パッケージをビットマップに分割し、それらの間の交差と補完を行うことで、通常のクエリをはるかに超えるパフォーマンス指標を達成します。
実装手順
ユーザー ID をビットマップに直接保存できる bitmap64 タイプを作成し、一連の交差および補数の集計計算を提供し、さらにマルチコア CPU の並列コンピューティング機能を最大限に活用できることを期待して、BitEngine を設計しました。例は次のとおりです
CREATE TABLE cdp.tag_uids_map (
tags String,
uids BitMap64 BitEngineEncode
)ENGINE = HaMergeTree('/clickhouse/xxxx/{shard}', '{replica}')
ORDER BY tagtag_uids_mapの格納形式は以下のとおりです。
| 鬼ごっこ | UID |
|---|---|
| あ | {10001,20001,30001,40001,50001,60001,70001,80001,90001} |
| B | {10001,20001,20002,20003,20004,20005,20006,20007,20008} |
A&B をクエリする結果の SQL は次のとおりです。
SELECT bitmapCount('A&B') FROM tag_uids_map
BitEngine はロジックを実装します
本旨
データを分割してエンコードして、各間隔のデータ間に交差がないことを確認してから、ローリング ビットマップを使用してデータを保存します。
計算中、マシンの並列機能を最大限に活用するために、各パーティションのデータを独立して集計できます。各パーティション内の集計計算は、複数のビットマップの交差および補完です。轟音ビットマップの効率的な交差および補完計算により、 CPU とメモリの使用量。
エンコードされた結果は辞書を通じて反転され、データのエンコードはデータの分散を可能な限り高密度にすることであり、轟音ビットマップは保存および計算時に優れたパフォーマンスを得ることができます。
ビジネスアプリケーション
ビジネスに不可欠な要素
クラウド パッケージ: 広告主のカスタム ルールによって計算されたクラウド データ、タグは市場の需要に応じて DMP チームによって定義されたクラウド データです。
タグID：出力ルールに従って1日1回更新されますクラウドIDは自己増加し、広告主のニーズに応じて毎日新たに計算されます。
ユニコード
ラベル データとクラウド データの uid を均一にエンコードするために、エンコード サービスはまずラベル データの uid とクラウド データの uid を抽出して統一エンコードし、全量の uid を 10,000 バケットに均等にハッシュします。バケット番号は i[ 0<=i<=9999]、uid は各バケットに 1 から順にコーディングされ、各バケットの範囲は i*2^40 - (i+1)*2^40 です。
uid データは毎日増加するため、増分エンコーディングをサポートする必要があります。エンコーディング サービスは、まず毎日増分 uid を取得し、ハッシュして各バケットに順次配置します。
データストレージ
エンコードが完了すると、辞書データは最初にハイブ テーブルに均一に書き込まれます。これは、辞書のさまざまな使用シナリオに便利です。
データが分割されエンコードされた後、ClickHouse はデータをさまざまなデータ インポート形式で bitmap64 としてディスクに保存できます。
データ計算
BitEngine はコンピュータの並列機能をどのように最大限に活用して、各パーティション内の複数のビットマップ間の交差および補数の計算を完了するのでしょうか?
問題があります：
4 つのビットマップ、つまり a、b、c、d があると仮定すると、(a | c) & (b | d) は、必ずしも (a & b) | (c & d) に等しいとは限りません。
群衆パック
群集パック A = [10001, 20001, 30001, 40001, 50001]、群集パック B = [10001, 20001, 20002, 20003, 20004]
望ましい結果
BitEngine を通じて A&B を計算 = [10001, 20001]
デザイン
群衆パッケージは特定のルールに従って複数の間隔に分割され、2 つの間隔の間にある群衆パッケージは交差しません。
計算スレッドは同じ間隔のクラウドパケットを読み込んで計算するだけで、中間結果を取得します。
最終的な中間結果は、単純にビットマップまたは計算を実行するだけで済みます。
この設計では、BitEngine はデータの読み取りと計算が間隔に従って厳密に実行されることを保証する必要があります。BitEngine はデータを読み取るときにファイルごとに読み取りタスクを構築し、スレッド スケジューリング モジュールがタスク全体のスケジューリングと読み取りを完了します。このスレッド スケジューリング モジュールのスケジューリング原理は次のとおりです。
異なるパーティション内のファイルは相互読み取りされません (ClickHouse のファイル読み取り粒度はファイル粒度よりも小さく、複数のスレッドが連続してファイルを読み取ることになり、パーティションは複数のファイルで構成される場合もあります)。つまり、スレッドA_1 、 B_1 のみを読み取ることができ、その間の A_2 または B_2 は読み取りません。
パーティションが読み取られた後、すぐに集計計算をトリガーしてビットマップ間の計算ロジックを実行し、中間結果を取得できます。つまり、A_1 と B_1 を読み取った後、すぐに A_1 と B_1 を計算できます。
スレッドは中間結果を計算した後、他のファイルの読み取りを続けることができます。
BitEngine はすべての中間結果の計算を完了した後、結果の出力要件に従ってデータのマージを実行します。
計算される結果がビットマップのカーディナリティである場合、BitEngine は各中間結果のカーディナリティを直接加算します。
計算結果にビットマップが必要な場合、BitEngine はすべてのビットマップを直接マージします。マージとはビットマップまたは計算を指します。
ビジネス効果
広告事業効果
データ保存スペースが 3 分の 1 +
インポート時間を 3 倍以上削減
クエリの avg/pct99/max はすべて大幅に減少し、pct99 は 5 秒から 2 秒に短縮されました。
CPU 使用率が大幅に低下し、PageCache で 100 G+ を節約
クエリエラーが 10% から 0% に減少
BitEngine がオンラインになる前後の時間のかかる監視をクエリする
BitEngine がオンラインになった後の CPU 負荷の比較
PageCache の使用量 (低いほど良い)
まとめ
BitEngine がオンラインになった後、多くのチューニングを経て、広告群衆推定ビジネスで良好な収益を達成しました。現在、BitEngine は外部出力用に火山エンジンのクラウド ネイティブ データ ウェアハウスである ByteHouse に統合されています。火山エンジン ByteHouse は主にユーザーに非常に高速な分析エクスペリエンスを提供します. リアルタイム データ分析と大量データのオフライン分析をサポートできます. 便利な弾性伸縮機能, 優れた分析パフォーマンスと豊富なエンタープライズ レベルの機能を備えています.中国地震ネットワークセンター、Neptunes Group、Lilith Games、Geekbang Technology、その他多くの業界企業と協力し、さまざまな業界のデジタル変革を深く支援するために協力に達しました。今後、BitEngine は、データ エンコーディングを統合してユーザーにエンコーディングを透過的にする機能、一部の繰り返し式の計算結果をキャッシュするためのきめ細かなキャッシュ機能、式解析の最適化機能など、広告ビジネス シナリオをサポートする機能の強化を継続していきます。 、など。