Engineering practice for real-time business support of B-side algorithms

a 背景

マーケティングシナリオにおいて、アルゴリズムチームは広告主向けにパーソナライズされたマーケティングツールを提供し、コストを抑えながらマーケティングの精度向上と ROI の改善を支援しています。これまで、入札戦略のリアルタイム推定、キーワード一括サービスの同期、リアルタイム特徴量生成など、複数のリアルタイムビジネスシナリオをサポートしてきました。ODPS はビジネス側の柔軟なニーズに対応できますが、Blink の活用はまだ十分とは言えず、ここで得た経験を共有し、お役に立てれば幸いです。

2 技術選定

Blink を選ぶ理由は以下の通りです。大半のオフラインシナリオでは、リアルタイム性が求められない場合やデータソースがバッチモードの場合、および TT、SLS、SWIFT、シーケンスなどの非ストリーミングデータソースでは ODPS が適しています。一般的に、データソースがリアルタイム (TT/SLS/SWIFT など) で、ODPS のシーケンシャルリードが必要かつ高いリアルタイム性が求められるシナリオでは Blink が適しています。

現在 Blink はバッチモードとストリーミングモードの両方をサポートしています。バッチモードは開始時刻と終了時刻を固定し、ODPS と比較してリソースを事前確保・専有できるためリアルタイム性を保証できます。ストリーミングモードは従来の意味でのリアルタイム消費で、ミリ秒レベルの処理を実現します。

開発モードの観点では、主に ODPS MR に近い Data Stream モードと SQL モードに分かれます。使いやすさの観点では SQL が最も学習コストが低いですが、複雑なシナリオでは Data Stream モードの制御能力が優れており、さまざまなキャッシュやデータ構造を柔軟に定義し、複数のシナリオに同時対応できます。

3 主要シナリオ

1 リアルタイム再生による入札戦略評価

ビジネスの背景

Replay システムは、オンライン入札ログを収集・構造化・後処理するシミュレーションシステムです。Through Train オンラインエンジンのリコール後の入札情報を記録し、主にオンラインリコール、入札、スコアリングなどのキュー情報をカバーします。ソートと控除式と組み合わせることで、ログを使用してオンライン入札環境をシミュレートできます。簡単に言えば、bidword に対して別の入札を採用した場合にどのような結果がもたらされるかを評価できます。リプレイシステムにより、アルゴリズムチームと広告主はオフライン AB テストの前にトラフィックを使用してユーザー戦略変更の効果を推定でき、より制御しやすくなります。同時に、ネガティブ戦略のテスト過程で市場の収益への影響を最小限に抑えられます。

アルゴリズムチームは、オンラインの精緻なソートとリコールログに基づいてビジネスサイドでの複数の入札戦略評価を実現し、サンプリングされたログ (10 億データ) を 1 日以内に再生して入札戦略を評価し、広告のリアルタイムオフラインをサポートすることで、オフライン広告の入札戦略への影響を回避することを望んでいます。10 億データボリュームを 1〜2 時間以内に完了させることが期待されています。

主な課題

1,000 万件のマテリアルデータの読み込み。
高 QPS (100 万) でのオフライン広告のリアルタイム同期。
ビジネスサイドのデカップリング — 全体のリアルタイムジョブリンクとビジネスの分離を実現する方法。
ソリューション

マテリアルデータの読み込み：Blink 起動時に全データを直接読み込み、高 QPS 条件での IGraph アクセスへの負荷を回避します。さらにブロードキャストモードを採用し、1 回の読み込みで各ノードが使用できるため、ODPS データの複数回読み込みを回避します。

オフライン広告情報はバケット単位で IGraph に保存され、定期キャッシュモードでオフライン広告の全量が読み取られます。200 万以上の QPS クエリを約 1 万に制御し、RateLimit 電流制限コンポーネントを使用してアクセス同時実行を制御します。IGraph の同時実行制御を約 40 万に制限し、全体のトラフィックを平滑化します。

全体のリアルタイムエンジニアリングフレームワークは UDF インターフェースを予約し、ビジネスサイドは SDK を実装するだけで、その他のエンジニアリングパフォーマンス、同時実行、電流制限、埋め込みロジックは内部で実装されます。エンジニアリングフレームワークとアルゴリズム戦略 Replay のデカップリングをサポートします。

まとめ

本ビジネス要件に基づき、Blink ストリーミングバッチモードの柔軟な機能を活用して、固定開始・終了時刻を持つ TT データのデータ処理を実現しました。TT 読み書きコンポーネント、ODPS コンポーネント、IGraph コンポーネント、埋め込みポイントコンポーネントを蓄積しました。これらの蓄積されたコンポーネントは、その後の類似ビジネスのジョブ開発を十分にサポートし、コンポーネントがその後のジョブのプロダクト化に基本機能を提供しています。

2 リアルタイム特徴量

ビジネスの背景

B 側アルゴリズムの発展に伴い、モデルアップグレードによる増分配当が徐々に減少しています。顧客のリアルタイム情報からユーザーの意図をさらに把握し、潜在的なニーズをより包括的かつリアルタイムに発掘し、B 側の視点から成長スペースをさらに拡大する必要があります。オンラインユーザー行動ログに基づいてユーザー行動のリアルタイム特徴量を生成し、アルゴリズムチームはリアルタイムデータを使用してオンラインモデルを改善しています。

本要件に基づき、ユーザーリアルタイム特徴量出力リンクを構築し、上流の A+ データソースを分析してユーザーリアルタイム特徴量を取得しました。リアルタイム特徴量は主に以下を含みます：

ユーザーの約 50 の特徴量データ値を取得し、IGraph に出力します。
特定の特徴量を持つユーザー ID を出力し、分単位で集約します。
過去 1 時間の特定の特徴量の合計、平均値、または件数を出力します。
主な課題

リアルタイム特徴量データ開発の量は非常に大きく、各特徴量データに対してリアルタイムデータリンクを開発・保守する必要があり、開発と運用・保守のコストが高く、車輪の再発明が繰り返されています。
特徴量データ開発には開発者の理解が必要です：

データソース：ファクチュアルデータソースに基づいて ETL 処理が実行されます。
計算エンジン：Flink SQL は独自の計算セマンティクスを維持しており、シーンに応じて習得し、熟練して使用する必要があります。
ストレージエンジン：リアルタイムデータ開発はサービス提供まで実装する必要があるため、IGraph、HBase、Holgres などのリレーショナルストレージエンジンを選択する必要があります。
クエリ最適化方法：異なるストレージエンジンにはそれぞれのクエリクライアント、使用方法、最適化方法があるため、さまざまなエンジンの使用方法を学ぶ必要があります。
ソリューション

製品設計の観点から、リアルタイムプラットフォーム機能を設計し、ODPS でオフラインテーブルを開発するのと同じくらい簡単にリアルタイム特徴量を開発できるようにしました。製品の利点は、ユーザーが SQL を理解するだけでリアルタイム特徴量を開発できることです：

リアルタイムデータソースの知識が不要です。
基盤となるストレージエンジンを理解する必要はありません。
SQL だけでリアルタイム特徴量データをクエリでき、異なるエンジンのクエリ方法を学ぶ必要はありません。
Jiguang プラットフォーム、Dolphin エンジン、Blink エンジン、ストレージエンジンをエンドツーエンドで直列に接続し、ユーザーにエンドツーエンドの開発体験を提供し、自身の作業に関係ない技術詳細を認識せずに済みます。

関連プラットフォーム紹介：

Dolphin インテリジェントアクセラレーション分析エンジン：Dolphin インテリジェントアクセラレーション分析エンジンは、Alimama データマーケティングプラットフォーム Dharma Disk (DMP) シナリオから派生したもので、一般的な OLAP MPP コンピューティングフレームワークをベースに、マーケティングシナリオの典型的な計算 (ラベルサークル、インサイト分析など) に向けて、ストレージ、インデックス、コンピューティングオペレーターのレベルで大幅なパフォーマンス最適化を実施し、計算パフォーマンス、ストレージコスト、安定性の大幅な改善を達成しました。Dolphin 自体はアクセラレーションエンジンとして位置付けられており、データストレージとコンピューティングオペレーターは ODPS、Holgres などの基盤エンジンに依存しています。プラグイン形式で、Holgres にオペレーターの統合と基盤データのストレージ・インデックス最適化を完了し、計算パフォーマンスの桁違いの改善と特定のコンピューティングシナリオでのビジネススケールのサポートを達成しました。現在、Dolphin のコアコンピューティング機能には、カーディナリティコンピューティングカーネル、近似計算カーネル、ベクター計算カーネル、SQL 結果のマテリアライズ、クロス DB アクセスなどがあります。Dolphin は一連の SQL 変換・最適化機能も実装しており、ユーザーが入力した元の SQL を基盤となる最適化されたストレージ形式と計算オペレーターに自動変換します。ユーザーは基盤データの保存や計算方法を意識する必要がなく、元のデータテーブルに従って SQL を記述するだけでよく、利便性が大幅に向上します。

Jiguang 消費者操作プラットフォーム：Jiguang は、マーケティングアクセラレーションシナリオ向けのワンストップ研究開発プラットフォームです。プラットフォームのプロダクト化を通じて、特徴的なエンジン機能をユーザーに提供します。サポートされている特徴的なシナリオには、超大量規模のタグ交差・差分 (数十億のタグサークルをミリ秒で出力)、crowd インサイト (数百億の秒次クエリ)、秒次の効果帰属 (イベント分析、帰属分析)、リアルタイムかつ百万レベルの crowd ターゲティング機能があります。マーケティングデータエンジンを基盤に、Jiguang はワンストップの運用保守管理、データガバナンス、セルフサービスアクセス機能を提供し、ユーザーがより便利に利用できるようにしています。Jiguang は検索・プロモーション向けの一般的なデータエンジンテンプレートを蓄積しており、カーディナリティ計算テンプレート、レポートテンプレート、帰属テンプレート、crowd インサイトテンプレート、ベクター計算テンプレート、近似計算テンプレート、リアルタイム配信テンプレートなど、成熟したビジネステンプレートに基づいて、ユーザーはゼロコスト・コードなしで利用できます。

現在のビジネスニーズに応じて、リアルタイムデータソースとストレージデータソースをカプセル化しています。

リアルタイム特徴量オペレーターを実装：

concat_id：

意味：入力テーブルに入力されたレコードからフィールドを選択し、タイムスタンプで降順にソートします。パラメータ設定で ID とタイムスタンプによる重複排除が可能で、ユーザーがトップ K データを取得できます。
使用例：

意味：入力テーブルに入力されたレコードからフィールドを選択し、指定した時間範囲の合計、平均値、またはカウントを計算します。
使用例

まとめ

B 側アルゴリズムのリアルタイム特徴量要件に基づき、Blink SQL + UDF によるリアルタイム特徴量出力システムを構築しました。ユーザーが提供した SQL をエスケープし、Bayes プラットフォーム上で Bin SQL ストリーミングタスクを生成し、リアルタイム特徴量データを生成して IGraph に保存します。IGraph コンポーネントへの Blink 書き込み、concat_id オペレーター、集約オペレーターなどの基本機能を蓄積し、その後の Dolphin ストリーミングリアルタイム特徴量出力システムの基盤を築きました。特徴量オペレーターの多様な拡張方法に対応し、このようなユーザーのニーズに迅速に対応できるようサポートしています。

3 キーワード一括同期

ビジネスの背景

毎日、多くのマーチャントが様々なチャネルから Through Train に参加しています。また、新規顧客の受け入れには大きな余地があります。一方、システムの既存顧客の低アクティブ層にも最適化の大きな余地があります。システムは、新規顧客獲得と低アクティブプロモーションの重要な出发点として、Through Train の新規顧客と低アクティブ顧客に対して高頻度なキーワード更新 (日次→時間レベル) を通じて、ターゲット顧客の広告がより多くのキーワードを試して優れたものを残し、不要なものを削除することで、顧客の成長を促進することを目的としています。

本要件に基づき、既存の日次オフラインリンクに時間レベルのメッセージ更新リンクを追加し、標準プラン配下の各ワードパッケージの更新とスマートプランのシステムワード更新をサポートします。1 時間あたりのメッセージ更新量は数千から数万に達し、Blink を使用して FaaS の関数サービスを ODPS リクエストパラメータで呼び出し、各リクエストの結果を ODPS 出力テーブルに書き込みます。更新頻度は 2 時間ごと、更新時間は午前 8 時から午後 10 時まで、単一の追加・削除規模は 500 万件追加 / 500 万件削除です。

主な課題

Blink バッチジョブの時間レベルスケジューリング。
FaaS 関数呼び出しのレート制限。
ソリューション

Blink UDF を使用して HSF の関数サービス呼び出し機能を実装します。
Blink UDF は RateLimiter によるレート制限を使用し、ノード並列度で関数サービスへのアクセス QPS を厳密に制御できます。
DataWorks プラットフォームでシェルスクリプトを設定し、Bayes プラットフォームでバッチコンピューティングタスクをスケジュールします。
まとめ

本要件に基づき、Blink SQL バッチモードを使用してこのようなニアリアルタイム更新リンクを実装し、このようなバッチジョブのスケジューリングモードを確立し、その後のバッチジョブの商業化の基盤を築きました。

4 将来の展望

B 側アルゴリズムのビジネスに基づき、Dolphin エンジンは Dolphin ストリーミングリンクを設計・開発しました。Aurora プラットフォームでのユーザーのリアルタイム特徴量の開発が、ODPS でオフラインテーブルを開発するのと同じくらい簡単になります。ユーザーはリアルタイムデータソースや基盤ストレージエンジンを理解する必要がなく、SQL でリアルタイム特徴量データをクエリできます。ただし、B 側アルゴリズムビジネスにはこの記事で説明されているようなバッチ処理サービスもあります。これらのビジネスでは、Blink バッチ SQL、Blink ストリーミングバッチモード、ODPS UDF、Java コードタスクを開発し、スケジューリングスクリプトを提供し、最終的にプロジェクトをパッケージ化してアルゴリズムチームが使用できるようにする必要があります。今後は、ユーザーが Jiguang プラットフォーム上でバッチコンピューティングサービスを自己開発できるようにし、アルゴリズム開発コストを削減し、スケーラブルで低コストなバッチコンピューティングエンジン機能を提供し、ビジネスの迅速なイテレーションをサポートし、ビジネス実装が迅速に成果を上げられるように支援したいと考えています。