kuda 瞭解片

原本上個月想去了解一下kuda的，結果一直沒有抽出時間去搞，如今大體先開個頭，方便後面深刻！

 

Apache Kudu是開源Apache Hadoop生態系統的新成員，它完善了Hadoop的存儲層，能夠 快速分析快速數據。

Kudu提供快速插入/更新和高效柱狀掃描的組合，以在單個存儲層上實現多個實時分析工做負載。做爲HDFS和Apache HBase的新補充，Kudu使架構師可以靈活地處理各類用例，而無需異乎尋常的解決方法。

Kudu專爲須要快速（快速變化）數據快速分析的用例而設計。Kudu專爲利用下一代硬件和內存處理而設計，可顯着下降Apache Impala（孵化）和Apache Spark（最初與其餘執行引擎）的查詢延遲。

 

Kudu和Impala均是Cloudera貢獻給Apache基金會的頂級項目。

 

以前一直是 hdfs+Parquet+hive+impala

如今不少廠有用kuda+impala(或其餘), 

去百度一番，快速瞭解一下。

 

kuda大體瞭解 

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的設計可以很好的處理此場景。

時間序列存儲引擎(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。（catalog table）目錄表可能沒法直接讀取或寫入。相反，它只能經過客戶端API中公開的元數據操做訪問。

Tables:table schemas, locations, and states

Tablets:the list of existing tablets, which tablet servers have replicas of each tablet, the tablet’s current state, and start and end keys.

Logical replication

Logical Replication(邏輯複製)

Kudu複製操做，而不是磁盤數據。這稱爲邏輯複製，而不是物理複製。這有幾個好處：

• 儘管插入和更新確實經過網絡傳輸數據，但刪除操做不須要移動任何數據。刪除操做將發送到每一個tablet server(服務器)，該服務器在本地執行刪除。

• 物理操做（例如壓縮）不須要在Kudu中經過網絡傳輸數據。這與使用HDFS的存儲系統不一樣，後者須要經過網絡傳輸塊以知足所需數量的副本。

• tables不須要同時或在相同的時間表上執行壓縮，或者在物理存儲層上保持同步。因爲壓縮或大量寫入負載，這下降了全部tables(平板電腦)服務器同時遇到高延遲的可能性。

Kudu架構概覽

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

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

leader以黃金顯示，而follower以藍色顯示。

 

 

Kudu+Impala對咱們意味着什麼

Kudu+Impala爲實時數據倉庫存儲提供了良好的解決方案。這套架構在支持隨機讀寫的同時還能保持良好的Scan性能，同時其對Spark等流式計算框架有官方的客戶端支持。這些特性意味着數據能夠從Spark實時計算中實時的寫入Kudu，上層的Impala提供BI分析SQL查詢，對於數據挖掘和算法等需求能夠在Spark迭代計算框架上直接操做Kudu底層數據。

Kudu-Impala集成功能

CREATE/ALTER/DROP TABLE

Impala支持使用Kudu做爲持久層建立，更改和刪除表。這些表遵循與Impala中其餘表相同的內部/外部方法，容許靈活的數據提取和查詢。

INSERT

可使用與任何其餘Impala表相同的語法將數據插入Impala中的Kudu表，例如使用HDFS或HBase進行持久化的表。

UPDATE / DELETE

Impala支持UPDATE和DELETESQL命令逐行或批量修改Kudu表中的現有數據。選擇SQL命令的語法與現有標準儘量兼容。除了simple DELETE 或UPDATE命令以外，還可使用FROM子查詢中的子句指定複雜鏈接。

靈活的分區

與Hive中的表分區相似，Kudu容許您經過散列或範圍動態地將表預分割爲預約義數量的平板電腦，以便在集羣中均勻分配寫入和查詢。您能夠按任意數量的主鍵列，任意數量的哈希值和可選的拆分行列表進行分區。請參閱架構設計。

並行掃描

爲了在現代硬件上實現最高性能，Impala使用的Kudu客戶端在多個平板電腦上並行掃描。

高效查詢

在可能的狀況下，Impala將謂詞評估推送到Kudu，以便儘量接近數據評估謂詞。在許多工做負載中，查詢性能與Parquet至關。

有關使用Impala查詢存儲在Kudu中的數據的更多詳細信息，請參閱Impala文檔。

 

 

Spark集成最佳實踐

每個羣集避免多個Kudu客戶端。

一個常見的Kudu-Spark編碼錯誤是實例化額外的KuduClient對象。在kudu-spark中，a KuduClient屬於KuduContext。Spark應用程序代碼不該建立另外一個KuduClient鏈接到同一羣集。相反，應用程序代碼應使用KuduContext訪問KuduClient使用KuduContext#syncClient。

要診斷KuduClientSpark做業中的多個實例，請查看主服務器的日誌中的符號，這些符號會被來自不一樣客戶端的許多GetTableLocations或 GetTabletLocations請求過載，一般大約在同一時間。這種症狀特別適用於Spark Streaming代碼，其中建立KuduClient每一個任務將致使來自新客戶端的主請求的週期性波。

 

Spark集成已知問題和限制

• Spark 2.2+在運行時須要Java 8，即便Kudu Spark 2.x集成與Java 7兼容。Spark 2.2是Kudu 1.5.0的默認依賴版本。

• 當註冊爲臨時表時，必須爲名稱包含大寫或非ascii字符的Kudu表分配備用名稱。

• 包含大寫或非ascii字符的列名的Kudu表不能與SparkSQL一塊兒使用。能夠在Kudu中重命名列以解決此問題。

• <>而且OR謂詞不會被推送到Kudu，而是由Spark任務進行評估。只有LIKE帶有後綴通配符的謂詞纔會被推送到Kudu，這意味着它LIKE "FOO%"被推下但LIKE "FOO%BAR"不是。

• Kudu不支持Spark SQL支持的每種類型。例如， Date不支持複雜類型。

• Kudu表只能在SparkSQL中註冊爲臨時表。使用HiveContext可能沒法查詢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能夠保證單行操做的原子性。

 

Example Use Cases

具備近實時可用性的流輸入

數據分析中的一個常見挑戰是新數據快速且持續地到達，而且須要幾乎實時地提供相同的數據以進行讀取，掃描和更新。Kudu提供快速插入和更新的強大組合，以及高效的柱狀掃描，以在單個存儲層上實現實時分析用例。

具備普遍變化的訪問模式的時序應用程序

時間序列模式是根據數據點發生的時間組織和鍵入數據點的模式。這對於隨時間調查指標的性能或嘗試根據過去的數據預測將來行爲很是有用。例如，時間序列客戶數據可用於存儲購買點擊流歷史記錄和預測將來購買，或供客戶支持表明使用。雖然這些不一樣類型的分析正在發生，但插入和突變也可能單獨和大量發生，而且可當即用於讀取工做負載。Kudu能夠以可擴展且高效的方式同時處理全部這些訪問模式。

因爲多種緣由，Kudu很是適合時間序列工做負載。因爲Kudu支持基於散列的分區，結合其對複合行密鑰的本機支持，能夠很容易地設置跨多個服務器的表，而不會出現使用範圍分區時常見的「熱點」風險。Kudu的柱狀存儲引擎在這種狀況下也頗有用，由於許多時間序列工做負載只讀取幾列，而不是整行。

過去，您可能須要使用多個數據存儲來處理不一樣的數據訪問模式。這種作法增長了應用程序和操做的複雜性，並使數據重複，使所需的存儲量翻倍（或更差）。Kudu能夠本地高效地處理全部這些訪問模式，而無需將工做卸載到其餘數據存儲。

預測建模

數據科學家常常從大量數據集開發預測性學習模型。當學習發生或建模的狀況發生變化時，可能須要常常更新或修改模型和數據。此外，科學家可能想要改變模型中的一個或多個因素，看看隨着時間的推移會發生什麼。更新存儲在HDFS中的文件中的大量數據是資源密集型的，由於每一個文件都須要徹底重寫。在Kudu，更新幾乎是實時發生的。科學家能夠調整值，從新運行查詢，並在幾秒或幾分鐘內刷新圖表，而不是幾小時或幾天。此外，批處理或增量算法能夠隨時在數據上運行，並具備接近實時的結果。

將Kudu中的數據與遺留系統(RDBMS,HDFS)相結合,用impala訪問查詢，無需該舊系統

 

 

 

其餘補充：

1.參考 kuda的官網： https://kudu.apache.org/overview.html#architecture

2.OLTP(On-line Transaction Processing) 面向的是高併發低延時的增刪改查(INSERT, DELETE, UPDATE, SELECT, etc..)。

OLAP(On-line Analytical Processing) 面向的是BI分析型數據請求，其對延時有較高的容忍度，處理數據量相較OLTP要大不少。

傳統意義上與OLTP對應的是MySQL等關係型數據庫，與OLAP相對應的則是數據倉庫。OLTP與OLAP所面向的數據存儲查詢引擎是不一樣的，其處理的請求不同，所須要的架構也大不相同。這個特色意味着數據須要儲存在至少兩個地方，須要按期或者實時的同步，同時還須要保持一致性，該特色對數據開發工程師形成了極大的困擾，浪費了同窗們大量的時間在數據的同步和校驗上。Kudu+Impala的出現，雖然不能完美的解決這個問題，但不能否認，其緩解了這個矛盾。

在此須要注意的是OLTP並無嚴格要求其事務處理知足ACID四個條件。事實上，OLTP是比ACID更早出現的概念。在本文中，OLTP和OLAP的概念關注在數據量、併發量、延時要求等方面，不關注事務。