參考文章：kudu介紹及安裝配置
Kudu-Impala 集成特性
CREATE/ALTER/DROP TABLE
Impala 支持使用 Kudu 作爲持久層來 creating（創建），altering（修改）和 dropping（刪除）表。這些表遵循與 Impala 中其他表格相同的 Internal / 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 來進行分區。參見模式設計。
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（數據壓縮）
由於給定的列只包含一種類型的數據，基於模式的壓縮比壓縮混合數據類型（在基於行的解決方案中使用）時更有效幾個數量級。結合從列讀取數據的效率，壓縮允許您在從磁盤讀取更少的塊時完成查詢。請參閱 數據壓縮
Table（表）
一張 table 是數據存儲在 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 來進行選舉 。一個 tablet server 可以服務多個 tablets ，並且一個 tablet 可以被多個 tablet servers 服務着。
Master
該 master 保持跟蹤所有的 tablets，tablet servers，Catalog Table 和其它與集羣相關的 metadata。在給定的時間點，只能有一個起作用的 master（也就是 leader）。如果當前的 leader 消失，則選舉出一個新的 master，使用 Raft Consensus Algorithm 來進行選舉。master 還協調客戶端的 metadata operations（元數據操作）。例如，當創建新表時，客戶端內部將請求發送給 master。 master 將新表的元數據寫入 catalog table，並協調在 tablet server 上創建 tablet 的過程。所有 master 的數據都存儲在一個 tablet 中，可以複製到所有其他候選的 master。tablet server 以設定的間隔向 master 發出心跳（默認值爲每秒一次）。
Raft Consensus Algorithm
Kudu 使用 Raft consensus algorithm 作爲確保常規 tablet 和 master 數據的容錯性和一致性的手段。通過 Raft，tablet 的多個副本選舉出 leader，它負責接受以及複製到 follower 副本的寫入。一旦寫入的數據在大多數副本中持久化後，就會向客戶確認。給定的一組 N 副本（通常爲 3 或 5 個）能夠接受最多(N - 1)/2 錯誤的副本的寫入。
Catalog Table（目錄表）
catalog table 是 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 同時遇到高延遲的機會。