概述
為什么需要這種存儲 ？
- 靜態數據： 以 HDFS 引擎作為存儲引擎，適用於高吞吐量的離線大數據分析場景。 這類存儲的局限性是數據無法進行隨
機的讀寫。 就是不支持按照行去檢索， 不支持行級別的update 和 delete - 動態數據：以 HBase、Cassandra 作為存儲引擎，適用於大數據隨機讀寫場景。局限性是批量讀取吞吐量遠不如
HDFS，不適用於批量數據分析的場景。 適合大數據量的按行檢索，但是批量分析能力弱，尤其SQL表現弱
大數據的特點就是涉及到的存儲非常多，所以尤其需要一個存儲搞定一切， 簡化使用成本和減少一致性問題。 KUDU 就是這類問題的救星。
對此業界常用解決方案如下：
就是數據只是存儲在 HBASE中滿足 按照快速檢索的需求，同時對於復雜SQL分析場景，采取hive 建外表的方式，把 HBASE 的 rowkey 、 column family 、column 映射成hive的字段，便於SQL的自定義分析。
外表的方式，查詢的時候還是把SQL翻譯成功 MR任務去執行的， 由於存儲受限還是無法改變 HBASE 不善於做大批量數據分析的需求。
業界還有一種解決方案如下：
如上圖所示，數據實時寫入 HBase，實時的數據更新也在 HBase 完成，為了應對 OLAP 需求，我們定
時將 HBase 數據寫成靜態的文件（如：Parquet）導入到 OLAP 引擎（如：Impala、Hive）。這一架
構能滿足既需要隨機讀寫，又可以支持 OLAP 分析的場景，但他有如下缺點：
- 數據還是存儲多份，存在一致性問題，運維成本高
- 時效性低，從HBASE導出成 parquet文件是周期性的，一般是一天或者一小時
- 每次發生數據更新都需要 覆蓋寫parquet 文件。
Kudu 應運而生。Kudu 的定位是 Fast Analytics on Fast Data，是一個既支持隨機讀寫、又支持 OLAP 分析的大數據存儲引擎。 業界也有很多人把 kudu作為實時數倉去使用， 全部導入 KUDU，不再使用 hive那一套。
數據時效性好，運維也簡單。
借用官網的圖片如下：
Kudu 是一個折中的產品，在 HDFS 和 HBase 這兩個偏科生中平衡了隨機讀寫和批量分析的性能。
當然 Kudu 身上還有很多概念或者標簽，有分布式文件系統（好比 HDFS），有一致性算法（好比
Zookeeper），有 Table（好比 Hive Table），有 Tablet（好比 Hive Table Partition），有列式存儲
（好比 Parquet），有順序和隨機讀取（好比 HBase），所以看起來 Kudu 是一個輕量級的 HDFS +
Zookeeper + Hive + Parquet + HBase，除此之外，Kudu 還有自己的特點，快速寫入+讀取，使得
kudu + Impala 非常適合 OLAP 場景，尤其是 Time-series 場景。
Kudu 是一個分布式列式存儲引擎/系統，官方給 Kudu 的定位是：在更新更及時的基礎上實現更快的數據分析
Kudu 的特性決定了它適合以下場景：
1、適用於那些既有隨機訪問，也有批量數據掃描的復合場景
2、CPU 密集型的場景
3、使用了高性能的存儲設備，包括使用更多的內存
4、要求支持數據更新，避免數據反復遷移的場景
5、支持跨地域的實時數據備份和查詢
缺點：
（1）只有主鍵可以設置 range 分區，且只能由一個主鍵，也就是一個表只能有一個字段 range 分區，
且該字段必須是主鍵。
（2）如果是 pyspark 連接 kudu，則不能對 kudu 進行額外的操作；而 scala 的 spark 可以調用 kudu
本身的庫，支持 kudu 的各種語法。
（3）kudu 的 shell 客戶端不提供表 schema 查看。如果你不通過 imapla 連接 kudu，且想要查看表
的元數據信息，需要用 spark 加載數據為 dataframe，通過查看 dataframe 的 schema 查看表的元數
據信息。
（3）kudu 的 shell 客戶端不提供表內容查看。如果你想要表的據信息，要么自己寫腳本，要么通過
spark、imapla 查看。
（4）如果使用 range 分區需要手動添加分區。假設 id 為分區字段，需要手動設置第一個分區為 1-
30，第二個分區為 30-60 等等
（5）時間格式是 utc 類型，需要將時間戳轉化為 utc 類型，注意 8 個小時時差
Kudu 和 RDBMS 對比
總之一句話： 如果你正在找尋一款既支持實時查詢又支持大規模數據分析和機器學習場景的存儲，Kudu 將是一 個很
好的選擇，它將在搞定需求的同時極大降低運維復雜度。
高層架構
跟 HBase 類似，Kudu 是典型的主從架構。一個 Kudu 集群由主節點即 Master 和若干個從節
點即 Tablet Server 組成。Master 負責管理集群的元數據（類似於 HBase 的 Master），Tablet
Server 負責數據存儲（類似 HBase 的 RegionServer）。在生產環境，一般部署多個 Master 實現高可
用（奇數個、典型的是 3 個），Tablet Server 一般也是奇數個。
Table 表
表具有 schema（表結構）和全局有序的 primary key（主鍵）。table 被水平分成很多段，每個段稱為Tablet。
Tablet:
分區，一張表的所有 tablet 包含了這張表的所有 key 空間。
Tablet Server：
Tablet server 是 Kudu 集群中的從節點，負責數據存儲，並提供數據讀寫服務。
Master：
集群中的主節點，負責集群管理、元數據管理等功能。
保持跟蹤所有的 tablets、tablet servers、catalog tables（目錄表）和其它與集群相關的 metadata。
在給定的時間點，只能有一個起作用的 Master（也就是 leader）。