[Kudu基礎]--Kudu+Impala介紹

阿新 • • 發佈：2019-01-11

Kudu+Impala介紹

概述

Kudu和Impala均是Cloudera貢獻給Apache基金會的頂級專案。Kudu作為底層儲存，在支援高併發低延遲kv查詢的同時，還保持良好的Scan效能，該特性使得其理論上能夠同時兼顧OLTP類和OLAP類查詢。Impala作為老牌的SQL解析引擎，其面對即席查詢(Ad-Hoc Query)類請求的穩定性和速度在工業界得到過廣泛的驗證，Impala並沒有自己的儲存引擎，其負責解析SQL，並連線其底層的儲存引擎。在釋出之初Impala主要支援HDFS，Kudu釋出之後，Impala和Kudu更是做了深度整合。

在眾多大資料框架中，Impala定位類似Hive，不過Impala更關注即席查詢SQL的快速解析，對於執行時間過長的SQL，仍舊是Hive更合適。對於GroupBy等SQL查詢，Impala進行的是記憶體計算，因而Impala對機器配置要求較高，官方建議記憶體128G以上，此類問題Hive底層對應的是傳統的MapReduce計算框架，雖然執行效率低，但是穩定性好，對機器配置要求也低。

執行效率是Impala的最大優勢，對於儲存在HDFS中的資料，Impala的解析速度本來就遠快於Hive，有了Kudu加成之後，更是如虎添翼，部分查詢執行速度差別可達百倍。

值得注意的是，Kudu和Impala的英文原意是來自非洲的兩個不同品種的羚羊，Cloudera這個公司非常喜歡用跑的快的動物來作為其產品的命名。

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的典型使用場景

流式實時計算場景

流式計算場景通常有持續不斷地大量寫入，與此同時這些資料還要支援近乎實時的讀、寫以及更新操作。Kudu的設計能夠很好的處理此場景。

時間序列儲存引擎(TSDB)

Kudu的hash分片設計能夠很好地避免TSDB類請求的區域性熱點問題。同時高效的Scan效能讓Kudu能夠比Hbase更好的支援查詢操作。

機器學習&資料探勘

機器學習和資料探勘的中間結果往往需要高吞吐量的批量寫入和讀取，同時會有少量的隨機讀寫操作。Kudu的設計可以很好地滿足這些中間結果的儲存需求。

與歷史遺產資料共存

在工業界實際生產環境中，往往有大量的歷史遺產資料。Impala可以同時支援HDFS、Kudu等多個底層儲存引擎，這個特性使得在使用的Kudu的同時，不必把所有的資料都遷移到Kudu。

Kudu中的重要概念

列式儲存

毫無疑問，Kudu是一個純粹的列式儲存引擎，相比Hbase只是按列存放資料，Kudu的列式儲存更接近於Parquet，在支援更高效Scan操作的同時，還佔用更小的儲存空間。列式儲存有如此優勢，主要因為兩點：1. 通常意義下的OLAP查詢只訪問部分列資料，列儲存引擎在這種情況下支援按需訪問，而行儲存引擎則必須檢索一行中的所有資料。2. 資料按列放一起一般意義來講會擁有更高的壓縮比，這是因為列相同的資料往往擁有更高的相似性。

Table

Kudu中所有的資料均儲存在Table之中，每張表有其對應的表結構和主鍵，資料按主鍵有序儲存。因為Kudu設計為支援超大規模資料量，Table之中的資料會被分割成為片段，稱之為Tablet。

Tablet

一個Tablet把相鄰的資料放在一起，跟其他分散式儲存服務類似，一個Tablet會有多個副本放置在不同的伺服器上面，在同一時刻，僅有一個Tablet作為leader存在，每個副本均可單獨提供讀操作，寫操作則需要一致性同步寫入。

Tablet Server

Tablet服務顧名思義，對Tablet的讀寫操作會通過該服務完成。對於一個給定的tablet，有一個作為leader，其他的作為follower，leader選舉和災備原則遵循Raft一致性演算法，該演算法在後文中有介紹。需要注意的是一個Tablet服務所能承載的Tablet數量有限，這也要求的Kudu表結構的設計需要合理的設定Partition數量，太少會導致效能降低，太多會造成過多的Tablet,給Tablet服務造成壓力。

Master

master儲存了其他服務的所有元資訊，在同一時刻，最多有一個master作為leader提供服務，leader宕機之後會按照Raft一致性演算法進行重新選舉。

master會協調client傳來的元資訊讀寫操作。比如當建立一個新表的時候，client傳送請求給master，master會轉發請求給catelog、 tablet等服務。

master本身並不儲存資料，資料儲存在一個tablet之中，並且會按照正常的tablet進行副本備份。

Tablet服務會每秒鐘跟master進行心跳連線。

Raft Consensus Algorithm

Kudu 使用Raft一致性演算法，該演算法將節點分為follower、candidate、leader三種角色，當leader節點宕機時，follower會成為candidate並且通過多數選舉原則成為一個新的leader，因為有多數選舉原則，所以在任意時刻，最多有一個leader角色。leader接收client上傳的資料修改指令並且分發給follower，當多數follower寫入時，leader會認為寫入成功並告知client。

Catalog Table

Catelog表儲存了Kudu的一些元資料，包括Tables和Tablets。

Kudu架構概覽

從下圖可以看出有三臺Master，其中一個是leader，另外兩個是follower。

有四臺Tablet server，n個tablets及其副本均勻分佈在這四臺機器上。每個tablet有一個leader，兩個follower。每個表會按照分片的數量分成多個tablet。
Kudu架構圖

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對行列資料深度分析。

Impala的優勢

和Hive高度相似的SQL語法，無需太多學習成本
超大資料規模SQL解析的能力，高效利用記憶體與CPU利用，快速返回SQL查詢結果。
整合多個底層資料來源，HDFS、Kudu、Hbase等資料皆可通過Impala共享，並且無需進行資料同步。
與Hue深度整合，提供視覺化的SQL操作以及work flow。
提供標準JDBC和ODBC介面，方便下游業務方無縫接入。
提供最多細化到列的許可權管理，滿足實際生產環境資料安全要求。

Impala和Hive的SQL相容性？

Impala高度相容Hive，不過有部分Hive的SQL特性在Impala中並不支援，其中包括：

Data等型別不支援
XML和Json函式不支援
多個DISTINCT不支援，完成多個DISTINCT需要如下操作

select v1.c1 result1, v2.c1 result2 from
(select count(distinct col1) as c1 from t1) v1
cross join
(select count(distinct col2) as c1 from t1) v2;
複製程式碼

Impala和Hive的相容不僅僅體現在語法上，在架構上Impala和Hive也保持著相當程度上的相容性，Impala直接採用Hive的元資料庫，對於公司而言，已經在Hive中的表結構無需遷移，Impala可以直接使用。

Kudu+Impala對我們意味著什麼

Kudu+Impala為實時資料倉庫儲存提供了良好的解決方案。這套架構在支援隨機讀寫的同時還能保持良好的Scan效能，同時其對Spark等流式計算框架有官方的客戶端支援。這些特性意味著資料可以從Spark實時計算中實時的寫入Kudu，上層的Impala提供BI分析SQL查詢，對於資料探勘和演算法等需求可以在Spark迭代計算框架上直接操作Kudu底層資料。

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