KuDu论文解读

      kudu是cloudera在2012开始秘密研发的一款介于hdfs和hbase之间的高速分布式存储数据库。兼具了hbase的实时性、hdfs的高吞吐，以及传统数据库的sql支持。作为一款实时、离线之间的存储系统。定位和spark在计算系统中的地位非常相似。如果把mr+hdfs作为离线计算标配，storm+hbase作为实时计算标配。spark+kudu有可能成为未来最有竞争力的一种架构。

      也就是kafka->spark->kudu这种架构，未来此架构是否会风靡，暂且不表。来分析下kudu的一些特性：

传统的实时/离线计算架构几乎都是分离的，用户需要把实时的数据从一个实时队列系统导入到在线存储，再导出到离线存储系统。有时候离线和实时的数据又存再join或并用的可能性。在计算领域spark已经几乎做到的离线+准实时(秒)的架构一体化覆盖。但是毕竟spark只是计算系统，还缺乏一套存储系统与之相配合。hbase查询不友好，alluxis数据结构和程度差。kudu目前看来是最优的候选系统，再加上有cloudera背书，应该不错。

      传统系统几大痛点：

      1、应用系统需要在实时、离线系统之间把数据倒来倒去，写很复杂的code

      2、系统庞杂，各种备份，安全策略，监控系统

      3、系统从实时系统中流出到离线系统才好做OLAP分析，这层转换存在延迟

      4、现实上来说，系统总是会存在落后的数据、对过去数据的修改，删除。然而当过去的数据已经被归档，这些操作需要昂贵的重写以及partiion交换或者各种人工干预

Kudu弥补了高速顺序吞吐系统和低延迟随机访问系统之间的gap。它同时提供行级别的插入，更新，删除。也提供类似Parquet的批量scan，列读取等。

2.1 表结构和schema

      和nosql不同，kudu中的字段带type，例如Int32或者String。几个列组合起来形成主键(和hbase类比rowkey需要自己来维护)，就是mysql中唯一索引概念同时又是主键。作为update或者deleted的index(但并不是说只能通过这个组合键更新或删除)

      看起来和关系数据库比较像吧，但kudu又可以随时更新表字段添加或删除(主键列们除外)

      nosql中提倡“所有数据都是bytes”，kudu不这样做：

      1、明确的类型让我们可以更好的做packing，例如integer

      2、更好的和sql类型的工具系统、bi系统、数据导出系统集成

      不过kudu不提供除了主键之外的二级索引或者唯一键索引，当前kudu需要用户指定固定的主键列，未来可能会生成代替的key

2.2 写操作

      insert、update、delete的aip必须指定主键，当然谓词操作在高级操作API中是支持的。kudu提供java和c++的api，python在实验中

2.3读操作

      只提供Scan接口，条件提供<,>,=几种过滤符

一致性模型：

      这块主要是如何协调多个client端读写时的先后顺序以及加锁操作等。kudu学习了spanner的commit-wait的模式。start，之后