在Apache Kudu上對時間序列工作負載進行基準測試

• 2020 年 4 月 7 日
• 筆記

時間序列作為對快速數據的快速分析

自2015年開放源代碼發佈Apache Kudu以來，它自稱是用於對快速數據進行快速分析的存儲。其常規任務包含許多不同的工作負載，但是增長最快的用例之一是時間序列分析。時間序列有幾個關鍵要求：

• 高性能流式攝取– 時序工作負載越來越需要以高採樣率從成千上萬的數據源中攝取數據。存儲系統需要支持每秒插入數百萬條記錄，而無需昂貴的硬件投資。

• 攝取後可立即獲得數據 -有時最有價值的時間序列數據是最近幾秒內攝取的數據。等待批處理管道將數據提取到存儲系統中以獲取靜態數據（例如，公有雲塊存儲）不是一種選擇。

• 高性能掃描-吸收了數百萬或數十億個數據點後，通常有必要對它們進行匯總分析。例如，可以跨時間或跨實體計算匯總和匯總，並且可以構建機器學習模型以查找異常或預測未來行為。時間序列存儲需要支持在廉價的硬件配置上每秒檢索數十億個單元。在某些情況下，預聚合和下採樣可以減少此要求，但在其他情況下，則需要訪問粒度數據。

• 高性能、低延遲的隨機查找– 除了掃描大量數據外，在線操作案例（如儀錶板或實時監控）還需要能夠以非常低的延遲和高吞吐量獲取短期數據。例如，為給定實體獲取一小時的數據可能具有10ms的第95個百分位延遲SLA。

乍看起來，這些要求將需要專門為時間序列構建的專用數據庫系統。實際上，近年來湧現出了諸如InfluxDB 和VictoriaMetrics 之類的 系統來應對這一利基。像Kudu這樣的通用系統是否有可能與這些目標設計競爭？

在此博客文章中，我們將使用時間序列基準套件 （TSBS）將Kudu與其他三個存儲系統進行比較，該套件 是數據的開源集合和代表IT操作時間序列工作負載的查詢生成工具。

Kudu-TSDB體系結構

由於Kudu是沒有任何內置查詢語言的存儲系統，因此我開發了一個新的守護程序kudu-tsdbd 的原型 。該守護程序提供與InfluxDB的REST協議兼容的HTTP端點，並包括InfluxQL查詢語言子集的解析器和執行程序。這樣，TSBS對基準InfluxDB的支持可以重新用於基準基於Kudu的實現。

請注意，此體系結構增加了一個額外的「躍點」。每個查詢都將提交到時間序列守護程序，進行解析和計劃，然後轉換為一個或多個對存儲在基礎Kudu群集中的表的「掃描」調用。然後將所有基礎數據從Kudu傳輸回TSDB流程，以進行聚合和處理。儘管如此，如後續圖所示，與單片時間序列系統相比，Kudu提供了競爭性的且通常是優越的性能。

基準目標系統

這篇博客文章針對四個目標系統評估了TSBS基準：

• InfluxDB 1.7.10 – InfluxDB是由InfluxData開發的開源時間序列數據庫，用Go編寫。開源版本僅支持單節點操作，但群集版本可作為付費產品使用。

• VictoriaMetrics 1.34.2 – VictoriaMetrics是Prometheus的開源時間序列數據庫和長期遠程存儲。單節點和群集產品均可用。

• ClickHouse 20.1.6.30 – ClickHouse是一個開源的列式SQL數據庫。像Kudu一樣，它是常規數據存儲，不僅限於時間序列數據。

• Kudu-tsdbd – 以上時間序列後台駐留程序，冒充InfluxDB，在同一主機上的單節點Kudu群集上運行。如本文底部所述，經過測試的 Kudu 版本 包括一些優化，這些優化將在未來幾個月內合併到Apache Kudu中。

基準硬件

在此ClickHouse TSBS Benchmark 的示例之後，我們使用一個具有以下規範的EC2 r5.2xlarge節點：

• 8個vCPU

• 64G內存

• 200GB的預配置IOPS EBS（注意：此基準測試中的數據集足夠小，因此磁盤性能似乎不是重要因素）

• Ubuntu 18.04.1 LTS

該硬件的價格約為每天12美元。

TSBS客戶端以及目標系統都在同一主機上運行，從而消除了結果數據在網絡上的傳輸瓶頸。

基準設置

遵循與VictoriaMetrics 和ClickHouse 之前的博客文章中所使用的相同的基準設置，我們使用以下配置：

• 僅用於TSBS cpu的工作負載– 該工作負載來自InfluxData自己的 influx 比較 基準工具，用於Influx 與 Cassandra ，Influx 與 OpenTSDB 等比較 的系列數據庫。

• 比例因子4000（3天） –模擬4000主機，每10秒生成10個CPU指標。這導致數據集中總共有大約10億個數據點。

• 我們將運行所有受支持的查詢， 除非另有說明：

• lastpoint，groupby-orderby-limit – kudu-tsdbd或VictoriaMetrics不支持。由ClickHouse和Influx提供的非常低的性能支持。這些查詢難以有效支持，因為它們需要許多存儲引擎中未實現的反向掃描功能。

• high-cpu- * – VictoriaMetrics不支持，而kudu-tsdbd部分支持。Kudu-TSDB缺乏支持的原因是InfluxQL執行引擎中的一個小缺陷，而不是任何缺少的底層存儲引擎功能。

查詢分為兩類：

• 輕量查詢–在所有系統上，這些查詢的響應時間均在200毫秒或更短時間內，我們會同時測量吞吐量（QPS）以及第95和第99個百分位數的延遲，以此來衡量性能是否穩定。

• 繁重的查詢-這可能需要幾秒鐘的時間，並且會聚集大量數據，我們以每分鐘查詢（QPM）的吞吐量來衡量

這些工作負載都使用8個客戶端線程（等於CPU數量）和16個客戶端線程來運行。後一種配置在遇到過載情況時測試系統的健壯性。在第一篇文章中，我們將重點介紹「輕型」查詢。在後續文章中，我們將分析「大量」查詢的性能。

可以使用github 上的腳本 來複制所有基準測試結果。

結果：數據加載性能

這篇文章簡介中提到的要求之一是高性能加載。在這裡，我們繪製每個系統在數據加載期間每秒的指標數量：

在這裡，我們看到Kudu，ClickHouse和VictoriaMetrics大致可比，平均速率在370萬至390萬個指標/秒之間。InfluxDB明顯落後，平均每秒130萬個指標，因此加載測試數據集所需的時間大約是原來的3倍。此處的加載時間與ClickHouse 團隊的基準報告中 的加載時間非常相似 。

結果：輕量查詢，8個客戶端線程

在短期查詢的吞吐量方面，VictoriaMetrics令人印象深刻，特別是在最簡單的查詢（single-groupby-1-1-1）上，該查詢僅從單個主機上獲取單個指標一個小時（360點） 。在其他查詢中，Kudu在某些情況下會將其排除在外。在每種查詢類型中，Kudu的性能都優於ClickHouse，並且比InfluxDB快5-10倍。

對於輕量級查詢，查看百分位數也很有趣：單個儀錶板在完全呈現之前可能會運行成百上千個此類簡短查詢，因此呈現時間受這些高百分位數離群值支配。

在這張第99個百分位數的延遲圖中，較短的條形表示響應時間更快，我們看到Kudu和VictoriaMetrics再次在競爭中勝出一個數量級，在大多數情況下，Kudu處於領先地位，有時甚至有相當大的差距。

結果：輕量查詢，16個客戶端線程

在評估系統時，查看負載下系統性能如何下降也很有用。如果我們將客戶端數量增加一倍，那麼每個核心不再有一個客戶端，而是每個核心現在有兩個客戶端，那麼我們就不希望吞吐量增加一倍，但是我們也希望避免任何實質性的降級.InfluxDB的速度要慢5-10倍在每種情況下。

對於輕量級查詢，查看百分位數也很有趣：單個儀錶板在完全呈現之前可能會運行成百上千個此類簡短查詢，因此呈現時間受這些高百分位數離群值支配。下表顯示了這種情況下輕查詢的吞吐量：

在這裡，Kudu顯示了在8到16個客戶端之間的吞吐量方面的輕微改進。這是由於Kudu內的各種攤銷和批處理效果以及8客戶端級別的未充分利用。相反，在過載時，VictoriaMetrics的吞吐量顯着下降。在這種情況下，ClickHouse的吞吐量也略有下降。

在延遲方面，我們看到了相同的效果：Kudu的p99延遲仍然很低，而其他系統在過載時表現出明顯的降級：

繁重查詢的性能

基準測試中的「繁重」查詢將掃描數據集中的所有數據一天，計算出1、5或全部10列的時間窗匯總。這將導致掃描超過30M，150M或300M的單元以計算查詢結果。這些查詢顯示了大型掃描的相對性能，還可能與將數據導出到其他工作負載（例如機器學習或異常檢測）中的性能相關。

對於這些查詢，我們看到的結果參差不齊，除了一個常數，InfluxDB比數據包的其餘部分慢幾個數量級。隨着掃描大小從1列增加到10列，Kudu會比其他列領先。

注意：鑒於Kudu和Kudu-TSDB的體系結構，這些查詢在內核中花費了大部分CPU周期，將數據從Kudu平板電腦服務器進程傳輸到時間序列守護程序。未來優化此問題的努力（例如，通過允許有限的計算向下推入Kudu進程本身）將大大改善Kudu。

對於這些繁重的查詢，我們不再看到VictoriaMetrics的吞吐量大幅下降，但我們再次注意到Kudu的吞吐量提高了10-20％。

基準測試結果匯總

儘管Apache Kudu是通用存儲，但它專註於快速數據的快速分析，使其非常適合時間序列工作負載。總結基準測試結果：

• Kudu在數據加載性能方面與ClickHouse和VictoriaMetrics相當。這三個指標均大大優於InfluxDB。

• Kudu和VictoriaMetrics在短期查詢的吞吐量（QPS）方面優於ClickHouse和InfluxDB。在某些情況下，Kudu的吞吐量要比VictoriaMetrics高，而在其他情況下，VictoriaMetrics的性能要優於Kudu。

• 對於長期運行的查詢，隨着度量列數的增加，Kudu將提供優於其他存儲的性能，並且在任何查詢類型中都不會表現出明顯的優勢。

• 當客戶端線程的數量增加到核心數量的兩倍時，Kudu的性能將超過所有其他系統，從而在吞吐量和高百分位數的延遲方面均表現出穩定的性能。

定性差異

除了上面概述的數量差異之外，了解存儲之間的質量差異也很重要。特別是Kudu和ClickHouse具有通用存儲的特徵，而VictoriaMetrics和InfluxQL僅限於時間序列應用程序。實際上，這意味着Kudu和ClickHouse允許您將時間序列數據與倉庫中的其他關係數據一起進行分析，並可以使用其他工具（例如Apache Spark，Apache Impala，Apache Flink或Python Pandas）進行分析。

此外，Apache Kudu具有廣泛的企業級功能集，其中包括：

• 具有自動故障恢復，故障域識別和重新平衡功能，可擴展到數百個節點

• 安全控制，包括身份驗證，在線加密和授權

• 支持在blob存儲或HDFS上使用Apache Parquet進行備份和還原

Apache Kudu作為高價值數據倉庫和datamart用例存儲的背景也意味着它具有清晰而強大的語義。插入的數據立即可見，可見的數據持久，並且完全支持刪除和更新數據等操作。在此進行基準測試的其他系統有一定的驚喜。例如：

• 直到攝取後30秒，VictoriaMetrics才可以讀取數據。此外，它沒有預寫日誌，因此崩潰的服務器將丟失最近插入的數據。僅通過使用年故障率為0.1-0.2％的永久磁盤（例如EBS）才能進行複製。

• InfluxDB的更新和刪除功能受到限制。例如，不支持用 NULL 條目替換值，並且不支持 基於謂詞的更新和刪除。

Apache Kudu即將進行的改進

在準備此博客文章時，已確定並改進了Apache Kudu本身。以下新功能是在Kudu 的分支 中實現的，並反映在上述基準測試中：

• 列式數據傳輸– 列式數據傳輸格式使Kudu平板服務器可以返回掃描的行結果，與當前面向行的結果格式相比，其CPU消耗低得多。就其本身而言，這在我們支持的查詢中產生了1.13倍的幾何平均改進。

• SIMD-BP128編碼–針對整數數據開發了一種新的編碼，可實現更高的掃描速度和更好的壓縮效果。此編碼需要進一步開發以在所有情況下均具有魯棒性，但最終應取代Kudu使用的默認的整數編碼的bithuffle編碼。就其本身而言，這在我們支持的查詢中產生了1.88倍的幾何平均值改進。

• 當結合列式數據傳輸和BP128編碼時，平均改進為2.17倍。

這些改進是對Apache Kudu的master分支（從commit 1cb4a0ae3e開始）已經承諾的其他性能改進的基礎，這些性能改進比Kudu 1.11.1的幾何平均值提高了1.13倍。包括所有優化，相對於Apache Kudu 1.11.1，幾何平均性能提高了約2.5倍。

下圖說明了這些更改對性能的影響。每個條形圖表示使用8個客戶端線程進行測試時QPS的改進，已針對Kudu 1.11.1的性能進行了標準化。

我們希望在接下來的幾個月中開始將BP128和列式編碼改進併入Apache Kudu。

kudu-tsdbd的未來

就提供InfluxQL兼容性層的kudu-tsdbd守護程序而言，它目前僅是一個原型，不能用於一般用途。儘管與InfluxDB和其他系統相比，它的性能令人滿意，但目前缺少許多功能，例如各種聚合功能，對子查詢等更複雜查詢的支持等。根據社區的興趣，我們可能會繼續從原型製作成功能齊全的查詢層。如果您有興趣使用或幫助開發此類圖層，請聯繫Kudu 社區 。

原文鏈接：https://blog.cloudera.com/benchmarking-time-series-workloads-on-apache-kudu-using-tsbs/