# 介紹 Kudu 原文鏈接 : [http://kudu.apache.org/docs/index.html](http://kudu.apache.org/docs/index.html) 譯文鏈接 : [http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813605](http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813605) 貢獻者 : [那伊抹微笑](/display/~wangyangting)，[ApacheCN](/display/~apachecn)，[Apache中文網](/display/~apachechina) **Kudu** 是一個針對 **Apache Hadoop** 平臺而開發的列式存儲管理器。**Kudu** 共享 **Hadoop** 生態系統應用的常見技術特性: 它在?**commodity hardware**（商品硬件）上運行，**horizontally** **scalable**（水平可擴展），并支持 **highly** **available**（高可用）性操作。 此外，**Kudu?**還有更多優化的特點： * **OLAP** 工作的快速處理。 * 與 **MapReduce**，**Spark** 和其他 **Hadoop** 生態系統組件集成。 * 與 **Apache Impala（incubating）**緊密集成，使其與 **Apache Parquet** 一起使用 **HDFS** 成為一個很好的可變的替代方案。 * 強大而靈活的一致性模型，允許您根據每個 **per-request**（請求選擇）一致性要求，包括 **strict-serializable**（嚴格可序列化）一致性的選項。 * 針對同時運行順序和隨機工作負載的情況性能很好。 * 使用?**Cloudera Manager?**輕松維護和管理。 * **High availability**（高可用性）。**Tablet server?**和 **Master** 使用?[Raft Consensus Algorithm](http://kudu.apache.org/docs/#raft)?來保證節點的高可用，確保只要有一半以上的副本可用，該 **tablet?**便可用于讀寫。例如，如果 **3** 個副本中有 **2?**個或 **5?**個副本中的 **3?**個可用，則該 **tablet?**可用。即使在 **leader** **tablet?**出現故障的情況下，讀取功能也可以通過 **read-only**（只讀的）**follower tablets** 來進行服務。 * 結構化數據模型。 通過結合這些所有的特性，**Kudu?**的目標是支持應用家庭中那些難以在當前**Hadoop?**存儲技術中實現的應用。**Kudu**?常見的幾個應用場景:? * 實時更新的應用。剛剛到達的數據就馬上要被終端用戶使用訪問到。 * 時間序列相關的應用，需要同時支持：? * 根據海量歷史數據查詢。 * 必須非常快地返回關于單個實體的細粒度查詢。 * 實時預測模型的應用，支持根據所有歷史數據周期地更新模型。 * 有關這些和其他方案的更多信息，請參閱?[Example Use Cases](http://kudu.apache.org/docs/#kudu_use_cases)。 ## Kudu-Impala 集成特性 **CREATE/ALTER/DROP TABLE** **Impala** 支持使用 **Kudu** 作為持久層來 **creating**（創建），**altering**（修改）和 **dropping**（刪除）表。這些表遵循與 **Impala?**中其他表格相同的 ?I**nternal / external**（內部 / 外部）方法，允許靈活的數據采集和查詢。 **INSERT** 數據可以使用與那些使用 **HDFS** 或 **HBase** 持久性的任何其他 **Impala** 表相同的語法插入 **Impala** 中的 **Kudu** 表。 **`UPDATE`?/?`DELETE`** **Impala?**支持?**`UPDATE?`**和?**`DELETE?`SQL** 命令逐行或批處理修改 **Kudu?**表中的已有的數據。選擇 **SQL?**命令的語法與現有標準盡可能兼容。除了簡單?**`DELETE`?**或?**`UPDATE?`**命令之外，還可以?**`FROM?`**在子查詢中指定帶有子句的復雜連接。 **Flexible Partitioning（靈活分區）** 與 **Hive?**中的表分區類似，**Kudu?**允許您通過 **hash** 或范圍動態預分割成預定義數量的 **tablets**，以便在集群中均勻分布寫入和查詢。您可以通過任意數量的 **primary** **key**（主鍵）列，任意數量的 **hashes?**和可選的 **list of split rows** 來進行分區。參見[模式設計](http://kudu.apache.org/docs/schema_design.html)。 **Parallel Scan（并行掃描）** 為了在現代硬件上實現最高的性能，**Impala?**使用的 **Kudu?**客戶端可以跨多個 **tablets?**掃描。 **High-efficiency queries（高效查詢）** 在可能的情況下，**Impala?**將謂詞評估下推到 **Kudu**，以便使謂詞評估為盡可能接近數據。在許多任務中，查詢性能與 **Parquet?**相當。 有關使用 **Impala?**查詢存儲在 **Kudu?**中的數據的更多詳細信息，請參閱 **Impala?**文檔。 ## 概念和術語 **Columnar Data Store**（列式數據存儲） **Kudu** 是一個?_**columnar data store**（列式數據存儲）_。列式數據存儲在強類型列中。由于幾個原因，通過適當的設計，**Kudu** 對 **analytical**（分析）或 **warehousing**（數據倉庫）工作會非常出色。 **Read** **Efficiency**（高效讀取） 對于分析查詢，允許讀取單個列或該列的一部分同時忽略其他列，這意味著您可以在磁盤上讀取更少塊來完成查詢。與基于行的存儲相比，即使只返回幾列的值，仍需要讀取整行數據。 **Data Compression**（數據壓縮） 由于給定的列只包含一種類型的數據，基于模式的壓縮比壓縮混合數據類型（在基于行的解決方案中使用）時更有效幾個數量級。結合從列讀取數據的效率，壓縮允許您在從磁盤讀取更少的塊時完成查詢。請參閱?[數據壓縮](http://kudu.apache.org/docs/schema_design.html#encoding) **Table**（表） 一張?_**talbe**?_是數據存儲在 **Kudu** 的位置。表具有 **schema?**和全局有序的 **primary** **key**（主鍵）。**table**?被分成稱為 **tablets** 的 **segments**。 **Tablet** 一個 **tablet** 是一張 **table** 連續的 **segment**，與其它數據存儲引擎或關系型數據庫中的 _**partition**_（分區）相似。給定的 **tablet**?冗余到多個?**tablet** 服務器上，并且在任何給定的時間點，其中一個副本被認為是 **leader tablet**。任何副本都可以對讀取進行服務，并且寫入時需要在為?**tablet?**服務的一組 **tablet server**之間達成一致性。 **Tablet** **Server** 一個 **tablet** **server**?存儲?**tablet** 和為?**tablet?**向?**client?**提供服務。對于給定的 **tablet**，一個 **tablet?server** 充當 leader，其他 **tablet server**?充當該 **tablet?**的 **follower** 副本。只有 **leader** 服務寫請求，然而 **leader** 或 **followers** 為每個服務提供讀請求。**leader** 使用?[Raft Consensus Algorithm](http://kudu.apache.org/docs/#raft)?來進行選舉?。一個 **tablet** **server** 可以服務多個 **tablets**?，并且一個 **tablet** 可以被多個 **tablet** **servers**?服務著。 **Master** 該 **master** 保持跟蹤所有的 **tablets**，**tablet** **servers**，[Catalog Table](http://kudu.apache.org/docs/#catalog_table)?和其它與集群相關的 **metadata**。在給定的時間點，只能有一個起作用的 **master**（也就是 **leader**）。如果當前的 **leader** 消失，則選舉出一個新的 **master**，使用??[Raft Consensus Algorithm](http://kudu.apache.org/docs/#raft)?來進行選舉。 **master** 還協調客戶端的?**metadata?operations**（元數據操作）。例如，當創建新表時，客戶端內部將請求發送給 **master**。**?master?**將新表的元數據寫入**?catalog table**，并協調在 **tablet server** 上創建 **tablet** 的過程。 所有 **master** 的數據都存儲在一個?**tablet** 中，可以復制到所有其他候選的 **master**。 **tablet** **server** 以設定的間隔向 **master** 發出心跳（默認值為每秒一次）。 **Raft Consensus Algorithm** **Kudu?**使用?[Raft consensus algorithm](https://raft.github.io/)?作為確保常規 **tablet** 和 **master** 數據的容錯性和一致性的手段。通過 **Raft**，**tablet** 的多個副本選舉出_?**leader**_，它負責接受以及復制到_?**_follower?_**_副本的寫入。一旦寫入的數據在大多數副本中持久化后，就會向客戶確認。給定的一組?`N?`副本（通常為 **3** 或 **5** 個）能夠接受最多`**(N - 1)/2**?`錯誤的副本的寫入。 **Catalog Table（目錄表）** _?**catalog** **talbe?**_是?**Kudu** 的 **metadata**（元數據中）的中心位置。它存儲有關 **tables** 和 **tablets** 的信息。該 **catalog table**（目錄表）可能不會被直接讀取或寫入。相反，它只能通過客戶端 **API** 中公開的元數據操作訪問。**catalog table** 存儲兩類元數據。 **Tables** **table schemas**, **locations**, **and states**（表結構，位置 和狀態） **Tablets** 現有 **tablet** 的列表，每個?**tablet 的**副本所在哪些 **tablet server**，**tablet** 的當前狀態以及開始和結束的 **keys**（鍵）。 **Logical Replication**（邏輯復制） ?**Kudu** 復制操作，不是磁盤上的數據。這被稱為?_**logical replication**（__邏輯復制）_，而不是?_**physical replication**（__物理復制）_。這有幾個優點 :? * 雖然 **insert**（插入）和 **update**（更新）確實通過網絡傳輸數據，**deletes**（刪除）不需要移動任何數據。**delete**（刪除）操作被發送到每個 **tablet** **server**，它在本地執行刪除。 * 物理操作，如 **compaction**，不需要通過 **Kudu?**的網絡傳輸數據。這與使用 **HDFS?**的存儲系統不同，其中 **blocks** （塊）需要通過網絡傳輸以滿足所需數量的副本。 * **tablet** 不需要在同一時間或相同的時間表上執行壓縮，或者在物理存儲層上保持同步。這會減少由于壓縮或大量寫入負載而導致所有 **tablet server** 同時遇到高延遲的機會。 ## 架構概述 下圖顯示了一個具有三個 **master** 和多個 **tablet** **server** 的 **Kudu** 集群，每個服務器都支持多個 **tablet**。它說明了如何使用 **Raft** 共識來允許 **master** 和 **tablet** **server** 的 **leader** 和 f **ollow**。此外，**tablet server** 可以成為某些 **tablet** 的 **leader**，也可以是其他 **tablet** 的 **follower**。**leader** 以金色顯示，而 **follower** 則顯示為藍色。  ## 案例示例 **Streaming Input with Near Real Time Availability**（具有近實時可用性的流輸入） 數據分析中的一個共同挑戰就是新數據快速而不斷地到達，同樣的數據需要靠近實時的讀取，掃描和更新。Kudu 通過高效的列式掃描提供了快速插入和更新的強大組合，從而在單個存儲層上實現了實時分析用例。 **Time-series application with widely varying access patterns**（具有廣泛變化的訪問模式的時間序列應用） **time-series**（時間序列）模式是根據其發生時間組織和鍵入數據點的模式。這可以用于隨著時間的推移調查指標的性能，或者根據過去的數據嘗試預測未來的行為。例如，時間序列的客戶數據可以用于存儲購買點擊流歷史并預測未來的購買，或由客戶支持代表使用。雖然這些不同類型的分析正在發生，插入和更換也可能單獨和批量地發生，并且立即可用于讀取工作負載。**Kudu** 可以用?**scalable** （可擴展）和 **efficient** （高效的）方式同時處理所有這些訪問模式。由于一些原因，**Kudu** 非常適合時間序列的工作負載。隨著 **Kudu?**對基于 **hash** 的分區的支持，結合其對復合 **row** **keys**（行鍵）的本地支持，將許多服務器上的表設置成很簡單，而不會在使用范圍分區時通常觀察到“**hotspotting**（熱點）”的風險。**Kudu** 的列式存儲引擎在這種情況下也是有益的，因為許多時間序列工作負載只讀取了幾列，而不是整行。?過去，您可能需要使用多個數據存儲來處理不同的數據訪問模式。這種做法增加了應用程序和操作的復雜性，并重復了數據，使所需存儲量增加了一倍（或更糟）。**Kudu** 可以本地和高效地處理所有這些訪問模式，而無需將工作卸載到其他數據存儲。 **Predictive** **Modeling**（預測建模）?數據科學家經常從大量數據中開發預測學習模型。模型和數據可能需要在學習發生時或隨著建模情況的變化而經常更新或修改。此外，科學家可能想改變模型中的一個或多個因素，看看隨著時間的推移會發生什么。在?**HDFS?**中更新存儲在文件中的大量數據是資源密集型的，因為每個文件需要被完全重寫。在 **Kudu**，更新發生在近乎實時。科學家可以調整值，重新運行查詢，并以秒或分鐘而不是幾小時或幾天刷新圖形。此外，批處理或增量算法可以隨時在數據上運行，具有接近實時的結果。 **Combining Data In Kudu With Legacy Systems**（結合 **Kudu** 與遺留系統的數據）? 公司從多個來源生成數據并將其存儲在各種系統和格式中。例如，您的一些數據可能存儲在 **Kudu**，一些在傳統的 **RDBMS?**中，一些在 **HDFS?**中的文件中。您可以使用 **Impala?**訪問和查詢所有這些源和格式，而無需更改舊版系統。 ## 下一步 * [Kudu 入門指南](/pages/viewpage.action?pageId=10813610) * [安裝指南](/pages/viewpage.action?pageId=10813613)