LinkedInのJay Kreps氏はどのようにデータを処理しているか、最近のHadoop Summitの発表で詳しく説明した。Kreps氏は、LinkedIn が大量ユーザ/短応答時間でサイトのサービスを提供しながら、1日に1200億もの関連を高速処理し大規模データの計算結果を集計している方法について解説した。
LinkedInの重要なデータのほとんどはオフラインにある。データが極めてゆっくり動く。よって、Hadoopによる日次バッチ処理で重要な計算を実行している。例えば、"知り合いの可能性が高い人" を見つけるため、予め以下のような計算を実行している。16 TB の中間データを必要とする82のHadoopのジョブからなるmapreduceのパイプラインで、1日に1200億の関係を評価し点数をつけているのだ。このジョブは2人の人が互いに知っている確率を予測するのに統計モデルを使用する。興味深いことに、マップの結合を加速するためにブルームフィルターが使用されており、これによりパフォーマンスが10倍改善した。
このパイプラインには2人のエンジニアが携わっており、そして2人で1週間に５つの新しいアルゴリズムをテストすることができる。このペースで改良していくために、古い手法と新しい手法を比較するA/B テスト と、最適な結果を得るための"計測飛行"を繰り返し実行している。パフォーマンスの改善のためには、大規模データを操作する必要もあるが、これは大規模クラスター処理で実現する。そのため、独自実装したグラフ処理のコードから Hadoop のmapreduce コードに移行した。これにはいくつかの思慮深い設計が必要だった。なぜなら、ほとんどのグラフアルゴリズムは、そのまま素直にmapreduceに書きなおすことができなかったからである。
LinkedIn はオープンソースに多大な投資をし、クラスコンポーネントと人材コミュニティの関与という基盤を得た。この２つのオープンソースプロジェクトはLinkerdInのデータ基盤の中心に位置付けられる。Azkaban はHadoop向けのオープンソースのワークフローシステムである。cronのようなスケジューリング機能とmakeのような依存関係解析機能をもち、再起動も実行可能である。これはETL ジョブを制御するのに使用している。ETLは、データベースとイベントログをエッジの サーバストレージ、Voldemortに登録するジョブである。
Voldemort はLinkedInのNoSQL キー/バリュー型ストレージエンジンである。ウェブページの検索機能を実現するために、変更のあったエッジの可能性のある関係情報数十億個を、毎日稼働サイトに登録している。 このデータは読み取り専用である。データはクラスターのジョブが計算するのだが、例えば、ある会社に興味がある人を絞り込んだり、 ユーザが知らないと示した人を除いたり、といった、ある条件での検索を可能にするフィルタリング処理はリアルタイムで実施している。これでデータベースを使用していたとき発生した問題のほとんどを解消することができた。データベースで実行するには、データを分割し、別のシステムに渡す必要があった。このシステムは、データをあちこちに移動させるようなジョブを、フルタイム・マニュアルで実行するものだった。 Voldemort は完全に分散型であり、個々が独立しており、そしてパーティショニングとフェールオーバーをサポートする。
LinkedIn は稼働サーバを日々更新している。更新時には、まずHadoopからVoldemortに蓄積された結果を大規模並行にフェッチし、キャッシュをウォームアップ（キャッシュを正しい情報で更新）、その後 それぞれのサーバごとに干渉せず独立して当日のデータに切り替えるのである。新しいデータセットで問題が発生した場合に瞬時に前の状態にフェールバックできるように前日のデータはサーバに保存しておく。LinkedIn はHadoopパイプラインにインデックスの仕組みも構築している。インデックスは完璧なハッシュ機能を利用する数TBの検索機能を提供する(ひとつのキーあたり 2.5 ビットしか必要としない)。この処理はクラスター計算リソースと高速なサーバ応答とのトレードオフとなる。LinkedInが45ノードの開発クラスタ上に900GBのデータストアを構築するのにかかる時間は約90分である。また、巨大なバッチ処理や、一時的なアップデートのために Hadoop クラスターを落としたりする場合にもHadoopを使用している。ただし、何があってもVoldemortサーバを絶対に落とさない。
プレゼンテーションのスライド で詳細が確認できる。
InfoQ ホームページ ニュース LinkedInのデータ基盤