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的一致性也比较自由，追求性能可以最终一致性地读。此外可以看下 ，这篇文章说，因为他顺序读吞吐比较好，并且raft协议自身提供了递增id，所以可以用来代替kafka搞消息队列，简单测试性能差不多（ “in the same realm”），还没GC。而且因为是数据库，可以随机写，相当于可以修改队列，灵活很多。