譯者 | 陳峻

審校 | 重樓

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

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

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

用于實時應(yīng)用的開源數(shù)據(jù)架構(gòu)

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

流管道：Apache Kafka

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

作為實時數(shù)據(jù)流平臺的Apache Kafka

流處理：Apache Flink

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

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

填充與轉(zhuǎn)換

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

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

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

{ “sensor_id”: “SensorA,” “l(fā)ocation”: “Room 101”, “temperature_Fahreinheit”: 73.4, “timestamp”: “2023-07-10T10:00:00” }

并且將其直接發(fā)送到應(yīng)用程序，或直接發(fā)回Kafka。

Flink數(shù)據(jù)處理的結(jié)構(gòu)化表格示例

持續(xù)監(jiān)控和警報

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

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

值得注意的是，使用Flink進(jìn)行監(jiān)控和警報時，往往需要持續(xù)使用系統(tǒng)CPU來根據(jù)閾值和模式評估條件。這與只在執(zhí)行查詢時，才用到CPU的數(shù)據(jù)庫有所不同。因此，您需要最好事先了解待開發(fā)的應(yīng)用是否需要持續(xù)使用CPU。

實時分析：Apache Druid

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

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

Druid如何與Kafka原生集成，以實現(xiàn)數(shù)據(jù)流捕獲

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

高度交互式查詢

工程團(tuán)隊可以使用Druid支持包括：各種內(nèi)部（即運營）和外部（即面向客戶）涉及到可觀察性、安全性、產(chǎn)品分析、物聯(lián)網(wǎng)與遙測、制造運營等數(shù)據(jù)密集型分析應(yīng)用。其核心特點包括：

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

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

下圖展示的是一個由Apache Druid支持的分析應(yīng)用示例。

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

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

實時歷史數(shù)據(jù)

Druid與實時數(shù)據(jù)架構(gòu)的關(guān)聯(lián)之處在于，它可以提供實時數(shù)據(jù)與歷史數(shù)據(jù)相結(jié)合的交互式數(shù)據(jù)體驗，從而提供更豐富的語境。

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

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

Druid 的查詢引擎如何處理實時和歷史數(shù)據(jù)

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

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

選擇Flink和Druid的檢查表

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

1. 您是否需要對流式數(shù)據(jù)進(jìn)行實時轉(zhuǎn)換或連接？

• Flink就是這樣一款專為實時數(shù)據(jù)處理而設(shè)計的服務(wù)。

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

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

3. 事件相關(guān)指標(biāo)是否需要持續(xù)更新或匯總？

• Flink支持有狀態(tài)的復(fù)雜事件處理。

4. 分析是否更加復(fù)雜，是否需要與歷史數(shù)據(jù)進(jìn)行比較？

• Druid可以方便快捷地查詢實時數(shù)據(jù)和歷史數(shù)據(jù)。

5. 您是否正在為面向用戶的應(yīng)用程序提供數(shù)據(jù)可視化？

• 可先使用Flink予以填充，然后將數(shù)據(jù)發(fā)送到作為數(shù)據(jù)服務(wù)層的Druid。

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

小結(jié)

隨著企業(yè)對于數(shù)據(jù)實時性的要求越來越高，數(shù)據(jù)團(tuán)隊需要重新考慮端到端的數(shù)據(jù)工作流程。這就是為什么許多公司已將Kafka+Flink+Druid作為構(gòu)建實時應(yīng)用的開源數(shù)據(jù)架構(gòu)的原因。

譯者介紹

陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗。

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