伯克利開源Confluo：吞吐量比Kafka高4到10倍

作者 | ANURAG KHANDELWAL

編輯 | 薛命燈

伯克利 RISE 實驗室又有新動作，最近開源了一個多數據流實時分布式分析系統 Confluo。它可以作為網絡監控和診斷框架，也可以作為時序數據庫和發布訂閱消息系統。作為時序數據庫，它的性能比其他時序數據庫高出數倍，而作為發布消息訂閱系統，它的吞吐量比 Kafka 高出 4 到 10 倍。具體請見下文。

Confluo 是一個多數據流分析系統，可實現實時的分布式數據分析。Confluo 通過為多數據流的一些專門應用場景而精心設計的數據結構和針對端到端而優化的系統設計實現了高吞吐量並發寫入、毫秒級在線查詢和高效的即時查詢。

我們很高興將 Confluo 作為一個開源 C++ 項目，其中包括：

Confluo 的數據結構庫，支持高吞吐量日誌攝入，以及各種在線（實時聚合、條件觸發器執行等）和離線（即時過濾器、聚合等）的查詢；

Confluo 伺服器實現，封裝了數據結構，並提供 RPC 接口，以及 C++、Java 和 Python 客戶端庫。

我們針對幾種不同的應用場景對 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，例如，下面是一個帶有五個屬性的簡單模式示例：

為了加速即時離線查詢，可以為模式中的屬性添加索引。為了支持在線查詢，Confluo 還採用一種匹配操作語言，其中包含三個主要元素：過濾器、聚合和觸發器。

Confluo 過濾器是一種表達式，由任意有界寬度屬性和關係運算符及布爾運算符組成（參見下表），用於標識與表達式匹配的記錄。

Confluo 聚合（參見下表）用於計算與特定過濾器表達式相匹配的所有記錄的屬性的可計算函數。

Confluo 觸發器是基於 Confluo 聚合計算得到的布爾條件（例如 、= 等）。

Confluo 隻支持為模式中具有固定大小的屬性創建索引、過濾器、聚合和觸發器。在添加好這些東西後，在新的數據記錄到達時，它們都會被計算和更新。Confluo 目前不支持連接操作，因為在大多數監控和診斷應用程式中，這個操作並不常見。

實 現

Confluo 使用了一種新的數據結構作為數據流的基本存儲抽象：Atomic MultiLog，一組無鎖並發日誌，可用於存儲原始數據、聚合統計資訊和物化視圖，並使用新的技術將整個集合作為單個原子操作進行更新。Atomic MultiLog 利用上述的應用程式工作負載假設來實現高吞吐量數據攝取和豐富的在線和離線查詢。

Atomic MultiLogs 與數據庫表的接口有點類似。為了存儲來自不同流的數據，應用程式可以創建具有預定義模式的 Atomic MultiLog，並寫入符合模式的數據流。然後，應用程式在 Atomic MultiLog 上創建索引、過濾器、聚合和觸發器，為各種監控和診斷功能提供支持。

有關如何實現和使用 Confluo 的更多資訊，請查看相關文檔（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 存儲庫。