最近，一群人要求我詳細介紹我為我們的書《分布式實時計算的風暴藍圖》撰寫的Druid / Storm集成。 德魯伊很棒。 風暴很大。 兩者一起解決了實時維查詢/聚合問題。

實際上，人們正在將其視為主流，將其稱為RAD Stack ，并添加了“ Lambda Architecture”標簽。 老實說，也許有更好的方法。 Lamda Architectures的以下假設一直困擾著我。

摘自Nathan關于Lambda體系結構的文章 ：

實時計算任意數據集上的任意函數是一個艱巨的問題。 沒有哪個工具可以提供完整的解決方案。 相反，您必須使用各種工具和技術來構建完整的大數據系統。

lambda體系結構將問題分解為三層：批處理層，服務層和速度層，從而實時解決了在任意數據上計算任意函數的問題。

該建議使大多數人為批處理，速度/處理和查詢部署了單獨的基礎架構/框架，這很好，因為它允許您“為每個作業使用正確的工具”。 這導致了諸如“ RAD Stack”之類的問題。 人們為每一層選擇一種技術。 （例如，速度= Storm，批處理= Hadoop和服務= Impala）

但是，如果您生活在這樣的環境中，則它們需要大量資源，因為整個系統之間的重復使用很少。 我相信人們越來越開始質疑各層之間的區別 。 其他人則提出了統一Lambda架構 。

最近，我發現自己處于統一主義者的陣營中……

在HMS，幾年來我們一直在迭代Lambda架構。 我們有Storm，Hadoop和實時Web服務層。 這些功能均充當數據攝取機制。

它們都處理相同類型的數據，僅在接口，容量和客戶端期望方面有所不同：

• 交易處理：
  • 我們的事務處理是我們的Web服務層。
• 基于流/隊列的處理
  • 通常，我們發現自己更多地依賴于我們的事務處理能力。
• 批量處理
  • 對于批處理，客戶的期望甚至進一步降低。

像許多其他人一樣，我們發現自己需要支持所有這些范例。 從字面上看，我們正在跨不同的框架/系統重寫代碼，當這些實現不同時（甚至略有不同），這會造成很大的痛苦。 數字沒有排隊，等等。

我們被迫提出一個解決方案，并使系統稍微崩潰。

我們用Storm看了DRPC，并考慮了從我們的Web服務層調用Storm，但是DRPC似乎很笨拙，并且沒有得到支持。 另外，從Hadoop調用DRPC似乎是不明智的。 （有人嘗試過嗎？）

相反，我們決定鎖定持久性的抽象。 我們環顧了ORM和DAO模式，但大多數都不支持微批處理的概念，這是一種抽象，我們希望該選項能夠在不同的處理機制中加以利用。 最后， 我們決定將風暴/突發狀態抽象作為持久性的通用機制。 我們構建了storm-cassandra-cql ，并將其嵌入到我們的Web服務和Hadoop中。

從Hadoop和我們的Web服務中，我們實例化了自己的元組，它們實現了Storm Tuple接口。 從那里，我們可以使用State抽象并重新使用Mappers，以確保所有三個處理范例之間的數據模型均一致。

作為一種快捷方式，在Hadoop中，我們直接在reduce階段使用State對象，將輸出格式設置為NullOutputFormat。 理想情況下，我們可能應該實現一個新的OutputFormat，即StormCassandraCqlFormat之類的東西，但是我不確定這會給我們帶來很多好處。

對于Web服務，直接集成是直接的。 將JSON轉換為元組，在StateUpdater上調用update（），然后在State對象上調用commit（）。 但是我們還希望能夠在提交到“深度存儲”之前進行批處理并執行維度聚合。 這帶來了一個問題，我們將擁有已確認（200個響應代碼）但尚未持久的數據。 不好。 如果節點發生故障，我們將丟失數據。 真的不好。

那么，解決方案是什么？ 我們本可以集成Druid，但是相反，我們決定保持它的輕便，并…利用Storm作為我們的安全網！

考慮以下對Lambda體系結構的“傳統”解釋：

在這種傳統方法中，批處理層（Hadoop）通常用于“糾正”速度層（Storm）中引入的處理中的錯誤。 Hadoop是安全網，可以糾正數字（通常通過通宵的批處理作業），我們決定采用這種方法來翻轉該模型，并使用Storm作為我們的安全網：

在這種情況下，我們使用嵌入式State對象在批處理中聚合數據，但是在確認HTTP請求之前，我們還寫入Kafka隊列以實現持久性。 序列圖如下所示：

我們將事件持久化到隊列中，更新Trident State對象，然后*然后*返回200。然后，定期將State刷新到存儲中。 （在這種情況下為Cassandra），如果我們刪除一個節點也是可以的，因為Storm最終將最終（重新）處理該事件并在需要時（重新）合并數據。 （這是我要掩蓋一些非常重要的細節的地方，將在下一篇文章中解決）

關鍵是……我們已經開始從持久性開始崩潰。 我們正在重新使用Hadoop和Web服務中的Trident State抽象，并且已經將Storm移到了“重新處理/安全網”層，該層以前由Hadoop /批處理填充。

由于缺乏更好的術語，我們一直將其稱為Delta體系結構，因為整個系統專注于根據任何和所有處理范例進行的狀態增量更新。

希望這能使人們思考。 在我的下一篇文章中，我將解釋如何使用相同的體系結構交付維度聚合（如Druid），而無需直接合并Druid。

我們也有未解決的問題-

我們可以執行嵌入式拓撲嗎？

這樣做有意義嗎？

有關更多詳細信息，請查看我在Storm NYC聚會中所做的演示， 數據管道和Lambda體系結構的改進 。

我完全理解Lambda的大部分內容都是透視問題。 FWIW –這是我的（當前–可能會更改=）。 多虧了內森（Nathan）闡明了Lambda架構的概念，實現“大數據”視圖已使人們有了共同的語言，可以與他們討論一些真正棘手的問題的解決方案。

翻譯自: https://www.javacodegeeks.com/2015/03/delta-architectures-unifying-the-lambda-architecture-and-leveraging-storm-from-hadooprest.html

總結

以上是生活随笔為你收集整理的Delta架构：统一Lambda架构并利用Hadoop / REST中的Storm的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。