1.4 近實時解決方案——可用的架構

在本節，讀者將學會如何構建可擴展、可持續且具有魯棒性的實時系統解決方案，以及如何對可能的架構模式進行選型。

高級NRT解決方案看起來非常直觀和簡單，其具有數據收集漏斗、分布式處理引擎以及一些其他組件（如緩存、穩定存儲和儀表板插件）。

如圖1-4所示，在較高層面上，基本的分析過程可以分為3類：流數據的實時數據收集；分布式流數據的高性能計算；以可查詢消耗層/儀表板的形式探索和可視化生成的見解。

市場上有兩種存在競爭的流式計算技術，即Storm和Spark。下面我們將深入研究從這些堆棧中獲得的高級NRT解決方案。

1.4.1 NRT的Storm解決方案

該解決方案實時捕獲高級流數據并將其路由到某個隊列/代理（Kafka或RabbitMQ）中，然后通過Storm拓撲處理分布式處理部分，一旦計算出見解，就可以將它們快速寫入數據存儲（如Cassandra）或其他隊列（如Kafka），以進行進一步的實時下游處理。如圖1-5所示，通過發送/提取收集代理（如Flume、Logstash、FluentD或Kafka適配器），可從不同數據源收集實時流數據。然后，數據被寫入Kafka分區，Storm拓撲從Kafka中提取/讀取流數據并在其拓撲中處理此數據，并將見解/結果寫入Cassandra或其他一些實時儀表板。

1.4.2 NRT的Spark解決方案

在更高的層級上，Spark的數據流管道與圖1-5所示的Storm架構非常相似，但是它最受詬病的一點是Spark利用HDFS作為分布式存儲層。在進一步深入之前，我們先看看對整體流程及其細節的進一步剖析，如圖1-6所示。

與典型的實時分析管道一樣，流數據使用Flume或Logstash等抓取代理來提取數據。本節首先介紹Kafka，以確保數據源與抓取代理之間的系統解耦；然后介紹Spark Streaming組件——它將結果轉儲到穩定的存儲單元、儀表板或Kafka隊列之前，提供了一個用于處理數據的分布式計算平臺。

前兩種架構范式之間有一個本質區別：雖然Storm本質上是一個實時事務處理引擎，默認情況下，擅長按事件處理傳入數據；但Spark基于微批的工作理念，本質上是一個偽實時計算引擎，通過減少微批的大小，可以滿足接近實時的期望計算。Storm主要用于快速處理，所以所有轉換都在內存中，因為任何磁盤操作都會產生延遲；對于Storm來說，這既是一個優點，又是一個缺點（因為如果事情中斷，內存是不穩定的，一切都必須重新處理，中間結果會丟失）。此外，Spark基本上由HDFS支持，并且功能強大且容錯性更強，因為中間結果在HDFS中有備份。

在過去的幾年中，大數據應用程序按以下順序進行了精彩的轉換。

●僅批處理應用程序（早期的Hadoop實現）；

●僅流處理（早期的Storm實現）；

●可以是兩者（前兩者的定制組合）；

●前兩者（Lambda架構）。

問題是：為什么發生了上面的演變？當人們熟悉了Hadoop的強大功能時，他們真的很喜歡構建幾乎可以處理任何數據量的應用程序，并且可以將其以無縫、容錯、無中斷的方式擴展到任何級別。然后，隨著Storm等分布式處理引擎的出現，逐步進入到了一個大數據處理成為強烈需求的時代。Storm可擴展性強，且具有輕量級快速處理能力。但是，有些情況發生了變化，大部分人意識到了Hadoop批處理系統和Storm實時系統的局限性和優勢：前者滿足了對數據量的需求，后者在速度方面非常出色。這些實時應用程序非常完美，它們在整個數據集的短時窗口上表現得很好，但在以后的某個時間沒有任何修正數據/結果的機制。雖然Hadoop實現準確而強大，但需要花費很長時間才能獲得確定性的結論。我們達到了這樣的一個程度，即復制了完整/部分解決方案，以獲得涉及批處理和實時實現相結合的解決方案。最近的NRT架構模式中的Lambda架構，是頗受歡迎的解決方案，結合了批處理和實時實現，無須復制和維護兩個解決方案。Lambda架構能同時滿足數據量和速度的要求，這是早期架構的優勢，可以滿足更廣泛的用例集。