Apache Kudu 讀後感

kudu[1]是apache下一個新開源産品，其介紹

        a new addition to the open source apache hadoop ecosystem, apache kudu (incubating) completes hadoop's storage layer to enable fast analytics on fast data.

        其目标是很快的分析資料，在多處的介紹裡面也看到其希望彌補hdfs和hbase之間的gap，前者是重離線批量，後者中線上随機，今天看了下kudu的論文[2]，記錄感想。

        其在文章開始說如果使用者想完成資料線上寫入，然後又要分析，沒有一個獨立的軟體能夠完成（關系資料庫就沒提了，其實有些寫入能力還是可以的，比如tokudb），常見的架構是寫入hbase然後導入到hdfs分析，或者寫入kafka，然後分别分入hbase和hdfs進行分析，作者認為這種架構有如下不足：

        1. 複雜：這不用講了，幾個大家夥一起肯定不是那麼好搞懂的；

        2. 安全：猜測作者主要意思是資料在各個元件間流動，那麼如果有一款元件安全性做的不好，就有導緻資料洩露的風險；

        3. 一緻性：上面方案中的資料同步機制一般都是通過異步隊列進行的，存在一定的延時性，是以資料源和資料目标之間會有一部分資料不一緻；

        4. 時效性：跟一緻性是類似問題，因為是異步隊列或者定期拉資料，那麼就不能實時的分析此類的資料。

        是以他們就要做一款完整解決上面問題的産品了，kudu大羚羊誕生。

        kudu從整體看是列存儲，就是列資料之間是分開存儲的，這樣掃描的時候如果隻需要掃描部分列就會比較快（大塊掃描場景）；

        kudu是強schema的，這樣系統就有了更多的資訊，可以進行更好的編碼壓縮，比如bitvector之類的，都是傳統資料庫早就發明的；

        kudu支援range和hash兩種方式對資料進行分片，這是個使用者友好的選擇，技術方案上差别不大；

        kudu沒有使用類似hdfs的共享存儲，而是自己管理磁盤，這當然利于做将事情做到極緻且利于快速推進，不過自己管理磁盤，資料複制也不是那麼容易的。

        kudu支援基于raft協定提高可用性，支援動态增加、減少replica個數。這個好了解，反正存儲都自己做了，一個完全的垂直産品，搞raft是天經地義，mysql兄弟們啥時候推出來這個？

        kudu支援mvcc做事務控制，不過事務這一段寫的太模糊，寫了靠token機制，也寫了靠類似spanner的commit-wait（根本上來說，同步隻有兩種，一種是消息，就是給你打個電話告訴你點事情；一種基于一個共同的時間，比如約定7點開戰，commit wait是後一種），不知道到底要幹嘛。

        文中看到了一個東西叫做fractured mirrors（很早别人提的）, 這個想法實在妙，三份replica的底層存儲引擎可以不同，比如replica a更好的支援随機讀，replica b更好的支援批量讀，這樣就可以在不同的場景中充分的利用各個replica的能力，在産品架構上，分層和垂直的設計半斤八兩不分上下。

        kudu對pk做了唯一性限制，也就是每次寫會檢查是否存在，是在引擎層做的，這似乎不是個很好的設計，做的太硬了。

        kudu也要做compaction來移除無效資料，或者整理資料以便優化讀，這裡其将資料檔案切小，再加上很好的優先級控制和一些啟發式算法，對各個replica的時機也做控制，那麼還是能做到盡量少的影響業務。

        整體而言，kudu似乎想做一個集合oltp/olap的東西，線上寫入，高可用，可選的一緻性，即時快速的掃描分析，好嘛。大一統的産品能不能做成要打個問号，不過我個人倒覺得如果沿着這條路，mysql類似的産品們希望更大。

[1] kudu: http://getkudu.io/

[2] kudu 論文：http://getkudu.io/kudu.pdf