1.kudu事物
strong的事務，kudu的事務和架構受spanner和calvin系統的啟發 Transaction Semantics ( 事務語義 )
不支持多行事物。
2.查詢條件關聯語句，應用場景，性能測試
創建關聯表
CREATE TABLE spark_kudu_test(id1 int, id2 int, id3 string) USING org.apache.kudu.spark.kudu OPTIONS("kudu.master" "node1:7051,node2:7051,node3:7051","kudu.table" "kudu_test");
應用場景
適用於既有隨機訪問，也有批量數據掃描的復合場景
適用於高計算量的場景
充分利用高性能存儲設備
支持數據更新，避免數據反復遷移
支持跨地域的實時數據備份和查詢
性能測試
天級別讀：源數據2.8億，541.7 G，耗時10min，平均46.6w條/s
小時級別寫
源數據2000W行，38G，耗時1.4min，平均23w條/s
天級別更新列：
源數據4.74億行，10個新列，耗時17min，平均46.5w條/s （其中包括讀800G的text格式hive表的時間，真實插入時間更少）
3.缺陷
隨機更新會變慢：HBase可以不用掃描硬盤進行隨機更新，而Kudu需要在更新之前進行關鍵值查找，在插入前進行Bloom查找
單行讀取可能會變慢：列式存儲設計是為了全表掃描做的優化，未來可能會為單行訪問的應用引入“列組”的概念
只有主鍵可以設置range分區，且只能由一個主鍵，也就是一個表只能有一個字段range分區，且該字段必須是主鍵
kudu的shell客戶端不提供表schema查看。如果你不通過imapla連接kudu，且想要查看表的元數據信息，需要用spark加載數據為dataframe，通過查看dataframe的schema查看表的元數據信息。
4.優勢
支持update和upsert操作
結構化數據模型
與imapla或spark集成后，可通過sql操作，使用方便
一個table由多個tablet組成，對分區查看、擴容和數據高可用支持非常好
掃描大數據量時吞吐率高
隨機訪問數據時延時低
通過高CPU性能發揮RAM和Flash潛力
IO效率高
5.持久化存儲
Kudu是一種完全的列式存儲引擎，表中的每一列數據都是存放在一起，列與列之間都是分開的。
為了能夠保存一部分歷史數據，並實現MVCC，Kudu將數據分為三個部分。一個部分叫做base data，是當前的數據；第二個部分叫做UNDO records，存儲的是從插入數據時到形成base data所進行的所有修改操作，修改操作以一定形式進行組織，實現快速查看歷史數據；第三個部分是REDO records，存儲的是還未merge到當前數據中的更新操作。
6.寬表問題 ,建表后加列
在批量讀取和批量寫入速度上（寬表，字段90+），Kudu都比HBase要快很多，Kudu使用bulk load寫空表不超過2分鍾、讀取Hfile的方式kudu讀取一天的數據在10分鍾左右
impala 或hive 給指定kudu庫中的表添加列，修改列並調整列位置
alter TABLE spark_kudu_test add columns(column_name string COMMENT '字段名稱');
alter TABLE spark_kudu_test CHANGE column_name column_name STRING AFTER doc_id;
7.單條數據性能
Kudu可支持一些分析性查詢的基礎。每一個Column的數據被存儲在一個相鄰的數據區域，而這個數據區域進一步被細分成一個個的小的Page單元，與HBase File中的Block類似，對每一個Column Page可采用一些Encoding算法，以及一些通用的Compression算法。 既然可對Column Page可采用Encoding以及Compression算法，那么，對單條記錄的更改就會比較困難了
Kudu可支持單條記錄級別的更新/刪除， 把DiskRowSet分為了兩部分：base data、delta stores。base data 負責存儲基礎數據，delta stores負責存儲 base data 中的變更數據.
Kudu簡單來說就是加強版的Hbase，除了像hbase一樣可以高效的單條數據查詢，他的表結構是類型關系型數據庫的。集合impala可以達到復雜sql的實時查詢。
如果是存粹的隨機讀寫，或者單行的檢索請求這類場景，由於這些Tradeoff的存在，HBASE的性能吞吐率是要優於Kudu不少的（2倍到4倍），kudu的優勢還是在支持類SQL檢索這樣經常需要進行投影操作的批量順序檢索分析場合。