コンテンツに移動
データベース

YouTube が Bigtable を使用して世界最大規模のストリーミング サービスを運用している方法

2023年8月30日
Google Cloud Japan Team

※この投稿は米国時間 2023 年 8 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Bigtable は、Google Cloud で広く使われている人気の Key-Value データベースです。柔軟なスケーラビリティ、高い費用効率、高パフォーマンス、99.999% の高可用性 SLA を備えたサービスです。その結果、大規模な導入が進み、お客様は Bigtable を信頼してさまざまなミッション クリティカルなワークロードを実行しています。

Bigtable は、15 年以上にわたって Google の本番環境で使われ続けており、ピーク時には 1 秒あたり 60 億件以上のリクエストを処理し、10 エクサバイト以上のデータを管理しています。

Google 内の Bigtable ユーザーの 1 つである YouTube は、世界最大規模のストリーミング サービスであり、数千万人のクリエイターと数十億人のユーザーに利用されています。YouTube は、視聴履歴に基づくユーザーへの新しいコンテンツの紹介や、広告機能の強化のための視聴回数などの指標の記録をはじめ、幅広いユースケースに Bigtable を使用しています。

この投稿では、YouTube が大規模データ アーキテクチャの中のレポート ダッシュボードと分析を担う主要コンポーネントとして Bigtable をどのように使用しているかをご紹介します。

YouTube のデータ ウェアハウス

YouTube は動画、チャンネル、プレイリストといった主要エンティティに関して、いくつかのメタデータを収集します。メタデータには、動画のアップロード回数、タイトル、説明文、カテゴリ、動画による収益化可能性などが含まれます。複数のエンティティ間の関係も収集します。たとえば、ある動画が 1 つのチャンネルや所有者がアップロードしたものであっても、そのアセットの権利を複数の所有者が保持している場合があります。  

YouTube のデータ ウェアハウスにはこうしたディメンションのメタデータを保存しており、YouTube 全体のデータ パイプラインやダッシュボードに提供しています。このウェアハウスは Bigtable を基盤に構築されています。ウェアハウスを分析に利用する例を見てみましょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/yt.max-2000x2000.jpg

クリエイター アナリティクス パイプラインによって、何千万というクリエイターに、作成したコンテンツについての視聴者のデータに関するインサイトを伝えるダッシュボードの情報が作成されます。このパイプラインは、厳格に安全対策し、プライバシーに配慮した方法で、YouTube のサービスログから視聴者のデータを取得します。このログを処理、セッション化し、ウェアハウスから得られる動画の属性などのメタデータで拡充することで、ダッシュボードの機能をサポートします。コンテンツ クリエイターはダッシュボードによって、特定の動画が得た視聴回数やインプレッション数を、セグメント別の表示や時間軸で見た動画のトレンドなどと合わせて確認できます。

収益化パイプラインはクリエイターの推定収益額を含むレポートを毎日発行します。これは動画の視聴者データに基づきます。このパイプラインは動画のメタデータ、アセットの権利、所有権の申し立てをウェアハウスから取得して、収益を権利所有者の間でどう分配すべきかを決定します。

ウェアハウスのビジネス要件は以下のとおりです。

  • エンティティ データの時系列のバージョニングができること

  • データソースの準リアルタイムでの取り込みのサポート

  • YouTube 全体で求められるレポートに必要な規模と容量でデータのクエリが可能であること

  • ユーザーデータ プライバシー保護に関する YouTube のポリシーへの準拠

YouTube のウェアハウスのビジネス要件を Bigtable がどう満たすかという議論の前に、アーキテクチャの概要を見ておきましょう。

アーキテクチャ

データ ウェアハウスに流れ込む処理パイプラインには、3 つのステージが存在します。

最初のステージでは、オペレーショナル データベース(Spanner や他の Bigtable データベース)のような上流の正規ソースからのデータを読み、元データの形で Bigtable のウェアハウス データベースに書き込みます。

この元データをウェアハウスから読出してクリーニングし、変換して再度ウェアハウスに格納します。この変換により、複数のソースの間でデータが正規化されており、効率的な表現であり、理解や利用が容易であることが保証されます。その結果、YouTube 全体で一貫したレポートが可能となります。

標準化されたデータは、リアルタイムのポイント ルップアップもしくは定期的なバッチダンプによってユーザーが利用できるようになります。

エンティティのタイプ(プレイリストなど)1 つごとに、対応するウェアハウスの Bigtable データベース内のテーブルが 1 つあります。1 つのエンティティ(プレイリストとその属性など)が 1 行に格納され、その中には Protobuf 形式でエンコードされたさまざまな上流ソースのデータが含まれます。

ウェアハウスには 2 つの異なる方法で追跡されるディメンションが存在します。標準ディメンション テーブルは、エンティティの現在の状態を示します。たとえば、あるクリエイターが新しい動画をアップロードすると、動画のエンティティ テーブルに新しい行が書き込まれます。1 週間後にこのクリエイターが動画のタイトルを変更すると、元の行が新しいタイトルで書き換えられます。動画を削除すると、行がテーブルから削除されます。

変更管理用のディメンション テーブルでは、エンティティの変更の経過を確認できます。たとえば、あるクリエイターが新しい動画をアップロードすると、新しい行が書き込まれます。1 週間後にそのクリエイターが動画のタイトルを変更した場合は、テーブル中の元の行は最新版ではないことを示すマークが付いた状態で残り、新しいタイトルの入った新しい行が作成されます。動画を削除すると、該当の行に削除済みのマークが付き、YouTube のユーザーデータ プライバシー保護ポリシーに従ってウェアハウスから完全に削除されます。変更管理用のディメンション テーブルでは、「as of」句を使用したクエリによって過去のメタデータの中の特定の時点にアクセスできます。これは、データ バックフィル(たとえばデータ品質の問題によるデータの修正)やバックテスト(たとえば過去のデータのオフラインでのモデル評価)のために必要です。

Bigtable を使用する理由

YouTube のデータ ウェアハウスについて Bigtable が外せない選択となる理由がいくつかあります。

柔軟なスキーマとデータモデル
Bigtable には柔軟なデータモデルがあり、新しいデータソースの統合の費用を最小限に抑えたいユースケースでの使用に適しています。元データを手早く取り込み、データのセマンティクスが良くわかってきた時点で、適切な標準データモデルを作成するようにできることが望まれます。これにより、アーキテクチャもチームも、常時変化する環境に対してレスポンシブになります。

スケール、費用、性能
ウェアハウスには履歴を含めた YouTube のコア エンティティすべてのメタデータが保存されており、YouTube での分析報告の大部分の基盤になっています。非常に大量のデータの保存と日常的な処理が必要で、低所有費用のスケーラビリティの高いデータベースが必要です。Bigtable のコスト パフォーマンスは業界屈指のものです。リソースの費用 1 ドルあたりの読み書きスループットが高いために、ウェアハウスのデータを使用するバッチ分析に適しています。

ウェアハウスを使用する下流のクライアントは多様で、アクセス パターン、レイテンシ、スループットの要求もさまざまです。Bigtable にはリクエストに優先度を関連付けられる機能があり、高優先度で処理されるトラフィックと低優先度の分析トラフィックを織り交ぜながら、互いに競合しないように処理できます。このため、Bigtable を使うことで、ウェアハウスでトランザクションと分析のハイブリッド処理(HTAP)を使用して異種のクライアントをサポートできます。

変更データ キャプチャ
ウェアハウスでは Bigtable の変更ストリーム機能を利用しています。上流のデータが変化すると、Bigtable の対応する行が無効化されます。Bigtable の変更ストリームを使用するストリーム パイプラインでは無効化されたエンティティの行を特定し、最新のデータをそのソースから取得します。これにより、エンティティには確実に新しいメタデータが常に存在するようになり、レポートで使用できます。

まとめ

YouTube データ ウェアハウスで実施しているような運用分析のワークロードに対しては、Bigtable で低費用でパフォーマンスに優れたストレージが得られます。柔軟なデータモデルにより、新しいデータソースをウェアハウスに組み入れる際につきものの摩擦が低減され、データを元の形式で手早く取り込み、データのセマンティクスがわかるにつれて徐々に構造化していくことが可能となります。こうしたデータ モデリングの反復プロセスにより、組織のアジリティが増し、変化に対する対応力が強くなります。

その他のリソース

Bigtable の利用を開始するには、Qwiklab でお試しください。製品について詳しくは、こちらをご覧ください。


- Bigtable 担当エンジニアリング マネージャー Sudarshan Kadambi
- YouTube データ ウェアハウス、ソフトウェア エンジニア Bin Liu

投稿先