Hadoop新型數據庫Kudu應用經驗分享

kudu應用經驗分享

本文是小米工程師常冰琳於10月25日晚10點在「大數據產業聯合會」微信群中分享的內容，由hadoop123小編整理而成，供大家學習。

小米使用kudu的背景

小米大概在14年中開始和cloudera合作，作為kudu小白鼠用戶，幫cloudera在生產環境驗證kudu。kudu+Impala可以幫助我們解決實時數據的ad-hoc查詢需求。

在kudu之前，我們的大數據分析pipeline大概是有這幾種：
1. 數據源-> scribe打日志到HDFS -> MR/Hive/Spark -> HDFS Parquet -> Impala -> 結果service
這個數據流一般用來分析各種日志。

2. 數據源 -> 實時更新HBase/Mysql -> 每天批量導出Parquet-> Impala -> 結果serve
這個數據流一般用來分析狀態數據，也就是一般需要隨機更新的數據，比如用戶profile之類。

這兩條數據流主要由幾個問題：
1. 數據從生成到能夠被高效查詢的列存儲，整個數據流延遲比較大，一般是小時級別到一天；
2. 很多數據的日志到達時間和邏輯時間是不一致的，一般存在一些隨機延遲。

比如很多mobile app統計應用，這些tracing event發生後，很可能過一段時間才被後端tracing server收集到。
我們經常看到一些hive查詢，分析一天或者一小時的數據，但是要讀2-3天或者多個小時的日志，然後過濾出實際想要的記錄。
對於一些實時分析需求，有一些可以通過流處理來解決，不過他肯定沒用SQL方便，另外流式處理只能做固定的數據分析，對ad-hoc查詢無能為力
kudu的特點正好可以來配合impala搭建實時ad-hoc分析應用。

改進後的數據流大概是這個樣子：
1. 數據源 -> kafka -> ETL(Storm) -> kudu -> Impala
2. 數據源 -> kudu -> Impala
數據流1 主要是為需要進一步做ETL的應用使用的，另外kafka可以當做一個buffer，當寫吞吐有毛刺時，kafka可以做一個緩沖。

如果應用有嚴格的實時需求，就是只要數據源寫入就必須能夠查到，就需要使用數據流2。

引入kudu的目的

引入kudu主要是用來替換 HDFS+parquet的。

kudu的列存和parquet列存有什麼區別？

從功能上說，kudu的列存除了提供跟parquet接近的scan速度，還支持隨機讀寫。支持隨機寫，數據就可以實時灌入存儲中，達到實時查詢的效果；但是parquet文件只能批量寫，所以一般只能定期生成，所以增大了延遲。kudu的存儲類似hbase的lsm存儲。

為什麼說kudu的scan會比kylin快呢

kylin是存儲在hbase上的，kudu的scan為什麼比hbase快，簡單的說kudu是真正的列存儲，hbase只是列簇存儲。kudu是有schema的，每一列的數據是在文件中已數組的形式保存的，而hbase存儲在hfile裡面的還是sort好的(rowkey, column, timestamp, value)對，scan是開銷要多很多，具體需要看kudu的paper了，在這裡文字不好解釋。

storm 寫kudu的吞吐量能到多少，和storm寫hbase比呢

我們在71個節點的集群做了測試，隨機寫性能：隨機寫26億條記錄：每個節點大概4W 隨機寫性能。

大概的情況如下：
71 Node cluster
Hardware
CPU: E5-2620 2.1GHz * 24 core Memory: 64GB
Network: 1Gb Disk: 12 HDD
Software
Hadoop2.6/Impala 2.1/Kudu
3個大表，其中一個大表每天：
~2.6 Billion rows
~270 bytes/row
17 columns, 5 key columns
storm到kudu，按照每天26億數據來算，每秒大概30000條記錄吧。

這個是我們的應用挑出的6個查詢，做的查詢性能對比。同樣6個查詢，查詢parquet和查詢kudu做的對比。當時kudu的設計目標是接近parquet的scan性能，驚喜的是，目前kudu的scan性能在生產環境下有時還比parquet快一些。

像hbase有coprocessor，kudu有類似的計算功能嗎？

kudud。kudu有predicatepushdown，目前有impala使用時，scan時是把一些過濾提交給kudu去做的。

你們是想用kudu替換hbase還是一起搭配用？

感覺這兩個工具目前用來解決不同的問題，hbase還是用來做OLTP類存儲跟Mysql類似，kudu則用來升級我們現有的數據分析數據流，主要還是OLAP的workload。

Kudu支持隨機增加列嗎？

只要不是primarykey的列，是可以隨時增加的，而且不像mysql增加列時影響其他操作，kudu altertable是異步的，而且對性能影響不大。hbase是無schema的，所以可以成千上萬個列，kudu不行的，列的數量也不能過多。我們目前也就試過30多列的，一些300+列的表還沒有測試過。

Kudu目前有穩定版嗎

目前beta版本，不推薦現在在生產環境使用。

能否介紹一下小米使用kudu過程中踩過的坑？

目前踩的坑都還在開發階段，其實都不算什麼，而且從大方向上看，我們還是相信kudu這種方式對比之前的數據流優勢很明顯，對吞吐不是非常高的應用，這種方案是發展方向。其實我們在老的數據流上碰到很多問題，之前提到的數據延遲，數據無序，多個組件之間的兼容性，數據無schema導致灌入數據時缺少驗證，其實都希望引入kudu後能夠解決。

Kudu研發團隊目前多大？

cloudera kudu team目前7，8個全職做開發的。對代碼有貢獻的有十幾個吧，這個項目從12年就開始做了，一直保密。