DMPパート1.キーワードを使用してオーディエンスをマイクロセグメント化する

記事の著者：ダニラ・ペレペチンダニラ・ペレペチン 、ドミトリー・チェクロフdcheklov



こんにちは。

データ管理プラットフォーム（DMP）は、オンライン広告の歴史全体で私たちのお気に入りのトピックです。 RTBはすべてデータに関するものです。

Targetixテクノロジースタック（ SSP 、 DSP ）についての一連のストーリーを続けて、今日は含まれるツールの1つについて説明します

DMP- キーワードビルダー

マイクロセグメンテーション

キーワードビルダーを使用すると、広告主は非常に狭いオーディエンスセグメント（マイクロセグメントとも呼ばれます）を作成できます。 こうしたオーディエンスを構築するために、次のメカニズムを使用することにしました。広告主はキーワードのリストを設定し、最後に、指定されたキーワードでページにアクセスしたか、検索でこれらの単語を検索したユーザーで構成されるオーディエンスを受け取ります。 一方では、これは非常にシンプルなツールであり、他方では、マーケティング担当者に実験の機会を提供します。



このツールの主な利点は、オーディエンスの作成を完全に制御できることです。 広告主は、最終的にどのユーザーが広告を見るかを明確に理解しています。 たとえば、次のようなキーワードのリストに基づいてオーディエンスを作成できます：ford focus、opel astra、toyota corola。



広告主の側から見た場合：







まず、この問題を解決するために、考えられるすべてのデータプロバイダー（生データサプライヤー）からクリックストリーム （ページへのユーザーアクセスの履歴）を取得します。 データは次の形式で提供されます。

{ user_id; url }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

目標と要件

私たちが楽器に求めた主な要件は、聴衆を作成する速度でした。 このプロセスは、最も頻度の高い単語でも5分以上かかることはありません。 キーワードを指定する際に、インターフェースの広告主がオーディエンスのサイズを推定できることも重要です。 サイズの推定は、単語を入力するときにリアルタイムで実行する必要があります（上のビデオで見られるように、100ミリ秒以内）。



理解を深めるために、ツールの要件の完全なリストを以下に示します。

• データの局所性の原則;
• データベースの高可用性（高可用性）;
• 水平方向のスケーラビリティ。
• 書き込み速度が速い。
• 高速全文検索;
• 高速キー検索。

確かに、このツールの最初のバージョンを作成した後にこれらの要件に達しました:)

「やってはいけないこと」を教える最初のアーキテクチャ

最初は、 MongoDBを使用しましたが、すべてうまくいきました。







訪問者の履歴コレクションは、ユーザーについて、ページインデックスに - ページについて書かれています。 ページURL自体は重要ではありません。ページをダウンロードしてキーワードを抽出する必要があります。 その後、最初の問題が発生しました。 実際、最初はページコンパイルされたコレクションはなく、キーワードはページインデックスに記録されていましたが、サプライヤーからのキーワードとデータの同時記録により、このコレクションに非常に高い負荷がかかっていました。 通常、 Keywordsフィールドは大きく、インデックスが必要であり、その時点のMongoDB（バージョン2.6）では、書き込み操作中にコレクション全体がロックされていました。 一般的に、キーワードを別のページコンパイル済みコレクションに配置する必要がありました。 私がしなければならなかった-だから何が、問題が解決された-私たちは嬉しいです。 今ではサーバーの数と特性を思い出すのは困難です...約50個のシャード。







キーワードでオーディエンスを作成するために、 Page Compiledコレクションにリクエストを行い、これらの単語が見つかったURLのリストを受け取りました。このリストでVisitor Historyコレクションにアクセスし、これらのページにアクセスしたユーザーを探しました。 すべてがうまく機能し（皮肉）、もちろん何も落ちない限り、1日に5、または10（!!!）のオーディエンスセグメントを作成できました。 当時の負荷は1日あたり約8億データポイント、TTLインデックス-2週間：800 * 14 ...大量のデータがありました。 作業が議論され、3か月で負荷が2倍になりました。 しかし、この奇妙な設計の寿命をサポートするために、さらにN台のサーバーを使用することは、決して面白くない。



このアーキテクチャの最大かつ最も明らかな欠点は、URLのリストの取得に関連する上記のリクエストです。 このクエリの結果は、数千、数百万のレコードになる可能性があります。 そして、最も重要なことは、このリストで別のコレクションにリクエストを行う必要があったことです。



アーキテクチャの他の欠点：

• グローバルロックによる不便な記録。
• インデックスの巨大なサイズ。これはデータの削除にもかかわらず成長していました。
• 大規模クラスターの監視の複雑さ。
• 全文検索の簡易バージョンを独立して作成する必要性。
• データ処理における局所性の原則の欠如;
• 聴衆の規模を迅速に評価できない。
• ユーザーをその場で視聴者に追加できないこと。

長所：

• すべての短所を理解しました。

何に来たの

一般に、最初から何かがうまくいかなかったことが明らかでしたが、今では明らかになっています。 リアルタイムで更新され、次の形式のレコードを含むテーブルが必要であるという結論に達しました。

 user { user_id; keywords[] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

考えられるソリューションを分析した後、1つのデータベースではなく、データの小さな複製との組み合わせを選択しました。 データを複製するコストが、このアーキテクチャが私たちに与えた機会と比較できないため、これを行いました。







最初のソリューションは、 Solr全文検索プラットフォームです。 ドキュメントの分散インデックスを作成できます。 Solrは、多くのドキュメントがあり、 Clouderaでサポートされている一般的なソリューションです。 ただし、本格的なデータベースとしての作業は機能しなかったため、分散HBase列データベースをアーキテクチャに追加することにしました。



最初は、Solrではユーザーがドキュメントとして機能し、すべてのキーワードを含むインデックスフィールドキーワードが存在することが決定されました。 ただし、テーブルから古いデータを削除する予定だったため、 ユーザー+日付の束をドキュメントとして使用することにしました。これがUser_idフィールドになりました。つまり、各ドキュメントにはその日のすべてのユーザーのキーワードが格納されます。 このアプローチにより、TTLインデックスによって古いエントリを削除したり、さまざまな「新鮮さ」のオーディエンスを構築したりできます。 Real_Idフィールドは実際のユーザーIDです。 このフィールドは、指定された対象期間を持つリクエストの集約に使用されます。



ちなみに、 Solrに余分なデータを保存しないようにするために、 キーワードフィールドにはインデックスが付けられているだけであったため、保存される情報量を大幅に減らすことができました。 この場合、すでに理解しているように、キーワード自体はHBaseから取得できます。



このアーキテクチャで私たちにとって有用だったSolrの機能：

• 高速インデックス付け;
• コンパクトインデックス;
• 全文検索;
• 要求に一致するドキュメントの数の推定。
• データ削除後のインデックスの最適化（他のデータベースでよくあるように、その成長を防ぎます）。

HBaseおよびSolrで複製されたアプリケーションは、HBaseでのみアプリケーションに書き込まれます。Clouderaサービスは、指定されたフィールド属性とTTLインデックスを使用してSolrのレコードを自動的に複製します。



したがって、大量のリクエストに関連するコストを削減することができました。 しかし、これらは私たちにとって必要であることが判明し、私たちの基盤となったすべての要素ではありません。 まず、オンザフライで大量のデータを処理する必要がありましたが、ここでは、 Apache Sparkとそのストリーミング機能が役立ちました。 また、データキューとして、この役割に最適なApache Kafkaを選択しました。



現在、作業図は次のとおりです。







1. Kafkaから、2つのプロセスがデータを選択します。 キューの機能により、それぞれが独自のカーソルを持つ複数の独立したプロセスに読み込むことができます。



2. PageIndexer-エントリから{user_id：[urls]}はURLのみを使用します。 Page Compiledテーブルでのみ機能します。

• データポイントが到着すると、ページが既にダウンロードされているかどうかを確認するためにHBaseにリクエストを行います
• ページがデータベースで見つからなかった場合、そこからキーワードを抽出します
• HBaseにデータを書き込みます。

3. VisitorActionReceiver — kafkaに保存されているユーザーアクションに関する情報を30秒（バッチ間隔）で収集します。

• キューから重複を削除する
• {user_id：[urls]}のようなエントリを作成する
• HBaseでページコンパイルテーブルにクエリを実行してキーワードを取得し、{user_id：[keywords]}のようなエントリを作成します
• ユーザーキーワードテーブルのHBaseでクエリを実行し、ユーザーが既に持っているキーワードを取得します
• ユーザーのキーワードの統合
• SolrおよびHBaseでの記録

4. SegmentBuilderはオーディエンスを構築し、既存のユーザーにリアルタイムで新しいユーザーを追加します。

• タイマーで、未処理の視聴者の存在を確認します。
• Solrでリクエストを作成し、対象ユーザーのユーザーを受け取ります。
• Aerospikeにデータを書き込みます

PageIndexerの機能は、さまざまな種類のページ（さまざまな単語のセット）に対して、ページからキーワードを選択することです。

1〜2台のサーバー32GB RAM Xeon E5-2620で動作し、1分あたり15〜30Kページをダウンロードします。 同時に、200-400Kレコードをキューから選択します。

また、 VisitorActionReceiverの主な利点は、Solr / HBaseにレコードを追加することに加えて、データがセグメントビルダーにも送信され、新しいユーザーがリアルタイムでオーディエンスに追加されることです。



セグメントビルダーは、Solrで複雑なクエリを生成します。Solrでは、異なるタグの単語に異なる重みが割り当てられ、ユーザーの関心の期間（短期、中期、長期）も考慮されます。 オーディエンスを構築するためのすべてのリクエストは、edismaxクエリを使用して行われます。edismaxクエリは、リクエストに対する各ドキュメントの重みを返します。 この方法で、本当に関連性の高いユーザーが視聴者になります。

1秒あたり約20Kの読み取り要求と2.5Kの書き込み要求がHBaseに届きます。 ストレージ容量は最大100 GBです。 Solrは最大 250 GBを占有し、7日間の最大2億5,000万件のTTLインデックスが含まれています。 （複製を除くすべての数値）。



インフラストラクチャの主な要素を簡単に思い出してください。

Kafkaはスマートで安定したキューであり、 HBaseは高速な列データベースであり、 Solrは長い間実績のある検索エンジンであり、 Sparkはストリーミングを含む分散コンピューティングであり、最も重要なことは、すべてがHDFS上にあり 、完全にスケーリングされ、監視され、非常に安定していることです。 Clouderaを搭載。

おわりに

さまざまなツールを使用してワークフローを複雑にしているように思われるかもしれません。 実際、私たちは最大の簡素化の道を歩んできました。 はい、1つのmonguをサービスのリストに変更しましたが、それらはすべて、作成されたニッチで機能します。

現在、キーワードビルダーは、広告主と常識のすべての要件を本当に満たしています。 250万人の視聴者が1〜7分で作成されます。 オーディエンスサイズの推定はリアルタイムで行われます。 8台のサーバーのみが関係しています（i7-4770、32GB RAM）。 サーバーを追加すると、パフォーマンスが直線的に向上します。



また、ハイブリッドリターゲティングプラットフォームで作成されたツールをいつでも試すことができます 。



ユーザーdcheklovに感謝します。記事を作成し、本当の道を教えてくれました=）。

DMPトピックは開始されており、公開されたままです。今後のリリースでお待ちください。