大数据仓库－kudu
数据仓库里面存储引擎是非常重要的，存储引擎的好坏，基本决定了整个数仓的基础。
kudu目标
cloudera公司最近发布了一个kudu存储引擎。按照cloudera的想法，kudu的出现是为了解决，hbase,parquet不能兼顾分析和更新的需求，所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用。cloudera 的设计目标是：（http://blog.cloudera.com/blog/2015/09/kudu-new-apache-hadoop-storage-for-fast-analytics-on-fast-data/）
•Strong performance for both scan and random access to help customers simplify complex hybrid architectures
在扫描和随机访问两种场景下都有很强的性能，帮助客户简化混合架构。
•High CPU efficiency in order to maximize the return on investment that our customers are making in modern processors
高cpu利用率
•High IO efficiency in order to leverage modern persistent storage
高io效率充分利用现代存储
•The ability to update data in place, to avoid extraneous processing and data movement
支持数据原地更新
•The ability to support active-active replicated clusters that span multiple data centers in geographically distant locations
支持双活复制集群
kudu核心机制
Cloudera有一篇论文描述kudu的机制，Kudu: Storage for Fast Analytics on Fast Data 。可以从http://getkudu.io/kudu.pdf下载。这里简单说下kudu的关键机制。
- 模仿数据库，以二维表的形式组织数据，创建表的时候需要指定schema。所以只支持结构化数据。
- 每个表指定一个或多个主键。
- 支持insert/update/delete，这些修改操作全部要指定主键。
- read操作，只支持scan原语。
- 一致性模型，默认支持snapshot ，这个可以保证scan和单个客户端 read-you-writes一致性保证。更强的一致性保证，提供manually propagate timestamps between clients或者commit-wait。
- cluster类似hbase简单的M-S结构，master支持备份。
- 单个表支持水平分割，partitions叫tablets，单行一定在一个tablets里面，支持范围，以及list等更灵活的分区键。
- 使用Raft 协议，可以根据SLA指定备份块数量。
- 列式存储
- delta flushes，数据先更新到内存中，最后在合并到最终存储中，有专门到后台进程负责。
- Lazy Materialization ，对一些选择性谓词，可以帮助跳过很多不必要的数据。
- 支持和MR/SPARK/IMPALA等集成，支持Locality ，Columnar Projection ，Predicate pushdown 等。
总结
为应对BI领域少量更新和大量扫描分析场景，kudu 借鉴了很多传统数仓等技术。对这个领域目前是impala+kudu/Hive/Spark SQL/Greenplum MPP数据库在混战，未来这个会走向融合，传统的mpp数据库个人认为会是一个过渡产品。