2010年のHadoop Summit では、Hadoopと関連技術の、数多くの大規模ユーザから、発表があった。とりわけ、 Facebookは、分析にHiveを使っていることについて、基調講演で詳細に発表した。 FacebookでEngineering のVPである Mike Schroepfer氏がHadoopによるデータ処理の規模について基調講演を行った。
Schroepfer 氏は、FacebookがHadoopを使ってどのように、大規模な分析を計算しているか，例を示した。FacebookがLikeボタンを公開する計画をしている時に、彼らは、共食いを心配した－それによって参加が増えるより、単に、テキスト コメントの投稿が減ってしまうのではないか？ 確認するために、彼らは A/Bテスト を行った。一方のグループには、新しいフィーチャー（Likeボタン）があり、もう一方の対照グループには、それがないもので、ユーザの行動を比較した。そのためには、繋がりのあるコミュニティ、「内因性グループ」－グループ外とほとんど繋がりを持たないグループ－内でテストを行う必要があった。この目的のために、南米の国の2セットを使った：コロンビア、ベネゼーラ 対 アルゼンチン、チリ。テストの結果では、コメントの増加が、Likeボタンのある方が、 4.46% で、対照グループが0.63%だった。そのようなテスト用の膨大なデータ量は、Facebookがいかに、データの高速処理にHadoopに頼っているかを示す例である。それからSchroepfer 氏は、なぜデータ駆動のA/Bテストが非常に重要であるかを示す別の例を示した：Facebookは、またユーザへのメール リマインダの2つの違った設計もテストした。大抵の人がグラフィカルで表現豊かなメールのほうが、単純なテキスト中心のメールよりも、もっとレスポンスがいいだろうと、予測したが、実際は、後者のほうが3倍レスポンスが良かった－この事実は、アイデアをテストするために、直感に頼るより、データを使う方が、有意義があることを示している。
氏が言うには、Facebookのユーザは，4億人で、半分以上が毎日ログインしている、 Neilsenの調べでは、Facebookサイトが見られている時間は、2位以下の6サイトの合計よりも長い。Facebookのユーザは、月に250億のコンテントを共有しており、月に5000億ページ見ている。このデータ量をこなすには、Facebookは、36ペタバイト（PB)の非圧縮データを保存する大きなHadoopクラスタを持ち、2250以上のマシンと23000コア，マシン当たり32GBのRAMを持ち、1日当たり80－90TB（新しいデータと仮定して）処理している。クラスタ当たり、月に300－400のユーザがいて、1日に25000のジョブを発行する。
Facebookは、2つの主要なソースからHadoopクラスタにデータを送っている。それらは、5～15分毎に何万台のマシンからデータを転送しながら、オープンソースの Scribe アップロード機能を使って、webクラスタからログをロードする。また記録システム、約2000ノードからなる連携したMySQLクラスタから，毎日データもロードする。このデータの中には、プロファイル、友達、広告や広告キャンペーンについての情報が含まれている。 彼らは、情報を稼働中の Platinumクラスタにロードする。このクラスタは、ロード前に、注意深く監視し、管理されたミッションクリティカルなジョブだけを走らせている。Facebookは、またより重要度の低いジョブを走らせるGold や Silver クラスタにデータを入れるために、Hiveレプリケーションも使っている。また Platinumクラスタから Oracle RACのインスタンスにデータをコピーする。クラスタは、1つのコアスィッチを持った1組のノードとして設定される。このようにデータを異なったクラスタに分割ことによって、クリティカルなジョブに対して高い信頼性を確保することができ、一方、Hadoopをもっと調査や分析目的で使うことができる。これは、Yahooが、どのように製品クラスタと科学的なクラスタの両方を使っているかを説明した、やり方に非常に似ている（これについてもっと知りたければ、 Hadoop Summit 2010からYahooのアーキテクチャをアップデートを参照）。
Hadoopクラスタにログをロードする頻度を高められるように、Scribeを走らせて中間でデータを収集し、ツリーベースの分散システムを使って、データをローカルにホストされたHDFSとHadoopクラスタにダンプしている。この層では、もう一つのHDFS（別のNameNodeといっしょに）も走らせている。このHDFSは、即対応可能な代替品として機能する － もし第一のHDFSがダウンしたら、システムは、バックアップのHDFSに書き込む。稼働中の環境にロードするために、データを読み出す時、彼らは，単に両方のファイルシステムからデータを読み出し、圧縮し、それから稼働中のクラスタに転送する。
Schroepfer 氏が言うには、Facebookのジョブの95％は、Hive使って書かれていて、非常に早く書くことができ、普通は約10分しかかからない、と言う。実際、Facebookは、HiPalというwebベースのツールを作って、Hiveを使うビジネスアナリストが、簡単にクエリを書き、データウェアハウスにロードされている20000のテーブルを調べることができるようになっている（HiPalは、公開されていない）。彼らは、日に1回のバッチ処理からリアルタイムなクエリにずっと近いものに変化している。彼が考えているのは、最も速いクエリを1分以内で返すことができるシステムを開発することが、全く新しい領域のアプリケーションを切り開くキーとなる、ということである。
続いて、Facebookの John Sichi と Yongqiang Heが、Hiveと HBase、RCFileとの統合について発表した。HBaseは、BigTableに似たキー・バリュー型データストアで、データをHadoopのDFSファイルシステムに保存する。Facebookは、彼らのデータウェアハウスのディメンジョン データを常にアップデートして、HBaseをテストしている。Facebookは、HBaseの20ノードのクラスタを使って、Hive統合をテストしている。－ Hive から HBaseに6 TBのgzipされた データを一括ロードするのに30時間かかった。その構成で、30 GB/hr の速度で漸増 的にロードできた。 HBaseのデータをテーブルスキャンするのは、ネイティブなHiveクエリより5倍遅かった。彼らは、最新の HBaseで利用できるパフォーマンスの最適化を利用するために、この最適化を検討している。 RCFileは、Hiveの新しいストレージ フォーマットで、多桁フォーマットでデータを保存する。彼らは、この形式を採用したために、必要な保存域を平均で約20％削減できた、そしてこれを使ってパフォーマンスの改善もできている（必要に応じて、カラムの遅延解凍によって）。
Facebookは、引き続きHadoop技術に投資しており、彼らが使っているHive (彼らが始めた) や HBase のようなオープンソース プロジェクトに貢献している。彼らは、コンピューティング クラスタで、大規模なデータを処理し、Hadoopとのデータベースの統合と同時に、高可用性、低遅延なアプリケーションをサポートするアーキテクチャを有している。Facebookに関する多くのケーススタディは、 infoq.com/facebookで見ることができる。
InfoQ ホームページ ニュース FacebookによるHadoop, Hive, HBaseそして A/B Testingへの取組み