Kudu是什么?
Kudu是Todd Lipcon@Cloudera帶頭開(kāi)發(fā)的存儲(chǔ)系統(tǒng)忙干，其整體應(yīng)用模式和HBase比較接近，即支持行級(jí)別的隨機(jī)讀寫浪藻，并支持批量順序檢索功能捐迫。
那既然有了HBase，為什么還需要Kudu呢爱葵，簡(jiǎn)單的說(shuō)施戴，就是嫌棄HBase在OLAP場(chǎng)合，SQL／MR類的批量檢索場(chǎng)景中萌丈，性能不夠好赞哗。通常這種海量數(shù)據(jù)OLAP場(chǎng)景，要不走預(yù)處理的路浓瞪，比如像EBAY麒麟這樣走Cube管理的懈玻，或者像谷歌Mesa這樣按業(yè)務(wù)需求走預(yù)定義聚合操作。再有就是自己構(gòu)建數(shù)據(jù)通道乾颁，串接實(shí)時(shí)和批量處理兩種系統(tǒng)涂乌，發(fā)揮各自的特長(zhǎng)。
但是OLAP是個(gè)復(fù)雜的問(wèn)題英岭，場(chǎng)景眾多湾盒，必然不可能有完美的通用解決方案，Kudu定位于應(yīng)對(duì)快速變化數(shù)據(jù)的快速分析型數(shù)據(jù)倉(cāng)庫(kù)诅妹，希望靠系統(tǒng)自身能力罚勾，支撐起同時(shí)需要高吞吐率的順序和隨機(jī)讀寫的應(yīng)用場(chǎng)景（可能的場(chǎng)景，比如時(shí)間序列數(shù)據(jù)分析吭狡，日志數(shù)據(jù)實(shí)時(shí)監(jiān)控分析）尖殃，提供一個(gè)介于HDFS和HBase的性能特點(diǎn)之間的一個(gè)系統(tǒng)，在隨機(jī)讀寫和批量掃描之間找到一個(gè)平衡點(diǎn)划煮，并保障穩(wěn)定可預(yù)測(cè)的響應(yīng)延遲
那為什么不能想辦法改進(jìn)HBase呢送丰？Todd自己做為HBase的重要貢獻(xiàn)者之一，沒(méi)有選擇這條路弛秋，自然是因?yàn)槿魏蜗到y(tǒng)設(shè)計(jì)時(shí)都有Tradeoff器躏，基于HBase的設(shè)計(jì)思想很難實(shí)現(xiàn)Kudu所定位的目標(biāo)
相關(guān)鏈接：
核心思想是什么俐载？
數(shù)據(jù)模型：
數(shù)據(jù)模型定義上，Kudu管理的是類似關(guān)系型數(shù)據(jù)庫(kù)的結(jié)構(gòu)化的表登失，表結(jié)構(gòu)由類Sql的Schema進(jìn)行定義遏佣，相比于HBase這樣的NoSql類型的數(shù)據(jù)庫(kù)，Kudu的行數(shù)據(jù)是由固定個(gè)數(shù)有明確類型定義的列組成揽浙，并且需要定義一個(gè)由一個(gè)或多個(gè)列組成的主鍵來(lái)對(duì)每行數(shù)據(jù)進(jìn)行唯一索引状婶，相比于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，kudu在索引上有更多的限制馅巷，比如暫時(shí)不支持二級(jí)索引太抓，不支持主鍵的更新等等。
盡管表結(jié)構(gòu)類似于關(guān)系型數(shù)據(jù)庫(kù)令杈，但是Kudu自身并不提供SQL類型的語(yǔ)法接口，而是由上層其他系統(tǒng)實(shí)現(xiàn)碴倾，比如目前通過(guò)Impala提供SQL語(yǔ)法支持逗噩。
Kudu底層API，主要面對(duì)簡(jiǎn)單的更新檢索操作跌榔，Insert／Update／Delete等必須指定一個(gè)主鍵進(jìn)行异雁，而Scan檢索類型的操作則支持條件過(guò)濾和投影等能力。
集群架構(gòu)：
Kudu的集群架構(gòu)基本和HBase類似僧须，采用主從結(jié)構(gòu)纲刀，Master節(jié)點(diǎn)管理元數(shù)據(jù)，Tablet節(jié)點(diǎn)負(fù)責(zé)分片管理數(shù)據(jù)担平，
和HBase不同的是示绊，Kudu沒(méi)有借助于HDFS存儲(chǔ)實(shí)際數(shù)據(jù)，而是自己直接在本地磁盤上管理分片數(shù)據(jù)暂论，包括數(shù)據(jù)的Replication機(jī)制面褐，kudu的Tablet server直接管理Master分片和Slave分片，自己通過(guò)raft協(xié)議解決一致性問(wèn)題等取胎，多個(gè)Slave可以同時(shí)提供數(shù)據(jù)讀取服務(wù)展哭，相對(duì)于HBase依托HDFS進(jìn)行Region數(shù)據(jù)的管理方式，自主性會(huì)強(qiáng)一些闻蛀，不過(guò)比如Tablet節(jié)點(diǎn)崩潰匪傍，數(shù)據(jù)的遷移拷貝工作等，也需要Kudu自己完成觉痛。
存儲(chǔ)結(jié)構(gòu)：
因?yàn)閿?shù)據(jù)是有嚴(yán)格Schema類型定義役衡，所以Kudu底層可以使用列式存儲(chǔ)的方案來(lái)提高存儲(chǔ)和投影檢索效率（不過(guò)，設(shè)計(jì)kudu時(shí)秧饮，因果關(guān)系我估計(jì)是倒過(guò)來(lái)的映挂，先決定要使用列式存儲(chǔ)泽篮，再?zèng)Q定需要schema）
和HBase一樣，Kudu也是通過(guò)Tablet的分區(qū)來(lái)支持水平擴(kuò)展柑船，與HBase不同的是帽撑，Kudu的分區(qū)策略除了支持按照KeyRange來(lái)分區(qū)以外，還支持Hash based的策略鞍时，實(shí)際上亏拉，在主鍵上，Kudu可以混合使用這兩種不同的策略
Hash分區(qū)的策略在一些場(chǎng)合下可以更好的做到負(fù)載均衡逆巍，避免數(shù)據(jù)傾斜及塘，但是它最大的問(wèn)題就是分區(qū)數(shù)一旦確定就很難再調(diào)整，所以目前Kudu的分區(qū)數(shù)必須預(yù)先指定（對(duì)Range的分區(qū)策略也有這個(gè)要求锐极，估計(jì)是先簡(jiǎn)單化統(tǒng)一處理）笙僚，不支持動(dòng)態(tài)分區(qū)分裂，合并等灵再，因此表的分區(qū)一開(kāi)始就需要根據(jù)負(fù)載和容量預(yù)先進(jìn)行合理規(guī)劃肋层。
在處理隨機(jī)寫的效率問(wèn)題方面，Kudu的基本流程和HBase的方案差不多翎迁，在內(nèi)存中對(duì)每個(gè)Tablet分區(qū)維護(hù)一個(gè)MemRowSet來(lái)管理最新更新的數(shù)據(jù)栋猖，當(dāng)尺寸超過(guò)一定大小后Flush到磁盤上形成DiskRowSet，多個(gè)DiskRowSet在適當(dāng)?shù)臅r(shí)候進(jìn)行歸并處理
和HBase采用的LSM（LogStructured Merge）方案不同的是汪榔，Kudu對(duì)同一行的數(shù)據(jù)更新記錄的合并工作蒲拉，不是在查詢的時(shí)候發(fā)生的（HBase會(huì)將多條更新記錄先后Flush到不同的Storefile中，所以讀取時(shí)需要掃描多個(gè)文件痴腌，比較rowkey雌团，比較版本等），而是在更新的時(shí)候進(jìn)行衷掷，在Kudu中一行數(shù)據(jù)只會(huì)存在于一個(gè)DiskRowSet中辱姨，避免讀操作時(shí)的比較合并工作。那Kudu是怎么做到的呢戚嗅？ 對(duì)于列式存儲(chǔ)的數(shù)據(jù)文件雨涛，要原地變更一行數(shù)據(jù)是很困難的，所以在Kudu中懦胞，對(duì)于Flush到磁盤上的DiskRowSet（DRS）數(shù)據(jù)替久，實(shí)際上是分兩種形式存在的，一種是Base的數(shù)據(jù)躏尉，按列式存儲(chǔ)格式存在蚯根，一旦生成，就不再修改，另一種是Delta文件颅拦，存儲(chǔ)Base數(shù)據(jù)中有變更的數(shù)據(jù)蒂誉，一個(gè)Base文件可以對(duì)應(yīng)多個(gè)Delta文件，這種方式意味著距帅，插入數(shù)據(jù)時(shí)相比HBase右锨，需要額外走一次檢索流程來(lái)判定對(duì)應(yīng)主鍵的數(shù)據(jù)是否已經(jīng)存在。因此碌秸，Kudu是犧牲了寫性能來(lái)?yè)Q取讀取性能的提升绍移。
既然存在Delta數(shù)據(jù)，也就意味著數(shù)據(jù)查詢時(shí)需要同時(shí)檢索Base文件和Delta文件讥电，這看起來(lái)和HBase的方案似乎又走到一起去了蹂窖，不同的地方在于，Kudu的Delta文件與Base文件不同恩敌，不是按Key排序的瞬测，而是按被更新的行在Base文件中的位移來(lái)檢索的，號(hào)稱這樣做纠炮，在定位Delta內(nèi)容的時(shí)候涣楷，不需要進(jìn)行字符串比較工作，因此能大大加快定位速度抗碰。但是無(wú)論如何，Delta文件的存在對(duì)檢索速度的影響巨大绽乔。因此Delta文件的數(shù)量會(huì)需要控制弧蝇，需要及時(shí)的和Base數(shù)據(jù)進(jìn)行合并。由于Base文件是列式存儲(chǔ)的折砸，所以Delta文件合并時(shí)看疗，可以有選擇性的進(jìn)行，比如只把變化頻繁的列進(jìn)行合并睦授，變化很少的列保留在Delta文件中暫不合并两芳，這樣做也能減少不必要的IO開(kāi)銷。
除了Delta文件合并去枷，DRS自身也會(huì)需要合并怖辆，為了保障檢索延遲的可預(yù)測(cè)性（這一點(diǎn)是HBase的痛點(diǎn)之一，比如分區(qū)發(fā)生Major Compaction時(shí)删顶，讀寫性能會(huì)受到很大影響）竖螃，Kudu的compaction策略和HBase相比，有很大不同逗余，kudu的DRS數(shù)據(jù)文件的compaction特咆，本質(zhì)上不是為了減少文件數(shù)量，實(shí)際上Kudu DRS默認(rèn)是以32MB為單位進(jìn)行拆分的录粱，DRS的compaction并不減少文件數(shù)量腻格，而是對(duì)內(nèi)容進(jìn)行排序重組画拾，減少不同DRS之間key的overlap，進(jìn)而在檢索的時(shí)候減少需要參與檢索的DRS的數(shù)量菜职。
以32MB這樣小的單位進(jìn)行拆分青抛，也是為了能夠以有限的資源快速的完成compaction的任務(wù)，及時(shí)根據(jù)系統(tǒng)負(fù)載調(diào)整Compaction行為些楣，而不至于像HBase一樣脂凶，Major Compaction動(dòng)作成為導(dǎo)致性能不穩(wěn)定的一個(gè)重要因素。所以對(duì)于Kudu來(lái)說(shuō)愁茁，IO操作可以是一個(gè)持續(xù)平緩的過(guò)程蚕钦，這點(diǎn)對(duì)響應(yīng)的可預(yù)測(cè)性至關(guān)重要。
其它
Kudu底層核心代碼使用C++開(kāi)發(fā)鹅很，對(duì)外提供Java API接口嘶居，沒(méi)有使用Java開(kāi)發(fā)核心代碼，也許有部分原因是希望通過(guò)自己管理內(nèi)存促煮，更好的適應(yīng)和利用當(dāng)前服務(wù)器上普遍越來(lái)越大的內(nèi)存空間（256G＋）邮屁，另外也便于在關(guān)鍵邏輯中更好的優(yōu)化代碼。
小結(jié)
總體來(lái)說(shuō)菠齿，個(gè)人感覺(jué)佑吝，Kudu本質(zhì)上是將性能的優(yōu)化，寄托在以列式存儲(chǔ)為核心的基礎(chǔ)上绳匀，希望通過(guò)提高存儲(chǔ)效率芋忿，加快字段投影過(guò)濾效率，降低查詢時(shí)CPU開(kāi)銷等來(lái)提升性能疾棵。而其他絕大多數(shù)設(shè)計(jì)戈钢，都是為了解決在列式存儲(chǔ)的基礎(chǔ)上支持隨機(jī)讀寫這樣一個(gè)目的而存在的。比如類Sql的元數(shù)據(jù)結(jié)構(gòu)是尔，是提高列式存儲(chǔ)效率的一個(gè)輔助手段殉了，唯一主鍵的設(shè)定也是配合列式存儲(chǔ)引入的定制策略，至于其他如Delta存儲(chǔ)拟枚，compaction策略等都是在這個(gè)設(shè)定下為了支持隨機(jī)讀寫薪铜，降低latency不確定性等引入的一些Tradeoff方案
官方測(cè)試結(jié)果上，如果是存粹的隨機(jī)讀寫恩溅，或者單行的檢索請(qǐng)求這類場(chǎng)景痕囱，由于這些Tradeoff的存在，HBASE的性能吞吐率是要優(yōu)于Kudu不少的（2倍到4倍）暴匠，kudu的優(yōu)勢(shì)還是在支持類SQL檢索這樣經(jīng)常需要進(jìn)行投影操作的批量順序檢索分析場(chǎng)合鞍恢。
目前kudu還處在Incubator階段，并且還沒(méi)有成熟的線上應(yīng)用（小米走在了前面，做了一些業(yè)務(wù)應(yīng)用的嘗試）帮掉，在數(shù)據(jù)安全弦悉，備份，系統(tǒng)健壯性等方面也還要打個(gè)問(wèn)號(hào)蟆炊，所以是否使用kudu稽莉，什么場(chǎng)合怒竿，什么時(shí)間點(diǎn)使用敬特，是個(gè)需要好好考量的問(wèn)題 ；）
