Netflixのデータプラットフォームアーキテクトのマネージャー、Jeff Magnusson氏が、彼らのData Platform as a ServiceについてQCon SF 2013でプレゼンテーションをした。このプレゼンテーションをフォローアップして、技術スタックがどうなっていて、それがNetflixの重要なビジネス判断にどう役立っているのか説明する。
Netflixは世界中で3000万人以上のサブスクライバを抱えている。ユーザはNetflixのWebサイトを訪問するうちに、様々なデータポイントを提供する。ビデオの再生、評価付け、検索といったイベントは記録されて分析される。時間、日付、地理的位置、デバイス、ページの閲覧やスクロールといった振る舞いも、イベントが発生したコンテキストをもたらし、ユーザを分類するのに使われる。彼らは、サイトとのエンゲージメントを高め、どのシリーズに次に投資すべきかといったビジネス判断をするために、これらのデータを利用している。
この他、Nielsenやソーシャルデータといったサードパーティからのメタデータも、プラットフォームに対するエンゲージメントや新たなサブスクライバをもたらすのに貢献している。
2009年以来、Netflixはクラウドで運用されており、Hadoopプラットフォームを使っている。彼らが使っている重要なインフラストラクチャ、Big Dataブロックは以下のようになっている。
- Amazon S3: Amazon S3は内部データパイプラインツールのUrsulaを使って、様々なデバイスからの何十億ものイベントを記録するのに使われる。S3はHadoopジョブを実行するElastic Map Reduce (EMR) クラスタの真実を語る資料として使われる。
- Hadoop: Apache Hadoopは分散計算のベースラインライブラリとして使われる。HadoopはAWSのElastic Map Reduceクラスタにデプロイされ、各ノードが提供するストレージのHDFSを使う代わりに、S3バケットストレージを利用している。これは直感に反している。Hadoopが利用するデータの局所性原則に反して、S3からEMRノードへのデータ移動を引き起こすおそれがあるためだ。だが、その一方で、S3は単一の真実を語る資料となり、EMRクラスタはほぼリアルタイムにフィットするよう拡張、サイズ変更できることを意味する。
- Hive: NetflixのHiveはアドホッククエリと軽量アグリゲーションに使われる。これに対して、PigはETLともっと複雑なデータフローに使われる。データ移動において、複雑なオペレーションを接続するのにも利用される。
- Genie: GenieはHadoop PaaS技術で、EMRにジョブを投入するのに使われる。GenieはRESTful APIを提供し、開発者は組み込み関数を扱ってHadoopクラスタを動かしたりメンテナンスする必要がなくなる。GenieはGitHubリポジトリからフォークできる。
- Franklin: FranklinはメタデータAPIで、RDS、Redshift、Cassandra、Teradata、S3といったソースから情報を抽出するのに使われる。2011年にOracleデータセンタベースのソリューションからAWSクラウドへ移行して以来、Netflixでのオンラインデータ収集にはCassandraが使われている。Teradataは主にデータセンターで使われているが、NetflixがTeradata Cloudに参加するというTeradataの発表で、これも変わるだろう。
- Forklift: Forkliftはデータストア間で分析データを移動するのに使われる。データのソースとターゲットには、Hive、RDBMS、S3、Rなどが使える。
- Sting: StingはGenieジョブの結果をアドホックに可視化するのに使われる。データセットをメモリに保持することで、スライシングやダイシングといったOLAPオペレーションを1秒以下の応答時間で提供する。
- Lipstick: LipstickはユーザがPigジョブのデータフローと全体のジョブ進捗を可視化するのに使われる。これにより、詰まったジョブ、間違った出力データ、失敗したジョブがひと目でわかり、修正して正しく実行するのに役立つ。
こうしたツールとともに、NetflixはCuratorなど数々のヘルパーツールを開発している。CuratorはApache Zookeeperを使いやすくするJavaライブラリ群だ。Curatorを使うと堅牢なクライアントを作るのが簡単になり、安全でないクライアント呼び出しをしたり、リクエストを間違って成功だと思ってしまうといった落とし穴を避けることができる。
上に説明したテクノロジースタックのうち、本当に重要なアプリケーションは、Netflixレコメンデーションだ。レコメンデーション結果はNetflixの全ビデオストリームの約75%を動かしている。レコメンデーションを動かすシステムのひとつに、マルコフ連鎖を使って、映画を状態としてモデル化し、状態遷移の確率を計算するものがある。RDBMSでは週に一度、ストアドプロシージャとして、うまくスケールできない高価なコピーとして実行される。Hadoopを使うことで、これはデータをコピーする必要なしにスケールできるようになり、PigやJava Map Reduceジョブを使うことで、ストアドプロシージャよりもメンテナンスが簡単になる。
マルコフ連鎖は遷移確率行列に従って状態群の離散時間確率過程を記述したものだ。映画をノードとしてモデル化し、ダブルパスのMap Reduceジョブを使うことで、Netflixはあるノードから別のノードへの遷移確率を計算できる。これがレコメンデーション値となる。将来の値は現在の値にのみ依存しており、Hadoopノードで状態を保持する必要がない。これはMap Reduceジョブにぴったりだ。
Netflixがレコメンデーションエンジンで考慮しているパラメータはこれだけではない。コンテキストも考慮すべき興味深い面だ。ユーザは、見ているデバイスが何か、家にいるか、休暇中か、何時か、何曜日かによって、異なるコンテンツを鑑賞したいかもしれない。コンテキストと鑑賞の嗜好を相関付けるのには様々な課題があり、Netflixもまだ解決できてはいない。
Netflixのビッグデータアーキテクチャは、別の業界や競合他社に簡単にコピーされるようなものではない。だが、構成要素のいくつかはオープンソースであり、彼らのGitHubアカウントで利用可能になっている。ビッグデータアーキテクチャの開発をはじめたいと思っている組織にとって、これらは出発点となるだろう。そしてNetflixが示してきたように、ビッグデータ戦略は後で付け足すものではなく、事前に計画し、何年もかけて徹底的に実行する必要がある。