每一種引擎有其優勢的地方，如何選擇適合自己業務的流計算引擎成了一個由來已久的話題。除了比較各個引擎提供的不同的功能矩陣之外，性能是一個無法繞開的評估因素。基準測試（benchmark）就是用來評估系統性能的一個重要和常見的過程。
01 背景
隨着數據時效性對企業的精細化運營越來越重要，“實時即未來”、“實時數倉”、“數據湖” 成爲了近幾年炙手可熱的詞。流計算領域的格局也在這幾年發生了巨大的變化，Apache Flink 在流批一體的方向上不斷深耕，Apache Spark 的近實時處理有着一定的受衆，Apache Kafka 也有了 ksqlDB 高調地進軍流計算，而 Apache Storm 卻開始逐漸地退出歷史的舞臺。
每一種引擎有其優勢的地方，如何選擇適合自己業務的流計算引擎成了一個由來已久的話題。除了比較各個引擎提供的不同的功能矩陣之外，性能是一個無法繞開的評估因素。基準測試（benchmark）就是用來評估系統性能的一個重要和常見的過程。
本文將探討流計算基準測試設計上的難點，以及我們是如何設計 Nexmark 這個流計算基準測試框架的，以及將來的規劃。最後會回顧審視我們對基準測試的一些看法。
02 現有流計算基準測試的問題
目前在流計算領域中，還沒有一個行業標準的基準測試。目前業界較爲人知的流計算 benchmark 是五年前雅虎 Storm 團隊發佈的 Yahoo Streaming Benchmarks：https://github.com/yahoo/streaming-benchmarks。雅虎的原意是因爲業界缺少反映真實場景的 benchmark，模擬了一個簡單的廣告場景來比較各個流計算框架，後來被廣泛引用。具體場景是從 Kafka 消費的廣告的點擊流，關聯 Redis 中的廣告所屬的 campaign 信息，然後做時間窗口聚合計數。
然而，正是因爲雅虎團隊太過於追求還原真實的生產環境，導致這些外部系統服務（Kafka, Redis）成爲了作業的瓶頸。Ververica 曾在這篇文章中做過一個擴展實驗，將數據源從 Kafka 替換成了一個內置的 datagen source，性能提升了 37 倍！ 由此可見，引入的 Kafka 組件導致了無法準確反映引擎真實的性能。更重要的一個問題是，Yahoo Benchmark 只包含一個非常簡單的，類似 “Word Count” 的作業，它無法全面地反映當今複雜的流計算系統和業務。試想，誰會用一個簡單的 “Word Count” 去衡量比較各個數據庫之間的性能差異呢？正是這些原因使得 Yahoo Benchmark 無法成爲 一個行業標準的基準測試。這也正是我們想要解決的問題。
因此，我們認爲一個行業標準的基準測試應該具備以下幾個特點：
1. 可復現性。
可復現性是使得 benchmark 被信任的一個重要條件。許多 benchmark 的結果是難以重現的。有的是因爲只擺了個 benchmark 結果圖，用於生成這些結果的代碼並沒有公開。有的是因爲用於 benchmark 的硬件不容易被別人獲取到。有的是因爲 benchmark 依賴的服務太多，致使測試結果不穩定。
2. 能調整作業的負載（數據量、數據分佈）
例如數據庫領域非常著名的 TPC-H、TPC-DS 涵蓋了大量的 query 集合，來捕獲查詢引擎之間細微的差別。而且這些 query 集合都立於真實業務場景之上（商品零售行業），數據規模大，因此也很受一些大數據系統的青睞。
3. 能調整作業的負載。即數據量、數據分佈。
在大數據領域，不同的數據規模對於引擎來說可能會是完全不同的事情。例如 Yahoo Benchmark 中使用的 campaign id 只有 100 個，使得狀態非常小，內存都可以裝的下。這樣使得同步 IO 和 checkpoint 等的影響可以忽略不計。而真實的場景往往要面對大狀態，面臨的挑戰要複雜困難的多。像 TPC-DS 的數據生成工具會提供 scalar factor 的參數來控制數據量。其次在數據分佈上最好也能貼近真實世界的數據，如有數據傾斜，及調整傾斜比例。從而能全面、綜合地反映業務場景和引擎之間地差異。
4. 有統一的性能衡量指標和採集彙總工具。
基準測試的性能指標的定義需要清晰、一致，且能適用於各種計算引擎。然而流計算的性能指標要比傳統批處理的更難定義、更難採集。是流計算 benchmark 最具挑戰性的一個問題，這也會在下文展開描述。
我們也研究了很多其他的流計算相關的基準測試，包括：StreamBench、HiBench、BigDataBench，但是它們都在上述幾個基本面有所欠缺。基準測試的行業標杆無疑是 TPC 發佈的一系列 benchmark，如 TPC-H，TPC-DS。然而這些 benchmark 是面向傳統數據庫、傳統數倉而設計的，並不適用於今天的流計算系統。例如 benchmark 中沒有考慮事件時間、數據的亂序、窗口等流計算中常見的場景。因此我們不得不考慮重新設計並開源一個流計算基準測試框架，Nexmark: https://github.com/nexmark/nexmark。
03 Nexmark 基準測試框架的設計
爲了提供一個滿足以上幾個基本面的流計算基準測試，我們設計和開發了 Nexmark 基準測試框架，並努力讓其成爲流計算領域的標準 benchmark 。
Nexmark 基準測試框架來源於 NEXMark 研究論文，以及 Apache Beam Nexmark Suite，並在其之上進行了擴展和完善。Nexmark 基準測試框架不依賴任何第三方服務，只需要部署好引擎和 Nexmark，通過腳本 nexmark/bin/run_query.sh all 即可等待並獲得所有 query 下的 benchmark 結果。下面我們將探討 Nexmark 基準測試在設計上的一些決策。
移除外部 source、sink 依賴
如上所述，Yahoo Benchmark 使用了 Kafka 數據源，卻使得最終結果無法準確反映引擎的真實性能。此外，我們還發現，在 benchmark 快慢流雙流 JOIN 的場景時，如果使用了 Kafka 數據源，慢流會超前消費（快流易被反壓），導致 JOIN 節點的狀態會緩存大量超前的數據。這其實不能反映真實的場景，因爲在真實的場景下，慢流是無法被超前消費的（數據還未產生）。所以我們在 Nexmark 中使用了 datagen source，數據直接在內存中生成，數據不落地，直接向下遊節點發送。多個事件流都由單一的數據生成器生成，所以當快流被反壓時，也能抑制慢流的生成，較好地反映了真實場景。
與之類似的，我們也移除了外部 sink 的依賴，不再輸出到 Kafka/Redis，而是輸出到一個空 sink 中，即 sink 會丟棄收到的所有數據。
通過這種方式，我們保證了瓶頸只會在引擎自身，從而能精確地測量出引擎之間細微的差異。
Metrics
批處理系統 benchmark 的 metric 通常採用總體耗時來衡量。然而流計算系統處理的數據是源源不斷的，無法統計 query 耗時。因此，我們提出三個主要的 metric：吞吐、延遲、CPU。Nexmark 測試框架會自動幫我們採集 metric，並做彙總，不需要部署任何第三方的 metric 服務。
吞吐：
吞吐（throughput）也常被稱作 TPS，描述流計算系統每秒能處理多少條數據。由於我們有多個事件流，所有事件流都由一個數據生成器生成，爲了統一觀測角度，我們採用數據生成器的 TPS，而非單一事件流的 TPS。我們將一個 query 能達到的最大吞吐，作爲其吞吐指標。例如，針對 Flink 引擎，我們通過 Flink REST API 暴露的 <source_operator_name>.numRecordsOutPerSecond metric 來獲取當前吞吐量。
延遲：
延遲（Latency）描述了從數據進入流計算系統，到它的結果被輸出的時間間隔。對於窗口聚合，Yahoo Benchmark 中使用 output_system_time - window_end 作爲延遲指標，這其實並沒有考慮數據在窗口輸出前的等待時間，這種計算結果也會極大地受到反壓的影響，所以其計算結果是不準確的。一種更準確的計算方式應爲 output_system_time - max(ingest_time)。 然而在非窗口聚合，或雙流 JOIN 中，延遲又會有不同的計算方式。
所以延遲的定義和採集在流計算系統中有很多現實存在的問題，需要根據具體 query 具體分析，這在[參考文獻[2]](https://arxiv.org/pdf/1802.08496.pdf)中有詳細的討論，這也是我們目前還未在 Nexmark 中實現延遲 metric 的原因。
CPU：
資源使用率是很多流計算 benchmark 中忽視的一個指標。由於在真實生產環境，我們並不會限制流計算引擎所能使用的核數，從而給系統更大的彈性。所以我們引入了 CPU 使用率，作爲輔助指標，即作業一共消耗了多少核。通過 吞吐/cores，可以計算出平均每個覈對於吞吐的貢獻。對於進程的 CPU 使用率的採集，我們沒有使用 JVM CPU load，而是借鑑了 YARN 中的實現，通過採樣 /proc/<pid>/stat 並計算獲得，該方式可以獲得較爲真實的進程 CPU 使用率。因此我們的 Nexmark 測試框架需要在測試開始前，先在每臺機器上部署 CPU 採集進程。
Query 與 Schema
Nexmark 的業務模型基於一個真實的在線拍賣系統。所有的 query 都基於相同的三個數據流，三個數據流會有一個數據生成器生成，來控制他們之間的比例、數據偏斜、關聯關係等等。這三個數據流分別是：
- 用戶（Person）：代表一個提交拍賣，或參與競標的用戶。
- 拍賣（Auction）：代表一個拍賣品。
- 競標（Bid）： 代表一個對拍賣品的出價。
我們一共定義了 16 個 query，所有的 query 都使用 ANSI SQL 標準語法。基於 SQL ，我們可以更容易地擴展 query 測試集，支持更多的引擎。然而，由於 Spark 在流計算功能上的限制，大部分的 query 都無法通過 Structured Streaming 來實現。因此我們目前只支持測試 Flink SQL 引擎。
| Query | 標題 | 簡介 | Flink |
|---|---|---|---|
| q0 | Pass Through | 測量空跑時的開銷，包括監控和數據生成器的開銷。 | ✅ |
| q1 | Currency Conversion | 將每個競標價格從美元轉換爲歐元。 | ✅ |
| q2 | Selection | 過濾出滿足條件的競標記錄。 | ✅ |
| q3 | Local Item Suggestion | 來自指定城市的用戶的拍賣品。展示了雙流 JOIN。 | ✅ |
| q4 | Average Price for a Category | 求出在每個分類下，獲勝競標的平均價格。 | ✅ |
| q5 | Hot Items | 在過去一段時間，哪些拍賣品收到了最多的競標？ | ✅ |
| q6 | Average Selling Price by Seller | 每個賣家過去10個成功售出的拍賣品的平均價格是多少？ | FLINK-19059 |
| q7 | Highest Bid | 過去一段時間出價最高的競標，及其競標價格。 | ✅ |
| q8 | Monitor New Users | 過去一段時間新進入系統並創建拍賣的用戶。 | ✅ |
| q9 | Winning Bids | 計算每個拍賣品的獲勝競標記錄。 | ✅ |
| q10 | Log to File System | 將所有事件記錄到文件系統。展示了將數據流按窗口寫入分區文件。 | ✅ |
| q11 | User Sessions | 每個用戶在每個活躍週期中進行了多少次出價？展示了 session window。 | ✅ |
| q12 | Processing Time Windows | 每個用戶在固定的處理時間窗口中進行了多少次出價？展示了 processing time window。 | ✅ |
| q13 | Bounded Side Input Join | 競標流與一個靜態白名單關聯，展示了基礎的維表關聯。 | ✅ |
| q14 | Calculation | 爲競標流轉化和生成更多的字段。展示了更復雜的映射、過濾、UDF 的使用。 | ✅ |
| q15 | Bidding Statistics Report | 每天有多少不同的用戶參與了不同等級的拍賣中？展示了多 count distinct 的應用。 | ✅ |
作業負載的配置化
我們也支持配置調整作業的負載，包括數據生成器的吞吐量以及吞吐曲線、各個數據流之間的數據量比例、每個數據流的數據平均大小以及數據傾斜比例等等。具體的可以參考 Source DDL 參數。
04 實驗結果
我們在阿里雲的三臺機器上進行了 Nexmark 針對 Flink 的基準測試。每臺機器均爲 ecs.i2g.2xlarge 規格，配有 Xeon 2.5 GHz CPU (8 vCores) 以及 32 GB 內存，800 GB SSD 本地磁盤。機器之間的帶寬爲 2 Gbps。
測試了 flink-1.11 版本，我們在這 3 臺機器上部署了 Flink standalone 集羣，由 1 個 JobManager，8 個 TaskManager （每個只有 1 slot）組成，都是 4 GB內存。集羣默認並行度爲 8。開啓 checkpoint 以及 exactly once 模式，checkpoint 間隔 3 分鐘。使用 RocksDB 狀態後端。測試發現，對於有狀態的 query，每次 checkpoint 的大小在 GB 級以上，所以有效地測試的大狀態的場景。
Datagen source 保持 1000 萬每秒的速率生成數據，三個數據流的數據比例分別是 Bid: 92%，Auction: 6%，Person: 2%。每個 query 都先運行 3 分鐘熱身，之後 3 分鐘採集性能指標。
運行 nexmark/bin/run_query.sh all 後，打印測試結果如下：
+-------------------+-------------------+-------------------+-------------------+
| Nexmark Query | Throughput (r/s) | Cores | Throughput/Cores |
+-------------------+-------------------+-------------------+-------------------+
|q0 |1.9 M |8.17 |235 K |
|q1 |1.8 M |8.17 |228 K |
|q2 |2.1 M |8.16 |258 K |
|q3 |1.9 M |9.66 |198 K |
|q4 |305 K |11.55 |26 K |
|q5 |311 K |11.71 |26 K |
|q7 |153 K |12.14 |12 K |
|q8 |1.8 M |13.65 |135 K |
|q9 |170 K |11.86 |14 K |
|q10 |633 K |8.23 |76 K |
|q11 |428 K |10.5 |40 K |
|q12 |937 K |12.35 |75 K |
|q13 |1.4 M |8.26 |179 K |
|q14 |1.8 M |8.28 |228 K |
|q15 |729 K |9.06 |80 K |
+-------------------+-------------------+-------------------+-------------------+05 總結
我們開發和設計 Nexmark 的初衷是爲了推出一套標準的流計算 benchmark 測試集，以及測試流程。雖然目前僅支持了 Flink 引擎，但在當前也具有一定的意義，例如：
- 推動流計算 benchmark 的發展和標準化。
- 作爲 Flink 引擎版本迭代之間的性能測試工具，甚至是日常回歸工具，及時發現性能回退的問題。
- 在開發 Flink 性能優化的功能時，可以用來驗證性能優化的效果。
- 部分公司可能會有 Flink 的內部版本，可以用作內部版本與開源版本之間的性能對比工具。
當然，我們也計劃持續改進和完善 Nexmark 測試框架，例如支持 Latency metric，支持更多的引擎，如 Spark Structured Streaming, Spark Streaming, ksqlDB, Flink DataStream 等等。也歡迎有志之士一起加入貢獻和擴展。
06 參考文獻
[1] Pete Tucker and Kristin Tufte. "NEXMark – A Benchmark for Queries over Data Streams". June 2010.
[2] Jeyhun Karimov and Tilmann Rabl. "Benchmarking Distributed Stream Data Processing Systems". arXiv:1802.08496v2 [cs.DB] Jun 2019
[3] Yangjun Wang. "Stream Processing Systems Benchmark: StreamBench". May 2016.