如何评价kudu存储引擎？
据说Cloudera秘密开发了3年，兼顾数据更新实时性和分析速度的存储引擎，目前和impala配合的比较不错。国内目前小米在用这个东西。
http://getkudu.io
只说下我了解的部分，如有错误欢迎指出……
Kudu最初由Cloudera开发，但现在已经开始作为Apache的项目孵化。Kudu - ASF JIRA
定位是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。而且因为是数据库，可以随机写，相当于可以修改队列，灵活很多。
读过 paper 和代码，在生产环境中使用过，来答一波。
先说性能。对比 Hive，性能高了一个数量级，原本需要数分钟的查询，用 Kudu 可能只需要数秒；做过 TPC-DS benchmark，结果还不错，不过有一部分 query 计算时间太长，没有完成；对于随机写入来说，性能相当赞，SDD 硬盘，写入 ops 能到 100W 左右，几乎不需要特别的 bulk load 支持了。
再说 feature。支持数据更新，这是 Hive 的一大痛点，使用 Hive 通常来说会用 Sqoop 定期导入数据，一来，定期导入数据意味着会有延迟，数小时到数天，对于实时查询来说这点就很难接受，二来，定期导入对线上数据库也会有一定压力。而 Kudu 直接支持数据更新，意味着可以实时同步线上数据，可以实时查询到线上数据，对于数据驱动的增长来说，这无疑是很好的消息。
Kudu 作为一个存储引擎，提供的 API 其实跟 HBase 很像，增删改以及 scan 的接口。在上层，可以用 Impala 查询，Kudu 能提供 locality 信息以及谓词下推；也可以使用其他的 SQL on Hadoop 进行查询，SparkSQL 之类的，能很好地融入 Hadoop 生态。
所以 Kudu 的特点正如它的 slogan 所说，Fast Analytics on Fast Data。如果你需要对实时数据做查询，如果需要快速地查询，那么 Kudu 无疑是一个好的选择。
至于实现，未完待续。
我司 tangliu 同学的一篇文章可以看看 Kudu：一个融合低延迟写入和高性能分析的存储系统
可以参考我们团队技术博客有关Kudu以及Impala的文章：
Kudu 在一个系统中融合了 OLTP 型随机读写能力与 OLAP 型分析能力，填补了 Hadoop 存储层的缺憾，是 Hadoop 生态的一大生力军。Kudu 目前在网易、小米等公司的大数据技术体系中是不可或缺的。
Kudu的设计目标
Kudu设计之初，是为了解决以下问题：
- 对数据扫描(scan)和随机访问(random access)同时具有高性能，简化用户复杂的混合架构
- 高 CPU 效率，使用户购买的先进处理器的的花费得到 最大回报
- 高 IO 性能，充分利用先进存储介质
- 支持数据的原地更新，避免额外的数据处理、数据移动
- 支持跨数据中心 replica on
Kudu 的很多特性跟 HBase 很像，它支持索引键的查询和修改。Cloudera 曾经想过基于 HBase 进行修改，然而结论是对 HBase 的改动非常大，Kudu 的数据模型和磁盘存储都与 HBase 不同。HBase 本身成功的适用于大量的其它场景，因此修改 HBase 很可能吃力不讨好。 后 Cloudera 决定开发一个全新的存储系统。
Kudu 的定位是提供”fast analy cs on fast data”，也就是在快速更新的数据上进行快速的查询。它定位 OLAP 和少量的 OLTP 工作流，如果有大量的 randomaccesses，官方建议还是使用 HBase 更为合适。
Kudu 和 HBase 二者的区别，可以参考：分布式存储系统Kudu与HBase的简要分析与对比
Kudu 在网易的应用
Kudu 在网易主要有两个应用场景：
- 数据库数据上的快速分析
- 用户行为日志的快速分析
正如问题描述，我们通过 Kudu 和 Impala 的配合，实现透明分层储存管理，以实现快速数据的快速分析能力，让实时数据仓库的建设获得了革命性的变化，数据展现的时差从此成为了历史……
详情参考：实时性和完整性兼得，使用 Kudu 和 Impala 实现透明的分层存储管理
首先是一个分布式的列式存储，大家都说到了主要是用于分析计算的存储系统。但是也是可以用于存的存储系统。kudu是一个现代的列式存储系统，需要最新的硬件支持，充分发挥现在高性能硬件和cpu指令集。在存储方面做了很多性能优化，数据一致性和容灾主要还是靠raft。
和HBase很像，感觉很像是hbase+tikv+histore的结合体，分区参考了hbase，一致性参考了raft，物理存储为列式存储~ 分析性场景（count，sum(column)）有优势。
内部实现上，rowset机制，为了保证 tablet中rowset数据是disjoint的，用了很复杂的 机制，潜在问题是在复杂业务场景下，比如很多删除，更新场景下，文件数目会膨胀的很厉害。
分区虽然支持range和hash两种和两种的组合，但是不够自动化，range的扩展需要人工干预。
一致性模型不够清晰。
周边工具不够完善。
如果有数据量比较大的纯实时insert的olap场景，还是比较合适的。
c++实现，是优点也是缺点吧。
目前只对impala支持的比较好，如果引入它还要买一赠一。
kudu和计算框架结合之后，在大数据集上的操作，可以提供接近关系型数据库的使用体验
Kudu产品的几个要点：
- 数据模型和关系数据库类似，为结构化的表；列的数量有限（和HBase/Cassandra相比较而言）
- 内部数据组织方式为列式存储
- 很好的横向扩展能力，目前测试的是275个节点（3PB），计划支持到上千个节点(几十PB)
- 不错的性能，集群能达到百万级别的TPS，单节点吞吐为几个GB/s
- 本身不提供SQL接口，只支持类似NoSQL的接口，如 Insert(), Update(), Delete() and Scan() 等
- 通过与 Spark 和 Impala 等（Drill，Hive的支持还在进行中）的集成，对外提供基于 SQL 的查询分析服务
关于小米如何使用Kudu，这里有更详细的介绍：Apache Kudu 加速对频繁更新数据的分析 - 知乎专栏
1：支持增、删、改
2：一套存储，即支持较快速查询(对标HBase)，也支持较快速分析(对标impala)。而不必像之前，想查询，用HBase得一套存储，相分析，用impala得一套存储
一个项目负责人来公司做过seminar，是HBase那帮人搞的。
出发点是把数据分析放进存储里，这样达到一个在某些query的优化。本来如果做数据分析，要从HBase导出到hadoop平台再用Hive查询，太慢了，而且是offline的。搞Kudu就是要弄成结构化数据，支持online直接修改数据，支持加index，Kudu目前支持Dremel语句，用C++写的。
Performance是和Hive和另一个什么比较的，用的是一些大型的benchmark，结果表明在某些方面比较有优势，具体忘了。
对，他在slides最后还提到小米了，好像是和小米合作开发的。Kudu几个月前开源了，看文档和源代码应该更准确吧。
