はじめに：Zhihuはビジネス要件に基づいてDMPプラットフォームを構築しました。この記事では、DMPの動作原理とアーキテクチャの進化について詳しく紹介します。同時に、DMPプラットフォームでのApacheDorisのアプリケーションプラクティスを紹介します。この記事は次の場合に非常に役立ちます。 DMPがどのように機能するかを理解するために皆。ようこそ読んでください。
著者{2 }ユーザーの理解とデータエンパワーメントR＆DリーダーHou Rong
DMPビジネスの背景
DMPプラットフォームはありふれたトピックです。初期の広告システムが登場した後、TencentのGuangdiantong、AlibabaのDharmaなどの同様のDMPプラットフォームがありました。これらは、業界でより優れたDMPプラットフォームの典型的な例です。知乎は独自のDMPプラットフォームを構築しています。これは、知乎が関連するインサイトオペレーションを持っているためです。また、DMPプラットフォームを構築することで内部システムのドッキングをサポートできると同時に、また、関連する事業開発とカスタマイズの完了を支援します。需要構築の目的。
DMPサービスには、ビジネスモデル、ビジネスシナリオ、およびビジネス要件が含まれます。
図1.1DMPサービス
DMPプラットフォーム設計の方向性：コア顧客を見つけ、コア顧客の広告などのマーケティング業務を完了して、コア顧客とコンテンツをより適切に一致させるため。
事業の型
DMPプラットフォームのビジネスモデル
- 駅の外から駅の内側に移動します。典型的なシナリオは、広告主が広告の過程でマッピングを介してサイト外の可能性のある群衆をサイトに転送し、サイトのシステムでこれらのユーザーパッケージを引き受ける方法です。
- 駅構内から駅外へ。まず知乎でターゲットユーザーを見つけ、次にこれらのユーザーを使用して3者で宣伝します。
- オンサイト運用。コンテンツ操作、ユーザー操作、アクティビティ操作を含みます。知乎関連のコンテンツの宣伝を増やすことができる一方で、顧客を特定し、特定の顧客の問題やニーズを正確に解決することができます。同時に、イベントデザインを通じて業績を向上させることもできます。
ビジネスシーン
これらの3つのビジネスモデルに基づくと、主なアプリケーションビジネスシナリオは次のとおりです。
- 情報の流れ。推奨シナリオを例にとると、推奨シナリオでは、方向性のある推奨と方向性のある権利のエスカレーションの2種類の要求があります。ターゲットを絞った推奨とは、プッシュコンテンツをターゲットを絞った方法で特定のユーザーにプッシュすることを意味し、ターゲットを絞った特権の昇格とは、プッシュコンテンツをプッシュされたユーザーにエスカレーションして再スコアリングすることを意味します。
- 広告側のリアルタイムビッダー。どの広告がユーザーに表示されているかを知った後、リアルタイムビッダーを実行することができ、ユーザーに最適な広告を並べ替えることによって選択することができます。
- 詳細ページ。詳細ページにポップアッププロンプトが表示されます。たとえば、ユーザーが特定の詳細をクリックした後、ユーザーが目標の条件を満たしていない場合、ポップアップウィンドウがユーザーを条件に合わせるように案内します。
- 活動プラットフォーム。キャンペーンのターゲットユーザーを設定します。さまざまなターゲットグループのさまざまなアクティビティ情報を表示します。
- システムに触れます。たとえば、メッセージ、ポップアップウィンドウ、およびテキストメッセージをプッシュする場合、特定のタイプのユーザーを取得してから、対応するプッシュメッセージとインサイトメッセージをこのタイプのユーザーに公開できます。
- オフサイト配送。適切なユーザーグループを見つけて、オフサイトで適切な広告を配置します。
ビジネスニーズ
ビジネスモデルのシナリオに基づいて、群衆側で実行できることは3つのカテゴリに分類できます。
ドッキングシステム
一般的に、次の3つの状況に分けられます。
- このユーザーがヒットした群集パック。広告システムを例にとると、クラウドパックのIDを広告、つまりユーザーがヒットした広告にマッピングできます。
- 内部群集パック。内部的には、クラウドパックは、誰にコンテンツを推奨するか、または誰にコンテンツを公開するかをプッシュするものです。
- 外部広告に。サイト外に配置する必要のあるタイプのユーザーを除外する場合は、外部クラウドパッケージを使用します。2つのクラウドパッケージの違いとして、クラウドIDは異なります。1つはサイト内の一般IDであり、もう1つは異なる配信プラットフォームの対応する外部IDに基づいています。
群衆のオリエンテーション
群集の方向性には、インポート/エクスポート、特定の機能に基づくタグサークルの選択、群集の一般化、ユーザーボリュームの推定などが含まれます。
- 群集の一般化は、比較的小さなシード群集パッケージを取得した後、ルールに基づいて同様の機能を見つけ、同様の機能の信頼度を調整することでより多くの群集を拡張します。
- ユーザー数を見積もるユーザーのバッチを選択したら、このバッチのユーザー数をすぐに知る必要があります。
群集の洞察
プロファイルの洞察、ユーザーの内部プロファイル、および2つの異なるグループの人々の間の比較分析を含みます。
ビジネスプロセス
現在のDMPサービスの3つのシナリオはさまざまな人々のグループを対象としているため、これらの人々のグループに関連する操作を完了するために、ステーションの内外でさまざまなシステムが提供されます。
このような状況に応じて、クラウドターゲティング機能を整理し、対象ユーザーを獲得してからマッピングを行い、サイト内外のユーザーの効果を回復し、構成分析や比較分析のためのターゲットユーザーを取得して実施します。ユーザーの洞察。目標を達成した場合、打ち上げは成功します。目標を達成しなかった場合、運用側は関連する仮定を行います。ビジネスをさらに改善するための機能または特別な運用を追加することは可能ですか。仮説が提案された後、AB実験が設計され、AB実験の後、ターゲット母集団にいくつかの調整が行われます。以上が当社の運用プロセスです。
図1.2DMPビジネスプロセス
ステーション内操作セルフクローズループ
群衆のオリエンテーション。ラベルサークルの選択により、履歴に活動効果のある人を選択するか、この活動が好きな人をインポートし、一般化して基本グループパッケージの選択を完了し、ターゲットグループを決定します。
配信する。推薦側では、情報フロー、リーチシステム、ディテールシステム、広告エンジンシステムに多くのサービスが接続されているため、上記のシステムやサービスを利用して、サイトのさまざまな交通シナリオでターゲットユーザーの配信を完了することができます。
配達後。このローンチのパフォーマンスを取得して分析します。たとえば、プッシュをクリックするプッシュ、読み取り時間などの動作を送信する操作では、今回リリースしたプッシュを好むユーザーを分析して、ターゲットユーザーの典型的な特性を取得できます。
このプッシュのクリックがプッシュターゲットに到達した場合、ターゲットは完了します。クリックがターゲットに到達しなかった場合、最初にプッシュ>女性をクリックした男性を予測するなどの仮定を行いますが、最後の場合は結果は逆で、合格します。TGIアルゴリズムがソートされ、2つの違いの典型的な特性が検出され、設計が完了し、AB実験が生成されます。
AB実験を通じて、フロントとリアの群集パッケージを比較し、関連するプッシュをリリースできます。クリック数が増えた場合は、引き続きフォローアップのサイクルを完了し、運用シナリオに基づいて現場で正確なユーザーを見つけていきます。
オンサイトからオフサイトへの配送
蓄積されたユーザー特性データに基づいて、知乎内でオフサイト効果をもたらす可能性のある人々のグループを見つけ、そのような人々のグループの範囲を描きます。次に、マッピングを介して、サイト内のIDをサードパーティの配信プラットフォームで生成されたIDに変換して配信できます。
このプロセスではステーション内のシステムが異なるため、データリンク構築に対応する埋没点データを直接取得することはできません。したがって、サードパーティの配信プラットフォームを介して対応する埋没点データをダウンロードし、を介してデータのインポートを完了する必要があります。同様のシナリオ。その後、次のプロセスの構築に進みます。これはまた、プロセス全体の効果のより長い回復につながります。
駅乗り換え駅の外
私が知乎以外の広告主の場合、歯磨き粉製品を発売したいのですが、知乎のユーザーについてはよくわかりません。これまでのオペレーションズリサーチを通じて、歯磨き粉を購入した人々の歴史がどのようなものかを知ることができます。次に、以前の調査で取得した群集パッケージをIDマッピングを介して知乎IDに変換し、インポートしてターゲット群集を生成できます。ただし、広告主が歯磨き粉を購入する人を獲得し、知乎のユーザーとの重複度が低い場合があります。このとき、2番目の関数である群集一般化関数が有効になります。
群衆の一般化は、少数の輸入された人々の種の集団を知乎に結び付けます、そしてこのプロセスは、ユーザーによって達成されるすべての機能のためのAIモデルのトレーニングを完了することができます。知乎のすべてのユーザーの特性の下でシード母集団のモデルをトレーニングし、次にすべてのユーザーのすべての特性を取得したモデルに注ぎ込んで推論することができます。このようにして、自信を持ってターゲットユーザーを獲得します。
広告主が以前の調査結果に基づいて、関連するターゲットグループが知乎で約1,000万人であると信じている場合、ターゲットユーザーの信頼水準を選択できます。たとえば、信頼水準が0.7の場合、結果は2,000万になります。次に、信頼水準を0.8に調整すると、結果は1,000万になります。このとき、信頼水準0.8を選択して、広告エンジンを使用してサービスを開始します。効果を分析します。
上記の操作プロセスに基づいて、洞察、方向付け、IDマッピングなどのDMPプラットフォームのコア機能を抽象化できます。
ポートレート機能
図1.3DMPプロファイルの機能
上記のユーザーポートレートに基づいて、ポートレート機能を構築しました。その中で、ラベルは最も重要な部分であり、個別の部分でもあります。継続的な部分には、ユーザーの滞在時間と、特定の場所で誰かが行ったことなどの関連するユーザーの行動が含まれます。これらはすべて継続的な機能です。機能に関しては、機能にラベルが付けられていない限り、まとめて通常の機能と呼びます。
機能カーディング
図1.4DMP機能のカーディング
DMPプラットフォームの機能に基づいて、ビジネス機能として右側に拡張されています。ビジネス機能は、群集オリエンテーション、群集洞察、および関連するIDマッピングを含む、運用、販売、またはインサイトアプリケーションシステムに役立ちます。左側に拡張することは、有益で重要な機能アクセス部分です。
現在のDMPプラットフォームには、タグだけで250万のタグがあり、ユーザーXタグには1,100億の関連ユーザーデータがあります。同時に、ビジネスの一部のタグにはリアルタイムの要件があります。これにより、機能へのアクセスプロセス中に多くのことを行う必要があります。
次に、具体的な機能をご紹介します。
- 群衆のオリエンテーション。群集の方向性に関しては、一般に、インポートとエクスポート、フィーチャサークルの選択、群集の一般化の3つの機能に分けられます。
- 群集の洞察。組成分析と2つの機能の比較分析を含みます。構成分析の部分は、円グラフまたは棒グラフとして簡単に理解できます。比較分析は、複数の母集団の比較分析です。
- IDマッピング。全体として、oai、idfa、携帯電話番号のいずれであっても、知乎の連続統一IDはすべてハード生成され、この連続IDは基本的に厳密に自己インクリメントされます。
- 機能へのアクセス
-
- 工法はリアルタイム機能とオフライン機能に分けられます
- タググループには、オフラインおよびリアルタイムのアクセス方法があります。その中で、ツリータグは主に複雑なシナリオを処理するために使用されます。たとえば、ユーザーは複数選択のツリー構造でトピックを読んだり操作したりします。
DMPのアーキテクチャと実装
図2.1DMPサービスアーキテクチャ
建築は最終目標を達成するための重要な段階だと思いますが、必要な段階ではありません。すべての機能を向上させる限り、すべてのビジネス慣行を完了することができますが、これはシステムの継続的な拡張につながり、対応する保守コストは増加し続け、安定性は悪化し、最終的には誰もそれを維持できなくなります。苦痛が発生します。このアーキテクチャは、主に、低コストで保守と反復を行い、複数の複雑なビジネス機能シナリオで特定のモジュールをターゲットを絞って最適化する方法を解決できますが、実際のビジネス機能の問題を解決することはできません。
上記のアーキテクチャの理解に基づいて、ビジネスと全体的なDMPアーキテクチャを分解します。
DMPユーザー
DMPシステムは、次の3種類のユーザーに接続されています。
- プラットフォームに関しては、広告プラットフォーム、情報フロー、広告エンジン、リーチシステムが含まれます。
- 運営、配送、販売などの事業関連事業者を含む事業者。
- 機能開発製品や関連する社内製品など。
また、これら3人が接続しているフロントエンドシステムも異なります。
まず第一に、プラットフォームまたはシステムの側面がDMPのインターフェース層とインターフェースすることを信じています。インターフェイスには主に3つのタイプがあります。
最初のインターフェースは広告エンジンなどであり、フィードはユーザーがヒットした人々のグループのリストを要求することがよくあります。広告エンジンでは、リクエストを完了した後、クラウドパッケージリストを広告IDに直接変換して、入札を完了することができます。情報の流れは広告エンジンに似ています。現在のユーザーがエスカレーションしたいコンテンツまたはドメインタグにヒットした場合、エスカレーションします。このインターフェースの設計は、高い安定性、高い同時実行性、および高いスループットの典型です。このインターフェースと他のインターフェースの方位の違いは、オンラインデータで比較できます。このインターフェースは現在100,000 qpsを伝送します。インターフェースは会社のコアシステムに接続されているため、ジッターや障害が発生することはなく、安定性が要求されます。 Sレベルであるため、インターフェイスにはマルチマシンキャッシュと高い同時実行性に関連する設計もあり、高い安定性、高い同時実行性、および高いスループットという目標を達成できる必要があります。
2番目の部分は、駅の内外の群集パックです。この部分は、上記のコンテンツと同様であり、コアシステムに接続されます。群集パッケージが群集を選択できなくなると、全体的なマーケティングとターゲットを絞った配信も影響を受けます。DMPフロントエンド部分については、この部分とインターフェース層の間に明確な違いがあります。DMPフロントエンドは、主に社内のオペレーションクラスメートおよびセールスクラスメートと接続されています。DMPフロントデスクに異常な状況が発生した場合、新しい洞察と群集の方向付けを実行することはできず、歴史的な群集の通常の使用には影響しません。この部分は、再リクエストのインターフェイスではなく、多数の営業担当者や人とつながるため、使用の複雑さを最小限に抑え、運用のトレーニングコストを削減する必要があります。したがって、DMPフロントデスクの操作は簡単である必要があります。と低使用コスト。専門。
3番目の側面は、内部システムとのインターフェースです。これにより、主に日常の開発コストが削減されます。
DMPコア機能
DMPは、群集の選択、一般化、および群集の洞察のコアビジネスモジュールをサポートできます。ラベルの作成、IDマッピング、およびコンピューティングタスクの操作、保守、およびストレージ機能をサポートします。
DMPビジネスモジュール
DMPビジネスモジュールは上層と下層に分かれています。上層のビジネス層は新機能のコスト削減を実現し、スケーラビリティに重点を置いています。下層のビジネス層は、人口とビジネス機能の増加、および全体的な開発に伴って増加します。または、技術投資コストは高くありません。出力、つまりリソースのスケーラビリティが多すぎます。
DMPインフラストラクチャ
一番下にあるのはインフラストラクチャであり、インフラストラクチャの安定性を確保する必要があります。
要求されたインターフェースは主にRedisを担い、 Dorisは主にDMPのフォアグラウンドと全体的なビジネス機能を担い、バックグラウンド部分は主にMySQLとTiDBを担っているという事実に基づいてインターフェースを判断します。上記は、現在の特定の基礎となるデータベースの関連するベアリングの側面です。
Redisのコストが高すぎるかどうかを尋ねる人もいますか？しない。コアクラウド選択ロジックはDorisに実装されており、関連する多数のタグがDorisを介して保存されるため、広告でターゲットグループの特定の特性を指定して一般化を調整、結合、完了する必要がある場合にのみ、結果を丸で囲みます。特定のクラウドパッケージIDに対応し、最後にエクスポートしてRedisに保存します。したがって、Redisの主な目的は高い同時実行性を実現することであり、実際のストレージ量は非常に少なくなります。
DMPプラットフォーム機能インベントリ
機能インベントリは、主にビジネス指向と基本指向の2つの部分に分けられます。
図2.2DMPプラットフォーム機能インベントリ-ビジネス指向
事業の方向性
このビジネスにより、群集のターゲティングと群集の洞察をサポートすることができます。
群衆のオリエンテーション：
- 群集の推定：たとえば、性別、年齢、関心のあるトピック、ユーザーの携帯電話のブランドなどの複数の条件を整理して組み合わせ、群集の特徴の大きさの推定を1秒以内に正確な構造で完了する必要があります。 。
- 群集の選択：正確な構造で人数を推定した後、推定結果を関連する群集パッケージに変換して、数分以内に配信および使用できます。
- 群集パッケージの一般化：一般化の機能はできるだけ単純である必要があります。たとえば、履歴のある群集パッケージを選択した後、群集の一般化を実行し、特定の実行度を選択できます。
群集の洞察：
- 現在のアクティビティポータルのポートレートを調べて、トラフィックを完全に回復できます。たとえば、100万人にプッシュを公開し、そのうち3万人がクリックすると、この3万人のトラフィックを回復できます。すでにプッシュした100万人と比較すると、この3万人の明らかなユーザー特性将来、より正確なユーザーグループを抽出するのに便利です。
基本
さらに、DMPアーキテクチャには、主な機能の構築、IDマッピング、コンピューティングタスクの操作と保守などの基本的な機能がいくつかあります。
図2.3DMPプラットフォーム機能インベントリ-基本的な方向性
これらの3つの基本機能により、リアルタイムおよびバッチ計算をすばやく完了することができるだけでなく、新旧バージョンのロールアウトの問題を解決するのにも役立ちます。現在、AI、データ取得、機能スクリーニングを通じてユーザーを見つけているため、性別などの最も基本的な機能でさえ継続的な最適化の過程にありますが、各最適化の運用上の影響を迅速に評価する方法はありません。オンラインでマルチバージョンのグレースケールを実現し、オンラインで展開します。
フィーチャー構造
機能全体には2つの部分があり、1つはアトミック機能で、もう1つは派生機能です。
- アトミック機能を構築する場合、オフラインまたはリアルタイムのデータから同じベンチマークの多数の機能を生成する必要があります。
- 派生フィーチャーの場合、生成されたフィーチャーに基づいてもう1つのフィーチャーが生成されます。例：あるグループが高購買力グループであると考える場合、単純なシナリオでは、第1層と第2層の都市で18〜25歳の女性を選択し、そのような特性が化粧品の消費能力が比較的高いグループ特性です。次に、この機能を派生機能として保存して、後続の計算を高速化し、運用スクリーニングのコストを削減します。
機能の構築は、機能の分離を実現して、機能の構築とオンライン効率を向上させることができます。
マッピング機能
デバイスIDマッピング、ユーザー機能IDマッピング、および一般化された機能IDマッピングを含みます。この部分の全体的なシーンは主に統合IDであり、IDは、さまざまなタイプおよびさまざまなタイプの不連続IDから、継続的で統合されたintタイプの自己インクリメントIDに変更されます。
コンピューティングタスクの運用と保守
タスクの運用と保守は、主にDAGのスケジューリングとコンピューティングリソースの管理を完了することです。Dorisを使用したことがある場合は、Dorisが各SQL実行を完了するために最速の速度を使用することがわかります。したがって、群集を推定する場合は、適切なキューイングを行う必要があります。そうしないと、突然の運用アクションやホットイベントの波が発生した場合に、複数の群集パックが推定され、すべてのリソースが占有される可能性があります。したがって、タスクの運用と保守を通じてリソースに優先順位を付け、関連する人々のグループを1つずつサークル選択する必要があります。
要約する
- 機能の構築は、機能の分離を実現して、機能の構築とオンライン効率を向上させることができます。
- IDマッピングは、IDマッピングの難易度を覆い隠します。アトミックフィーチャの構築の完了、派生フィーチャの構築の完了、およびインフラストラクチャの構築の3つの部分に分けられます。インフラストラクチャ構築の学生がアーキテクチャのシールドまたは分離を完了すると、機能構築の学生はIDマッピングの問題について心配する必要はなく、機能の構築に集中するだけで済みます。
- コンピューティングタスクの運用と保守の部分では、ビジネス開発の学生は最下層で何が起こったのかを知る必要がありません。このため、最下層のカプセル化を完了し、上層へのインターフェイスを提供する学生が必要です。ビジネス側は、最下層の機能を直接使用し、同時にそれを保護することができます。根本的な複雑さ。抽象化とシールドにより、最終的な打ち上げと建設の効率を大幅に向上させることができ、その他の作業を研究開発側から運用側に移すことができます。
例：現在、2つの機能があり、1つ目はアトミック機能です。アトミック機能を形成するプロセスでは、単一のSQLを作成することで機能を形成できます。アナリストとビジネス製品の両方が、機能の構築プロセスに参加できます。2つ目は派生機能です。運用バックグラウンドで派生機能を統合・差別化する機能があり、一部の事業運営は管理バックグラウンドで直接運用でき、派生機能の構築を完了できます。このように、主な作業負荷は研究開発側から製品側、そしてビジネス側に徐々に移され、さまざまな機能の起動効率が大幅に向上します。
DMPコアの紹介
DMPのコア部分には、データの書き込み/インポートと高速チェック/高速読み取りの2つの側面があります。書き込みとインポートはリンクとストレージの一部です。クイックチェックとクイックリードについては後で紹介します。
機能データのリンクとストレージ
図3.1機能データのリンクとストレージ
書き込みプロセスの最初の部分はオフラインリンクです。オフラインリンクは、各ビジネスのHiveストレージから関連するSQLを実行し、タグテーブルを生成します。Hiveにタグテーブルをドロップした後、オフラインマッピングを完了します。このオフラインマッピングプロセスは、ユーザーデバイスのコアを介して統一された継続的なユーザーIDを自動的に生成するように要求します。同時に、オフラインマッピングプロセスは、imei、idfa、oaidなどのデータを変換して一意にバインドします。プロセス後に新しいユーザーが見つかると、それが生成されます。新しいIDは、古いユーザーの場合は、ユーザーIDを取得します。このプロセスにより、IDマッピングテーブルが生成され、キャピタライゼーションなどの複雑なプロセスを使用して、ユーザーの一意のIDとマッピングIDのマッピングテーブルを取得できます。これが最初に取得するテーブルです。
次に、IDマッピングの後に列挙収集を実行します。現在のタググループは125で、120のオフライン機能と5つの実装機能で構成されています。これらの125の関連データの開発が完了すると、データの対応する原子的特徴をマッピングから直接取り出すことができます。列挙と収集の理由は、ユーザーが使用中にタグの検索機能を必要とするためです。ユーザーがタグを検索する場合、250万の手動入力のコストが高すぎるため、オフラインおよびリアルタイムのプロセスで列挙および収集します。処理します。バルクロードを介してElasticSearchに書き込まれます。このプロセスでは、連続的な自己インクリメントIDも生成され、ユーザータグの転置リスト、つまり、取得した2番目のテーブルであるtag_mapテーブルがマップされます。さらに、3番目のテーブルのユーザー動作テーブルがあります。このテーブルは、リアルタイムのデータウェアハウスで作成されているため、一部が個別に強調されることはありません。
上記の3つの表の部分に基づいて、次の3セットのストレージを作成しました。
- 最初のセットは、ElasticSearchの検索タグストアです。
- 2番目のセットは、コアストレージでもあるDorisにあります。
- 3番目のセットは、IDマッピング全体のストレージです。
これらの3つのストレージを取得した後、さまざまな結合とクエリを実行できます。これにより、その後の洞察と群集の方向付けの基礎が提供されます。
次に、数桁を発表します。ユーザーXタグの順序は1100億、IDマッピングは幅の広いテーブル、1桁は8億5000万、ElastichSearch、1桁は250万です。これらの3桁は、ElasticSearchとDorisを選択した理由でもあります。
群衆のオリエンテーションプロセス
上記のデータがインポートされた後、3つのテーブルが形成されます。ここでは、3つのテーブルを使用して、群集関連の方向と群集パッケージが生成されます。
図3.2群衆のオリエンテーションプロセス
群集ターゲティングプロセスには、次の2つのタイプがあります。
- 1つ目は、ショッピングカートで群集タグをスクリーニングした後、群集を推定し、最後に群集サークルの選択をRedisに書き戻すプロセスを完了します。
- 2つ目は、群集の一般化です。AIモデルの全体的なトレーニングと群集の推論は、AIプラットフォームを介して完了し、Dorisに書き戻され、自信を持って選択され、ラベルが付けられます。
これら2つのプロセスのプロセスを簡単に説明します。
全体的なタグ検索。ユーザーのフロントデスクは、タグ検索イベントを生成した後、タグ検索を完了します。さまざまな名前の組み合わせを考えて目的のタグを探した後、このタグをタグショッピングカートに並べて配置します。このプロセスは、群衆のショッピングカートにさまざまなタグと組み合わせ条件を追加した後、人数をチェックするプロセスです。
このプロセスが存在する理由は、日常の運用で、各プロモーションまたはターゲットグループの規模を見積もるためです。もともと200万〜300万人程度のイベントで、観客選考後は5000万人と推定されるのであれば、選考条件が十分に正確ではないのではないかと思いますが、この場合は徐々に様々なものを追加していく必要があります正確な条件。そして、群集パッケージを形成する前に、円の選択を適切な範囲に制御します。これにより、このプロセスはループを続け、タグ/機能の適切な組み合わせを取得します。適切な組み合わせを取得した後、このラベルのターゲットと群集を決定する必要があります。このプロセスにより、群集パッケージが生成されます。群集パッケージを生成するプロセスは、テーブル結合操作を実行し、元のデータを相互に関連付け、IDマッピングテーブルも相互に関連付けます。オフサイトにエクスポートする状況がある場合は、IDマッピングテーブルが作成され、オフサイトID変換が完了します。次に、エクスポートされたクラウドパッケージIDとクラウドIDをReidsに書き込み、書き込み後に通知します。
プッシュやSMSなどのサービスを公開するためにクラウドパッケージを提供するだけでよい場合は、Redisに書き込む必要がないため、大量のストレージを解放してオフラインストレージに書き込むことができます。たとえば、一方ではHDFSであり、他方では、接続するオブジェクトストレージがこれらのストレージに書き込まれます。これらのストレージがプッシュシステムに直接送信された後、情報システムはクラウドパッケージを直接取得し、関連するプッシュまたはプッシュメッセージを関連するクラウドにバッチで発行できます。
群衆の一般化。群集の一般化プロセスには、最初に群集パッケージをアップロードするプロセスがある場合とない場合があります。このプロセスは主に、一部の企業では特定の歴史的活動の母集団があり、その母集団を一般化する必要があるという問題を解決します。クラウドパッケージが以前にプッシュをクリックしたことがある場合は、直接スクリーニングできます。スクリーニングが完了すると、すべてのユーザー特性がユーザートレーニングに関連付けられます。モデルトレーニングが完了すると、サイト全体のユーザーが推測され、信頼のバッチが取得されます。群集IDの結果が返され、Dorisに書き込まれます。このプロセス中に、別のプロセスが同時に開始されます。このプロセスは、ユーザー側で一般化の結果をフィルタリングし、適切な信頼度に応じて適切な数を選択できます。
次に、いくつかの一般的なプロセスを紹介します。開発が完了した後のコアプロセスは、タグとショッピングカートを追加し、従来の群集の一般化プロセスであるサークルの選択を完了することです。しかし、運用側とのコミュニケーションの結果、日常業務では運用側が実際に重複し、複数のプロセスを繰り返し使用していることがわかりました。実際の使用は次のとおりです。歴史的影響のある人を取得して一般化するが、一般化後が完了すると、それに応じてユーザー特性の効果が拡大され、この操作特性のラベルが重ね合わされて、円の選択と使用が完了します。
2つ目は、過去の影響を取得した後、洞察と分析を取得することです。ユーザーのポートレートを表示し、ラベルの関係に従って再選択し、一般化する前に過去のポジティブな群集パッケージを重ね合わせることを含みます。一般化後、配信条件を実現し、最終的にサークル選定を行い、広告・関連配信事業に参加します。操作側は、それらを使用する前に、アトミック機能に基づいてより複雑な組み合わせを多数実行します。
群集指向のパフォーマンスの最適化
バックグラウンド
図3.3群集指向のパフォーマンス最適化の背景と難しさ
現在のDMPシステムには2つの主要な機能があります。1つは群集の方向付けであり、もう1つは群集の洞察です。これらの2つの機能に基づいて、さまざまなユーザー側のポートレート機能を構築するための基本的な機能があります。解体を完了すると、群集オリエンテーションの機能のこの部分が、運用側またはビジネス側の問題点であることがわかります。
シナリオ要件
- 群集の見積もり、配送とマーケティングのシナリオでは、運用側に予想される人数が存在し、対応する規模のショッピングカートが構築され、新しい機能がショッピングカートに継続的に追加されます。新しい機能が追加されるたびに長時間待つ必要はなく、追加された後に丸で囲まれる新機能の数を確認してください。
- 群集の選択、ホットスポットの操作。運用側は、日々の業務でさまざまなホットイベントをフォローアップし続けます。特定のホットイベントが発生した場合は、群集パックをすばやく丸で囲んで、Psuhと推奨事項を公開する必要があります。サークルの選択プロセスに数分かかる場合、ホットイベントは見逃されます。
困難
- 上図に示すように、最初のデータ量は非常に大きくなります。
- 2番目の予想時間は非常に短く、群集の推定と群集のスクリーニングはそれぞれ1秒と1分で完了できます。
パフォーマンスの最適化（1）
最適化の最初の段階では、次の点でこれら2つの問題に対処します。
図3.3群集オリエンテーションパフォーマンス最適化の第1段階
転置インデックスと条件によるクエリ
図3.4群集指向のパフォーマンス最適化転置インデックスとIDマッピング
- まず、転置インデックスに関して、クエリ条件を元の条件からビットマップ関数の共通部分と相違点に変更しました。同時に、連続値を個別のラベルに分割しました。例：ユーザーの年齢は、0より大きく100未満のint型です。番号順にフィルタリングすると、操作側の制御が難しくなり、円の選択プロセスも不十分な使用結果につながります。したがって、年齢グループと呼ばれる、18〜25、0〜18などの別のラベルを年齢順に付けます。
- 次に、元のクエリと転置インデックス関連のクエリに変換すると、最初に作成されたテーブルがtag_group、tag_value_id、信頼区間識別子、ビットマップの順に並べ替えられます。同時に、この部分に基づいて、IDマッピングも実行する必要があります。インポートプロセスにおけるIDマッピングのコアは、ユーザーIDを継続的な自動インクリメントに変更することです。
クエリロジックの変更
図3.5群集指向のパフォーマンス最適化のためのクエリロジックの変更
元のクエリ条件はand、orであり、where条件ではありませんでした。現在、複雑な手段により、元のクエリ条件はbitmap_and、bitmap_or、bitmap_notに変更されています。ビジネスコードを使用して、andを介して外部操作を渡します。または視覚的背景構成のロジック。、のロジックはすべて機能ロジックに変更されます。これは、where条件を関数および集約ロジックに入れるのと同じです。
しかし、最適化後も2つの問題があります。
最初の問題は単一のビットマップが大きすぎることであり、2番目の問題はビットマップの空間分散です。これらの2つの問題により、交差点と差分の集計が実行されるたびに、ネットワークIOが非常に高くなります。
基礎となるドリスはbrpcを使用します。データ交換の過程では、各ビットビットが非常に大きいため、brpc送信の輻輳が発生し、場合によっては数百メガビットのビットマップが交換されます。数百メガビットのビットマップは、交差と差を計算するときにパフォーマンスが非常に低くなります。基本的に、1分で群集を一周するために到達したいので、1秒で群集を推定することは不可能です。
パフォーマンスの最適化（2）
残りの問題に基づいて、第2段階の最適化を実行しました。
図3.6群集指向のパフォーマンス最適化の第2段階
分割統治
第二段階の中心的なアイデアは分割統治法です。最初の波を開始したとき、群集推定能力は分レベルであり、円の選択は基本的に10分先であることがわかりました。分割統治の考え方は、サイト全体のすべてのユーザーを継続的な自己インクリメントIDにグループ化し、ある程度に従ってグループ化することです。たとえば、0〜100万はグループ、100万〜200万はグループです...徐々にいくつかのグループに分割されます。ステーション全体のユーザーの交差点と差は、グループ化後の交差点と差の結果の合計に相当します。
図3.7群集指向のパフォーマンス最適化分割統治
データプリセット
このルールを発見した後、分割統治法によって関連するデータのプリセットを行うことができます。Dorisのコロケーショングループ機能を使用すると、ネットワークのオーバーヘッドを回避するために、各グループの100万人全員が物理マシンに配置されます。
オペレーターの最適化
それらすべてを特定の物理マシンに配置した後、元のbitmap_and_notのビットマップnotとビットマップカウントを関数に置き換えることで、集約演算子を実装できます。現時点では、Dorisチームの新しいバージョンに基づいて、bitmap_and_not_countと同様の組み合わせ関数を追加した後、元のネストされた関数と比較してパフォーマンスが大幅に最適化されています。
解決
上記のソリューションのアイデアに基づいて、新しいソリューションを設計しました。
新しいソリューションは、クエリロジックの変更、推定からのサブロジックの合計、群集選択からのサブロジックのマージなど、上記の3つのアイデアに分けられます。
- 元のビットマップ計算が複数グループのビットマップ計算に変換されるため、マルチスレッドの並列処理がさらに向上し、計算速度が向上します。同時に、コードも最適化され、複合bitmap_and_or_not関数がマージされます。同じ機能に送信する場合、書き込みプロセス中に、グループIDと対応する100万グループが調整のために書き込まれます。
- 対応するタグテーブルは、オフラインとリアルタイムの両方で書き込まれます。タグテーブルの書き込みが完了したら、各タグの異なるユーザータグを異なる物理マシンに書き込むことができます。たとえば、300万を分割し、3つの異なる物理マシンに書き込んで、物理マシンの分離を完了することができます。これは、コロケーショングループとグループキーを使用して設定されます。書き込みが完了すると、計算プロセスは、元の全体的な計算から、グループごとに独立した計算に変わります。全体的なビットマップが非常に大きいため、各独立グループは物理マシン上で計算され、速度が大幅に向上します。
- 各グループが計算された後、それがマージされます。マージ後、群集の推定は、さまざまな物理マシンの数の単純な合計になり、結果は基本的に数秒で達成されます。群集の選択もさまざまな物理マシンのビットマップになり、シャッフルが出て最終的なマージを行います。このプロセスは非常に小さく、結果は1分以内に出力できます。
最適化の結果
次の2つのスクリーンショットは、それぞれマージ前後のクエリプランです。
図2.7群集指向のパフォーマンス最適化データプリセット
最適化の前に：クエリプロセスでは、最初に特定のタグに対してbitmap_andとbitmap_notまたはbitmap_orを実行する必要があります。その後、他のタグも同じ集計を実行し、集計後にシャッフルを実行し、最後に結合を実行します。同時に、他の部分も集約され、集約後、シャッフルと結合が実行されます。
これらのいくつかの集約プロセスでは、各タグのコストが非常に高く、参加する前に集約ネットワーク送信-再集約-再ネットワーク送信のプロセスを経る必要があります。
最適化後：クエリプランが大幅に変更されました。関数を介したマージプロセス中にクエリを実行するだけで、マージが完了した後、最終結果のマージを完了することができます。int型の追加であろうとビットマップのマージであろうと、最後のレイヤーのみがあり、速度が大幅に向上します。当初の一人当たりの見積もりは数分で完了できます。最適化後は、わずか数百ミリ秒で完了できます。数千の条件が複雑な場合でも、わずか1秒で完了できます。
群集の選択プロセスも上記のプロセスと同様です。複雑な条件の場合、1分から2分以上で完了することができます。条件が数十から100しかない場合は、群集の選択を約1分で完了できます。
プロセス全体で主にデータが分割されます。分割されたデータは、DorisのColocateの原則により、事前に物理マシンに事前設定されています。最適化により、ほとんどのシナリオの運用要件を満たすことができます。
将来と展望
事業の方向性
図4.1将来および展望ビジネスの方向性
赤いボックスの選択からわかるように、現在のシステムプロセスは、群集のオリエンテーションの後にマッピングを実行することです。ユーザーインサイトの観点から、それは群集を中心に構築され、同時に、リンクで各ビジネスサイドに接続しますマッピング、洞察、および群衆の。しかし、このプロセスでは、操作を通じて目標を達成する方法とABスキームを設計する方法で、2つの部分が緩く結合されます。
将来的には、DMP運用プラットフォームが緩く結合されたモデルであるだけでなく、ビジネスで強力な結合および強力な結合モデルを実装できるようになることを期待しています。このような操作モードは、使用プロセスでより快適になり、操作プロセス全体をDMPプラットフォームで完全に完了でき、関連するAB実験を設計し、操作効果に応じて継続的に最適化できます。
テクノロジー
図4.2将来および将来の技術動向
技術構築の過程で最も重要なことは、群衆を一周することです。操作側は、群集を選択するために何百もの条件を選択することさえあります。そして、これらのオペレーターは異なるビジネスに属している可能性があり、そのため、基本的な条件が非常に似たものになります。このような基本的な条件では、事前マージに対応するビットマップを手動で作成し、この機能に基づいて選択範囲を丸で囲みます。事前マージにより、その後の実行速度が大幅に向上します。
1つ目はクエリの効率です。すべての運用クラウド選択に対する定期的なスキャンとSQLパーサー。分析後、SQLの集計条件は事前集計用に自動的に設計され、対応するビットマップが合成され、関連する機能に登録されます。群集が選択されると、同じSQLパーサーを使用して以前に選択されたSQLも自動的に書き換えられます。書き換え前には、数十の機能が存在する可能性があり、それらは派生機能の結果とまったく同じです。現時点では、派生機能に直接置き換えることができます。この移動により、クエリのサークル選択率をさらに向上させることができます。
2つ目はインポート速度です。5日後、毎日約2TBのデータをインポートし、11TBのデータを保存する必要があります。データ量は比較的多いので、インポートプロセスをさらに高速化したいと考えています。現在、Sparkが業界内の特定のOLAPエンジンファイルを直接書き込むことを学びました。また、インポートまたは書き込みをすばやく完了することができるように、Sparkを介してDorisTabletファイルを直接書き込んでFEにマウントできるかどうかも検討しています。
質疑応答
Q：知乎のラベルシステムにはいくつのラベルがありますか？レコードはいくつありますか？背景に大きな幅の広いテーブルや複数のシートがありますか？群集選択時にテーブルをリンクすると、事業者は選択した群集の特徴や人数をリアルタイムで表示できますか？
A：知乎のラベルシステムは、ユーザー、コンテンツ、ビジネス、ビジネスガバナンス、セキュリティのラベルを含めて非常に大きく、DMPシステムは主にユーザーのラベルと接続します。認定済みおよび使用中のラベルグループだけでも、700近くのラベルがあり、ビジネスを追加すると、未認定のラベルの数は数千に達する可能性があります。使用しているユーザー側のタグには、120個のタググループと5個のライブタグがあり、合計125個のタグがあります。
記録に関しては、1100億の記録があります。
バックエンドは幅の広いテーブルではありません。サブタグが生成された後、tag1、tag2、およびtag3の独立したデータソーステーブルが生成されます。これらのテーブルをDMPに書き込んだ後、最終的には大幅テーブルになります。DMPでは、問題の大幅テーブルであり、ビジネスでは、それぞれ独立したラベルテーブルです。群集ラベルの円を選択すると、複数の大幅テーブルが接続されます。データ処理後、1つの大幅テーブルではなく1つのテーブルにデータを書き込みます。
最適化により、このテーブルに保存されているファイルは、タグIDのクエリの進行が遅いために分散しなくなります。保存されたキーに従ってキーを保存します。たとえば、0から100万のIDが同じ場所に保存されます。計算の過程で、同じ物理マシン上でスキャンし、集計ロジックの後で結果を取得できます。したがって、関連する数量の結果をリアルタイムで丸で囲むことができます。
Q：グループサークルの選択は、タグコンビネーションサークル選択の経験に基づいていますか？投資後の効果を分析する方法は？スタンドアロンの分析プラットフォームツールですか？クラウドパックのコンバージョン率を知るにはどうすればよいですか？コンバージョンはタグ付けに戻り、別の分析プラットフォームを使用して分析されますか？
A：群集の選択は2つの部分に分けることができます。最初の部分は、私たちの運用経験に基づくサークルの選択です。この部分は、既知の群集の選択と未知の群集の選択の2つのブランチに分かれています。
既知の群集サークルの選択は、このシーンについて操作が非常に明確であることを意味します。私たちが運営しているユーザーグループは、特定の性別やユーザー年齢層などであることがわかっています。今回は、過去の経験に基づいて選択を丸で囲みます。完全に未知のユーザー特性については、市場を直接一周します。
これら2つの運用プロセスの違いは、既知のユーザーグループのサークル選択の精度が高くなることです。既知の結果に基づくと、この打ち上げを完了するためにAB実験を実行する必要はほとんどありません。完全に未知のユーザー特性については、市場を直接循環させる場合、トラフィックの少ないAB実験を実施し、[プッシュ]をクリックしたユーザーが特定の関心を満たした後、この関心の部分に基づいて経験を蓄積し、設計できることを確認する必要があります。新しいもの。AB実験を行い、適切なシーンに合わせて群集の特性を調整します。効果が徐々に目的の目標を達成するまで、未知の群集から既知の群集に変化します。
別の経験があります。たとえば、広告主の経験、広告主はZhihuでの過去の経験がない場合がありますが、広告主は、携帯電話番号の暗号化されたMD5やモバイルIDFAの暗号化されたMD5など、私の製品を誰が購入したかを知っています。他のステーションが提供するエフェクトをインポートして、基本的な群集を形成することができます。群集の一般化を通じて、ステーションのすべての機能に参加してモデルをトレーニングし、AIの機能を通じて過去の購入群集の顕著な特徴を自動的に見つけてから、一般化のこの部分の選択を完了します。一般化ベースの選択後も、同じリンクを通過し、サイクルのこの部分を数回完了します。これにより、私のシナリオでどのユーザーにサービスを提供するかを知ることができます。
別の場所でコンバージョン率を確認します。これは、後でDMPプラットフォームに統合したいものです。別のページで、さまざまなプッシュのコンバージョン率を確認できます。DMPプラットフォームでは、エフェクトのリサイクルを通じてのみ表示できます。
Q：バックエンドはすべてDorisに基づいていますか？クラスタにはいくつのノードがありますか？
A：バックエンドの主なコンピューティングの側面は、Dorisに基づいています。また、高スループットのためにRedisに依存しています。TPPには、TiDBを使用します。現在のDorisクラスターは6ノードの64コア256gBEであり、3つのFEは6ノードの16コア32gクラスター構成です。
Q：群集の拡大は信頼できますか？すべての群集選択の割合と、使用されるアルゴリズムは何ですか？
A：群集の拡大はより信頼性があります。運用側からのフィードバックから、広告主や過去の運用効果に基づいて取得したデータだけでは基本的にこの運用の完了をサポートできないが、すべての機能を追加してトレーニングすれば、基本的に毎回CTRの観点からは、80％〜90％に達する可能性があるため、より明らかな改善になります。信頼水準は80％に調整されます。
クラウドサークル選択でのビジネス使用の割合は、一般的なサークル選択での使用の割合よりも少なくなります。一般的なサークルの選択については、現在の履歴にある機能にも自信があります。これらの既存の機能に基づいて、基本的にほとんどの運用作業を完了することができます。群集の一般化は、主にこれらの顧客の知識がまったくない状況を解決するために使用されます。同時に、ステーション内のすべてのランダムな大規模ユーザーをインポートして、ユーザーグループの特性を検出したいと思います。実際、このプロセスは運用側で比較的大きなワークロードを持っています。この特定のケースでのみ一般化が選択されるため、一般化の割合はあまり比例しません。たとえば、1日あたり300の機能ベースおよびラベルベースのオリエンテーションがあり、アルゴリズムベースの一般化は1日あたり1〜2回です。
どのアルゴリズムが使用されているかは調べていません。現在、このデータを使用して、AI学生の関連するアルゴリズムを呼び出します。現在提供しているのは、AIの自動的にトレーニングされたモデルにすべてのユーザーの機能を注ぎ込むことです。トレーニングが完了したら、モデルを再度呼び出し、推論のためにすべての機能を注入します。
Q：ABがReidsを使用してタグをチェックするかどうかを設計するにはどうすればよいですか？リアルタイムのパフォーマンスを維持する方法は？
A：ラベルを確認するための質問のテーブルAとテーブルBの場合、データ量が爆発的に増加します。この状況は存在します。したがって、ラベルを作成することをお勧めします。できれば、すべてのラベルをこの1つのテーブルに含めることをお勧めします。現在の調査では、この問題の解決策は、各物理マシンが100万を超えるストレージを格納する可能性があることですが、100万の各セグメントが同じ物理マシン上にあることを確認するために、この物理マシンのスキャンになり、直接実行できます。集約後の操作であるため、二重テーブルの結合の問題はなく、テーブルに直接集約できます。ビットマップに似ているかどうかにかかわらず、タグの計算はいくつかありますが、演算子に関しては、演算子はすでに集計演算子にマージされて集計が完了し、集計後に最終的なデータマージが行われます。パフォーマンスは大幅に向上します。より良く、AテーブルとBテーブルを結合した結果を回避することもできます。
2番目の質問では、この関数を渡して、群集のID集計を完了します。この機能が終了すると、現在の配信機能の下にいる人のリストが生成され、参加を完了します。現時点では、通常の結合にはそれほど爆発的な数はなく、数千億の高速クエリ計算も含まれません。
Q：約250万タグの関連コンテンツを解釈できますか？
A：図1.3からわかるように、タググループでは性別が1と数えられていることが主な理由で、250万のタグがあり、タグに関しては、男性、女性、その他3つのタグがあります。携帯電話のブランドの中で、現在、1つのタググループの下に20近くの携帯電話のブランドタグがあります。その後、topic-interestタググループにはかなりの数のtopic-interestタグがあります。たとえば、知乎には実際に多くのトピックがあります。一部のユーザーは、映画やテレビのコンテンツ、母親と赤ちゃんのコンテンツ、教育や学生のコンテンツに興味があるかもしれません。上記のトピックには、継続的な共通の関心があります。連続タグについては、今後の記事で紹介していきます。現在のユーザーポートレートのコンテンツに関して、タグからグループ化されている場合、それらはすべて個別のタグです。連続するタグは、より多くのユーザーの行動やオペランド値などです。
Q：ラベルと機能の関係は何ですか？ラベルはどのように作成されますか？
A：機能をラベルよりも大きく定義しています。現在の機能の90％はラベルであり、残りの10％はユーザーの行動の割合であることがわかります。
コミュニティに参加する
オープンソースを愛する友人を歓迎して、Apache Dorisコミュニティに参加し、コミュニティの構築に参加してください。GitHubでPRまたはIssueを送信するだけでなく、次のようなコミュニティの日常の構築にも積極的に参加できます。
テクニカル分析や応用実践などの記事を作成するためのコミュニティエッセイ活動に参加する、講師としてドリスコミュニティのオンラインおよびオフライン活動に参加する、ドリスコミュニティユーザーグループの質疑応答に積極的に参加するなど。
最後に、より多くのオープンソーステクノロジー愛好家がApache Dorisコミュニティに参加し、一緒に成長し、コミュニティエコシステムを構築することを歓迎します。
SelectDBは、Apache Dorisコミュニティにフルタイムのエンジニア、製品マネージャー、サポートエンジニアのチームを提供し、オープンソースコミュニティのエコシステムを繁栄させ、リアルタイム分析の分野で国際的な業界標準を作成することに専念するオープンソーステクノロジー企業です。データベース。SelectDBは、Apache Dorisに基づいて開発された新世代のクラウドネイティブリアルタイムデータウェアハウスであり、複数のクラウドで実行され、ユーザーと顧客にすぐに使える機能を提供します。
関連リンク：
SelectDB公式ウェブサイト：
Apache Dorisの公式ウェブサイト：
Apache Doris Github：
https://github.com/apache/doris
Apache Doris開発者メーリンググループ：
貢献したい：https ：//jinshuju.net/f/nEPj5W
