譯者 | 陳峻

審校 | 重樓

如今，對于使用批處理工作流程的數據團隊而言，要滿足業務的實時要求并非易事。從數據的交付、處理到分析，整個批處理工作流往往需要大量的等待，其中包括：等待數據被發送到ETL工具處，等待數據被批量處理，等待數據被加載到數據倉庫，甚至需要等待查詢的完成。

不過，開源世界已對此有了解決方案：通過Apache Kafka、Flink和Druid的協同使用，我們可創建一個實時數據架構，以消除上述等待狀態。如下圖所示，該數據架構可以在從事件到分析、再到應用的整個數據工作流程中，無縫地提供數據的新鮮度、擴展性和可靠性。

目前，Lyft、Pinterest、Reddit和Paytm等知名公司，都在同時使用這三種由互補的數據流原生技術構建的應用，來共同處理各種實時用例。

用于實時應用的開源數據架構

上圖展現的架構能夠使得構建可觀察性、物聯網與遙測分析、安全檢測與診斷、面向客戶的洞察力、以及個性化推薦等實時應用，變得簡單且易于實現。下面，我們將和您探討此類工具的各個組成部分，以及它們將如何被結合起來實現廣泛的實時應用。

流管道：Apache Kafka

過去，RabbitMQ、ActiveMQ、以及其他被用來提供各種消息傳遞模式的消息隊列系統，雖然可以將數據從生產者分發到消費者處，但是其可擴展性十分有限。而隨著Apache Kafka的出現，以及被80%的財富100強企業所使用，它已成為了流式數據的實際標準。其根本原因在于，Kafka架構遠不止簡單的消息傳遞，其多功能性使之非常適合在大規模的互聯網上進行數據流傳輸。而其容錯性和數據一致性，則可以支持各類關鍵性任務應用。同時，由Kafka Connect提供的各種連接器，也可與任何數據源相集成。

作為實時數據流平臺的Apache Kafka

流處理：Apache Flink

Kafka雖然能夠提供實時數據，但是用戶在需要兼顧實時效率和擴展性時，往往會選擇Apache Flink。作為一個高吞吐量且統一的數據流批處理引擎，Flink的獨特優勢在于能夠大規模處理連續的數據流。而作為Kafka的流處理器，Flink可以無縫地集成并支持精確的一次性語義（exactly-once semantics）。也就是說，即使在系統出現故障時，它也能保證每個事件被精確地處理一次。

具體而言，它會連接到Kafka主題，定義查詢邏輯，然后連續輸出結果，正所謂“設置好就不用管它（set it and forget it）”。這使得Flink非常適用于對數據流的即時處理和可靠性要求較高的應用案例。以下是Flink的兩個常見用例：

填充與轉換

如果數據流在使用之前需要進行諸如：修改、增強或重組數據等操作，那么Flink是對此類數據流進行操作的理想引擎。它可以通過持續處理，來保持數據的新鮮度。例如，假設我們有一個安裝在智能建筑中的、溫度傳感器的、物聯網遙測用例。其每一個被捕獲的Kafka事件，都具有以下JSON結構：

{ "sensor_id"："SensorA," "temperature"：22.5, "timestamp"：“2023-07-10T10:00:00”}

如果每個傳感器的ID都需要映射到一個位置，而且溫度需要以華氏度為單位的話，那么Flink可以將JSON結構更新為：

{ “sensor_id”: “SensorA,” “location”: “Room 101”, “temperature_Fahreinheit”: 73.4, “timestamp”: “2023-07-10T10:00:00” }

并且將其直接發送到應用程序，或直接發回Kafka。

Flink數據處理的結構化表格示例

持續監控和警報

通過將Flink的實時持續處理和容錯功能相結合，我們可以為各種關鍵性應用的實時檢測和響應需求，設計出理想的解決方案。例如：當需要具備高檢測靈敏度（如：亞秒級）和高采樣率時，Flink的持續處理功能就非常適合作為數據服務層，被用于監控條件，觸發警報，進而采取相應的行動。

Flink在警報方面的優勢主要體現在：它既能夠支持無狀態警報，也可以支持有狀態警報。例如：像“溫度達到X時，通知消防隊”這樣的閾值或事件觸發條件雖然簡單，但不夠智能。在一些真實的使用案例中，警報需要由能夠保持狀態的復雜模式驅動，甚至需要在持續的數據流中匯總各項指標（如：總量、平均值、最小值、最大值、以及計數等），而Flink則可以監控和更新狀態，以及時發現偏差和異常。

值得注意的是，使用Flink進行監控和警報時，往往需要持續使用系統CPU來根據閾值和模式評估條件。這與只在執行查詢時，才用到CPU的數據庫有所不同。因此，您需要最好事先了解待開發的應用是否需要持續使用CPU。

實時分析：Apache Druid

總的說來，Apache Druid完善了數據架構，能夠與Kafka和Flink一起成為支持實時分析的數據流消費者。雖然它是一個被用于分析的數據庫，但是其設計中心和用途與其他數據庫、以及數據倉庫有較大的不同。

首先，由于Druid是數據流原生的，因此，Druid和Kafka之間不需要連接器，它可以直接連接到Kafka主題，并且支持精確的一次性語義。同時，Druid也被設計為用于大規模地快速捕獲流數據，并在事件到達時，立即在內存中進行查詢。

Druid如何與Kafka原生集成，以實現數據流捕獲

在查詢方面，Druid是一種高性能的實時分析數據庫，可以在大規模和負載條件下，提供亞秒級的查詢。它非常適用于那些對性能極其敏感，并且需要處理從TB到PB的數據（例如：聚合、過濾、GroupBy、以及復雜連接等）和高查詢體量的用例。Druid不但能夠持續提供快如閃電的查詢，而且可以輕松從一臺筆記本電腦擴展為由1000個節點組成的集群。這就是Druid被稱為實時分析數據庫的原因。以下是Druid與Flink的互補用例：

高度交互式查詢

工程團隊可以使用Druid支持包括：各種內部（即運營）和外部（即面向客戶）涉及到可觀察性、安全性、產品分析、物聯網與遙測、制造運營等數據密集型分析應用。其核心特點包括：

1. 大規模性能：應用程序需要在不進行預計算的情況下，對大型數據集進行亞秒級讀取、查詢和分析。即使用戶以TB甚至PB的規模，對大量隨機查詢進行任意分組、過濾、切片、以及切割，Druid都能提供不俗的性能。
2. 高查詢量：能夠針對具有較高QPS（每秒查詢率）要求的分析查詢應用，例如：任何面向外部的數據產品應用，都需要為產生100到1000次不同的并發查詢的工作負載，提供亞秒級SLA。
3. 時間序列數據：由于采用了時間分區和數據格式的應用需求，Druid可以非常快速地、大規模處理時序數據，進而提出洞見。這使得基于時間的WHERE過濾器的速度極快。

這些應用要么具有交互性很強的數據可視化、以及合成結果集的用戶界面，并得益于Druid的快速，能夠非常靈活地即時更改查詢；要么在很多情況下，它們利用Druid的應用程序接口（API）來提高查詢速度，從而為決策工作流提供依據。

下圖展示的是一個由Apache Druid支持的分析應用示例。

圖片來源：Confluent的Confluent Health+儀表板

眾所周知，由Apache Kafka原創的Confluent，可以通過Confluent Health+為客戶提供分析服務。上圖中的應用具有高度交互性。通常，事件會以每秒500萬次的速度流向Kafka和Druid，該應用通過提供350 QPS的服務，來深入洞察客戶的Confluent環境。

實時歷史數據

Druid與實時數據架構的關聯之處在于，它可以提供實時數據與歷史數據相結合的交互式數據體驗，從而提供更豐富的語境。

如果說Flink擅長回答“現在發生著什么（即發出Flink任務的當前狀態）”的話，那么Druid則在技術上能夠回答“現在發生的與之前相比有何不同，哪些因素或條件對結果產生了影響”?；卮疬@些問題將有助于消除誤報，協助檢測新的趨勢，進而做出更有洞見的實時決策。

要回答“與以前相比情況如何？”的疑問，我們往往需要以過去的某一天、一周、一年或其他時間跨度，來進行相關性分析。而要回答“哪些因素或條件影響了結果”，我們則需要挖掘完整的數據集。由于Druid是一個能夠實時分析的數據庫，因此它可以捕獲可供實時洞察的數據流，同時它也會持久性地保存數據，以便隨時查詢多維度的歷史信息。

Druid 的查詢引擎如何處理實時和歷史數據

假設我們正在構建一個用于監控登錄可疑行為的應用程序，那么我們可能希望在五分鐘的時間窗口內設置一個閾值--更新并發布登錄嘗試的狀態。憑借Druid，當前的登錄嘗試可以與歷史數據相關聯，以識別過去未發生、但的確被利用過的登錄安全漏洞。據此，歷史背景將有助于確定當前的登錄反復嘗試是否屬于正常行為。

此外，如果您的應用程序需要接收大型批處理文件，且對瞬息萬變的事件進行大量分析（如：當前狀態、各種聚合、分組、時間窗口、以及復雜連接等），同時還要提供歷史背景，并通過高度靈活的應用程序接口來檢索數據集，那么這些都是Druid的優勢所在。

選擇Flink和Druid的檢查表

可見，Flink和Druid都是為流數據而構建的。雖然它們有著一些高層次的相似之處，例如：都屬于內存內部（in-memory）、都能擴展、都能并行，但是正如前文所述，它們的架構實際上是為完全不同的用例而構建的。下面，我為您整理了一份簡單的、基于工作量來判斷該如何選擇的檢查表：

1. 您是否需要對流式數據進行實時轉換或連接？

• Flink就是這樣一款專為實時數據處理而設計的服務。

2. 您需要同時支持許多不同的查詢嗎？

• Druid可以支持高QPS分析，而無需管理各種查詢和任務。

3. 事件相關指標是否需要持續更新或匯總？

• Flink支持有狀態的復雜事件處理。

4. 分析是否更加復雜，是否需要與歷史數據進行比較？

• Druid可以方便快捷地查詢實時數據和歷史數據。

5. 您是否正在為面向用戶的應用程序提供數據可視化？

• 可先使用Flink予以填充，然后將數據發送到作為數據服務層的Druid。

總的說來，在大多數情況下，您的選擇不會是“非Druid即Flink”，而是“既Druid又Flink”。它們各自的技術特性使得兩者能夠共同支持各種實時應用。

小結

隨著企業對于數據實時性的要求越來越高，數據團隊需要重新考慮端到端的數據工作流程。這就是為什么許多公司已將Kafka+Flink+Druid作為構建實時應用的開源數據架構的原因。

譯者介紹

陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。

原文標題：Building a Real-Time Data Architecture With Apache Kafka, Flink, and Druid ，作者：David Wang