概述
Kudu和Impala均是Cloudera贡献给Apache基金会的顶级项目。Kudu作为底层存储，在支持高并发低延迟kv查询的同时，还保持良好的Scan性能，该特性使得其理论上能够同时兼顾OLTP类和OLAP类查询。Impala作为老牌的SQL解析引擎，其面对即席查询(Ad-Hoc Query)类请求的稳定性和速度在工业界得到过广泛的验证，Impala并没有自己的存储引擎，其负责解析SQL，并连接其底层的存储引擎。在发布之初Impala主要支持HDFS，Kudu发布之后，Impala和Kudu更是做了深度集成。
Kudu介绍
Kudu是什么
Kudu是围绕Hadoop生态圈建立存储引擎，Kudu拥有和Hadoop生态圈共同的设计理念，它运行在普通的服务器上、可分布式规模化部署、并且满足工业界的高可用要求。其设计理念为fast analytics on fast data.。Kudu的大部分场景和Hbase类似，其设计降低了随机读写性能，提高了扫描性能，在大部分场景下，Kudu在拥有接近Hbase的随机读写性能的同时，还有远超Hbase的扫描性能。
区别于Hbase等存储引擎，Kudu有如下优势：
- 快速的OLAP类查询处理速度
- 与MapReduce、Spark等Hadoop生态圈常见系统高度兼容，其连接驱动由官方支持维护
- 与Impala深度集成，相比HDFS+Parquet+Impala的传统架构，Kudu+Impala在绝大多数场景下拥有更好的性能。
- 强大而灵活的一致性模型，允许用户对每个请求单独定义一致性模型，甚至包括强序列一致性。
- 能够同时支持OLTP和OLAP请求，并且拥有良好的性能。
- Kudu集成在ClouderaManager之中，对运维友好。
- 高可用。采用Raft Consensus算法来作为master失败后选举模型，即使选举失败，数据仍然是可读的。
- 支持结构化的数据，纯粹的列式存储，省空间的同时，提供更高效的查询速度。
Kudu架构概览
从下图可以看出有三台Master，其中一个是leader，另外两个是follower。
有四台Tablet server，n个tablets及其副本均匀分布在这四台机器上。每个tablet有一个leader，两个follower。每个表会按照分片的数量分成多个tablet。
Impala介绍
Impala是什么
Impala是建立在Hadoop生态圈的交互式SQL解析引擎，Impala的SQL语法与Hive高度兼容，并且提供标准的ODBC和JDBC接口。Impala本身不提供数据的存储服务，其底层数据可来自HDFS、Kudu、Hbase甚至亚马逊S3。
Impapa最早由Cloudera公司开发，于15年12月贡献给Apache基金会，目前其正式名字为Apache Impala(incubating)
Impala本身并不是Hive的完全替代品，对于一些大吞吐量长时间执行的请求，Hive仍然是最稳定最佳的选择，哪怕是SparkSQL，其稳定性也无法跟Hive媲美。
稳定性方面Impala不如Hive，但是在执行效率方面，Impala毫无疑问可以秒杀Hive。Impala采用内存计算模型，对于分布式Shuffle，可以尽可能的利用现代计算机的内存和CPU资源。同时，Impala也有预处理和分析技术，表数据插入之后可以用COMPUTE STATS指令来让Impala对行列数据深度分析。
Kudu以及Impala的不足
Kudu主键的限制
- 表创建后主键不可更改；
- 一行对应的主键内容不可以被Update操作修改。要修改一行的主键值，需要删除并新增一行新数据，并且该操作无法保持原子性；
- 主键的类型不支持DOUBLE、FLOAT、BOOL，并且主键必须是非空的(NOT NULL)；
- 自动生成的主键是不支持的；
- 每行对应的主键存储单元(CELL)最大为16KB。
Kudu列的限制
- MySQL中的部分数据类型，如DECIMAL, CHAR, VARCHAR, DATE, ARRAY等不支持；
- 数据类型以及是否可为空等列属性不支持修改；
- 一张表最多有300列。
Kudu表的限制
- 表的备份数必须为奇数，最大为7；
- 备份数在设置后不可修改。
Kudu单元（Cells）的限制
- 单元对应的数据最大为64KB，并且是在压缩前。
Kudu分片的限制
- 分片只支持手动指定，自动分片不支持；
- 分片设定不支持修改，修改分片设定需要”建新表-导数据-删老表”操作；
- 丢掉多数备份的Tablets需要手动修复。
Kudu容量限制
- 建议tablet servers的最大数量为100；
- 建议masters的最大数量为3；
- 建议每个tablet server存储的数据最大为4T（此处存疑，为何会有4T这么小的限制？）；
- 每个tablet server存储的tablets数量建议在1000以内；
- 每个表分片后的tablets存储在单个tablet server的最大数量为60。
Kudu其他使用限制
- Kudu被设计为分析的用途，每行对应的数据太大可能会碰到一些问题；
- 主键有索引，不支持二级索引(Secondary indexes)；
- 多行的事务操作不支持；
- 关系型数据的一些功能，如外键，不支持；
- 列和表的名字强制为UTF-8编码，并且最大256字节；
- 删除一列并不会马上释放空间，需要执行Compaction操作，但是Compaction操作不支持手动执行；
- 删除表的操作会立刻释放空间。
Impala的稳定性
- Impala不适合超长时间的SQL请求；
- Impala不支持高并发读写操作，即使Kudu是支持的；
- Impala和Hive有部分语法不兼容。
FAQ
Impala支持高并发读写吗？
不支持。虽然Impala设计为BI-即席查询平台，但是其单个SQL执行代价较高，不支持低延时、高并发场景。
Impala能代替Hive吗？
不能，Impala设计为内存计算模型，其执行效率高，但是稳定性不如Hive，对于长时间执行的SQL请求，Hive仍然是第一选择。
Impala需要多少内存？
类似于Spark，Impala会把数据尽可能的放入内存之中进行计算，虽然内存不够时，Impala会借助磁盘进行计算，但是毫无疑问，内存的大小决定了Impala的执行效率和稳定性。Impala官方建议内存要至少128G以上，并且把80%内存分配给Impala
Impala有Cache吗？
Impala不会对表数据Cache，Impala仅仅会Cache一些表结构等元数据。虽然在实际情况下，同样的query第二次跑可能会更快，但这不是Impala的Cache，这是Linux系统或者底层存储的Cache。
Impala可以添加自定义函数吗？
可以。Impala1.2版本支持的UDFs，不过Impala的UDF添加要比Hive复杂一些。
Impala为什么会这么快？
Impala为速度而生，其在执行效率细节上做了很多优化。在大的方面，相比Hive，Impala并没有采用MapReduce作为计算模型，MapReduce是个伟大的发明，解决了很多分布式计算问题，但是很遗憾，MapReduce并不是为SQL而设计的。SQL在转换成MapReduce计算原语时，往往需要多层迭代，数据需要较多的落地次数，造成了极大地浪费。
- Impala会尽可能的把数据缓存在内存中，这样数据不落地即可完成SQL查询，相比MapReduce每一轮迭代都落地的设计，效率得到极大提升。
- Impala的常驻进程避免了MapReduce启动开销，MapReduce任务的启动开销对于即席查询是个灾难。
- Impala专为SQL而设计，可以避免每次都把任务分解成Mapper和Reducer，减少了迭代的次数，避免了不必要的Shuffle和Sort。
同时Impala现代化的计算框架，能够更好的利用现代的高性能服务器。
- Impala利用LLVM生成动态执行的代码
- Impala会尽可能的利用硬件配置，包括SSE4.1指令集去预取数据等等。
- Impala会自己控制协调磁盘IO，会精细的控制每个磁盘的吞吐，使得总体吞吐最大化。
- 在代码效率层面上，Impala采用C++语言完成，并且追求语言细节，包括内联函数、内循环展开等提速技术
- 在程序内存使用上，Impala利用C++的天然优势，内存占用比JVM系语言小太多，在代码细节层面上也遵循着极少内存使用原则，这使得可以空余出更多的内存给数据缓存。
Kudu相比Hbase有何优势，为什么？
Kudu在某些特性上和Hbase很相似，难免会放在一起比较。然而Kudu和Hbase有如下两点本质不同。
- Kudu的数据模型更像是传统的关系型数据库，Hbase是完全的no-sql设计，一切皆是字节。
- Kudu的磁盘存储模型是真正的列式存储，Kudu的存储结构设计和Hbase区别很大。
综合而言，纯粹的OLTP请求比较适合Hbase，OLTP与OLAP结合的请求适合Kudu。
Kudu是纯内存数据库吗？
Kudu不是纯内存数据库，Kudu的数据块分MemRowSet和DiskRowSet，大部分数据存储在磁盘上。
Kudu拥有自己的存储格式还是沿用Parquet的？
Kudu的内存存储采用的是行存储，磁盘存储是列存储，其格式和Parquet很相似，部分不相同的部分是为了支持随机读写请求。
compactions需要手动操作吗？
compactions被设计为Kudu自动后台执行，并且是缓慢分块执行，当前不支持手动操作。
Kudu支持过期自动删除吗？
不支持。Hbase支持该特性。
Kudu有和Hbase一样的局部热点问题吗？
现代的分布式存储设计往往会把数据按主键进行有序存储。这样会造成一些局部的热点访问，比如把时间作为主键的日志实时存储模型中，日志的写入总是在时间排序的最后，这在Hbase中会造成严重的局部热点。Kudu也有同样的问题，但是比Hbase好很多，Kudu支持hash分片，数据的写入会先按照hash找到对应的tablet，再按主键有序的写入。
Kudu在CAP理论中的位置？
和Hbase一样，Kudu是CAP中的CP。只要一个客户端写入数据成功，其他客户端读到的数据都是一致的，如果发生宕机，数据的写入会有一定的延时。
Kudu支持多个索引吗？
不支持，Kudu只支持Primary Key一个索引，但是可以把Primary Key设置为包含多列。自动增加的索引、多索引支持、外键等传统数据库支持的特性Kudu正在设计和开发中。
Kudu对事务的支持如何？
Kudu不支持多行的事务操作，不支持回滚事务，不过Kudu可以保证单行操作的原子性。