How to update 100 million level video content in real time?

1. 背景
オンラインサービスとして、検索レコメンデーションシステムは、オンラインクエリの性能要件を満たすため、クエリ前のデータをインデックスデータとして構築し、異種ストレージメディアにプッシュしてオンラインクエリを提供する必要があります。この段階では主に、リアルタイムエンティティの処理と更新、オフライン前処理、および Offline/Nearline 経由のアルゴリズム処理データを扱います。これには、アルゴリズムによるオフラインおよびオンライン処理と、異なるビジネスドメイン間の最終的なデータマージング（リコール、ソート、相関計算など）が含まれます。プラットフォーム機能の面では、従来のデータウェアハウスモデルが採用されています。すなわち、共通リソースと共通機能を中心に構築し、ビジネスの上層部に向き合うデータを分離する階層化戦略を形成するモデルですが、ビジネスのアジャイルな反復、ナレッジ化、サービス化という文化的特性の面では、もはやニーズを十分に満たせなくなっています。

知識グラフは、データの構造化組織と体系化管理の中核技術として、実際のビジネス指向アプリケーションプロセスにおいて、ナレッジ、ビジネス、サービスの要件を十分に満たすことができます。コンテンツグラフシステムを基盤とする特徴量プラットフォームの構築に基づき、動画、番組、ユーザー、キャスト、要素などのコンテンツを中心に、リアルタイムなナレッジフュージョンとデータ更新を実現するプラットフォームを構築します。

2. 設計概要
検索レコメンデーションシステムに基づくデータ処理パイプラインには、一般的に以下のステップが含まれます。コンテンツ制作側（メディアアセット、インタラクション、コンテンツインテリジェンス、Baoluo、Granary、Linlang など）からダンプされた完全データとビジネス側からの増分データを受け取り、ビジネスドメイン別にレイヤーごとに処理してから、インデックス構築を通じてエンジン側に入力します。

他のビジネスシナリオと異なり、Youku のシナリオでは、受け取るコンテンツ制作側はソース制作端ではなく、その間に多くの半処理済み異種データが混在しており、データ整合性（論理的整合性、機能的整合性）に課題があります。ユーザー側には実際的な問題があり、特にリアルタイム出力と完全データ出力で構造の一貫性を保つ必要があり、同時に検索エンジンのフィールド構造とも一致させる必要があります。データの構造化組織とビジネスシステム管理の観点から、インデックスプラットフォームを更新・設計します。

1 データの構造化組織
エンターテインメントブレイン のアプリケーション指向ミドルレイヤーを設計し、知識グラフをミドルレイヤーに導入して、ビジネスドメイン向けのデータ組織方式を実現します。知識グラフをミドルレイヤーのデータモデル層に統合し、エンティティ、リレーションシップ、イベント、ラベル、指標を含む知識グラフの統合ビューを活用して、ドメイン指向のデータモデルを定義します。動画ドメインの知識グラフをミドルレイヤーのデータ組織の基盤として使用し、ビジネスドメインにおけるデータ組織の変革を実現します。

2 ビジネスシステム管理
アルゴリズムのロジックをコンポーネント化モードでカプセル化し、ビジネス側が 1 セットのロジック、リアルタイムと完全データのコードのみを維持すればよいようにし、統一 UDF を使用して実現します。Blink のストリームバッチ統合アーキテクチャを活用して、完全増分アーキテクチャモデルを実現します。たとえば、完全データのクリーニングと修正ロジックを実行する場合（リアルタイムエンジンにはメッセージ損失防止の仕組みがあるため、完全データを毎日実行する必要はありません）、完全データも同じロジックを通過させることができます。

3. 主要モジュール
1 特徴量ライブラリ
特徴量ライブラリは 2 層で構成されます。第 1 レベルは完全データと増分データの特徴量計算で、異なるデータソース（リアルタイムとオフラインを含む）に接続します。特徴量ドメインの計算ではオフライン完全データを使用せず、コールドデータや修正済みデータにはストックの完全セットを使用してストリーム処理を再度実行します。データ組織は頂点とエッジのリレーショナルテーブルに保存されます。リアルタイム更新プロセスでは、上流からの逆引きによるパフォーマンス負荷を軽減するため、異なるエンティティ属性の変更を内部グラフで直接クエリし、DataAPI を統一してカプセル化してこれらのデータを操作します。異なるタイプの頂点は独立した Blink ジョブで計算します。

オフラインデータ組織の面では、検索エンジンのオンラインサービスマシンはデータを永続化しません。新しいオンラインマシンがクラスターに参加する際、データロードのためにどこかから完全インデックスファイルをプルする必要があります。インデックスモデルと同一構造の完全ファイルをアセンブルします。完全ファイルはあるタイムスタンプのスナップショットに過ぎません。完全ファイルのタイムスタンプが古いほど、追跡すべきリアルタイムメッセージが多くなり、障害復旧速度も遅くなります。最新の完全ファイルをできるだけ迅速に生成して、リアルタイム増分メッセージのパフォーマンス負荷を軽減する仕組みが必要です。

第 2 レベルの特徴量計算は、検索相関、ソート、リコールなど、アルゴリズム指向のアクセスを提供します。このレイヤーはビジネスドメインに直接対応し、第 1 レベルの特徴量ライブラリのデータを直接消費します。ビジネスの主要ロジックはこのレイヤーに集中して計算されます。リアルタイムとオフラインのロジックは主にコンポーネントライブラリを通じて完了します。

2 コンポーネントライブラリ
異なるビジネスラインのアルゴリズムが同じデータから各自のビジネスに応じて必要なデータを取得して処理するため、コードの重複が生じます。コンポーネントライブラリは主要なオープン適応インターフェイスを確立し、同じ機能コードの再利用を可能にして重複開発を削減します。

コンポーネントライブラリは、ビジネスロジックをシンプルな UDF ベースの算術式として抽象化して整理します。シンプルで簡潔、かつ保守しやすい構造です。特徴量の利用者は特徴量の粒度にだけ注目すればよく、全体像を把握する必要はありません。

3 Trace & Debug モジュール
各メッセージにはユニークな署名（UUID）があり、ソースデータは各計算プロセスを流れます。ビジネスが処理中の問題をよりよく追跡・処理できるように、異なるシステムデータを UUID とエンティティ ID で集約し、Trace & Debug サービスによりビジネスプロセス情報とシステム処理情報を比較しやすくします。

4. 技術詳細
全体のコンピューティングフレームワークは次世代リアルタイムコンピューティングエンジン Blink を採用しています。主な利点はストリームとバッチの統合にあります。ビジネスモジュールをジョブで分割し、異なるコンピューティングモジュールを自由に組み合わせることができます。消費サイトは自動的に保存され、メッセージの損失はなく、プロセスのフェールオーバー自動復旧メカニズムを備えています。分散コンピューティングにより、単一障害点の消費ソースと書き込みパフォーマンスのボトルネックを排除できます。ストレージエンジンは Lindorm をエンティティデータストレージに使用し、主に Lindorm セカンダリインデックスで KV と KKV データ構造を保存し、知識グラフの基礎データを構築しています。

1 知識グラフのストレージと組織
Labeled Property Graph（LPG）でモデリングを行い、Lindorm を主要ストレージとして使用します。エンティティテーブル（動画、番組、キャストなど）を頂点テーブルとし、エンティティ間のリレーションシップは Lindorm のセカンダリインデックス機能を活用してエッジテーブルとします。

データアクセス面では、データ駆動レイヤーを実装して外部向けに API を提供し、開発者はローカル API を使用して Lindorm を操作します。インターフェイスレイヤーがリクエストを受信すると、データ処理レイヤーを呼び出して具体的なデータ処理を完了させます。Java コード属性と Lindorm カラム値の変換や結果クエリの値マッピングを隠蔽し、アノテーションを使用して設定とマッピングを行い、Java オブジェクトを Lindorm の行列ストレージに直接シリアライズする問題を解決します。

2 計算と更新戦略
特徴量計算とインデックス更新には Blink コンピューティングプラットフォームを使用します。完全増分アーキテクチャを採用しているため、完全更新プロセスでの逆引き負荷が軽減され、カラム更新戦略を採用しています。異なるエンティティ属性やエッジテーブル属性の更新（エッジテーブル属性はグラフクエリプロセスでの頂点クエリ負荷を軽減するため）では、カスケード更新戦略を採用しています。すなわち、属性更新後に新しいメッセージを生成してバスリンクエンドにプッシュし、異なるエンティティやリレーションシップがそのメッセージをサブスクライブした後、必要に応じて自身の属性を更新します。

ビジネス更新の中核要件は整合性であり、その本質はメッセージの損失を防ぎ、順序を維持することです。MetaQ を主要メッセージチャネルとして使用しており、MetaQ 自体にはメッセージ損失がなく、障害は主に外部サービス、ストレージ、処理リンクのレベルで発生します。

エンティティデータやリレーションシップデータの操作（通常は 1 つのジョブ）では、アトミック操作を使用し、内部に一定のリトライメカニズムがあります。たとえば、外部サービスへのアクセス時には、それ自体にリトライメカニズムがあります。全体のリンクパフォーマンスに影響を与えないよう、Fast try と呼ばれるリトライで、一般的にタイムアウトなどのネットワークジッターに対処します。失敗した場合はサイトを保持し、データをリトライキューに書き込み、例外をスローして最外層でキャッチし、この更新を破棄して次のメッセージを受け取ります。失敗メッセージは 5 分後、10 分後、20 分後に合計 3 回リトライされ、それでも失敗した場合は通知を送信して人為的な介入を促します。

3 統一 UDF
UDF の中核でビジネスロジックを解決することで、さまざまなシステム間で移植可能となり、技術的手段を通じて 1 セットのビジネスロジックのみを維持するようにします。各コンピューティングプラットフォーム（オフライン/リアルタイム）で再利用可能で、UDF ビジネスロジックの一貫性と移植性の問題を解決します。

5. まとめと展望
コンテンツグラフの構造特性とインデックス更新プラットフォームに基づき、従来のデータウェアハウスモデリング手法を構造面で打破し、ナレッジ、ビジネス、サービスの観点からデータプラットフォームを構築して、コンテンツ、行動、リレーションシップグラフを蓄積しています。現在、Youku 検索、Piaopiao、Damai などのシナリオで適用されています。

グラフニューラルネットワークと表現学習の継続的な発展に伴い、グラフストレージとグラフコンピューティングでの OLTP と OLAP の深い最適化にさらに注力し、深層アルゴリズム戦略を使用してリアルタイムフュージョンとリアルタイム推論の構築を補完していきます。

インデックス更新プラットフォーム構築の面では、マルチパーティーサービスのアクセスと検索とプッシュの統合による課題に対応し、インデックス更新は完全増分化に向けて進んでいます。ビジネスセルフサービス面では、抽象 DSL をさらに探求して、サービスの全体的なアクセス効率を向上させていきます。