記事ディレクトリ
広告業務システムのデータブリッジ「ログセンター～露出データ転送・決済」
露光データ転送決済
暴露データは ADX のさらなる懸念事項であり、そのデータ フローは収益に関わる通信と決済の重要な橋渡しとなります。エクスポージャ データは実稼働場所に分割され、インターフェイスのエクスポージャ、リアル エクスポージャ、クライアントローディングのエクスポージャなど、多くの種類
に分類できます。さまざまなタイプの露出は、広告契約におけるさまざまな露出決済形式に対応します。インプレッションに加えて、コンバージョンやクリックなどの支払い方法もあります
インターフェイスの露出は最も高い制作位置にあり、サーバー サービスによって配信される広告スペースの最終候補になります。次にクライアントの読み込みが行われ、クライアントによって読み込まれたサーバーが候補を送信します。最後に実際の露出になります。は、ユーザの視界に現れる広告候補、露出度は、この順に大きい。
注: この記事本文の露出データはインターフェイスの露出です。
パイプライン アーキテクチャにより高可用性が促進される
上記の導入により、露出データの粒度は pv、つまり 1 つのリクエスト データに複数の広告枠の露出情報が含まれることがわかります。データ サイズはフローの入口と正の相関があり、それに応じて変動します。もちろん広告枠の粒度も考えられますが、データ規模が数倍になり、pvとのカップリング分析には追加のマッピング/集計ロジックが必要になるなど、状況に応じてシナリオが異なります。
サービスの高可用性と高パフォーマンスを確保するには、データ転送サービスの最大伝送容量とスケーラビリティを考慮する必要があります。**ここでは、このシナリオでデータ フロー機能を実行するのに適した「パイプライン アーキテクチャ」と呼ばれるアーキテクチャ パターンを紹介します。
パイプライン アーキテクチャのパターン図
このモードでは、データの流れがミドルウェアから始まりミドルウェアで終わり、途中にフローサービスが挟まれます。
このミドルウェアは、交通規模と交通動態/変化する上昇と下降に効率的に対応し、流れと下流の支持圧力を効果的に分離/排除します。
データ フロー サービスは上流および下流のサービスから完全に分離されており、ビジネス機能は軽量でありながら高度に専門化されています。データ消失がないことを前提に、サービスの柔軟かつ弾力的な導入・機能変更に対応し、高い拡張性を備えています。
データ ストリーミング ビジネスでは、このモードはこのようなシナリオで広く使用されています。
ストリーミングリンクの特別なキャッシュ設計
データ転送サービスに注目すると、露出データは再編成/分割/階層化され、データが抽象化され、「パブリック フィールド - ユーザー フィールド - 広告フィールド - 拡張フィールド...」スタイルに再編成され、kv はpvId/uuid 形式で形成されます。
Kv フォーマットでは、k はその後の決済およびデータラベル付けプロセスでエクスポージャーデータの一意の識別子として使用されます。
また、エクスポージャーデータの流れはADXフルデータであるため、次のパートの「モニタリングとレポート」サービスのデータサポートを提供するために、ここでデータキャッシュが実行されます。
まず、2次キャッシュ
ここでは、キャッシュは 2 つのレベルに分かれており、1 番目のレベルのキャッシュは Redis、2 番目のレベルのキャッシュは HBase です。【シーンに応じて多層化も可能】 キャッシュシステムに精通している学生、特にチケット販売や電子商取引に関わる業務を行っている学生。キャッシュ階層化の重要性をよりよく理解できるようになります。
現在のシナリオに基づいた簡単な説明は次のとおりです。
- 必要なのはパフォーマンスだけ
- キャッシュが発生する場合、重要なのはデータ読み取りパフォーマンスの向上です。特に同時実行性や大規模なトラフィックが多い場合、従来の DB、Mysql/SqlServer、およびその他のコンポーネントの容量、読み取りおよび書き込み特性のパフォーマンス、およびデータ ストレージの規模は明らかに場違いになります。
- ホットデータとコールドデータ
- 一部のシナリオでは、読み取りと書き込みの頻度が非常に高いデータ セットがあり、ホット データが形成され、対応するデータはコールド データになります。このデータの特性を考慮して、ホット データは 1 層目のキャッシュ層に配置され、コールド データは 2 層目のキャッシュ層に配置されることがよくあります。多くの場合、1 つの層がメモリ空間内に存在するため (当面はカーネル高速バッファは関与しません)、高速処理速度により、この限られた空間は非常に高価になります。
- …
上記のいくつかの要因に基づいて、ホット データとコールド データは期間に応じて分離されます。ホット データは Redis に保存され、コールド データは HBase に保存され、データ形式は kv です。
Nosqlデータキャッシュコンポーネント
キャッシュ コンポーネントの選択に関する質問に答えるためにここに来てください。
2 次キャッシュは Mysql などの従来のコンポーネントであることが多いですが、ここでは HBase が使用されます。違いは何ですか?
この疑問を持つ学生は、主に構造化データに基づいた従来型のビジネスに携わっている可能性があり、ストレージ構造とデータ構造の選択について深く理解していないのは当然のことです。
ADX システムの核となるデータ フローはストリーム処理に基づいており、障害を保証しつつ、精度と信頼性の両方を考慮する必要があります。従来のビジネスデータフローの処理方法とは大きく異なります。
もう 1 つの点は、このシナリオでは、キャッシュ システム内のデータが No-sql タイプに属する kv 形式であり、リレーショナル データベースをデータ キャリアとして使用できないことです。
HBase は、オープン ソースの分散型マルチバージョン データおよび列ベースの nosql データベースです。[ HBase の詳細については、フォローアップのブログ投稿/公開アカウントに注目してください。当面は注目しないでください]
- 強力な圧縮率
- カラムナ型ストレージは高い圧縮率を実現し、限られたスペースに無制限のデータを保存できます。levelDB、Prometheus など、他の列型ストレージも利用できます。
- 客観的なスループット
- HBase は、基盤となるストレージとして Hadoop の分散ファイル システム HDFS に依存し、数十億の行と数百万の列を持つ大規模なデータ テーブルに対するランダムなリアルタイムの読み取りおよび書き込みアクセスを提供できます。
最終的に、エクスポージャデータは決済タイプフィールドに分割され、異なる決済サービスに流れて計数処理が行われます。
優れたアーキテクチャ設計と適切な技術コンポーネントの選択は、ビジネス/チームが迅速かつ継続的に価値を提供できるようにする上で決定的な役割を果たします。
s2sモニタリングレポート
s2s のモニタリングとレポートは、ADX が広告露出、インタラクション [クリック/再生/ダウンロード/閉じる...]、および Win データをインターフェイスの形式で DSP [広告主] に転送することを意味します。広告主はこのデータに基づいてデータの帰属と決済を行い、広告の効果を説明/同期するためのコアチャネルです...
続きの記事をご覧ください!
推奨書籍：
広告・レコメンド・検索の3大複合ビジネス「広告業務システム詳細」
広告業務システムの過去と未来の継承「メッセージセンター」
広告業務システムデータ転送ステーション「ログセンター - リアルタイムサービス監視」
広告ビジネスシステムのデータブリッジ - 「ログセンター - 露出データ転送と決済」広告ビジネスシステムのコアチャネル -
「ログセンター - S2S監視とレポート」広告ビジネスシステムの補助意思決定
- 「」広告ビジネスシステム「AB実験プラットフォーム」
フレームワークPrecipitation —— 「データ消費型サービスフレームワーク」のSmart Fuse
広告ビジネスシステム —— 「スマートフローコントロール」のアジャイルデリバリー
広告ビジネスシステム —— 「Dockerコンテナベースのデプロイメント」
広告ビジネスシステムの業務接続—「PDB – 広告配信[数量と価格]」
3 行のコードで実現 - リンク リストの反転...
Kafka の高スループット、高パフォーマンスのコア テクノロジと最適なアプリケーション シナリオ...
HTTPS がデータ送信のセキュリティを確保する方法 - TLS プロトコル...
リアルタイムの構築Prometheus + Grafana に基づく監視システムを 5 分で完了...