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

點擊hadoop123Hadoop新型數據庫Kudu應用經驗分享關注我喲

最知名的hadoop/spark大數據技術分享基地,分享hadoop/spark技術內幕hadoop/spark最新技術進展hadoop/spark行業技術應用發布hadoop/spark相關職位和求職信息hadoop/spark技術交流聚會講座以及會議等。


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條記錄吧。

Hadoop新型數據庫Kudu應用經驗分享
這個是我們的應用挑出的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年就開始做了,一直保密。


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

閱讀原文


關於作者:
最知名的Hadoop/Spark/Docker大數據技術基地,分享Hadoop技術內幕,Hadoop最新技術進展,發布Hadoop相關職位和求職信息,Hadoop技術交流聚會、講座以及會議等。

微信號:hadoop-123