Facebook大规模实时数据处理系统的演变（一） - 2010年

Facebook的实时消息系统：HBase每月存储135百万条以上的消息。 

如果你的系统满足两个条件：大规模数据量（TB以上），需要实时分析处理。这篇文章对你或许有用。

 

Facebook的社交信箱集成了邮件，即时消息，短信息，文本消息，站内消息，为此facebook需要每个月存储1亿3千5百万条以上的消息（这是在2010年前，现在数据量更大了）。他们将数据存到哪里了？Facebook的Kannan Muthukkaruppan给出了惊人的答案：消息系统的底层技术采用了HBase。HBase击败了MySQL，Cassandra以及其它的方案。

让人惊奇的是，Facebook建立了Cassandra项目，但是他们发现Cassandra的一致性模型无法适应他们的新的实时消息产品（HBase和Cassandra的比较：http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

，http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/

），原以为他们要采用自己的Cassandra。Facebook拥有大量的MySQL集群，随着数据量和索引越来越多时，MySQL的性能就出现问题了，现在他们选择了HBase。

HBase的介绍我就不多说了，看看这些关键词：大规模数量，高可靠性，快速读写访问，分布式，线性扩展，高可靠性，开源，键值对，面向列的结构。Facebook之所以选择HBase是因为他们通过观测他们的系统，而真正领会到他们的系统的需求，要同时能够处理两种类型的数据模式：

• 临时存储的一小部分实时数据
• 很少访问的大量数据

这很容易理解，例如你阅读信箱里的当前消息以后，就会很少再看那些消息了。看起来这两种数据互相冲突，但是HBase能够很好的适应这两种情况。但是Facebook没有说清楚如何处理搜索，这方面不是HBase的强项（虽然它能够和其它的索引系统集成）。

Facebook实时消息系统的一些特点：

• HBase
• 相比Cassandra更简化的一致性模型
• 为它们的数据模式提供很好的扩展性和性能
• 很多他们想要的特性：自动负载均衡和故障保护，数据压缩，按服务器的分片
• HDFS，分布式文件系统，支持复制，端到端的数据验证，自动负载均衡
• Facebook团队在使用HDFS方面有丰富经验
• Haystack用于存储附件（参看：http://server.it168.com/a2009/0504/274/000000274726_2.shtml）
• 自己写的一个应用服务器，用于处理来自不同地方的大量消息流。
• 基于ZooKeeper写的用户发现服务。

 HBase在处理大规模实时消息的能力，通过Facebook再次验证了。我们不迷信大公司，但是参照大公司的实践经验可以作为自己的一个很好起点，被证明过的经验，用的再怎么差，也不会偏离大的方向。下篇文章，我们要讨论“Facebook新的实时分析系统 -  每天处理200亿条数据 - 2011年”。

 

注：这篇文章大部分内容翻译自：http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html。其中加入了自己的一些理解，如果对原文感兴趣，请参看链接。