Apache Kudu 加速對頻繁更新數據的分析

今天解讀的內容是來自 Hadoop Summit San 2016 關於 Apache Kudu 的一個介紹：Apache Kudu & Apache Spark SQL for Fast Analystics on Fast Data（視頻見文章末尾）。歡迎關注微信公眾號：大數據技術峰會解讀（bigdata_summit），獲取更多的內容和大數據技術峰會視頻。

Apache Kudu 加速對頻繁更新數據的分析_騰訊視頻 https://v.qq.com/x/page/h03728qz2xm.html

Kudu Overview

上圖是 Hadoop 生態體系中，存儲引擎和應用場景的對應關係。

橫軸代表數據查詢分析的頻度（Pace of Analysis），依次為：

• 歸檔
• 基於靜態數據的掃描/分析（一次寫入多次讀取）
• 基於頻繁更新數據的快速分析
• 實時訪問/更新（OLTP）

縱軸代表的是數據的更新頻度（Pace of Data），依次為

• 只讀
• 追加（Append-Only）
• 頻繁更新
• 實時更新

我們知道，HDFS 特別適合歸檔和基於靜態數據的掃描/分析的場景（一次寫入多次讀取），也就是上圖中左下角的黃色區域，而HBase擅長實時高並發的讀寫應用，也就是右上角的藍色區域。但是對於需要在頻繁更新的數據之上做快速分析，也就是上圖中間的虛線區域，Hadoop社區卻一直沒有比較好的存儲層產品來滿足。Kudu正是出於填補這個空白而誕生的。

視頻中提到，Kudu的設計借鑒了Parque和HBase一些理念 / 思想。

Kudu產品的幾個要點：

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

Kudu 和 Spark 集成後，能帶來的好處：

• 帶來和 Parquet 相似的掃描性能，但卻不存在數據更新/插入的延遲，也就是說，對數據的實時更新/插入，對分析應用來說是即時可見的，無延遲。
• Spark對數據的過濾條件（基於判定的過濾條件，即 predicate）可以下推到 Kudu 這一存儲層，能提高數據讀取/掃描的性能
• 相對 Parque，基於主鍵索引的查詢，性能更高

Spark Datasource

這部分比較簡單，介紹Kudu與Spark集成的代碼片段。基本上就創建一個kuduDataFrame後，後續的操作就和普通的Spark DataFrame API沒什麼差別了

Quick Demo

Demo也比較簡單，有興趣大家可以自己看一下視頻（位置在視頻的 18分26秒），就是在 Spark Shell 中操作一個 kuduDataFrame

Use Cases

Kudu 最適合的場景包含這兩個特點：

• 同時有順序和隨機讀寫的場景
• 對數據更新的時效性要求比較高

這樣的場景有：

• 和時間序列相關的數據分析：對市場/銷售數據的實時分析；反欺詐；網路監控等
• 在線報表和數據倉庫應用：如ODS（Operational Data Store）

片中還介紹了小米使用Kudu的一個具體場景，需求是要收集手機App和後台服務發送的 RPC 跟蹤事件數據，然後構建一個服務監控和問題診斷的工具，要求：

• 高寫入吞吐：每天大於200億條記錄
• 為了能夠儘快定位和解決問題，要求系統能夠查詢最新的數據並能快速返回結果
• 為了方便問題診斷，要求系統能夠查詢/搜索明細數據（而不只是統計信息）

在沒有使用kudu之前，方案的架構如下圖所示。

這是典型的Lambda架構（存在兩套相對獨立的數據流水線：批處理和流處理），一部分源系統數據是通過Scribe（日誌聚合系統）把數據寫到HDFS，另一部分源系統數據（實時性要求較高的？）是直接寫入HBase，然後：

• 為了能支持互動式/實時的查詢，需要通過Hive/MR/Spark作業把這兩部分數據合併成 Parquet 格式存放在HDFS，通過 Impala 對外提供互動式查詢服務
• 線下分析的就直接通過運行 Hive/MR/Spark 作業來完成

我們可以看到，這樣的數據線比較長，帶來兩個問題：

• 其一是數據時效性較差（一個小時到一天）；
• 其二是需要多次數據轉換（如：HFile + seqfile ==> Parquet）

還有一個問題，存儲層中數據不是按照時間戳來排序，如果有部分數據沒有及時到達，那麼為了統計某一天的數據，可能就要讀取好幾天的數據才能得到。

使用了Kudu以後，方案的架構如下圖所示。

數據都存儲在Kudu中，分兩條線進入Kudu：

• 對於需要做加工（ETL）的數據或來自壓力較大的系統的數據（產生的數據較多，源系統無法長時間緩存）可以先進入Kafka緩存，然後通過Storm做實時的ETL後進入Kudu，這種情況的延時在 0~10秒的區間
• 反之，源系統的數據可以直接寫入 Kudu，這種情況數據沒有任何延遲

然後，一方面可以通過 Impala 對外提供互動式查詢服務（基於SQL），另一方面也可以直接通過 Kudu API 直接訪問數據

這樣的架構帶來的好處比較明顯，一方面是大大提高數據的時效性，另一方面大大簡化系統架構

PPT中還有一張 Kudu + Impala 的方案與 MPP 資料庫產品（如 Greenplum，Vertica 和 Teradata）進行對比，但是由於時間關係視頻中沒有講，這裡簡單提一下：

他們有存在相似之處：

• 提供基於SQL的互動式快速查詢/分析
• 能夠提供插入、更新和刪除操作

相對於 MPP 資料庫，Kudu + Impala 方案的優勢：

• 更快的流式數據插入（streaming insert）
• 和 Hadoop 生態體系有較好的集成：
  • 把 Kudu 和 HDFS 部署在同一個集群，可以關聯分別存儲在 Kudu 和 HDFS 上的表
  • 和 Spark，Flume等的集成度較好

相對於 MPP 資料庫，Kudu + Impala 方案的劣勢：

• 批量插入的性能相對較慢
• 不支持數據裝載的原子操作，不支持跨行的原子操作，不支持二級索引

Kudu Roadmap

相對 HDFS 和 HBase，Kudu還是一個比較新的項目，視頻介紹了產品路線圖的一些想法：

安全方面：

• 和 Kerberos 的集成
• 力度更細的許可權控制
• 基於組和角色的許可權管理
• ...

運維方面：

• 穩定性的增強
• 一些恢復工具
• 故障診斷輔助工具

性能和擴展性：

• 具體一些讀寫性能提升的想法
• 擴展性的提升（短期到400節點，長期上千節點）

客戶端方面：

• 目前支持Java、C++ 和 python，Python目前還是短板，有些功能還沒支持
• 文檔、教程和日誌等方面

推薦閱讀：