Structure Big Data揭示Hadoop未来：DataStax Brisk，EMC和MapR

关于新版Hadoop的新闻和流言充斥着整个Structure Big Data会议。在以MapReduce为主题的小组讨论上，DataStax宣布了Brisk，这款产品基于Hadoop构建，但是它却使用了Cassandra而不是默认的HDFS作为文件系统来存储数据。同时，EMC制作了一整页的广告来宣传名为“05.09.11.EMC Greenplum. Apache Hadoop”的大会项目。而大会的主持人GigaOm则撰写了一篇文章探索隐式模式的MapR技术，表示“这是构建Hadoop的私有版本，而且很可能今年晚些时候会公诸于众”。大会闭幕后的一天被命名为“年度创新者”日，当日Cloudera工程师Todd Lipcon在EclipseCon的一个主题上介绍了Hadoop。

GigaOm认为MapR是：

构建一个HDFS的私有替代品，这个替代品比当前的开源版本快三倍，自带快照功能，而且支持无NameNode单点故障（SPOF），并且在API上和兼容，所以可以考虑将其作为替代方案。

DataStax（前身是Riptano）提供对Cassandra及其商业产品的支持，例如最近发布的管理工具OpsCenter。在产品介绍大会上，BenWerther认为Brisk是受到了例如Netflix这样的客户的启发。Netflix将所有的流数据都存储在Cassandra里面，而且Netflix也是使用Hive进行数据分析的重要用户之一。他也提到了Netflix希望能够和Hive的ClickStream数据查询结果直接交互，而不会产生ETL延迟。Werther告知InfoQ他们会在45天之内发布Brisk，届时由DataStax将会提供商业支持。他同样也宣传了OpsCenter，表示这个工具将支持多数据中心管理，冗余数据以及基本的Hadoop监控。此外，Werther还介绍了Twitter的Rainbird项目将会开源，这是一个基于Cassandra的实时计数分析项目。

Brisk将是基于Apache Hadoop 20.2，并且包括以下特性：

• CassandraFS数据系统，它高度兼容Hadoop，并且使用Cassandra存储数据。
• 兼容Hadoop任务的输入和输出格式，并且能够操作Cassandra列族。
• Hive支持从Cassandra中读取和存储数据，并且允许将数据从宽行转为多个窄行。
• 升级JobTracker；（JT）以支持自动重启故障节点。但是Werther表示，Brisk并不在内存中永久保存JobTracker的状态，所以当Brisk启动一个新JT的时候，正在运行的任务可能无法完成。
• 预置的配置项：Werther向InfoQ介绍，DataStax将会使用一些预定义的标志来简化流程，于是Cassandra可以以实时或者Hadoop的形式启动。

Cassandra本质上是结合了Dynamo架构的BigTable。最开始是Facebook创建并且将Cassandra开源，但是大多数贡献者却是来自于DataStax，其中就包括项目主席和公司的创始人之一JonathanEllis。而现在DataStax不再雇佣Hadoop贡献者。Cassandra支持多数据中心的数据冗余，范围扫描，数据存储的分离列族，而且最近还添加了二级索引支持，以及在多个冗余组中冗余数据，这样可以允许在不干扰产品运行的情况下对数据进行分析。

InfoQ询问了Werther关于Cassandra的成熟度以及它与HBase的对比情况。尤其当我们看到作为Cassandra的创建者，Facebook却使用了HBase来进行大规模消息服务和实时分析，这愈发让我们感到困惑和好奇。就此问题，他首先表示Hadoop有非常庞大的社区，而HBase的却非常微型，连Cassandra的社区都比HBase要庞大，而且有更多的动力。DataStax使用修复的bug数目，积压的未修复bug，社区讨论以及下载数作为比较一款开源软件使用量的标准。当提及InfoQ关于过去Cassandra部署的一些问题的时候（例如Digg曾经面对的），Werther说&ldquo快速成熟&rdquo技术有时候太早或者错误地使用，但是他们仍然有大量成功的客户案例，例如Cisco，Rackspace，ConstantContact，RealNetwork和Netflix。Werther也提到了由于Facebook向HBase做出一些投资，所以它更倾向于使用HBase，而且对存储一致性的争论是完全没必要的，因为Cassandra对最终一致性的支持情况是可配置的，用户可以在强一致性的情况下运行。

Werther曾经说过Brisk仍然是在内部测试中，没有任何的测试用户，因此InfoQ询问了Cassandra的大规模使用问题。Werther说最大规模的部署是一个政府部门的大概700个节点的集群。在事务处理能力上，他说Twitter每秒要运行200000写请求来接收数据。而在数据存储上，他说有一些集群存储了约莫数百个TB的数据。

InfoQ采访了Werther和首席工程师Jake Luciani，询问了Brisk的架构和作为文件系统的CassandraFS的实现。我们在此对HDFS及其可能的改进版本，还有CassandraFS的一些关键的区别列在下表中：

当前版本	HDFS可能改进	CassandraFS
NameNode（NN）是单点故障（SPOF）	一些改善和消除NNSPOF的方法正在开发中。	CassandraFS将数据存储在Cassandra中，没有SPOF。
文件元数据保存在RAM中的单个进程中，限制了文件总数	结合HDFS和BookKeeper是一个调节数据存储能力的方法，不过正在开发中。	CassandraFS提供了可视化的无限文件调整。
不支持WAN数据冗余	不支持WAN数据冗余	Cassandra支持多数据中心数据冗余
支持数据追加（在Cloudera Distribution for Hadoop 3和Apache Hadoop 0.21）	不可用	设计之初就支持追加功能，不过第一个版本并不支持，因为HDFS追加功能本来是用于支持HBase的，这个功能的开发很有难度

从技术上来说，CassandraFS创建了一个将其路径作为key的表，并且将inodes以及一些元数据，例如文件拥有者，权限和块数据作为值。而且还有另外一张表，使用块的id作为key，而序列化的块作为值。

Werther提到Brisk也可以和其他的Hadoop周边代码共存。并且回应了InfoQ的关于客户如何加载非Cassandra的日志数据，他说客户可以使用Cloudera Flume，这个工具已经验证可以和Brisk一起使用。同时，Wether也提到了Cloudera Hue，表示这个基于浏览器的用户界面同样也可以和Brisk共存。