如何使用 Apache 軟體處理實時數據

在「永不下線」的未來，入網設備規模可能會達到數十億。存儲原始數據，日後再進行分析的方案將不再能滿足需求，因為用戶需要實時且準確的響應。要對故障等對環境敏感的狀況進行預測，實時處理數據也必不可少 —— 數據到達資料庫後再處理肯定是來不及的。

有人可能會說，「雲可擴展性」能夠滿足實時處理流數據的需求，但一些簡單的例子就能表明它永遠無法滿足對無界數據流進行實時響應的需求。從移動設備到物聯網，都需要一種新的範式來滿足需求。儘管雲計算依賴於對大數據「先存儲後分析」的方案，但也迫切需要一種能夠處理持續、雜亂和海量數據流的軟體框架，並在數據流到達時立即對其進行處理，以保證實時的響應、預測和對數據的洞悉。

例如，在加利福尼亞州的帕洛阿爾托市，每天從基礎交通設施產生的流數據比 Twitter Firehose 還要多。這是很大的數據量。為 Uber、Lyft 和 FedEx 等消費者預測城市交通需要實時的分析、學習和預測。雲處理不可避免地導致每個事件大約會有半秒的延遲。

我們需要一個簡單而強大的編程範式，讓應用程序在類似下面的情況時能夠動態處理無界數據流：

• 數據量巨大，或原始數據的移動成本很高。
• 數據由廣泛分布的資產（例如移動設備）生成。
• 數據具有轉瞬即逝的價值，即時分析迫在眉睫。
• 需要始終洞悉最新數據情況，外推法行不通。

發布和訂閱

事件驅動系統領域中有一個關鍵架構模式： 發布/訂閱 publish/subscribe 消息傳遞模式。這是一種非同步通信方法，其中消息會從 發布者（數據產生方）傳遞到 訂閱者（處理數據的應用程序）。發布/訂閱模式可以將消息發送者與消費者分離開來。

在發布/訂閱模式中，消息源會 發布 針對某個 主題 topic 的 事件 event 至 服務端 broker ，後者按接收順序存儲它們。應用程序可以 訂閱 一個或多個 主題，然後 服務端 會轉發匹配的事件。 Apache Kafka 和 Pulsar 以及 CNCF NATS 是發布/訂閱系統。 發布/訂閱的雲服務包括 Google Pub/Sub、AWS Kinesis、Azure Service Bus、Confluent Cloud 等。（LCTT 譯註：本段部分術語英文名稱更為泛用，針對這些術語，採用了中英文標註。）

發布/訂閱系統不會 運行 訂閱者應用程序，它們只是 傳遞 數據給相應主題的訂閱者。

流數據通常包含應用程序或基礎架構狀態更新的事件。在選擇架構來處理數據時，發布/訂閱框架等數據分發系統的作用是有限的。消費者應用程序的「處理方式」超出了發布/訂閱系統的範圍。這讓開發人員的管理變得極具複雜性。所謂的流處理器是一種特殊的訂閱者，可以動態分析數據並將結果返回給同一個服務端。

Apache Spark

Apache Spark 是用於大規模數據處理的統一分析引擎。通常將 Apache Spark Streaming 用作流處理器，例如給機器學習模型提供新數據。Spark Streaming 將數據分成小批量，每個小批量都由 Spark 模型或其他系統獨立分析。事件流可以被分組成小批量以進行分析，但流處理器本身必須具有彈性：

• 流處理器必須能夠根據數據速率進行擴展，甚至要能夠跨越伺服器和雲，並且還可以跨實例實現負載均衡，以確保彈性和其他應用層的需求。
• 它必須能夠分析來自不同來源的數據，這些數據源的報告速率可能相差很大。這意味著它必須是有狀態的，或者將狀態存儲在資料庫中。當使用 Spark Streaming 作為流處理器時，通常會使用後一種方法，這種方法在需要超低延遲響應時可能會存在性能問題。

相關項目 Apache Samza 也提供了一種處理實時事件流的方法，並使用 Hadoop Yarn 或 Apache Mesos 來管理計算資源，以便進行彈性擴展。

解決數據擴展問題

需要注意的是，即使是 Samza 也不能完全減輕開發人員的數據處理需求。擴展數據規模意味著處理事件的任務需要跨多個實例進行負載均衡，而使用資料庫是實例間共享結果應用層狀態的唯一方法。然而，當應用程序任務之間的狀態協調轉移到資料庫時，對性能會產生不可避免的連鎖反應。此外，資料庫的選擇也至關重要。隨著系統的擴展，資料庫的集群管理會成為下一個潛在的瓶頸。

這個問題可以通過有狀態、有彈性的替代方案來解決，並且這樣的解決方案可以用來代替流處理器。在應用程序級別（容器或實例內），這些解決方案依據流的更新，動態構建並發、互連的「web 代理」的有狀態模型。代理是並發的「微服務」，它們消費單一來源的原始數據並維護它們的狀態。基於數據中發現的源之間的真實關係（如包含和臨近）,代理實現互連以共享狀態。代理也因此形成了一個並發服務圖，可以分析它們自己的狀態和鏈接到的代理的狀態。數據源將原始數據轉換為狀態，並根據自身及其鏈接子圖的變化進行分析、學習和預測，每個代理都為單個這樣的數據源提供微服務。

這些解決方案允許大量的代理（真實數據源的數字類比）分布，甚至還有在應用層使代理互連的分散式圖，從而簡化了應用架構。這是因為代理之間互連的本質，是映射到解決方案的當前運行時執行實例和代理本身的 URL。通過這種方式，應用程序可以跨實例無縫擴展，而無需擔心 DevOps 問題。代理消費數據並維護狀態，還會計算自己和其他代理的狀態。由於代理是有狀態的，因此不需要資料庫，並且數據洞察是以內存速度計算的。

使用開源閱讀數據世界

我們查看數據的方式正在發生翻天覆地的變化：不再將資料庫用作記錄系統，取而代之的是現實世界，現實世界事物的數字類比可以不斷地傳輸它們的狀態。幸運的是，開源社區在處理實時事件的項目豐富度方面處於領先地位。從發布/訂閱模式（其中最活躍的社區是 Apache Kafka、Pulsar 和 CNCF NATS）到持續處理流數據的分析框架，包括 Apache Spark、Flink、Beam、Samza，以及 Apache 許可的 SwimOS 和 Hazelcast，對開發人員來說，可選擇項目非常之多。可以說，沒有什麼地方比開源社區的專有軟體框架更多了。試看軟體的未來，必是開源的天下。

via: https://opensource.com/article/20/2/real-time-data-processing

作者：Simon Crosby 選題：lujun9972 譯者：unigeorge 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive