如何評價kudu存儲引擎？

01-21

據說Cloudera秘密開發了3年，兼顧數據更新實時性和分析速度的存儲引擎，目前和impala配合的比較不錯。國內目前小米在用這個東西。
http://getkudu.io

只說下我了解的部分，如有錯誤歡迎指出……

Kudu最初由Cloudera開發，但現在已經開始作為Apache的項目孵化。Kudu - ASF JIRA

定位是OLAP資料庫，說白了就是可以隨機讀但主要是針對順序讀做優化。所以在小米也是計算組搞而非存儲組。數據的模型個人覺得很像Cassandra的偽SQL——結構化的數據、SQL類似的語法但本質上還是NoSQL，可以設定是Hash還是range或者兩者結合來做partition分配到若干個tablet，每個tablet用raft協議寫在多個節點上。之前掃了眼論文似乎是沒寫如何做tablet的split/merge，也許現在還不支持也許我看漏了。

從資料庫的角度講，比較重要的兩個點是C++和raft。

C++的性能比較有保障，還沒有gc的停頓導致的.99響應時間不可控等問題，raft的心跳也因為沒有gc可以設的敏感一些，可用性更好，而這些都是HBase的痛點。當然這是題外話，畢竟Kudu不是用來代替HBase的。

用raft協議搞replication意味著不需要比較蛋疼的HDFS了，表面上似乎還在說Kudu屬於「Hadoop生態系統」，但我覺得他們的心思肯定不止於此。而且Raft的一致性也比較自由，追求性能可以最終一致性地讀。

此外可以看下Apache Kudu as a More Flexible And Reliable Kafka-style Queue ，這篇文章說，因為他順序讀吞吐比較好，並且raft協議自身提供了遞增id，所以可以用來代替kafka搞消息隊列，簡單測試性能差不多（「in the same realm」），還沒GC。而且因為是資料庫，可以隨機寫，相當於可以修改隊列，靈活很多。

讀過 paper 和代碼，在生產環境中使用過，來答一波。

先說性能。對比 Hive，性能高了一個數量級，原本需要數分鐘的查詢，用 Kudu 可能只需要數秒；做過 TPC-DS benchmark，結果還不錯，不過有一部分 query 計算時間太長，沒有完成；對於隨機寫入來說，性能相當贊，SDD 硬碟，寫入 ops 能到 100W 左右，幾乎不需要特別的 bulk load 支持了。

再說 feature。支持數據更新，這是 Hive 的一大痛點，使用 Hive 通常來說會用 Sqoop 定期導入數據，一來，定期導入數據意味著會有延遲，數小時到數天，對於實時查詢來說這點就很難接受，二來，定期導入對線上資料庫也會有一定壓力。而 Kudu 直接支持數據更新，意味著可以實時同步線上數據，可以實時查詢到線上數據，對於數據驅動的增長來說，這無疑是很好的消息。

Kudu 作為一個存儲引擎，提供的 API 其實跟 HBase 很像，增刪改以及 scan 的介面。在上層，可以用 Impala 查詢，Kudu 能提供 locality 信息以及謂詞下推；也可以使用其他的 SQL on Hadoop 進行查詢，SparkSQL 之類的，能很好地融入 Hadoop 生態。

所以 Kudu 的特點正如它的 slogan 所說，Fast Analytics on Fast Data。如果你需要對實時數據做查詢，如果需要快速地查詢，那麼 Kudu 無疑是一個好的選擇。

至於實現，未完待續。

我司 tangliu 同學的一篇文章可以看看 Kudu：一個融合低延遲寫入和高性能分析的存儲系統

沒有數據分析流式計算的經驗，根據對kv存儲系統的理解，簡單答一發，輕拍。。

數據存儲的選擇上，HBASE和HADOOP在吞吐率、延遲上各有側重，如果做數據分析，要從HBase導出到hadoop平台再用Hive查詢，這就要求系統要混布HBASE和hadoop。

KADU的目標就是要兼顧前兩個存儲系統，實現對外數據的存儲和後台計算的本地化，減少數據傳輸成本已經部署運維成本。

架構方面，還是延用BIGTABLE的基本架構，元數據和數據分開存儲的，但做了一些比較有挑戰的優化操作，提升查詢和插入的性能

另外的亮點是，多副本間使用了raft保證數據的高可靠性。

性能方面，目前beta版本要略差與HBASE,這也是意料之中的事情。。。

可以參考我們團隊技術博客有關Kudu以及Impala的文章：

Kudu+Impala介紹 | 微店數據科學團隊博客

Kudu的Schema表結構設計 | 微店數據科學團隊博客

kudu和計算框架結合之後，在大數據集上的操作，可以提供接近關係型資料庫的使用體驗

Kudu產品的幾個要點：

數據模型和關係資料庫類似，為結構化的表；列的數量有限（和HBase/Cassandra相比較而言）
內部數據組織方式為列式存儲
很好的橫向擴展能力，目前測試的是275個節點（3PB），計劃支持到上千個節點(幾十PB)
不錯的性能，集群能達到百萬級別的TPS，單節點吞吐為幾個GB/s
本身不提供SQL介面，只支持類似NoSQL的介面，如 Insert(), Update(), Delete() and Scan() 等
通過與 Spark 和 Impala 等（Drill，Hive的支持還在進行中）的集成，對外提供基於 SQL 的查詢分析服務

關於小米如何使用Kudu，這裡有更詳細的介紹：Apache Kudu 加速對頻繁更新數據的分析 - 知乎專欄

首先是一個分散式的列式存儲，大家都說到了主要是用於分析計算的存儲系統。但是也是可以用於存的存儲系統。kudu是一個現代的列式存儲系統，需要最新的硬體支持，充分發揮現在高性能硬體和cpu指令集。在存儲方面做了很多性能優化，數據一致性和容災主要還是靠raft。

1：支持增、刪、改

2：一套存儲，即支持較快速查詢(對標HBase)，也支持較快速分析(對標impala)。而不必像之前，想查詢，用HBase得一套存儲，相分析，用impala得一套存儲

一個項目負責人來公司做過seminar，是HBase那幫人搞的，出發點是把數據分析放進存儲里，這樣達到一個在某些query的優化。本來如果做數據分析，要從HBase導出到hadoop平台再用Hive查詢，太慢了，而且是offline的。搞Kudu就是要弄成結構化數據，支持online直接修改數據，支持加index，Kudu目前支持Dremel語句，用C++寫的。Performance是和Hive和另一個什麼比較的，用的是一些大型的benchmark，結果表明在某些方面比較有優勢，具體忘了。

對，他在slides最後還提到小米了，好像是和小米合作開發的。Kudu幾個月前開源了，看文檔和源代碼應該更準確吧。