伯克利 RISE Lab 開源 Confluo：吞吐量比 Kafka 高 4 到 10 倍
AI 前線導讀：
伯克利 RISE 實驗室又有新動作，最近開源了一個多資料流實時分散式分析系統 Confluo。它可以作為網路監控和診斷框架，也可以作為時序資料庫和釋出訂閱訊息系統。作為時序資料庫，它的效能比其他時序資料庫高出數倍，而作為釋出訊息訂閱系統，它的吞吐量比 Kafka 高出 4 到 10 倍。具體請見下文。
更多幹貨內容請關注微信公眾號“AI 前線”（ID：ai-front）
Confluo 是一個多資料流分析系統，可實現實時的分散式資料分析。Confluo 通過為多資料流的一些專門應用場景而精心設計的資料結構和針對端到端而優化的系統設計實現了高吞吐量併發寫入、毫秒級線上查詢和高效的即時查詢。
我們很高興將 Confluo 作為一個開源 C++ 專案，其中包括：
-
Confluo 的資料結構庫，支援高吞吐量日誌攝入，以及各種線上（實時聚合、條件觸發器執行等）和離線（即時過濾器、聚合等）的查詢；
我們針對幾種不同的應用場景對 Confluo 進行了評估，包括：
-
作為一個網路監控和診斷框架，Confluo 能夠在單個核心上以線路速率（10Gbps 鏈路）執行數千個觸發器和數十個過濾器。
-
作為一個時間序列資料庫，與其他先進的時序資料庫相比（如 CorfuDB、TimescaleDB 和 BTrDB），Confluo 的吞吐量提高了 2 之 20 倍，寫入延遲降低了 2 至 10 倍，吞吐量提高了 1.5 至 5 倍，時間區間查詢延遲降低了 5 至 20 倍。
-
作為一個 pub-sub 系統，Confluo 在釋出訂閱吞吐量方面是 Apache Kafka 的 4 至 10 倍。
Confluo 概覽
很多現代應用程式，例如基於終端主機的網路監控、物聯網和數字家庭一體化以及資料中心運營服務，它們的每臺伺服器每秒種都會捕獲到數千萬個數據點。這些資料被用於線上查詢，實現視覺化和監控，或者用於離線查詢，進行故障分析和系統優化。要實現這些應用程式，需要一個實時監控和分析工具，能夠支援高吞吐量資料攝取、低延遲的線上查詢和低開銷的離線查詢。
雖然現在已有的資料結構可以支援高吞吐量資料攝取和豐富的線上和離線查詢，但到目前為止，這兩種資料結構仍然是互斥的。在從多個數據流攝取資料時，上述的查詢需要更新多個數據結構——原始資料、聚合統計資訊和物化檢視。遺憾的是，用於支援這些查詢的資料結構往往具有較高的更新開銷，而且無法維持大多數應用程式所需的資料攝取速率。另一方面，可以維持高資料攝取速率的資料結構往往只支援非常簡單的查詢。
為了應對這一挑戰，我們構建了 Confluo，一個同時實現了高吞吐量資料攝取和豐富的離線和線上查詢的系統。
假設
Confluo 通過利用其目標應用程式語義來簡化底層系統的假設，從而實現上述的目標。Confluo 的主要簡化假設是：
-
應用程式資料流表現出一次性寫入語義（即資料是追加寫入的）；
-
監控和診斷應用程式使用固定大小的屬性（例如，網路資料包中固定寬度的標頭，分散式感測器網路中的 64 位時間戳和溫度讀數，資料中心操作指標中的浮點精度 CPU 和記憶體統計資訊等）；
-
應用程式不需要事務性語義來進行併發操作，原子性語義就足夠了。
Confluo API
Confluo 操作資料流，資料流由記錄組成，記錄使用了包含強型別屬性集合的預定義模式（schema）。如上所述，Confluo 目前只支援固定大小的屬性，包括原始資料型別，如二進位制、整數或浮點數，或特定於域的型別，如 IP 地址、埠、感測器讀數等。
Confluo 的模式是強型別屬性的集合，語義類似於 JSON，例如，下面是一個帶有五個屬性的簡單模式示例：
複製程式碼
{
timestamp: LONG,
op_latency_ms: DOUBLE,
cpu_util: DOUBLE,
mem_avail: DOUBLE,
log_msg:STRING(100)
}
目前，Confluo 只支援具有固定模式的資料流，即資料流中的記錄必須符合給定的模式。
為了加速即時離線查詢，可以為模式中的屬性新增索引。為了支援線上查詢，Confluo 還採用一種匹配操作語言，其中包含三個主要元素：過濾器、聚合和觸發器。
Confluo 過濾器是一種表示式，由任意有界寬度屬性和關係運算符及布林運算子組成（參見下表），用於標識與表示式匹配的記錄。
Confluo 聚合（參見下表）用於計算與特定過濾器表示式相匹配的所有記錄的屬性的可計算函式。
Confluo 觸發器是基於 Confluo 聚合計算得到的布林條件（例如 <、>、= 等）。
Confluo 只支援為模式中具有固定大小的屬性建立索引、過濾器、聚合和觸發器。在新增好這些東西后，在新的資料記錄到達時，它們都會被計算和更新。Confluo 目前不支援連線操作，因為在大多數監控和診斷應用程式中，這個操作並不常見。
實現
Confluo 使用了一種新的資料結構作為資料流的基本儲存抽象：Atomic MultiLog，一組無鎖併發日誌，可用於儲存原始資料、聚合統計資訊和物化檢視，並使用新的技術將整個集合作為單個原子操作進行更新。Atomic MultiLog 利用上述的應用程式工作負載假設來實現高吞吐量資料攝取和豐富的線上和離線查詢。
Atomic MultiLogs 與資料庫表的介面有點類似。為了儲存來自不同流的資料，應用程式可以建立具有預定義模式的 Atomic MultiLog，並寫入符合模式的資料流。然後，應用程式在 Atomic MultiLog 上建立索引、過濾器、聚合和觸發器，為各種監控和診斷功能提供支援。
有關如何實現和使用 Confluo 的更多資訊，請檢視相關文件（ ofollow,noindex">https://ucbrise.github.io/confluo/ ）。
效能
我們針對各種應用程式對 Confluo 進行了評估，包括網路監控和診斷、時間序列資料庫和 pub-sub 訊息系統。上圖顯示了 Confluo 在時間序列資料庫應用程式中的效能表現，並將其與執行在配備了 18 個 CPU 核心和 60GB RAM 的 EC2 c4.8xlarge 例項上的 BTrDB、CorfuDB 和 TimescaleDB 進行了比較。我們使用了開放式 uPMU 資料集 的 5 億個記錄子集，這個資料集包含了安裝在電網中的多個μPMU 的電壓、電流和相位的讀數，為期三個月。
我們發現，像 CorfuDB 和 TimescaleDB 這樣的系統的效能比 BTrDB 和 Confluo 低 10 倍。但請注意，這不算是個缺點：CorfuDB 和 TimescaleDB 支援比 BTrDB 和 Confluo 更強的（事務性）語義。因此，根據所需語義的不同，任何一類系統對底層應用程式來說都可能是有用的。總而言之，與最先進的時間序列資料庫相比，Confluo 的寫入速度提高了 2 至 20 倍，寫入延遲降低了 2 至 10 倍，時間區間過濾器的吞吐量提高了 1.5 至 5 倍，延遲降低了 5 至 20 倍。
網路監控和診斷工具的比較結果可以在我們即將釋出的 NSDI 論文 中找到，而 pub-sub 系統的比較結果可以在 這裡 找到。
限制
如前所述，Confluo 做了一些簡化的假設，從而能夠有效地實現各種線上和離線查詢，同時支援每臺伺服器攝取數千萬個數據點。因此，Confluo 只支援具有固定寬度的資料屬性。此外，Confluo 目前只支援具有嚴格模式的流，不過我們也正在努力支援更靈活的模式。
展望未來
我們正在開發另外幾個有趣的專案，以便讓 Confluo 更具表現力並進一步提升效率。包括支援使用草圖對資料流進行近似查詢，支援基於資料流的 SQL 介面，以及通過檔案合併和記憶體池來提高效能。要了解有關 Confluo 的更多資訊，請訪問我們的專案網站和 GitHub/">GitHub 儲存庫。
原文連結：
https://rise.cs.berkeley.edu/blog/confluo-millisecond-level-queries-on-large-scale-streaming-data/