1. Facebookの
リアルタイム Big Data処理
@maruyama097
丸山不二夫

2. o 毎月のアクティブ・ユーザ
8億4500万人
o 一日の「いいね」とコメント
27億
o 一日にアップロードされる写真
2億5000万枚
o Facebook上の友人関係
1000億

3. 構築されるべきインフラの目的
o 世界の誰とでもつながること、誰にも声を
与えること、未来のために社会を変革する
のを助けること。これらには、巨大なニー
ズと巨大なチャンスがあります。
o このテクノロジーと、構築されるべきインフ
ラの規模は、前例のないものです。私た
ちは、これこそが私たちが集中することの
出来る、もっとも重要な問題だと確信して
います。
-- Facebook上場申請文書から

4. Real-Time Analytics System
http://highscalability.com/blog/
2011/3/22/facebooks-new-realtime-
analytics-system-hbase-to-
process-20.html

5. このシステム・アーキテクチャーの
持つ意味
o このシステムは、あなたには、どのような
意味を持っているのだろうか？
o もしもあなたがFacebookではないとし
ても、このアーキテクチャは、十分にシン
プルで、十分に出来合いのツールによっ
て構成されているので、もっと小さなプ
ロジェクトでも機能することが出来るだろう。

6. システムの目標
o 人々に、信頼出来るやり方で、沢山の異なった
統計数字の、リアルタイムのカウンターを与え
、データの多寡の偏りを説明する。
o アノニマスなデータを提供する。データが誰の
ものかは知ることは出来ない。
o 何故、プラグインが価値があることを示す。あな
たのビジネスが、どのような価値を、それから導
きだすことが出来るか？

7. システムの目標
o データを、もっとアクティブなものに変える。
ユーザに、ユーザのコンテンツをもっと価値ある
ものにするアクションを取ることを助ける。
n 新しいUIのメタファー。漏斗のアイデアを利用する。
n どのくらいの人が、あるプラグインを見たか、どのくら
いの人がそのプラグインに反応したか、どれくらい
の人が、あなたのサイトに誘導されたか
o データをもっと、タイムリーなものに変える。
n システムはリアルタイムなものになった。一巡48時
間から30分に変わった。
n この目的のために、複数の障害点が除去された。

8. 沢山のイベント・タイプ
100以上の指標をトラックする
o Pluginのインプレッション
o いいね
o ニュースフィードのインプレッション
o ニュース・フィードのクリック
o 人口数
Massive Amounts of Data
o 一日に、20億イベント。
毎秒、20万イベント。

9. データの偏り – 不均等なキーの分布
o 「いいね」は、冪乗則に似た分布をする。ロン
グテールには、ほとんど「いいね」が集まらな
いが、あるリソースには、巨大な数の「いいね」
が集まる。
o このことは、アクセスが集中するホットな領域
、ホットなキーとロックの競合といった問題が生
まれることを意味する。

10. 様々な異なったプロトタイプでの
実装の試行錯誤
Facebookでは、このアーキテクチャーに到
達するまでに、様々の試行錯誤を行って
いる。ここでは、それを見ておこう。

11. MySQLをDBカウンターとして使う
o 行にキーとカウンターを持つ
o 結果は、沢山のデータベースの活動の結果。
o 状態は、一日単位の粒度のバケットに格納さ
れる。毎日、深夜に、その情報は置き換えら
れる。
n 状態更新の時が来ると、その結果は、一斉にデー
タベースに書き出される。それは沢山のロックの競
合を生み出す。
n この作業を、タイム・ゾーンを考慮に入れて拡張する
という課題もある。
n データ分割を異なったやり方で行うという課題。

12. MySQLをDBカウンターとして使う
o 高い書き込みレートは、ロックの競合をもたらす
。データベースに負荷をかけるのは容易なの
だが、いつもデータベースをモニターする必要
がある。また、データベースのshardingの戦略
を常に考え直す必要がある。
o この問題に対するソリューションは、よく、整理
されてはいない。

13. In-Memoryカウンターを使う
o もし、IOのボトルネックに悩まされているのなら、全てを
メモリー上におけばいい。
o スケールの問題はない。カウンターはメモリーにおかれ
ているので、書き込みは速く、かつ、カウンターの
shadingは容易である。
o In-memoryカウンターは、いくつかの理由で、他のア
プローチより正確でないと感じられる。 たとえ、1%の
失敗率でも、受け入れられない。 データ解析で、お金
が動く以上、カウンターは、極めて正確であらねばなら
ない。
o このシステムを、Facebookは実装した訳ではなく、思
考実験にとどまるのだが、正確性の問題は、別の解法
に向かわせた。

14. MapReduceを使う
o 以前のソリューションでは、Hadoop/Hive
を使っていた。
o 柔軟で、稼働するのが容易である。巨大な書き
出しと読み込みの双方のIOをハンドルできる。
事前に、どのようにクエリーが行われるか知る
必要はない。データは格納され、そして、クエリ
ーされる。
o リアルタイムでない。沢山の従属性と、沢山の
障害点がある。複雑なシステムで、リアルタイ
ムの目的には、十分には、依拠出来ない。

15. Cassandra/HBaseを使う
o アベイラビリティと書き込みの効率で、
CassandraよりHBaseが、より良いソリュ
ーションに見えた。
o HBaseの書き込みレートは巨大で、ボトルネ
ックは解消された。
o The Winner:
HBase + Scribe + Ptail + Puma

16. Real-Time Analytics
Systemのアーキテクチャ
このFacebookのシステムの重要な特徴は、
m-tierモデルではなく、WAL write ahead
logに基づく、Tailingアーキテクチャーで
ある。それは、中小規模のシステムにも応
用可能である。

17. WALを利用した、
Tailingアーキテクチャー
o HBaseは、沢山の分散したマシン上に、データ
を格納する。
o Tailingアーキテクチャを利用する。
o ユーザーは、Webページ上の「いいね」をクリッ
クする。
o Facebookに、AJAXリクエストが飛ぶ。
o AJAXリクエストは、Scribeを使って、ログ・ファ
イルに書き出される。

18. WALを利用した、
Tailingアーキテクチャー
o 新しいイベントはScribeでログ・ファイルに格
納され、 ログは、PTailで、後ろから処理される。
o システムは、ログからイベントを巻き取り、Pum
aで処理し、HBaseストレージに書き出す。
o UIは、ストレージからデータを引き出し、ユ
ーザーに表示する。
Web -> Scribe -> PTail
-> Puma -> HBase

19. Write Ahead Log
o Facebookのシステムで、スケータビリティと信
頼性に取って、本質的に重要な特徴は、WAL
write ahead logである。 おこると想定される
操作のログ。
o キーに基づいて、データは、リージョン・サーバ
に分割される。
o データは、まず最初に、WAL に書き出される。

20. Write Ahead Log
o データはメモリーにおかれ、ある時点で、ある
いは、十分なデータが集積したら、ディスクに
フラッシュされる。
o もしも、マシンが倒れたら、WALからデータを再
生できる。
o ログとメモリー内ストレージを組み合わせて利
用することで、極めて高レートのIOを、確実に
ハンドルできる。

21. Real-Time Analyticsの
データの流れ

22. データのスキーマ
o 一つのURLをベースに、沢山のカウンターを格
納する。
o 唯一のルックアップ・キーである、行のキーは、
リバース・ドメイン(com.facebookのような)の
MD5ハッシュである。適切なキー構造の選択は
、スキャンやｓｈａｄｉｎｇを容易にする。
o 問題は、適切に別のマシンにデータをshading
することである。MD5ハッシュを使うことで、UR
Lのこの範囲はここで、その範囲はあっちへと
決めることが簡単になる。

23. データのスキーマ
o データの中のURLについても同じようなことを
するのだが、URLには、IDを追加する。
Facebookの中では、全てのURLは、ユニークな
IDで表現されている。それは、shadingを助け
るために利用されている。
o com.facebookのようなリバース・ドメインはデ
ータを一緒にクラスター化するのに利用されて
いる。それらにデータが格納されているのなら、
一緒にクラスター化されているので、ドメインの
情報を効率的に計算することが出来る。

24. データのTTL
o 全ての行がURLで、そのカラムがカウンターだ
としよう。そのとき、そのカラム毎に異なったTTLs
(time to live) を設定することができる。
o だから、一時間毎のカウント数を数えているの
なら、全てのURLをずっと保存しておく必要は
ない。二週間のTTLでも設定しておけばいい。
典型的には、カラム・ファミリーをベースに、TTL
を設定する。

25. Scribe
o Scribeは、ログ・ファイルのロールオーバといっ
たたぐいの問題を処理する。
o Scribeは、Hadoopと同じHTFSファイル上に
構築されている。
o 非常に簡単なログ行を書き出す。それがコンパ
クトなものであればあるほど、多くをメモリー上
に格納することが出来る。

26. ログの処理
o サーバあたり、毎秒10,000個の書き込みを処
理出来る。
o ログからデータを読み出す際にデータの消失が
ないようにチェックポイントの設定が行われて
いる。
n Tailerは、ログ・ストリームのチェックポイントをHBas
eに保存している。
n 再起動時にも、チェックポイントからデータが再生
され、データ消失はおこらない。
o クリック詐欺の検出に使えるのだが、それはつく
られていない。

27. Ptail
o データは、Ptailを使って、ログ・ファイルから読まれる。
Ptailは、複数のScribeストアからデータを集約するた
めに社内で作成されたツールである。Ptailは、ログファ
イルを後ろから読んで、データを引き出す。
o Ptailのデータは三つのストリームに分離される。そう
して、最終的には、三つの異なるデータセンターの、そ
れぞれに固有のクラスターに送られることが可能となる。
n Pluginインプレッション
n ニュース・フィード インプレッション
n Actions (plugin + news feed)

28. PTailのホットスポット
o 分散システムでは、システムの一部分が、他の
部分よりホットになることが起こる。一つの例は
、リージョン・サーバで、こうして沢山のキーにア
クセスが向けられると、ホットになることがあり
得る。
o 一つのtailerは、他のtailerより、遅れることが
あり得る。もし、一つのtailerが一時間遅れで、他
のtailerには遅れがなかったら、どのような数
字を、ディスプレイに表示するだろうか？

29. PTailのホットスポット
o 例えば、インプレッションは、アクションよりも、
情報の量がかさむ。だから、CTR（Click
Through Rate)は、後の時間になってから、高
くなってゆく。
o この問題の解決策は、もっとも遅れている
tailerを見つけ出して、指標の問い合わせがあ
った場合には、それを使うことだ。

30. Puma
o ホット・キーたちのインパクトを軽減するために
、データをバッチ処理する。HBaseが、たとえ、
一秒あたりたくさんの書き込みをハンドルするこ
とが可能だとしても、それでも、彼らはデータ
のバッチ処理を望んだ
o ホットな投稿は、沢山のインプレッションやニュ
ーズ・フィードのインプレッションを生み出す。そ
れは巨大なデータの偏りを引き起こし、IOの問
題を引き起こすだろう。バッチ処理が多いほど、
いいことになる。

31. Puma
o バッチは、平均して1.5秒かかる。 もっと長いバ
ッチを望んでも、それは、沢山のURLを抱えるこ
とになり、ハッシュテーブルを作成する時にメ
モリー不足に陥るだろう。
o ロックの競合の問題を避ける為には、新しいバ
ッチを始めるために、最後のflushの終了を待
つこと。

32. データをレンダーするUI
o フロントエンドは、全てPHPで書かれている。
o バックエンドはJavaで書かれており、メッセージ
ングのフォーマットとしてはThriftが利用されて
いる。だから、PHPのプログラムも、Javaのサ
ービスを要求出来る。
o Webページの表示をもっと高速にするために
、キャシングによるソリューションが利用される。

33. システムのパフォーマンス
o パフォーマンスは、状況によって変化する。ある
カウンターは、即座に返ることができるが、ドメ
イン内のトップのURLでは、少し時間がかかる
かもしれない。そのレンジは、0.5秒から数秒で
ある。
o 沢山の長いデータがキャッシュされると、リアル
タイム性は、少なくなる。メムキャッシュで、それ
ぞれについて、ことなるキャッシュTTLを設定す
ること。

34. HBaseとHadoop
このシステムでは、HBaseが大きな役割を
果たしている。Hadoopは、バックアップ用
に準備されているという。

35. HBaseは、分散カラム・ストア
o HBaseデータベースは、Hadoopとインタ
ーフェースする。Facebookは、社内に、HBas
eで仕事するスタッフを抱えている。
o HBaseでは、リレーショナル・データベースとは
異なって、テーブル間のマッピングを作ることは
ない。
o インデックスもつくらない。唯一のインデックスは
、行のプライマリー・キーだけである。

36. HBaseは、分散カラム・ストア
o HBaseでは、行のキーから、数百万ものストレ
ージの疎なカラムを取得出来る。それは、非常
に柔軟である。
o スキーマを指定する必要がない。いつでもキー
を追加出来る、カラム・ファミリーを定義すれば
いい。

37. HBaseの自動化
o HBaseは、システムの失敗を検知して、自動的
にそれらを迂回することが出来る。
o 現在は、HBaseのデータのshardingの再分割
・再配置は、手動で行われている。
o ホット・スポットの検知と再分割・再配置の自動
化は、HBaseのロードマップにのぼっているの
だが、まだ、出来ていない。
o 毎週火曜日、だれかがキーをチェックして、デー
タの分割プランに、どのような変更が必要か判
断する。

38. MapReduce
o Hiveによってクエリー可能になるように、データ
はMapReduceサーバに送られる。
o これは、データがHiveによってリカバー出来る
ような、バックアップ・プランとしても機能する。
o もともとの生のログは、一定期間の後に、削除
される。

39. 将来の課題
ここでは、どのような課題が残されているの
かを、見ておこう。

40. 将来の課題のトップリスト
o 一番「いいね」が多いというような、トップのURL
を見つけるのが、大変難しい。
というのも、YouTubeのようなドメインでは、数
百万のURLが、短いあいだに共有されるからだ。
o メモリー内のソート順を維持し、データが変わる
につれて、順番が更新されるような、もっと創造
的なソリューションが求められている。

41. その他の課題
o 異なるユーザー数のカウント
n 時間枠をまたいで、何人が、あるURLに「い
いね」を押したのか。MapReduceでは簡単
なのだけれど、単純なカウンターでは、なか
なか難しい。
o ソーシャル・プラグイン以外のアプリケーション
の一般化。

42. その他の課題
o 複数のデータセンターへの移動
n 現在は、一つのデータセンターでのみ稼働している
のだが、複数のデータセンターで動くことを希望して
いる。
n 故障時の代替プランは、現在は、MapReduceを使
うというものである。
n このバックアップ・システムは、毎晩、テストされて
いる。Hiveとこの新しいシステムへのクエリー結
果は、一致することを見るために、比較されている。

43. このプロジェクトについて

44. このプロジェクトについて
o このプロジェクトには、5ヶ月かかった。最初は
、二人のエンジニアがこのプロジェクトで働き始
めた。その後、50%のエンジニアが追加された。
o UIのひと二人が、フロントエンドの為に働いて
いる。
o エンジニアリング、デザイン、PM、オペレーショ
ンで、14人が働いているようだ。

45. Cassandra
o 他のある人たちは、 Cassandraを選んだ。彼
らは、Cassandraのスケーラビリティ、マルチ
・データセンター機能、操作の易しさを愛してい
たから。 しかし、Cassandraは、リアルタイム
のデータ解析のスタックには、すっきりとは、お
さまらなかった。

46. メッセージング・システムとの共通性
o メッセージングのシステムを見た時、この解析シ
ステムとなんと共通点が多いのかということに気
づいた。
o 大きな数、HBase、リアルタイム。巨大な書き込
みの負荷を確実に、かつ、タイムリーに扱うとい
う挑戦は、これらの問題の共通の基盤なのである。
o Facebookは、HBase, Hadoop, HDFS という
エコシステムにフォーカスしながら、気まぐれな
操作の数を、後で展開すべく、数えているので
ある。

47. n

48. Real-time Analytics at Facebook
Zheng Shao
10/18/2011

49. Analytics and Real-time
what and why

50. Facebook Insights
o ユースケース
n Websites/Ads/Apps/Pagesの時系列データ
n 人口動態の解析
n ユニーク・ユーザ数/
アクセスの多いページ
o 大きなチャレンジ
n スケーラビリティ
n 遅延

51. FacebookのリアルタイムInsight
以前の処理
o Facebookには、既に、Insightの仕事を処理する完全
なデータウェアハウス・ソリューションが存在している。
o Insight処理のスケーラビリティを担保するために、
Facebookでは、3000ノードからなるHadoopクラスタ
ーを利用している。
n HTTPサーバーから生成されるログ・ストリームは、
n Scribeと呼ばれるログ収集フレームワークで、数秒以内にNF
Sに転送され、
n そのデータは、一時間毎に、Hadoopにコピー／ロードされる。
Copier/Loaderは、MapReduceジョブで、マシンの失敗を自
動的に処理する。
n 毎日のHadoopで生成されたログのサマリーは、パイプライン
・ジョブで、最終的には、サービスで利用するためにMySQL
にロードされる。

52. Hadoop/Hiveベースの解析
一時間毎
一日毎
数秒
数秒
Copier/ Pipeline
Jobs
Loader
HTTP
Scribe
NFS
Hive
MySQL
Hadoop
o 3000ノードの Hadoopクラスター
o パイプライン・ジョブ: Hiveは、SQL-like な
記述が可能
o Scalabilityはかなりのもので、データセンタ
ーのパワーの限界までもつ。
o ただ、遅延はひどい。24時間から48時間かかる

53. 遅延への可能な二つの対応
o 一つの考えは、小バッチ処理。
n 一日に一つのバッチを行う代わりに、もっと小さなバ
ッチを行う。
n 問題は、いかにして、一つのバッチあたりのオーバ
ーヘッドを少なくして、一分かそれ以下の小さなバッ
チが意味のあるようにできるかということ。
o もう一つの考えは、ストリーム処理。
n データが到着するとすぐに、それを集約する。これで
リアルタイムに近い結果を得ることが出来る。
n 問題は、ハードウェアの故障に対して、いかにシス
テムを信頼出来るものにするかということ。

54. 低遅延を、どう実現するか？
o 小バッチ処理
o ストリーム処理
n Map-reduce/Hiv
eを一時間ごと、15 n データが着き次第、
分ごと、5分毎に走 集約処理する。
らせる。 n 信頼性の問題を、ど
n バッチあたりのオ う解決するか？
ーバーヘッドをどう
減らすか

55. Facebookの選択
o Facebookは、ストリーム
処理を最終的に選択した。
n Map-Reduceのバッチ
あたりのオーバーヘッドは、
極めて高く、Hadoopクラス
ター上の5分のバッチでも、
実用的ではないということ
が分かった。

56. Data FreewayとPuma
o Facebookが構築したリアルタイム解析システ
ムは、二つの基本的なシステムからなる。
o 第一のシステムは、ScribeとHDFS上に構築
されたData Freewayである。
o 第二のシステムは、HBase上に構築された、
信頼性の高いストリーム集約エンジンPuma
である。

57. Data Freeway
scalable data stream

58. かつての、Scribeによるデータ転送
階層的にログ・データを収集
o 最初の転送は、クライアントから中間層になさ
れるもので、数万のノードから数百のノードに、
漏斗状に数が減らされる。
o 二つ目の転送は、ログのカテゴリーに基づい
てデータをシャッフルするもので、一つのログ・
カテゴリーは、一つのwriterノードに格納される。
o その後、ログ・データは、writerによってNFSに
書き込まれ、バッチのcopierとUnixのtail/
fopenによって利用される。
o Scribeは、2008年にオープンソース化。
当時は、ログのカテゴリーは、100種類程度。

59. Scribeによる転送
Batch
Copier
HDFS
tail/fopen
Scribe
Scribe
Scribe
Mid-­‐Tier
Writers
NFS
Clients
Log
Consumer
最初の転送
二番目の転送 三番目の転送
カテゴライズ
FSへの書き込み
o Scribeは、シンプルなpush/RPCベースの
ログ・システム
o ルーティングは、staticに設定する。

60. このスタイルの問題
o Scribeは、2008年のオープンソース化以降、
急速に沢山の企業に受けいられた。
o ルーティングは、スタティックな設定によるもので
、柔軟ではあったが、二つほど問題があった。
o 一つは、それぞれのwriterマシン毎に設定ファ
イルを管理しなければならなかったし、一つの
カテゴリーに一つのwriterというのも、スケーラ
ブルではなかった。
o もう一つの問題は、writerが、単一障害点とな
っていることだった。

61. Data Freeway 2011
o 2011年に、Facebookは、Data Freewayを
稼働させた。
o 現在では、ピーク時には9GB/sec、端から端ま
での遅延は10秒で、データを処理している。
o 今では、2500以上のカテゴリーがある。
o 現時点では、Calligraphusで書き出された
HDFSから直接PTailしているのだが、将来的
には、Continuous Copierによって書き出され
たHDFSから、PTailする計画である。

62. Data Freeway 2011
ConFnuous
Copier
C1 C2 DataNode
HDFS
PTail
C1 C2 DataNode
(in
the
Scribe
Calligraphus
Calligraphus
PTail
plan)
Mid-­‐Fer
HDFS
Clients
Writers
Log
Zookeeper
Consumer

63. Data Freewayを構成する
４つのコンポーネント
o 第一のコンポーネントはScribeで、クライアント上での
み稼働し、RPC経由で、データを送りつけることに責任
を持っている。
o 第二のコンポーネントは、Calligraphusと呼ばれるも
ので、Zookeeperを利用してカテゴリーの所有を管理し
、データをシャッフルして、HDFSに書き出す。
o 第三のコンポーネントは、Continuous Copierと呼
ばれるもので、ファイルが大きくなるにつれ、あるHDFS
から他のHDFSに連続的にファイルをコピーする。
o 第四のコンポーネントは、PTailと呼ばれるもので、
HDFS上の複数のディレクトリーを並列にtail処理して、
stdoutに書き出す。

64. Calligraphus
o Calligraphusは、RPCからのデータを取得
して、ファイルシステムに書き出すことに責任を
持つ。
o それぞれのログのカテゴリーは、一つ、または、
それ以上のファイルシステムのディレクトリーで
表現される。
o それぞれのディレクトリーは、ファイル名にデー
タの名前を含んだ、順序づけられたファイルの
リストである。
o ログデータを格納するには、思いつく限り最もシ
ンプルな形式をしている。

65. Calligraphusの二つのバケット化処理
o Calligrapusのもっとも興味深い特徴は、二つのバケッ
ト化をサポートしていることである。
o 一つは、アプリケーションで定義されたデータ分割、アプ
リケーション・バケットである。これらは、分割されたログ
のコンシューマによって利用される。大きなログのコ
ンシューマの大部分は、そのログ・ストリームが非常に
巨大であるので、分割されている。
o もう一つは、インフラストラクチャ・バケットで、一つのア
プリケーション・バケットが、毎秒数バイトから毎秒数ギ
ガバイトのスループットを持つことを可能にする。それぞ
れのインフラストラクチャ・バケットはディレクトリーである
。大きなストリームを、同時に複数のディレクトリに書き
込むことが出来る。

66. Calligraphusのパフォーマンス
o Calligraphus は、非常に、ハイパフォーマン
スである。
o Facebookは、ファイルシステムのsyncを7秒
おきに呼び出しているのだが、それが現時点で
のデータ遅延の最大の原因になっている。
o ネットワークのスループットは、簡単に1Gbitの
NICをあふれさせるくらい大きい。近いうちに、
10Gbit NICを使用することを計画中である。

67. Continuous Copier
o Continuous Copierは、一つのファイルシ
ステムから他のファイルシステムへの連続的
なデータコピーを行うコンポーネントである。バ
ッチベースのmap-reduceのCopierと比較す
ると、遅延がかなり低く、また、ネットワークの
利用もスムースである。

68. Continuous Copier
o 現在は、長期間走り続ける、mapだけを行うジ
ョブとして実装されているが、MapReduce以
外の、どんな簡単なジョブ・スケジューリング・シ
ステムにも用意に移し替えることが出来る。
o 現時点では、HDFSのロックファイルを使用して
いるが、早い時期に、ZooKeeperにかえる予
定である。
o 稼働中のContinuous Copierのピークの
スループットは、約3GB/secで、現在はデータ
圧縮を行っている。

69. Ptail
files checkpoint
directory
directory
directory
o File System à Stream ( à RPC )

70. PTail
o PTailは、ファイルシステムからのデータをアウ
トプット・ストリームに転送する。
o PTailの重要な特徴は、チェックポイントである。
PTailのチェックポイントは、現在のファイルと、
それぞれのディレクトリ内のファイルのオフセッ
トの値を含んでいる。
o こうして、以前のチェックポイントにロールバック
して、データの境界で、いかなるデータの損失
もダブりもなしに、データストリームを再生産す
ることが出来る。

71. チャンネルの比較
Push / RPC Pull / FS
Latency 1-2 sec 10 sec
Loss/Dups Few None
Robustness Low High
Complexity Low High
Scribe
Push / RPC
PTail + ScribeSend Calligraphus
Pull / FS
Continuous Copier

72. Puma
real-time aggregation/storage
Log
Stream
AggregaFons
Serving
Storage
Pumaは、シンプルなアーキテクチャーを
持つ、典型的なストリーム集約エンジンで
ある。

73. Puma概観
o ログストリームは、複数のマシンの集合上で集
約される。集約されたサマリーは、永続性を持
たすために、通常はストレージに格納される。
o オンラインのサービスは、Pumaから直接でもス
トレージからでも、サマリーを取得することが出
来る。
o Pumaでは、読み込みよりも書き込みのスル
ープットの方がかなり大きい。というのも、サ
マリー等の解析データは、Webサイト等のオ
ーナーだけによってみられるものだから。

74. Puma概観
o Pumaへの書き込みのスピードは、一秒あたり、
100万行のオーダーである。
o Facebookでは、ログ行を、年齢、性別等で、
複数のGroup-By操作を行う必要があった。
o Group-Byの最初のキーは、常に、time/dat
eに関連している。そのことは、サマリーは、一
定の時間の後で、確定したものになることを意
味している。
o Pumaは、また、ユニークユーザ数やもっともア
クセスの多い要素は何かといった、複雑な集約
もサポートしている。

75. MySQLとHBaseの比較
MySQL HBase
Parallel Manual sharding Automatic
load balancing
Fail-over Manual master/ Automatic
slave switch
Read High Low
efficiency
Write Medium High
efficiency
Columnar No Yes
support

76. Puma2
o Facebookが最初に実装したPumaのアーキテ
クチャは、Puma2と呼ばれている。実際に稼働
したのは、2011年の3月で、Puma2 + HBas
eが走る100個のボックス上で、毎秒60万行の
ログを処理することが出来た。
PTail
Puma2
HBase
Serving

77. Puma2のアーキテクチャ
o Puma2には、PTailがパラレルなデータストリ
ームを提供している。
o それぞれのログ行毎に、Puma2は、HBaseに
対して、“increment”操作を発行する。
o Puma2のサーバは、HBaseに対して全て対
称的に配置されていて、shardingは行ってい
ない。
o HBase内の同一の行が、同時に複数のPuma
2サーバによってincrementされることが出
来る。

78. HBaseのincrement操作
o HBaseは、同一行の複数カラムに対して、一つ
の命令で、increment処理を行うことが出来る
。それで、Group-Byされた複数のカラムの
incrementを、一つの操作で処理出来る。
o 注意してほしいのは、この操作が、increment
に単純化された形ではあるが、MapReduceの
Reduce操作にあたるということである。HBas
eへのキーアクセスは、Shufflingに相当する。

79. Puma2の利点
o Puma2のいいところは、非常にシンプルで、管
理がしやすいことである。
o その基本的な理由は、Puma2サーバがほとん
ど状態を持たず、対称的に配置されているから
である。
o Puma2サーバが持つ唯一の状態は、PTail
のチェックポイントについての情報で、それは、
HBaseに定期的に書き込まれる。
o その結果、マシン・ボックスを簡単に増設出来
るし、もしも、マシンがダウンした場合には、再
起動をかけることも出来た。

80. Puma2の問題点
o HBaseのincrement処理は、高価なものであ
った。なぜなら、一行を丸ごと読み込んで、
incrementして書き出す必要があるのだが、
行の読み出しは高いものにつく。
o Puma2はまた、カウント以外の集約をサポート
するのが難しかった。そのためには、HBase
のコードに沢山手を入れる必要があったから。
実際、「一番アクセスの多い要素」の集約の
ため、Puma2では、「アクセスの多い要素のテ
ーブル」を複数個用意するという、手の込んだ
実装を行っていた。

81. Puma2の問題点
o 最後に、Puma2では、incrementとチェックポ
イントの書き出しは、同一のトランザクションで
は行えなかったので、多少のデータの重複が生
じかねないという問題があった。

82. Puma2の改善の試み (1)
o Puma2のサービスの改善で、誰もが思いつく
アイデアは、HBaseの負荷を減らすために、
incrementの要求をバッチ化して、ひとまとめ
で行うことだった。
o しかし、Group-Byのキーは、ロングテール
状に、非常に広い範囲にわたって分布している
ので、このアイデアは、うまく機能しなかった。
o それに、バッチの途中ではチェックポイントを保
存することが出来ないので、データの正確性も
低めることになる。

83. Puma2の改善の試み (2)
o HBaseの側では、まず、ロックの数を減らすこ
とで、"increment"操作の最適化を行った。
o 別の大きな効果を上げた改善は、DataNode
のデーモンを経由しないで、ディスク上のHDF
Sファイルを直接読むという、ショートカット読み
出しだった。
o Facebookはまた、高負荷の下での信頼性を
改善した。
o いろいろやってみたが、Puma2は、特に、ユニ
ーク数のカウンターについては、ハッピーとは
いえない状態だった。

84. Puma3
PTail
Puma3
HBase
いろいろやってみたが、Puma2は、 Serving
不十分だった。そこで、Facebookは、
Puma3と呼ばれるアーキテクチャに切り替えた。

85. Puma2とPuma3の違い
メモリーの中での集約
o Puma2とPuma3の最大の違いは、Puma3
では、HBaseを使う代わりに、Puma3のプロセ
スのメモリーの中で集約を行っているというこ
とだ。ローカルなメモリー操作はずっと高速であ
るので、ずっと速いスループットを達成すること
が出来る。

86. Puma3のアーキテクチャ
PTail
Puma3
HBase
o Puma3は集約キーで分割される
o Shardはメモリー中のハッシュマップ
o ハシュマップのエントリーは、集約キー Serving
と、集約のユーザー定義のペア
o HBaseは、永続的なキー／バリューのス
トレージ

87. 集約キーによるSharding
o メモリー中で集約を行うために、Facebookは、
Puma3のサーバを集約キーで分割シェーディ
ングした。
o このことは、入力となるPTailのデータストリー
ム自身も分割シェーディングされねばならない
ことを意味する。それは、Calligraphusのアプ
リケーション・バケッティングの機能によって
サポートされる。

88. ハッシュマップのエントリーと
永続的なストレージ
o Puma3の分割の要素は、基本的にはイン・メ
モリーのハッシュマップである。それぞれのハ
ッシュマップのエントリーは、count, sum, avg,
その他なんでもいいのだが、集約キーと集約
のユーザー定義のペアである。
o Facebookは、HBaseを永続的なキー/バリュ
ーのストレージとして使っている。ただ、普通は
それから読み出すことはない。

89. Puma3への書き込み
PTail
Puma3
HBase
o 書き込みの流れ
n それぞれのログ行から、キー／バリュー
のカラムを抜き出す。 Serving
n ハッシュマップを検索して、ユーザーが定義した
集約関数を呼び出す。

90. Puma3への書き込み
o Puma3の書き込みの流れは、かなり単純で
ある。基本的には、それぞれのログ行のカラム
から、キーと値を抜き出す。
o キーを使ってメモリー中のハッシュマップを検
索し、ユーザー定義の集約関数に、値を与えて
呼び出す。
o 注意してほしいのは、ログのストリームは、集
約キーで分割されているので、同じ集約キーは
一つ以上のPuma3のプロセスには現れること
はないということである。このことが、Puma3が
機能する鍵となる。

91. Puma3の状態の保存
PTail
Puma3
HBase
o チェックポイントの流れ
n 五分毎に、修正されたハッシュマップの
エントリーとPTailのチェックポイントを
HBaseに格納する。 Serving
n これらは、起動時には、 (ノードが落ちた後も)、
HBaseからロードされる。
n 一定時間が経過したら、メモリーから、これらの
アイテムは取り除かれる。

92. Puma3の状態の保存
o Facebookは、Puma3のプロセスの状態を5
分おきに、HBaseにチェックポイントしている。
基本的には、PTailのチェックポイントだけでは
なく、修正された全てのハッシュマップのエン
トリーを保存している。
o このことは、もしPuma3がクラッシュして再起
動するのなら、HBaseからシークエンシャル
Readで、状態をロードすることが出来るという
ことである。HBaseのシークエンシャルReadは
、かなり速い。

93. Time Window
o メモリーを節約するために、ある集約の時間枠
がすぎたら、そのハッシュマップ・エントリーをメ
モリーから取り除いた。
o なぜなら、その時間枠に対して、新しいログ行
を受け取ることは、二度とないからだ。

94. Puma3からの読み込み
PTail
Puma3
HBase
o 読み込みの流れ
n コミットされない読み込み：
メモリー中のハッシュマップから Serving
直接サービスされる。ミスがあった場合には、
HBaseからロードされる
n コミットされたRead:
HBaseから読み込まれサービスされる

95. Puma3からの
コミットされない読み込み
o データの読み込みの流れについては、二つの
選択がある。
o もし、遅延が10秒程度の、コミットされていない
集約を読み出したいのなら、直接、イン・メモリ
ーのハッシュマップのサービスを受ければいい。
o 集約の時間枠が終了してしまったという時だけ
に起きる、ミスの場合にだけ、HBaseにいけば
いい。

96. Puma3からの
コミットされた読み込み
o もし、コミットされたデータを読みたければ、
Puma3は、HBaseから読み出してサービス
する。
o コミットされていない集約の結果の価値は、
Puma3のプロセスが、次のチェックポイントを
残す前に死んだ時には、価が少なくなることが
あるのに注意しよう。
o Facebookでは、カウントが減らないように、
Puma3とサービスの間にキャッシュの層をおく
ことを計画している。

97. Puma3でのJoin
PTail
Puma3
HBase
o ジョイン
n HBaseにStaticなジョイン・テーブルがある
n ユーザー定義関数user-defined Serving
function (udf)は、分散ハッシュ検索される
n ローカル・キャッシュで、udfの検索のスループッ
トは大きく改善される。

98. Static Table Join
o Puma3は、HBase中のスタチックなテーブル
とのジョインの機能もサポートしている。
o ジョインのキーは、スタティックなHBaseテーブ
ルの行キーでなければいけない。それは、ユー
ザ定義関数の中に、簡単な分散ハッシュ検索と
して実装されている。
o ローカルキャッシュが、このユーザ定義関数の
スループットを大きく改善することが知られて
いる。

99. Puma2とPuma3の比較
o Puma2とPuma3を比較すると、Puma3は、
書き込みのスループットが、はるかに優れてい
ることが分かる。
o 同じ負荷の仕事をするのに、25%のマシンで
十分だった。その主な理由は、HBaseが本当
に書き込みのスループットがいいからだった。

100. Puma3の問題
o 同時に、Puma3は、沢山のメモリーを必要と
した。基本的には、変化する集約は、ログ・ス
トリームの書き込みスループットを保証するた
めには、全てメモリー上に格納されている必要
があった。
o 現在、Facebookは、ハッシュマップのために
一ボックスあたり、60GBのメモリーを利用して
いる。
o 将来的には、SSDを利用して、一ボックスあたり
、この10倍のスケールを可能とすることは容易
だと思う。

101. Puma3での、特別な集約
o Puma3では、多少の近似値になるが、次のよ
うな特別な集約を行うことは簡単に出来る。
o ユニーク数のカウントでは、単純なadaptiveサ
ンプリング・アルゴリズムを実装した。このアル
ゴリズムでは、ユニークなアイテムの数が増え
るにつれ、積極的なサンプリングが行われる。
o Facebookは、また、標準的なブルーム・フィル
タを実装することを計画している。最もアクセス
の多いアイテムの集約では、古典的なlossyカ
ウンティング・アルゴリズムと確率的なLossyカ
ウンティング・アルゴリズムの実装を計画して

102. PQL – Puma Query Language
o Pumaの、他のストリーム処理のプロジェクトと区別さ
れる、最も大きな特徴は、その言語である。
o Facebookは、入力ストリームと出力テーブル、そしてク
エリーそのものも定義する、SQL-likeなクエリー言語、
PQL – Puma Query Language を作り上げた。
o このクエリーには、ジョインのために、ユーザー定義関
数だけでなく、集約機能も含まれていることに注意して
ほしい。
o Puma3は、現時点では、製品版の一つ前の段階にある。
Facebookは、Puma2とHiveと比較して、全てのサ
マリーを検証出来たら、直ちに、Puma3を製品版に押
し上げていく予定である。

103. PQL – Puma Query Language
o CREATE INPUT TABLE t o CREATE AGGREGATION
(‘time', ‘adid’, ‘userid’); ‘abc’
o CREATE VIEW v AS INSERT INTO l (a, b, c)
SELECT *, udf.age(userid) SELECT
FROM t udf.hour(time),
WHERE udf.age(userid) > adid,
21 age,
count(1),
o CREATE HBASE TABLE h … udf.count_distinc(userid)
o CREATE LOGICAL TABLE l … FROM v
GROUP BY
udf.hour(time),
adid,
age;

104. Future Works
challenges and opportunities

105. 今後の課題
o Facebookが、次に行おうと計画しているもののリスト
である。
o 第一に、Puma3のシンプルなスケジューラがある。作
業は連続的に続いていくのだから、必要なのは、シンプ
ルなスケジューリングだけである。もっともありそうなこ
とは、既存のフレームワークを再利用することだ。
o 第二に、Facebook内部で、このプロジェクトを広く利用
していくことである。毎日のレポート用の検索の大部分を
、その検索がPumaでサポート出来る、十分シンプルな
ものであるなら、Hiveから移行する計画である。このこ
とは、遅延を軽減するだけでなく、圧縮・解凍の削減
によって、効率性も改善するだろう。

106. o 第三は、オープンソース化である。現時点では
、最大のボトルネックは、Java Thriftで、
Facebookとオープンソースの間には、分岐が
生じている。
o Facebookは、まず、Calligraphusから始めて
、一つずつ、オープンソース化を進めていく計
画である。

107. リアルタイムの
Stream処理のシステム
o アカデミーでも企業でも、沢山の同じような、リ
アルタイムのStream処理のシステムが存在し
ている。次のようなものがある。
o STREAM ：Stanford
o Flume ： Cloudera
o S4 ：Yahoo
o Rainbird/Storm ：Twitter
o Kafka ：Linkedin

108. Facebookのシステムの特徴
o 一つ一つを比較する代わりに、Facebookのシ
ステムの重要な違いについてまとめてみよう。
o Data Freewayは、10秒以内の遅延で毎秒
9GBのスループットを持つ、スケーラブルなデ
ータ・ストリームのフレームワークである。
o それは、Push/RPCとPull/FS、両方のチャン
ネルのサポートしている。
o それは、ユースケースに応じて、チャンネルの
任意の組み合わせが出来るコンポーネントを持
っている。

109. Pumaがサポートする機能
o Pumaは、信頼性の高いストリーム集約エンジ
ンである。それは、時間ベースのGroup Byと
Table-Stream Lookup Joinの両方を、しっ
かりとサポートしている。
o 新しいリアルタイムMapReduceとこれまでの
MapReduceを比較したとき、Facebookの
Pumaは、これまでのHiveに比較出来る、ク
エリー言語PQLを持っている。

110. Pumaがサポートしない機能
o Pumaは、スライディング・ウィンドウやストリ
ーム・ジョインのサポートはしない。
o というのも、これらは非常に難しい問題で、
Facebookの環境では存在しない問題だから
である。

112. Apache hadoop goes realtime
at Facebook

113. Facebook recently deployed Facebook
Messages, its first ever user-facing application
built on the Apache Hadoop platform. Apache
HBase is a database-like layer built on Hadoop
designed to support billions of messages per
day. This paper describes the reasons why
Facebook chose Hadoop and HBase over other
systems such as Apache Cassandra and
Voldemort and discusses the application’s
requirements for consistency, availability,
partition tolerance, data model and scalability.
We explore the enhancements made to
Hadoop to make it a more effective realtime
system, the tradeoffs we made while
configuring the system,

114. and how this solution has significant
advantages over the sharded MySQL
database scheme used in other
applications at Facebook and many other
web-scale companies.
We discuss the motivations behind our
design choices, the challenges that we face
in day-to-day operations, and future
capabilities and improvements still under
development. We offer these observations
on the deployment as a model for other
companies who are contemplating a
Hadoop-based solution over traditional
sharded RDBMS deployments

115. 4. リアルタイム HDFS

116. 高可用性 –- AvatarNodeの導入
o 立ち上げ時に、HDFSのNameNode（GFSの
MasterNode）は、fsimageというファイルから
、ファイルシステムのメタデータを読み込む。こ
のメタデータは、HDFSの全てのファイルとディ
レクトリの名前とメタデータを含んでいる。
o ただ、NameNodeは、それぞれのファイルの
ブロックの位置をずっと記憶している訳ではない
。だから、NameNodeのコールドスタートの時
間は、主に二つの部分から構成されることに
なる。

117. DataNodeのコールド・スタート
o 第一に、ファイルシステムのイメージを読み込み
、トランザクションログを適用して、新しいファイ
ルシステムのイメージをディスクに書き戻す。
o 第二に、多数のDataNodeから、クラスタ中の
全てのブロックの位置情報を回復するために、
ブロック情報を処理する。Facebookの最大の
HDFSクラスタは、約1億五千万個のファイル
を持っているのだが、この二つのステップに同
じ程度の時間を要した。全体で、このHDFS
のコールドスタートには、45分かかった。

118. BackupNodeのフェールオーバ
o Apache HDFSのBackupNodeでは、フェー
ルオーバ時にディスクからfsimageファイルを
読み込むことを回避できるのだが、それでも、
全てのDataNodeからブロック情報を集める必
要があった。こうして、BackupNodeを利用し
たソリューションでは、フェールオーバの時間は、
20分近くかかることになる。
o 我々の目標は、フェールオーバを数分以内に
終えることだったので、BackupNodeによる
ソリューションは、迅速なフェールオーバとい
う我々の目標にはあわなかった。

119. BackupNodeの別の問題
o 別の問題もある。NameNodeは、全てのトランザクショ
ンの度に、同期的にBackupNodeを更新するので、シ
ステム全体の信頼性は、単一のNameNodeの信頼性
より低いものになる。
o こうして、HDFS Avatarが生まれることになった。

120. HDFS AvatarＮｏｄｅ
o Facebookのクラスタは、二つのAvatarNode
を持っている。アクティブなAvatarNodeとスタ
ンバイしているAvatarNodeの二つである。そ
れらは、アクティブ・パッシブなホット・スタンバイ
のペアを構成している。
o AvatarNodeは通常のNameNodeのラッパ
ーである。Facebookの全てのHDFSクラス
タは、ファイルシステムのイメージの一つのコピ
ーとトランザクション・ログの一つのコピーを保
存するのに、NFSを利用している。

121. 二つのAvatarＮｏｄｅ
o アクティブAvatarNodeは、そのトランザクション
をNFSファイルシステムのトランザクション・ログ
に書き込む。
o 同時に、スタンバイAvatarNodeは、NFSファ
イルシステムから同じトランザクション・ログを
読み込むためにオープンする。そうして、自分
の名前空間上でそのトランザクションを実行して
、その名前空間を可能な限りアクティブな
AvatarNodeの名前空間に近いものに保ち続
ける。

122. Figure 1

123. GFS Architecture

124. AvatarNodeとDataNode
o スタンバイAvatarNodeは、また、アクティブ
AvatarNodeのチェックポイントの面倒も見て、
新しいファイルシステムのイメージを作り、分離し
たSecondaryNameNodeが無くてもいいよう
にする。
o DataNodeは、単一のNameNodeだけに話し
かける代わりに、アクティブAvatarNodeとスタ
ンバイAvatarNodeの両方に話しかける。この
ことは、スタンバイAvatarNodeが、最も新しい
ブロックの位置情報を持つと同時に、一分以内に
Activeになりうることを意味する。

125. AvatarDataNodeとZooKeeper
o AvatarのDataNodeは、ハートビートとブロッ
ク情報と受け取ったブロックを、両方の
AvatarNodeに送る。
o AvatarDataNodeは、ZooKeeperで統合さ
れていて、どちらのAvatarNodeがプライマリ
かを知っていて、そのプライマリのAvatarNod
eから来る、複製／削除命令のみを処理する。
スタンバイAvatarNodeからの複製・削除命
令は、無視される。

126. HDFSのトランザクション・
ロギングの強化
o HDFSは、ファイルが閉じられるか、あるいは
sync/flushされた時だけ、トランザクション・ロ
グに新しく割り当てられたブロックidを記録する。
o 我々は、出来る限り、フェールオーバをトランス
ペアレントにしたいので、スタンバイしている
AvatarNodeは、それぞれのブロックの割当を
それが起きたときに知る必要がある。

127. ログの利用
o それで、新しいトランザクションを、それぞれの
ブロックの割当の都度、エディット・ログに書き
出す。こうして、クライアントは、書き込み中のフ
ァイルのフェールオーバの直前まで、ファイル
に書き込みを続けることが出来る。
o スタンバイしているAvatarNodeが、アクティブな
AvatarNodeによって書き込まれたトランザ
クション・ログから、トランザクションを読み込む
とき、不完全なトランザクションを読み出す可能
性がある。

128. ログ・フォーマットの変更
o こうした問題を避けるために、このファイルに書
き込まれたトランザクション毎、トランザクション
の長さ、トランザクションのID、チェックサムの
情報を持つように、エディット・ログのフォーマッ
トを変更する必要があった。

129. トランスペアレントなフェールオーバ：
DAFS
o 我々は、フェイルオーバ・イベントをまたいで
HDFSにトランスペアレントなアクセスを提供
する、クライアント上の階層ファイルシステムであ
るDistributedAvatarFileSystem (DAFS)
を開発した。
o DAFSは、ZooKeeperと統合されている。
ZooKeeperは、与えられたクラスタのプライマリ
なAvatarNodeの物理アドレスを持つzNode
を保持している。

130. DAFSとZooKeeper
o クライアントがHDFSクラスタ（例えば、
dfs.cluster.com）と接続しようとする時には、DAFSは、
ZooKeeper上でプライマリAvatarNode（dfs-0.
cluster.com）の実際の物理アドレスを持つ対応する
zNodeを探して、その後の全ての呼び出しをプライマリ
AvatarNodeに向ける。
o もしも呼び出しが、ネットワーク・エラーにあったら、プラ
イマリ・ノードの変更のために、ZooKeeperをチェック
する。
o フェールオーバ・イベントの場合には、zNodeは新しい
プライマリAvatarNodeの名前を含んでいることにな
ろう。DAFSは、そうした時、新しいプライマリ
AvatarNodeに対してその呼び出しを再実行するだろう。

131. DAFSとZooKeeper
o 我々は、ZooKeeperのサブスクリプション・モ
デルを利用しなかった。なぜなら、それは、
ZooKeeperサーバにもっと沢山のリソースが
向けられることを必要とする可能性があったか
らである。
o もしも、フェールオーバが進行中であったなら、
DAFSは、フェールオーバが完全に終わるまで
自動的にブロックするだろう。フェールオーバ・
イベントは、HDFSのデータにアクセスするアプ
リケーションにとって、完全に、トランスペアレン
トなものになる。

132. リアルタイムの仕事の為の
パフォーマンスの改善
o HDFSは、もともと、MapReduceのような高
スループットのシステム用にデザインされている
。そのもともとのデザインの原則の大多数は、
スループットを改善しようというもので、反応時
間については、あまりフォーカスしていない。
o 例えば、エラーを扱う際、fast failureに際し
ても、再実行や待機を行いがちである。たとえ
エラーの場合でもリーズナブルな反応時間で、
リアルタイムなアプリケーションをサポートする
ことは、HDFSによって、重要な挑戦となる。

133. RPC タイムアウト
o 一つの例は、HadoopがどのようにRPCのタイ
ムアウトをハンドルするのかということである。
o Hadoopは、Hadoop-RPCを送るのに、TCP
コネクションを利用している。RPCのクライアン
トが、TCPソケットのタイムアウトを検出すると、
RPCタイムアウトを宣言する代わりに、RPCサ
ーバにpingを送る。もしも、まだサーバが生き
ているなら、クライアントはレスポンスを待つ。

134. いつ待機すべきか？
o このアイデアは、もしRPCサーバが、通信の爆
発や一時的な高負荷や広域のGCで、停止状
態に遭遇していているのなら、クライアントは、
待機してサーバへのトラフィックを絞り込むべき
だというものである。
o その反対に、タイムアウトの例外を投げたり、
RPCリクエストを再試行するというのは、タスク
の不必要な失敗を招いたり、あるいは、RPCサ
ーバに更なる負荷を加えることになる。

135. いつ、待機すべきでないか
o しかしながら、無限に待機を続けることは、リア
ルタイム性が要求される、どのようなアプリケ
ーションに対してインパクトを与える。
o HDFSクライアントは、時々、あるDataNodeに
RPCを行うのだが、DataNodeが時間内にレ
スポンスを返すことに失敗した時には、悪いこ
とになる。そのクライアントはRPCの中で固まっ
てしまう。

136. より良い戦略、Fail Fast
o より良い戦略は、fail fastであり、読み出しでも
書き込みでも、異なるDataNodeを試すことで
ある。
o こうして、我々は、サーバとのRPCセッションが
始まるときに、RPCタイムアウトを指定する能力
を開発した。

137. Recover File Lease
o 別の増強は、書き手のリースを早く取り消すということで
ある。HDFSは、ファイルに対しては、一人の書き手し
かサポートしていない。そして、このセマンチックスを強
化するために、NameNodeはリースを保持している。
o アプリケーションが、あるファイルを読み込みで開こうと
した時、そのファイルが、以前のクローズがきれいに行
われていなかったという例は沢山存在する。以前は、こ
の対応は、ログファイルに対してHDFS-appendを、呼
び出しが成功するまで繰り返すことで行われていた。

138. Append操作とLease
o append操作は、ファイルのソフト・リースのエ
クスパイアをトリガーする。それで、アプリケーシ
ョンは、HDFSのNameNodeがログファイル
のリースを手放すまで、ソフト・リースの最小時
間（デフォールトでは一分）は待たなければいけ
なかった。

139. RecoverLease APIの追加
o 第二に、HDFS-append操作は、通常は一つ
以上のDataNodeを巻き込んだ書き込みパイ
プラインを確立するので、不必要なコストを加え
ることになる。
o エラーが起きれば、パイプラインの確立には10
分近くかかりかねない。HDFS-appendのオー
バヘッドを避けるために、我々は、ファイルのリ
ースを取り消す、軽量なrecoverLeaseと呼ばれ
るHDFS APIを追加した。

140. recoverLeaseの働き
o NameNodeは、recoverLease要求を受け取
ると、ただちにファイルのリース保持者を自分
自身に変更する。そして、リースの回復プロセ
スを開始する。
o recoverLeaseのRPCは、リースの回復が終了
したかについてのステータスを返す。アプリケ
ーションは、ファイルを読もうとする前に、
recoverLeaseからの成功したというリターンコ
ードを待つ。

141. HDFSへの読み書きの遅延
o アプリケーションが、スケーラビリティやパフォ
ーマンスの理由で、HDFSにデータを格納した
いと思うことは度々ある。
o ただ、HDFSへの読み書きの遅延は、マシン上
のローカル・ファイルに対する読み書きより、か
なりの程度で大きい。

142. ローカルなレプリカからの読み出し
o こうした問題を和らげるために、HDFSクライア
ントが、データのローカルなレプリカがあるかを
検出して、もし存在すれば、データをDataNod
e経由で転送すること無く、 ローカルなレプリカ
からトランスペアレントにデータを読み出す、機
能強化を実装した。
o これによって、HBaseを利用するある種の作業
では、パフォーマンスのプロファイルは、二倍の
結果を得た。

143. 新しい特徴 -- Hflush/sync
o Hflush/syncは、HBaseとScribeの両方にと
って、重要な操作である。それは、クライアント
側のバッファーに書き込まれたデータを、書き
込みパイプラインにプッシュして、どんな読み手
に対してもデータを見えるようにして、パイプラ
イン上のクライアントあるいはDataNodeのど
ちらか一方が倒れた場合でも、データの耐久性
を高める。

144. 新しい特徴 -- Hflush/syncの改善
o Hflush/syncは同期的な操作である。このことは、書き
込みパイプラインからのアクノレッジが受け取られるま
でかえってこないことを意味する。
o この操作は、頻繁に呼び出されるので、その効率性を
高めることは重要である。我々が行った一つの最適化は、
Hflush/syncが応答を待っている間にも、引き続いて
書き込みを許すことである。
o この最適化は、ある特定のスレッドが定期的にHflush/
syncを呼び出すHBaseとScribeの両方で、大幅に、書
き込みのスループットを改善した。

145. 新しい特徴 --Concurrent Readers
o 我々は、書き込みの最中にも、ファイルを読む
ことの出来る能力を必要とするアプリケーション
を持っている。
o 読み手は、まず、NameNodeに、そのファイル
のメタデータ情報を取得するために問い合わ
せる。NaneDataは、最後のブロックの長さに
ついては、最新の情報を持っていないので、ク
ライアントは、レプリカが存在するDataNode
の一つからその情報を取得する。

146. チェックサムの再計算
o そして、ファイルの読み出しを始める。この読み
手と書き手を並行して走らせるという挑戦は
、データの内容やチェックサムが動的に変わり
つつあるときに、いかにしてデータの最新のチ
ャンクを提供するかということである。
o 我々は、この問題を、データの最新のチャンク
のチェックサムを、要求された時点で再計算す
ることで解決した。

147. 製品版HBASE
この節では、我々がFacebookで行ってきた、正
確性、耐久性、可用性、パフォーマンスに関連した、
HBaseの重要な機能増強のいくつかを紹介したい。

148. ACIDコンプライアンス
o アプリケーションの開発者は、彼らのデータベ
ース・システムに、ACID適合性、あるいは、そ
のある種の近似に、期待するようになってきて
いる。実際、我々の初期の評価では、強い整合
性の保証は、HBaseのメリットの一つであった。

149. ACID適合性でのHBaseの修正
o 既存のMVCC（MultiVersion Concurrency
Control）風の、読み書きの整合性コントロール
（Read-Write Consistency Control）は、十
分な隔離を保証し、HDFSのHLog（Write
Ahead Log=ログ先行書き込み）は、十分な
耐久性を与えている。
o しかし、我々が必要とする、ACID適合性の行
レベルでのAtomicityと整合性に、HBaseが
忠実であることを明確にするためには、いくつ
かの修正が必要であった。

150. Atomicityの保証
o 最初のステップは、行レベルでのAtomicityを
保証することだった。RWCCは、大部分の保証
を与えていた。
o しかしながら、ノードが落ちたときには、そうした
保証は失われる可能性があった。
o 元来、一つの行の中の複数のエントリーのトラ
ンザクションは、HLogには、シーケンシャルに
書き込まれるもの。

151. ログ・トランザクション（WALEdit）
の新しいコンセプト
o もしも、RegionServerが、この書き込みの間
に死ぬと、そのトランザクションは、部分的にし
か書き込まれない。
o ログ・トランザクション（WALEdit）の新しいコン
セプトで、それぞれの書き込みトランザクショ
ンは、完全に終了するか、全く書き込まれない
かのどちらかになるだろう。

152. Consistencyの保証
o HDFSは、HBaseに複製機能を提供し、我々
の使用のためにHBaseが必要とする、強い整
合性の保証の大部分をハンドルすることが出
来る。
o 書き込みの間、HDFSは、それぞれのレプリカ
にパイプラインの接続を準備し、全てのレプリ
カは、どんなデータが送られてもいいというACK
を返す。
o HBaseは、レスポンスか失敗の通知を受け取
るまで、次へは進まない。

153. Consistencyの保証
o シーケンス・ナンバーの利用を通じて、
NameNodeは、レプリカのどんな間違った振
る舞いも同定出来て、それを排除する。
o 機能している間は、NameNodeがこのファイ
ルの回復をするには、時間がかかった。

154. HLogのロールバック
o HLogの場合には、整合性と耐久性を維持しな
がら、前に進むというのは、絶対的にマストな
条件である。
o もし、たった一つでもHDFSのレプリカがデータ
の書き出しに失敗していることが検出されたら、
HBaseは、直ちにログをロールバックして、新
しいブロックを取得する。

155. データ保護機能
o HDFSはまた、データの破壊に対する保護機能
も提供している。HDFSブロックが読み込まれ
る時、チェックサムのチェックが行われて、それ
が失敗する場合には、全てのブロックが破棄さ
れる。
o データの破棄は、ほとんど問題にはならない。
なぜなら、そのデータには、二つのレプリカが
存在しているから。
o 我々は、もしも3つのレプリカ全てが破損したデ
ータを含んだ場合には、そのブロックを隔離して
、事後解析にまわすという機能を追加した。

156. 可用性の改善
o 我々は、HBaseリージョンをオフラインにするよう
なKillテストに際して、沢山の問題があることを
、独自に明らかにした。
o すぐに、次のような問題を特定した。クラスタの
遷移の情報は、その時点でアクティブなHBase
マスターのメモリー上にしか格納されていない。
マスターが失われれば、こうした情報も失わ
れる。

157. HBaseマスターの書き換え
o 我々は、HBaseマスターの大規模な書き換え
を行った。この書き換えの、重要なコンポーネン
トは、リージョンの割当情報をマスターのメモリ
ーからZooKeeperに移すものであった。
o ZooKeeperは、多数のノードに書き込む
Quorum制を採用しているので、マスター
のフェールオーバの際もこの遷移状態は失わ
れず、多数のサーバの障害時でも、生きながら
える。

158. オンライン・アップデート
o クラスターのダウン時間の最大の要因は、サー
バのランダムな故障ではなく、むしろ、システム
のメンテナンスであった。我々は、このダウン時
間を最小なものにするために、多くの問題を解
決した。
o まず、我々は、RegionServerが、停止要求を
発してからシャットダウンするまでに数分を要す
る場合が、間欠的にあることをたびたび発見
した。

159. 圧縮を割り込み可能に
o この間欠性の問題は、長い圧縮サイクルに起
因していた。この問題に対応して、我々は、終
了時の応答性を良くするために、圧縮を割り込
み可能にした。
o この対応で、RegionServerは数秒でダウン
出来るようになり、クラスタのシャットダウン時
間は、リーズナブルな範囲に収まった。

160. 順次再起動
o もう一つの、Availabilityの改善は、順次再起
動である。もともと、HBaseは、クラスタ全体を
止めて、それからアップグレードを始めることし
かサポートしていなかった。
o 我々は、一つのサーバをある時点でアップグレ
ードするソフトウェアを実行する順次再起動スク
リプトを追加した。マスターは、RegionServer
がストップした時点で、リージョンを再割り当て
するので、このことは、我々のユーザーが経験
するダウン時間の量を最小厳なものにする。

161. 再起動の問題
o 我々は、サーバが新しく再起動したことに起因
する、数々の新しい問題を解決した。
o たまたま、順次再起動中に起きる数々のバグは
、リージョンの停止と再割り当てに関連していた。
o そういうわけで、ZooKeeperとの統合というマ
スターの書き換えは、ここで述べた数々の問題
の対応にも助けとなった。

162. 分散ログの分割
o RegionServerが死んだ時には、そのリージョ
ンが再開可能となり読み書きが利用可能となる
前に、そのサーバのHLogは分割され再生され
なければならない。
o 以前には、ログが再生される前に、残った
RegionServerをまたいで、マスターがログを
分割していた。
o サーバ毎にたくさんのHLogがあるので、ここが
リカバリーのプロセスのもっとも遅い部分であ
った。

163. ログ分割の並列化
o この処理は並列化出来る。RegionServerを
またいだ、この分割タスクの管理に、ZooKeepe
rを活用することで、いまやマスターは分散した
分割ログの協調のみを行う。
o このことは、リカバリーの時間を大幅に削減し
、フェールオーバのパフォーマンスに深刻な影
響を与えることなしに、RegionServerがより多く
のHLogを保持することを可能とした。

164. パフォーマンスの改善
o HBaseのデータの挿入は、時には余分な読み
出しを犠牲にしても、連続的な書き込みにフォ
ーカスすることで、書き込みのパフォーマンスに
最適化されている。
o データのトランザクションは、まず、コミット・ログ
に書き出され、それからMemStoreと呼ばれる
メモリー内のキャッシュに適用される。
MemStoreが、あるしきい値に到達すると、
HFileに書き出される。HFileは、書き換え不可の
HDFSファイルで、ソートされたkey/valueペア
を含んでいる。

165. HFileの圧縮
o 既に存在しているHFileを編集する代わりに、
flushの度に新しいHFileが書き出され、リージ
ョンごとのリストに追加される。
o 読み出しの要求は、これら複数のHFileに対し
てパラレルに行われ、最終的な結果に集約さ
れる。
o 効率を上げるため、これらのHFileは、定期的
に圧縮され一つにマージされる必要がある。こ
うして、読み出しのパフォーマンスの低下を避
ける。

166. 圧縮アルゴリズム
o 読み出しのパフォーマンスは、リージョン内のフ
ァイルの数と相関する。こうして、よく出来た圧
縮アルゴリズムが、本質的に重要なかなめと
なる。
o もう少し詳しく述べれば、ネットワークIOの効
率は、もしも圧縮アルゴリズムが不適切であ
れば、ドラスティックな影響を受けかねない。我
々のユースケースにとって効率的な圧縮アルゴ
リズムを得たと確信するために、重要な努力が
なされた。

167. 二つの圧縮
o 圧縮は、最初は、それがマイナーかメジャーか
に従って、二つの異なったコードパスに分離さ
れていた。
o マイナーな圧縮は、サイズを指標として全て
のファイルからその一部分を選び出す。
o 一方、時間ベースのメジャー圧縮は、無条件で
全てのHFileを圧縮する。

168. 圧縮コードベースの統一
o 以前には、メジャー圧縮のみが、消去・上書き・
期限切れデータの除去を行っていたのだが、そ
れで、マイナー圧縮が、必要以上に大きなHFil
eを生み出す結果になった。
o それは、ブロック・キャッシュの効率を低下させ
、将来の圧縮に悪影響を与える。二つのコード
パスを統一することで、コードベースはシンプル
になり、ファイルは可能な限り小さなものにな
った。

169. 圧縮アルゴリズムの改善
o 次の仕事は、圧縮アルゴリズムの改善であった
。社内でローンチをした後で、我々は、putとsyn
cの遅延が非常に大きいことに気づいた。
o 病的な場合には、通常の圧縮では、3つの5M
Bのファイルは5MBより少し大きいファイルを生
成するのだが、1GBものファイルがあることを
見つけた。このネットワークIOの浪費は、圧
縮キューがバックログになるまで続いていた。

170. 遅延の解消
o この問題は、既存のアルゴリズムでは最初の４つ
のHFileを無条件でマイナー圧縮するのだが、
一方で、HFileが３つになった時に、マイナー圧
縮のトリガーがかかることに起因していた。
o この問題は、ある一定以上のサイズのファイル
の無条件なファイル圧縮をやめ、圧縮対象の
適当な対象が見つからなかったら圧縮をスキッ
プすることで解決された。
o その後、putの遅延は、25ミリsecから3ミリsec
に落ちた。

171. サイズ比の決定
o 我々は、圧縮アルゴリズムのサイズ比の決定
の改良にも取り組んだ。もともとの圧縮アルゴ
リズムは、ファイルの年齢でソートし、関連す
るファイルを比較するものだった。
o もしも、古いファイルが新しいファイルのサイズの
2倍以下だったら、圧縮アルゴリズムは、そのフ
ァイルを取り込んで、この操作を繰り返す。
o しかし、このアルゴリズムは、HFileの数とサイ
ズが非常に大きいものになると、望ましくない振
る舞いをした。

172. アルゴリズムの修正
o これを改善するために、全ての新しいHFileの
サイズ総計の2倍以内であれば、古いファイル
を取り込むことにした。
o これで安定状態は、古いHFileは、次の新し
いファイルの約4倍のサイズになるように変わ
った。
o 結果として、圧縮率は50%を維持した。

173. 読み込みの最適化
o 既に議論したように、読み込みのパフォーマンス
では、リージョン内のファイルの数を低いものに
して、ランダムIO操作を減らすことがかなめと
なる。
o さらに、圧縮の利用がディスク上のファイルの数
を低いものにし、また、ある検索においてはあ
るファイルをスキップすることも、同様に、IO操
作を低減する。

174. ブルームフィルタの利用
o ブルームフィルタは、ある行、または、行とカラ
ムが、あるHFile内に存在するかをチェックする
、メモリー空間的に効果的で固定時間の方法
を提供する。
o それぞれのHFileは、末尾にオプションのメタデ
ータブロックを持って、連続的に書き込まれてい
るので、ブルームフィルタの追加は、重要な変
更なしに行える。

175. ブルームフィルタのキャッシュ化
o foldingの利用を通じて、それぞれのブルー
ムフィルタは、ディスクとメモリー内のキャッシュ
への書き込み時には、可能な限り小さいものに
抑えられた。
o 特定の行またはカラムに対する検索の要求は
、それぞれのHFileのキャッシュされたブルー
ムフィルタのチェックで、いくつかのファイルを全
くスキップすることを可能にした。

176. HFileのタイムスタンプ
o HFileに格納されたデータは、時系列であるか
特別のタイムスタンプを含んでいるので、特別
のタイムスタンプ選択のアルゴリズムが追加さ
れた。
o 時間が進んでも、あるデータのタイムスタンプよ
りずっと後に、データが挿入されることはほとん
どないので、それぞれのHFileは、一般的には
、固定された時間のレンジの値を含んでいる。

177. タイムスタンプのチェック
o この情報は、それぞれのHFileにメタデータとし
て格納され、ある特定のタイムスタンプ、ある
いは、タイムスタンプの範囲に対する検索は、
その要求がそれぞれのファイルの範囲を共通
点を持つかチェックされ、範囲に合わないもの
はスキップされる。

178. リージョンの局所性
o HDFSのローカルファイルの読み出しについて
の改善は、著しいものであったので、リージョ
ンが、そのファイルと同じ物理ノードでホストさ
れていることは、本質的に重要である。
o クラスタをまたぐリージョンの割り当てを維持し
ながら、局所性が維持されることを保証するよ
うに、ノードを再起動する変更が行われた。

181. Figure 1

182. GFS Architecture

183. Scribe

184. Scribe
https://github.com/facebook/scribe/wiki
o Scribe is a server for aggregating log data
that‘s streamed in real time from clients. It is
designed to be scalable and reliable.
o There is a scribe server running on every node
in the system, configured to aggregate
messages and send them to a central scribe
server (or servers) in larger groups.
o If the central scribe server isn’t available the
local scribe server writes the messages to a file
on local disk and sends them when the central
server recovers.

185. Scribe
https://github.com/facebook/scribe/wiki
o The central scribe server(s) can write the
messages to the files that are their final
destination, typically on an nfs filer or a
distributed filesystem, or send them to another
layer of scribe servers.
o Scribe is unique in that clients log entries
consisting of two strings, a category and a
message. The category is a high level
description of the intended destination of the
message and can have a specific configuration
in the scribe server, which allows data stores to
be moved by changing the scribe configuration
instead of client code.

186. Scribe
https://github.com/facebook/scribe/wiki
o The server also allows for configurations based
on category prefix, and a default configuration
that can insert the category name in the file
path.
o Flexibility and extensibility is provided through
the “store” abstraction.
o Stores are loaded dynamically based on a
configuration file, and can be changed at
runtime without stopping the server.

187. Scribe
https://github.com/facebook/scribe/wiki
o Stores are implemented as a class hierarchy,
and stores can contain other stores. This allows
a user to chain features together in different
orders and combinations by changing only the
configuration.
o Scribe is implemented as a thrift service using
the non-blocking C++ server. The installation
at facebook runs on thousands of machines
and reliably delivers tens of billions of
messages a day.

188. Scribe Overview / Reliability
https://github.com/facebook/scribe/wiki/Scribe-Overview
o The scribe system is designed to be robust to
failure of the network or any specific machine,
but does not provide transactional guarantees. If
a scribe instance on a client machine (we’ll call it
a resender for the moment) is unable to send
messages to the central scribe server it saves
them on local disk, then sends them when the
central server or network recovers. To avoid
overloading the central server upon a restart, the
resender waits a random time between
reconnect attempts, and if the central server is
near capacity it will return TRY_LATER, which
tells the resender to not attempt another send
for several minutes.

189. Scribe Overview / Reliability
https://github.com/facebook/scribe/wiki/Scribe-Overview
o The central server has similar behavior (the
same code in fact) for handling failure of the
nfs filer or distributed filesystem it’s writing to.
If the filesystem goes down the scribe server
writes to local disk until it recovers, then sends
the data from local disk to the remote
filesystem. The order of the messages is
preserved in both this and the resender case.

190. Scribe Overview / Reliability
https://github.com/facebook/scribe/wiki/Scribe-Overview
o These error cases will lead to loss of data:
o If a client can’t connect to either the local or
central scribe server the message will be lost
o If a scribe server crashes it could lose a small
amount of data that’s in memory but not on
disk
o Some multiple component failure cases, such
as a resender can’t connect to any central
server and its local disk fills up
o Some rare timeout conditions can lead to
duplicate messages

191. Scribe Overview / Configuration
https://github.com/facebook/scribe/wiki/Scribe-Overview
o The scribe server is configured by the file
specified in the -c command line option, or the
file /usr/local/scribe/scribe.conf if none is
specified on the command line.
o The basic idea of the configuration is that a
particular category if messages is sent to one
or more “stores” of various types. Some types
of stores can contain other stores, for example
a bucket store contains many file stores and
distributes messages to them based on a hash.

192. Scribe Overview / Configuration
https://github.com/facebook/scribe/wiki/Scribe-Overview
o The configuration file consists of a global
section and a section for each store. The global
section includes the listening port number and
the maximum number of messages that the
server can handle in a second.
o Each store section must include a category and
a type. There is no restriction on the number
categories or the number of stores per
category.

193. Scribe Overview / Configuration
https://github.com/facebook/scribe/wiki/Scribe-Overview
o The remaining items in the store configuration
depend on the store type, and include such
things as file location, maximum file size, how
often to rotate files, and where a resender
should send its data.
o A store can also contain another store
configuration, the name of which is specific to
the type of store. For example a store of type
buffer contains and stores and a store of type
bucket contains a store called .

194. Scribe Overview / Configuration
https://github.com/facebook/scribe/wiki/Scribe-Overview
o The types of stores currently available are:
o file – writes to a file, either local or nfs.
o network – sends messages to another scribe
server.
o buffer – contains a primary and a secondary
store. Messages are sent to the primary store if
possible, and otherwise the secondary. When the
primary store becomes available the messages
are read from the secondary store and sent to
the primary. Ordering of the messages is
preserved. The secondary store has the
restriction that it must be readable, which at the
moment means it has to be a file store.

195. Scribe Overview / Configuration
https://github.com/facebook/scribe/wiki/Scribe-Overview
o bucket – contains a large number of other
stores, and decides which messages to send to
which stores based on a hash.
o null – discards all messages.
o thriftfile – similar to a file store but writes
messages into a Thrift TFileTransport file.
o multi – a store that forwards messages to
multiple stores.

196. The Underlying Technology
of Messages
http://www.facebook.com/note.php?
note_id=454991608919#
2010年11月16日