不生產博客，只是官網的搬運工
https://docs.cloudera.com/documentation/enterprise/5-16-x/topics/kudu_schema_design.html
column設計
非主鍵可爲空，支持如下類型
8、16、32、64位整數
timestamp(64位)
float(32位)
double(64位)
decimal
string(utf-8，最大爲壓縮前64k)
binary(最大爲壓縮前64k)
與hbase不同的是，kudu不提供version或timestamp字段來track row的修改，如果需要，schema應該包括一個顯式的version或timestamp字段(咋指定呢?)
decimal類型
位數最多爲38，
位數9以下4字節，10到18 8字節，18以上，16字節
列編碼
主鍵設計
kudu創表得指定主鍵，插入已經存在的主鍵會報錯，一旦表被創建，主鍵不能更改，kudu不支持自增id，但是可以用uuid，刪除和更新數據必須指定完整的主鍵，kudu不支持range刪除or更新(疑問？刪除必須指定主鍵？那我們在impala執行delete from table的時候，是impala把所有主鍵交給kudu然後刪除嗎，不支持range？那批量的時候也是impala把所有主鍵交給kudu？)
當數據插入後，主鍵的值不能被更新，但是可以刪掉，然後重新插入
主鍵索引
類似關係型數據庫，kudu的主鍵用的是clustered索引，所有的行按主鍵排序，scan kudu表時，使用= or range是非常高效的
backfill插入的注意事項
討論主鍵是timestamp的情況，或者主鍵中第一個字段是timestamp，每次插入一行數據，kudu都會在主鍵索引中檢測是否存在。擔心翻譯的扯淡，將原文粘過來
In the typical case where data is being inserted at the current time as it
arrives from the data source, only a small range of primary keys are "hot".
So, each of these "check for presence" operations is very fast. It hits
the cached primary key storage in memory and doesn’t require going to disk
數據被插入當它從數據源到達kudu的時候，僅僅一小部分主鍵是"hot"，（意思這部分主鍵在內存中），所以每次檢測主鍵是否存在是非常快的，它hit(類似指示標明的意思吧)，那部分主鍵是在內存中的，不需要在磁盤檢查.
有時候，需要load歷史數據，叫做backfill，插入的每一行可能都在"cold'區域，導致更多的磁盤seek，例如，正常insert，可能每秒百萬級，backfill可能幾千
如何解決backfill?
1.使主鍵有更好的壓縮性
例如主鍵的第一個字段是32位的隨機Id(uuid嗎？),緩存1億條至少需要32G內存，也就是如果是8位的話放的更多，命中率更高
2.使用ssd固態
3.更改主鍵結構，使得backfill寫入能命中連續的主鍵
(不知道啥意思，怎麼能命中連續的主鍵？還有就是怎麼讓主鍵都緩存在內存裏，後面得測試下，
1種是表裏有數據，然後往裏upsert或insert，一種是空表，往裏insert，瞅瞅到底多大差別)
分區，
目標，寫入可以分佈在多個分區上，對於short scan如果可以只掃描一個分區，可以提高性能
range分區
分區鍵必須是主鍵的子集
range分區一般分區鍵都是基於時間的，所以可以動態添加刪除而不影響別的分區
range分區對scan有優勢，可以通過分區裁剪不對某些分區scan,但寫的時候會有熱點問題，只向某個分區寫入
第一種是無邊界range分區，第二種是有邊界分區，兩種分區可能都有熱點問題，但第二種更加靈活，可以將未來的數據添加到新建的分區，而第一種，以後的數據都會在最後一個分區
hash分區
寫入的時候不會有熱點問題，與範圍分區一樣，分區鍵是主鍵的子集
當數據量不斷增加時，可能單分區會很大，影響並行度
兩種分區的比較
可以看到range分區寫會有“熱點”問題，而scan的話，可以修建掉更多分區，不止有=，還有range謂詞，當表不斷增大時，可以通過添加新分區
而hash分區，寫會寫到所有分區，scan只有=可以來修建分區(待我測試完再來更新這)，分區可能會很大
多級(mulitilevel)分區
既有range、也有hash分區，中和兩種分區優缺點
以上示例，如果寫入2017年的數據，會有4個並行度，寫到4個分區種
分區修剪
很重要，擔心翻譯的扯，貼出來
Kudu scans will automatically skip scanning entire partitions when it can
be determined that the partition can be entirely filtered by the scan
predicates. To prune hash partitions, the scan must include equality
predicates on every hashed column. To prune range partitions, the scan must
include equality or range predicates on the range partitioned columns.
Scans on multilevel partitioned tables can take advantage of partition
pruning on any of the levels independently.
scan將自動跳過整個分區當kudu可以確定該分區可以被全部過濾通過scan謂詞(hash分區怎麼跳過呢?)，爲了修建hash分區,scan必須包括=謂詞在每個hash分區鍵上（看來只能=，別的都不會skip）
爲了修建range分區，scan必須包括=or range謂詞(between，大於，小於應該都是吧)。scan多級分區，可以都是用兩種分區的修建
修改schema
1.rename table
2.rename 主鍵
3.rename、添加、刪除非主鍵
4.添加、刪除range分區