概述
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可以保證單行操作的原子性。