kudu應用經驗分享mysql
本文是小米工程師常冰琳於10月25日晚10點在「大數據產業聯合會」微信羣中分享的內容，由hadoop123小編整理而成，供你們學習。sql
小米使用kudu的背景後端
小米大概在14年中開始和cloudera合做，做爲kudu小白鼠用戶，幫cloudera在生產環境驗證kudu。kudu+Impala能夠幫助咱們解決實時數據的ad-hoc查詢需求。數組
在kudu以前，咱們的大數據分析pipeline大概是有這幾種：微信
1. 數據源-> scribe打日誌到HDFS -> MR/Hive/Spark -> HDFS Parquet -> Impala -> 結果serviceapp
這個數據流通常用來分析各類日誌。異步
2. 數據源 -> 實時更新HBase/Mysql -> 天天批量導出Parquet-> Impala -> 結果serve工具
這個數據流通常用來分析狀態數據，也就是通常須要隨機更新的數據，好比用戶profile之類。oop
這兩條數據流主要由幾個問題：性能
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後可以解決。
