01

02

リアルタイムコンピューティングは、秒単位または分単位の鮮度を必要とするデータ計算の問題に対処します。極めて高いデータ鮮度要件の下では、リアルタイムコンピューティングエンジンの安定性の問題が必然的にデータの適時性の問題につながります。一方、バッチコンピューティングは、より長い期間にわたって分散されたデータのバッチ処理を行います。典型的なビジネスシナリオには、履歴データマイニングやオフラインレポート計算などがあります。例えば、毎日作成される顧客レポートは、翌日の午前8時までに生成する必要があります。前日のデータが午後2時に利用可能で、レポート処理時間が30分であると仮定すると、5.5時間のエラー冗長期間があります。リアルタイムコンピューティングの別の例を考えてみましょう。リアルタイムデータストリームのSLAは、最大レイテンシが1時間以内であり、20分を超えるレイテンシの継続時間は1時間を超えてはならないとされています。このため、リアルタイムコンピューティングエンジンは、SLA違反が偶発的に発生しても回復できるよう、常に安定し、高いスループットを備えていることが強く求められます。重要なデータストリームには、効率的なプライマリ/バックアップ冗長性スキームが必要です。

複雑なオンライン検索システムでは、複雑なビジネスシナリオの要求を満たすために、通常、多層・多階層のファンアウトメカニズムが採用されています。1つのページビュー（PV）には、数百ものサービスへの呼び出しが含まれる可能性があり、そのほとんどは多数の均質で冗長なインスタンスで構成されています。各呼び出しは任意のインスタンスに発生する可能性があり、SLA制約内の障害は許容されます。リアルタイムコンピューティングでは、通常、ビジネスロジックを処理するために、複数レベルのオペレータが協調的に処理する必要があります。違いは、オペレータサービス内のインスタンスが均質ではないという点にあります。商用シナリオでは、ビジネスロジックはほぼ常に「exactly-once」セマンティクスに従います。これは、上流と下流のデータ依存関係、データの偏り、複数レベルのオペレータ間の処理速度の不一致といった問題につながります。リアルタイムコンピューティングは、階層的なプッシュ・トゥ・コンプリート、バックトラッキングとロールバック、複雑なトポロジにおけるバックプレッシャーの特定と緩和といった処理によって、問題をさらに複雑化させます。コンバージョンデータを例に挙げると、コンバージョンデータは広告主にとって最も重要なビジネスデータであり、広告のROIに直接影響を与えます。したがって、コンバージョンデータはビジネスデータストリームの中で最も価値のあるデータとなります。コンバージョンデータの処理には、リード収集、コンバージョントラッキング、アトリビューションと連結、不正防止処理、ストリーミング重複排除、ビジネスタグ付け、コンバージョン配信など、複数の段階が含まれます。いずれかの段階で異常が発生すると、ダーティデータ配信や処理のブロックなどの問題が発生する可能性があります。各ノードにおけるデータビジネスロジックの反復処理には包括的な考慮が必要です。発生したエラーは、データストリーム全体の安定性に影響を与え、複雑なバックトラッキングやロールバック操作を必要とする場合もあります。このプロセス中は通常、すべての変更が停止されるため、リアルタイムデータ反復処理の効率が大幅に低下します。つまり、リアルタイムコンピューティングの複雑さは、主にマルチレベルコンピューティングに起因しているのです。

今日のオンラインサービスの多くは、高い凝集性と疎結合を特徴としており、サービス間のインターフェースはほとんど、あるいは全く変更されず、主に内部的な反復的なアップグレードが行われています。オンラインサービスにおけるサービス間インターフェースの変更は、通常、複雑なテストと統合を伴い、その後、小規模な実験を通して慎重に展開されます。リアルタイムコンピューティングの分野では、データスキーマは、リアルタイムデータストリームの様々なレベルにおけるオペレータ間の「インターフェース」と捉えることができます。オンラインサービスのインターフェースは頻繁に変更されませんが、リアルタイムコンピューティングのデータストリームでは、新しいビジネスデータ処理ロジックをサポートするために、データスキーマに新しいフィールドやデータ型を頻繁に追加する必要があります。データスキーマの変更は、上流プロセスと下流プロセスにわたる変更の一貫性と順序を考慮する必要があるため、大きなリスクを伴います。一貫性のない変更や、データスキーマの変更順序が不合理だと、様々なデータフローの問題を引き起こし、数十万ドルにも達する可能性のある収益損失につながる可能性があります。今日のデータフライホイール時代において、絶え間なく流れるデータ需要と複雑なスキーマ変更プロセスは、主要な矛盾となっています。

03

1.表示データストリームは広告データの取得ログに相当し、そのデータ量はすべてのデータストリームの中で最も大きい。広告取得ログには、広告の表示スタイル、広告ソース、広告チャネルなどの情報が記録される。このデータフィールドには数千ものフィールドがあり、データフィールドの反復処理が頻繁に必要となる。

2. クリックログは広告課金に使用されます。新製品のリリース時には、収集されたクリックデータに基づいて異なる課金ロジックが適用されます。クリックデータは広告プラットフォームの収益に直接影響を与えるため、重複やデータ損失を確実に防ぐための厳格な要件が設けられています。

3. 前述のように、コンバージョン データは、広告主のフィードバックや管理されたランディング ページからのデータ収集から得られる、最も商業的に価値のあるデータです。

3.1 シナリオベースのビジネスデータ開発

まず、異なるトラフィック バジェットの組み合わせには、価格保護、コスト管理、頻度管理などのリアルタイムの意思決定戦略が異なりますが、それらはすべて、表示ポイント変換データの同じフィールド前処理ロジックに基づいています。

第二に、リアルタイム意思決定はデータ駆動型のビジネスであり、戦略の反復ごとに新しい分野の導入が伴うと言えます。

3 番目に、多様なリアルタイムの意思決定戦略では、ビジネス フレームワークをカプセル化し、計算とストレージを分離してカスタム ビジネス ロジック (UDF) をサポートする必要があります。

データ ソース情報の作成: ユーザーは、プラットフォーム上のデータ ソースのメタデータ情報を登録し、アカウント権限の検証を完了し、データ ソースのメタデータ バージョンを関連付けます。

データ テーブルの作成: ユーザーは、プラットフォーム上にデータ テーブルの作成を申請し、メタデータを記述し、ビジネス特性に基づいてデータ テーブル GC サイクルを選択します。

カスタムロジックの作成：ユーザーはプラットフォーム上でカスタムロジック（UDF）を編集し、登録を完了できます。バージョンがリリースされると、UDFはプラットフォーム上で使用できるようになります。

インポート タスクの作成: ユーザーは、インポートするデータ ソースとデータ テーブルを選択し、ETL 処理ロジックを記述する SQL を記述して、インポート タスクを作成します。

エクスポート タスクの作成: ユーザーはエクスポートするデータ テーブルを選択し、エクスポート ロジックを記述する SQL を記述し、エクスポート先として HDFS またはメッセージ キューを選択できます。

新しいフィールドの追加: ユーザーはデータ ソース情報とテーブル情報を変更し、インポート/エクスポート ロジックで新しいフィールドを使用できます。

3.2 RTSプラットフォームエンジン

04