kudu存储引擎

Kudu最初由Cloudera开发，但现在已经开始作为Apache的项目孵化。

定位是OLAP数据库，说白了就是可以随机读但主要是针对顺序读做优化。所以在小米也是计算组搞而非存储组。数据的模型个人觉得很像Cassandra的伪SQL——结构化的数据、SQL类似的语法但本质上还是NoSQL，可以设定是Hash还是range或者两者结合来做partition分配到若干个tablet，每个tablet用raft协议写在多个节点上。之前扫了眼论文似乎是没写如何做tablet的split/merge，也许现在还不支持也许我看漏了。


从数据库的角度讲，比较重要的两个点是C++和raft。
C++的性能比较有保障，还没有gc的停顿导致的.99响应时间不可控等问题，raft的心跳也因为没有gc可以设的敏感一些，可用性更好，而这些都是HBase的痛点。当然这是题外话，毕竟Kudu不是用来代替HBase的。
用raft协议搞replication意味着不需要比较蛋疼的HDFS了，表面上似乎还在说Kudu属于“Hadoop生态系统”，但我觉得他们的心思肯定不止于此。而且Raft的一致性也比较自由，追求性能可以最终一致性地读。


此外可以看下Apache Kudu as a More Flexible And Reliable Kafka-style Queue ，这篇文章说，因为他顺序读吞吐比较好，并且raft协议自身提供了递增id，所以可以用来代替kafka搞消息队列，简单测试性能差不多（ “in the same realm”），还没GC。而且因为是数据库，可以随机写，相当于可以修改队列，灵活很多。

 

没有数据分析流式计算的经验，根据对kv存储系统的理解，简单答一发，轻拍。。 数据存储的选择上，HBASE和HADOOP在吞吐率、延迟上各有侧重，如果做数据分析，要从HBase导出到hadoop平台再用Hive查询，这就要求系统要混布HBASE和hadoop。 KADU的目标就是要兼… 显示全部

没有数据分析流式计算的经验，根据对kv存储系统的理解，简单答一发，轻拍。。

数据存储的选择上，HBASE和HADOOP在吞吐率、延迟上各有侧重，如果做数据分析，要从HBase导出到hadoop平台再用Hive查询，这就要求系统要混布HBASE和hadoop。
KADU的目标就是要兼顾前两个存储系统，实现对外数据的存储和后台计算的本地化，减少数据传输成本已经部署运维成本。

架构方面，还是延用BIGTABLE的基本架构，元数据和数据分开存储的，但做了一些比较有挑战的优化操作，提升查询和插入的性能
另外的亮点是，多副本间使用了raft保证数据的高可靠性。

性能方面，目前beta版本要略差与HBASE,这也是意料之中的事情。。。