譯者 | 陳峻
審校 | 重樓
如今，對于使用批處理工作流程的數(shù)據(jù)團(tuán)隊(duì)而言，要滿足業(yè)務(wù)的實(shí)時(shí)要求并非易事。從數(shù)據(jù)的交付、處理到分析，整個(gè)批處理工作流往往需要大量的等待，其中包括：等待數(shù)據(jù)被發(fā)送到ETL工具處，等待數(shù)據(jù)被批量處理，等待數(shù)據(jù)被加載到數(shù)據(jù)倉庫，甚至需要等待查詢的完成。
不過，開源世界已對此有了解決方案：通過Apache Kafka、Flink和Druid的協(xié)同使用，我們可創(chuàng)建一個(gè)實(shí)時(shí)數(shù)據(jù)架構(gòu)，以消除上述等待狀態(tài)。如下圖所示，該數(shù)據(jù)架構(gòu)可以在從事件到分析、再到應(yīng)用的整個(gè)數(shù)據(jù)工作流程中，無縫地提供數(shù)據(jù)的新鮮度、擴(kuò)展性和可靠性。
目前，Lyft、Pinterest、Reddit和Paytm等知名公司，都在同時(shí)使用這三種由互補(bǔ)的數(shù)據(jù)流原生技術(shù)構(gòu)建的應(yīng)用，來共同處理各種實(shí)時(shí)用例。
用于實(shí)時(shí)應(yīng)用的開源數(shù)據(jù)架構(gòu)
上圖展現(xiàn)的架構(gòu)能夠使得構(gòu)建可觀察性、物聯(lián)網(wǎng)與遙測分析、安全檢測與診斷、面向客戶的洞察力、以及個(gè)性化推薦等實(shí)時(shí)應(yīng)用，變得簡單且易于實(shí)現(xiàn)。下面，我們將和您探討此類工具的各個(gè)組成部分，以及它們將如何被結(jié)合起來實(shí)現(xiàn)廣泛的實(shí)時(shí)應(yīng)用。
流管道：Apache Kafka
過去，RabbitMQ、ActiveMQ、以及其他被用來提供各種消息傳遞模式的消息隊(duì)列系統(tǒng)，雖然可以將數(shù)據(jù)從生產(chǎn)者分發(fā)到消費(fèi)者處，但是其可擴(kuò)展性十分有限。而隨著Apache Kafka的出現(xiàn)，以及被80%的財(cái)富100強(qiáng)企業(yè)所使用，它已成為了流式數(shù)據(jù)的實(shí)際標(biāo)準(zhǔn)。其根本原因在于，Kafka架構(gòu)遠(yuǎn)不止簡單的消息傳遞，其多功能性使之非常適合在大規(guī)模的互聯(lián)網(wǎng)上進(jìn)行數(shù)據(jù)流傳輸。而其容錯(cuò)性和數(shù)據(jù)一致性，則可以支持各類關(guān)鍵性任務(wù)應(yīng)用。同時(shí)，由Kafka Connect提供的各種連接器，也可與任何數(shù)據(jù)源相集成。
作為實(shí)時(shí)數(shù)據(jù)流平臺(tái)的Apache Kafka
流處理：Apache Flink
Kafka雖然能夠提供實(shí)時(shí)數(shù)據(jù)，但是用戶在需要兼顧實(shí)時(shí)效率和擴(kuò)展性時(shí)，往往會(huì)選擇Apache Flink。作為一個(gè)高吞吐量且統(tǒng)一的數(shù)據(jù)流批處理引擎，F(xiàn)link的獨(dú)特優(yōu)勢在于能夠大規(guī)模處理連續(xù)的數(shù)據(jù)流。而作為Kafka的流處理器，F(xiàn)link可以無縫地集成并支持精確的一次性語義（exactly-once semantics）。也就是說，即使在系統(tǒng)出現(xiàn)故障時(shí)，它也能保證每個(gè)事件被精確地處理一次。
具體而言，它會(huì)連接到Kafka主題，定義查詢邏輯，然后連續(xù)輸出結(jié)果，正所謂“設(shè)置好就不用管它（set it and forget it）”。這使得Flink非常適用于對數(shù)據(jù)流的即時(shí)處理和可靠性要求較高的應(yīng)用案例。以下是Flink的兩個(gè)常見用例：
填充與轉(zhuǎn)換
如果數(shù)據(jù)流在使用之前需要進(jìn)行諸如：修改、增強(qiáng)或重組數(shù)據(jù)等操作，那么Flink是對此類數(shù)據(jù)流進(jìn)行操作的理想引擎。它可以通過持續(xù)處理，來保持?jǐn)?shù)據(jù)的新鮮度。例如，假設(shè)我們有一個(gè)安裝在智能建筑中的、溫度傳感器的、物聯(lián)網(wǎng)遙測用例。其每一個(gè)被捕獲的Kafka事件，都具有以下JSON結(jié)構(gòu)：
{ "sensor_id"："SensorA," "temperature"：22.5, "timestamp"：“2023-07-10T10:00:00”}
- 1.
如果每個(gè)傳感器的ID都需要映射到一個(gè)位置，而且溫度需要以華氏度為單位的話，那么Flink可以將JSON結(jié)構(gòu)更新為：
{ “sensor_id”: “SensorA,” “location”: “Room 101”, “temperature_Fahreinheit”: 73.4, “timestamp”: “2023-07-10T10:00:00” }
- 1.
并且將其直接發(fā)送到應(yīng)用程序，或直接發(fā)回Kafka。
Flink數(shù)據(jù)處理的結(jié)構(gòu)化表格示例
持續(xù)監(jiān)控和警報(bào)
通過將Flink的實(shí)時(shí)持續(xù)處理和容錯(cuò)功能相結(jié)合，我們可以為各種關(guān)鍵性應(yīng)用的實(shí)時(shí)檢測和響應(yīng)需求，設(shè)計(jì)出理想的解決方案。例如：當(dāng)需要具備高檢測靈敏度（如：亞秒級）和高采樣率時(shí)，F(xiàn)link的持續(xù)處理功能就非常適合作為數(shù)據(jù)服務(wù)層，被用于監(jiān)控條件，觸發(fā)警報(bào)，進(jìn)而采取相應(yīng)的行動(dòng)。
Flink在警報(bào)方面的優(yōu)勢主要體現(xiàn)在：它既能夠支持無狀態(tài)警報(bào)，也可以支持有狀態(tài)警報(bào)。例如：像“溫度達(dá)到X時(shí)，通知消防隊(duì)”這樣的閾值或事件觸發(fā)條件雖然簡單，但不夠智能。在一些真實(shí)的使用案例中，警報(bào)需要由能夠保持狀態(tài)的復(fù)雜模式驅(qū)動(dòng)，甚至需要在持續(xù)的數(shù)據(jù)流中匯總各項(xiàng)指標(biāo)（如：總量、平均值、最小值、最大值、以及計(jì)數(shù)等），而Flink則可以監(jiān)控和更新狀態(tài)，以及時(shí)發(fā)現(xiàn)偏差和異常。
值得注意的是，使用Flink進(jìn)行監(jiān)控和警報(bào)時(shí)，往往需要持續(xù)使用系統(tǒng)CPU來根據(jù)閾值和模式評估條件。這與只在執(zhí)行查詢時(shí)，才用到CPU的數(shù)據(jù)庫有所不同。因此，您需要最好事先了解待開發(fā)的應(yīng)用是否需要持續(xù)使用CPU。
實(shí)時(shí)分析：Apache Druid
總的說來，Apache Druid完善了數(shù)據(jù)架構(gòu)，能夠與Kafka和Flink一起成為支持實(shí)時(shí)分析的數(shù)據(jù)流消費(fèi)者。雖然它是一個(gè)被用于分析的數(shù)據(jù)庫，但是其設(shè)計(jì)中心和用途與其他數(shù)據(jù)庫、以及數(shù)據(jù)倉庫有較大的不同。
首先，由于Druid是數(shù)據(jù)流原生的，因此，Druid和Kafka之間不需要連接器，它可以直接連接到Kafka主題，并且支持精確的一次性語義。同時(shí)，Druid也被設(shè)計(jì)為用于大規(guī)模地快速捕獲流數(shù)據(jù)，并在事件到達(dá)時(shí)，立即在內(nèi)存中進(jìn)行查詢。
Druid如何與Kafka原生集成，以實(shí)現(xiàn)數(shù)據(jù)流捕獲
在查詢方面，Druid是一種高性能的實(shí)時(shí)分析數(shù)據(jù)庫，可以在大規(guī)模和負(fù)載條件下，提供亞秒級的查詢。它非常適用于那些對性能極其敏感，并且需要處理從TB到PB的數(shù)據(jù)（例如：聚合、過濾、GroupBy、以及復(fù)雜連接等）和高查詢體量的用例。Druid不但能夠持續(xù)提供快如閃電的查詢，而且可以輕松從一臺(tái)筆記本電腦擴(kuò)展為由1000個(gè)節(jié)點(diǎn)組成的集群。這就是Druid被稱為實(shí)時(shí)分析數(shù)據(jù)庫的原因。以下是Druid與Flink的互補(bǔ)用例：
高度交互式查詢
工程團(tuán)隊(duì)可以使用Druid支持包括：各種內(nèi)部（即運(yùn)營）和外部（即面向客戶）涉及到可觀察性、安全性、產(chǎn)品分析、物聯(lián)網(wǎng)與遙測、制造運(yùn)營等數(shù)據(jù)密集型分析應(yīng)用。其核心特點(diǎn)包括：
- 大規(guī)模性能：應(yīng)用程序需要在不進(jìn)行預(yù)計(jì)算的情況下，對大型數(shù)據(jù)集進(jìn)行亞秒級讀取、查詢和分析。即使用戶以TB甚至PB的規(guī)模，對大量隨機(jī)查詢進(jìn)行任意分組、過濾、切片、以及切割，Druid都能提供不俗的性能。
- 高查詢量：能夠針對具有較高QPS（每秒查詢率）要求的分析查詢應(yīng)用，例如：任何面向外部的數(shù)據(jù)產(chǎn)品應(yīng)用，都需要為產(chǎn)生100到1000次不同的并發(fā)查詢的工作負(fù)載，提供亞秒級SLA。
- 時(shí)間序列數(shù)據(jù)：由于采用了時(shí)間分區(qū)和數(shù)據(jù)格式的應(yīng)用需求，Druid可以非?？焖俚亍⒋笠?guī)模處理時(shí)序數(shù)據(jù)，進(jìn)而提出洞見。這使得基于時(shí)間的WHERE過濾器的速度極快。
這些應(yīng)用要么具有交互性很強(qiáng)的數(shù)據(jù)可視化、以及合成結(jié)果集的用戶界面，并得益于Druid的快速，能夠非常靈活地即時(shí)更改查詢；要么在很多情況下，它們利用Druid的應(yīng)用程序接口（API）來提高查詢速度，從而為決策工作流提供依據(jù)。
下圖展示的是一個(gè)由Apache Druid支持的分析應(yīng)用示例。
圖片來源：Confluent的Confluent Health+儀表板
眾所周知，由Apache Kafka原創(chuàng)的Confluent，可以通過Confluent Health+為客戶提供分析服務(wù)。上圖中的應(yīng)用具有高度交互性。通常，事件會(huì)以每秒500萬次的速度流向Kafka和Druid，該應(yīng)用通過提供350 QPS的服務(wù)，來深入洞察客戶的Confluent環(huán)境。
實(shí)時(shí)歷史數(shù)據(jù)
Druid與實(shí)時(shí)數(shù)據(jù)架構(gòu)的關(guān)聯(lián)之處在于，它可以提供實(shí)時(shí)數(shù)據(jù)與歷史數(shù)據(jù)相結(jié)合的交互式數(shù)據(jù)體驗(yàn)，從而提供更豐富的語境。
如果說Flink擅長回答“現(xiàn)在發(fā)生著什么（即發(fā)出Flink任務(wù)的當(dāng)前狀態(tài)）”的話，那么Druid則在技術(shù)上能夠回答“現(xiàn)在發(fā)生的與之前相比有何不同，哪些因素或條件對結(jié)果產(chǎn)生了影響”?；卮疬@些問題將有助于消除誤報(bào)，協(xié)助檢測新的趨勢，進(jìn)而做出更有洞見的實(shí)時(shí)決策。
要回答“與以前相比情況如何？”的疑問，我們往往需要以過去的某一天、一周、一年或其他時(shí)間跨度，來進(jìn)行相關(guān)性分析。而要回答“哪些因素或條件影響了結(jié)果”，我們則需要挖掘完整的數(shù)據(jù)集。由于Druid是一個(gè)能夠?qū)崟r(shí)分析的數(shù)據(jù)庫，因此它可以捕獲可供實(shí)時(shí)洞察的數(shù)據(jù)流，同時(shí)它也會(huì)持久性地保存數(shù)據(jù)，以便隨時(shí)查詢多維度的歷史信息。
Druid 的查詢引擎如何處理實(shí)時(shí)和歷史數(shù)據(jù)
假設(shè)我們正在構(gòu)建一個(gè)用于監(jiān)控登錄可疑行為的應(yīng)用程序，那么我們可能希望在五分鐘的時(shí)間窗口內(nèi)設(shè)置一個(gè)閾值--更新并發(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)、各種聚合、分組、時(shí)間窗口、以及復(fù)雜連接等），同時(shí)還要提供歷史背景，并通過高度靈活的應(yīng)用程序接口來檢索數(shù)據(jù)集，那么這些都是Druid的優(yōu)勢所在。
選擇Flink和Druid的檢查表
可見，F(xiàn)link和Druid都是為流數(shù)據(jù)而構(gòu)建的。雖然它們有著一些高層次的相似之處，例如：都屬于內(nèi)存內(nèi)部（in-memory）、都能擴(kuò)展、都能并行，但是正如前文所述，它們的架構(gòu)實(shí)際上是為完全不同的用例而構(gòu)建的。下面，我為您整理了一份簡單的、基于工作量來判斷該如何選擇的檢查表：
- 您是否需要對流式數(shù)據(jù)進(jìn)行實(shí)時(shí)轉(zhuǎn)換或連接？
- Flink就是這樣一款專為實(shí)時(shí)數(shù)據(jù)處理而設(shè)計(jì)的服務(wù)。
- 您需要同時(shí)支持許多不同的查詢嗎？
- Druid可以支持高QPS分析，而無需管理各種查詢和任務(wù)。
- 事件相關(guān)指標(biāo)是否需要持續(xù)更新或匯總？
- Flink支持有狀態(tài)的復(fù)雜事件處理。
- 分析是否更加復(fù)雜，是否需要與歷史數(shù)據(jù)進(jìn)行比較？
- Druid可以方便快捷地查詢實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)。
- 您是否正在為面向用戶的應(yīng)用程序提供數(shù)據(jù)可視化？
- 可先使用Flink予以填充，然后將數(shù)據(jù)發(fā)送到作為數(shù)據(jù)服務(wù)層的Druid。
總的說來，在大多數(shù)情況下，您的選擇不會(huì)是“非Druid即Flink”，而是“既Druid又Flink”。它們各自的技術(shù)特性使得兩者能夠共同支持各種實(shí)時(shí)應(yīng)用。
小結(jié)
隨著企業(yè)對于數(shù)據(jù)實(shí)時(shí)性的要求越來越高，數(shù)據(jù)團(tuán)隊(duì)需要重新考慮端到端的數(shù)據(jù)工作流程。這就是為什么許多公司已將Kafka+Flink+Druid作為構(gòu)建實(shí)時(shí)應(yīng)用的開源數(shù)據(jù)架構(gòu)的原因。
譯者介紹
陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗(yàn)。
原文標(biāo)題：Building a Real-Time Data Architecture With Apache Kafka, Flink, and Druid ，作者：David Wang
