Agile Cat — in the cloud

Facebook の HBase は、毎月 1350億 メッセージを処理する!

Posted in Big Data, Facebook, HDFS, NoSQL by Agile Cat on November 18, 2010

Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month
TUESDAY, NOVEMBER 16, 2010 AT 7:52AM
http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html

highscalability

You may have read somewhere that Facebook has introduced a new Social Inbox integrating email, IM, SMS,  text messages, on-site Facebook messages. All-in-all they need to store over 135 billion messages a month. Where do they store all that stuff? Facebook’s Kannan Muthukkaruppan gives the surprise answer in The Underlying Technology of Messages: HBase. HBase beat out MySQL, Cassandra, and a few others.

Facebook が導入する新しい Social Inbox が、電子メールおよび、IM、SMS、テキスト・メッセージ、Facebook オン・サイト・メッセージを統合するという記事を、どこかのメディアで読んでいると思う。 全般的に見て、Facebook は 1カ月に、1350億以上のメッセージをストアする必要がある。それら全てを、何処にストアするのであろうか? Facebook の Kannan Muthukkaruppan は、The Underlying Technology of MessagesHBase だと答えて、多くの人々を驚かせた。 つまり、HBase は、MySQL や、Cassandra などを打ち負かしたことになる。

image

Why a surprise? Facebook created Cassandra and it was purpose built for an inbox type application, but they found Cassandra’s eventual consistency model wasn’t a good match for their new real-time Messages product. Facebook also has an extensive MySQL infrastructure, but they found performance suffered as data set and indexes grew larger. And they could have built their own, but they chose HBase.

なぜ、それが驚きなのだろうか? Facebook は、InBox タイプのアプリケーションを目的として Cassandra を作り出した。しかし、Cassandra のイベンチュアル・コンシステンシー・モデルが、今回の新しいリアル・タイム Messages に適合しないことに気付いた。 また、Facebook は大規模な MySQL インフラストラクチャを有しているが、これまで以上の大規模なデータセットとインデックスにおいて、パフォーマンスの問題が生じることを見いだした。 さらに Facebook は、独自のものを構築できたはずだが、HBase を選択した。

HBase is a scaleout table store supporting very high rates of row-level updates over massive amounts of data. Exactly what is needed for a Messaging system. HBase is also a column based key-value store built on the BigTable model. It’s good at fetching rows by key or scanning ranges of rows and filtering. Also what is needed for a Messaging system. Complex queries are not supported however. Queries are generally given over to an analytics tool like Hive, which Facebook created to make sense of their multi-petabyte data warehouse, and Hive is based on Hadoop’s file system, HDFS, which is also used by HBase.

HBase は スケールアウト型のテーブル・ストアであり、きわめて頻度の高い Row レベル・アップデートを、大量のデータに対してサポートする 。 まさに、Messaging システムにとって必要とされるものである。 さらに HBase は、BigTable モデル上に構築される、Column ベースの  key-value ストアでもある。 それは、Key によるフェッチや、Row レンジのスキャン、そしてフィルタリングに優れている。これも、Messaging システムにとって必要とされるものである。 しかし、複雑なクエリーがサポートされていない。クエリーは、一般的には Hive のような Analytics ツールへと託される。 Hive とは、数ペタバイト・オーダーのデータ・ウエアハウスを活用するために、Facebook が作成したものである。そして Hive は、Hadoop のファイル・システムである HDFS をベースにするが、それは HBase でも使用されるものである。

Facebook chose HBase because they monitored their usage and figured out what the really needed. What they needed was a system that could handle two types of data patterns:

Facebook が HBase を選択した理由は、自らの用法をモニターし、実際に必要とされるものを理解したところにある。彼らが必要としたものは、2種類のデータ・パターンを取り扱うことができるシステムだ:

  1. A short set of temporal data that tends to be volatile
  2. An ever-growing set of data that rarely gets accessed
  1. 揮発性の高い、一時的なデータのショート・セット
  2. 頻繁にはアクセスされない、永遠に成長していくデータ・セット

Makes sense. You read what’s current in your inbox once and then rarely if ever take a look at it again. These are so different one might expect two different systems to be used, but apparently HBase works well enough for both. How they handle generic search functionality isn’t clear as that’s not a strength of HBase, though it does integrate with various search systems.

尤もである。 あなたは、InBox のカレント・データを一度読む。 そして、もう一度読むにしても、それは稀なことである。 それらは、きわめて異なる要件であり、2種類のシステムを使うべきかもしれないが、HBase は双方において充分に機能するらしい。一般的なサーチ機能については、そこに HBase の強みがないため、方式は明らかにされない。したがって、各種のサーチ・システムを統合することになるだろう。

Some key aspects of their system:

このシステムにおける、主要な局面をリストアップする:

  • HBase:
    • Has a simpler consistency model than Cassandra.
    • Very good scalability and performance for their data patterns.
    • Most feature rich for their requirements: auto load balancing and failover, compression support, multiple shards per server, etc.
    • HDFS, the filesystem used by HBase, supports replication, end-to-end checksums, and automatic rebalancing.
    • Facebook’s operational teams have a lot of experience using HDFS because Facebook is a big user of Hadoop and Hadoop uses HDFS as its distributed file system.
    • Cassandra と比較して、よりシンプルなコンシステンシー・モデルを持つ
    • Facebook のデータ・パターンに対して、最適なスケーラビリティと性能
    • この要件に対するリッチな機能:オート・ロード・バランシングとフェイルオーバーおよび、圧縮のサポート、サーバーごとの multiple shard。
    • HBase で用いられる HDFS(ファイル・システム)による、リプリケーションおよび、End-to-End チェックサム、自動的な rebalancing のサポート
    • Facebook の運用チームが有する、HDFS 利用のエクスペリエンス。 Facebook が Hadoop のビッグ・ユーザーであり、Hadoop の分散型ファイル・システムとしてHDFS を利用
  • Haystack is used to store attachments.
  • A custom application server was written from scratch in order to service the massive inflows of messages from many different sources.
  • A user discovery service was written on top of ZooKeeper.
  • Infrastructure services are accessed for: email account verification, friend relationships, privacy decisions, and delivery decisions (should a message be sent over chat or SMS?).
  • Keeping with their small teams doing amazing things approach, 20 new infrastructures services are being released by 15 engineers in one year.
  • Facebook is not going to standardize on a single database platform, they will use separate platforms for separate tasks. 
  • ストア・アタッチメントのために Haystack を使用
  • カスタム・アプリケーション・サーバを、スクラッチで記述。多様なソースから流入する、大量のメッセージに対応するため
  • ユーザー・ディスカバリー・サービスを、ZooKeeper 上に記述
  • インフラストラクチャ・サービスへのアクセス:電子メール・アカウント検証および、フレンド・リレーション、プライバシー設定、配達設定(例:メッセージをチャットや SMS に送信するか?)
  • 驚くほど、小規模なチームによるアプローチ。20 種類の新しいインフラストラクチャ・サービスを、15人のエンジニアにより 1年間でリリース
  • Facebook は、単一のデータベース・プラットフォームを標準にはしない。それぞれのタスクに適合した、それぞれのプラットフォームを使用

image

I wouldn’t sleep on the idea that Facebook already having a lot of experience with HDFS/Hadoop/Hive as being a big adoption driver for HBase.  It’s the dream of any product to partner with another very popular product in the hope of being pulled in as part of the ecosystem. That’s what HBase has achieved. Given how HBase covers a nice spot in the persistence spectrum–real-time, distributed, linearly scalable, robust, BigData, open-source, key-value, column-oriented–we should see it become even more popular, especially with its anointment by Facebook.

これは、一夜漬けのアイデアではないだろう。 すでに Facebook は、HBase の大規模実装をドライブするための エクスペリエンス を、HDFS / Hadoop / Hive により有している。  それは、エコシステムの一部として取り込みたいポピュラーなプロダクトを、あらゆるプロダクトと組み合わせるという、夢のような話である。 そして、それは HBase により達成されたことである。パーシスタンス領域の、ちょうど良い部分をカバーする方法が、HBase に提供されたことになる。そこでは、リアルタイムや、分配、リニア・スケーラブル、堅牢性、BigData、オープンソース、Key-Value Column が実現される。そして、Facebook の大きな一歩により、さらに HBase がポピュラーになっていく状況が、確認できるはずだ。

Related Articles

ーーーーー

きわめて大量のデータを、きわめて洗練されたアプローチで処理! さすがですね、Facebook は。  以下の Big Link 集も、ぜひ、ご利用ください :) ーーー A.C.

ーーーーー

<関連>
Hadoop DFS _ Introduction
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
Apache ZooKeeper による分散並列キューの構築 _1
Apache ZooKeeper による分散並列キューの構築 _2
Apache ZooKeeper による分散並列キューの構築 _3
Apache ZooKeeper による分散並列キューの構築 _4
Observers と ZooKeeper _1
Observers と ZooKeeper _2
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート _1
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート _2
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート _3
ーーーーー
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
Facebook の Social Inbox は、単なる Email ではない!
Google vs. Facebook のメール対決で盛り上がる全米
これが Facabook の Mail Server、Project Titan なのか?
Facebook は Google キラーを発表するのか?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: