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

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

摘自Nathan關(guān)于Lambda體系結(jié)構(gòu)的文章 ：

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

lambda體系結(jié)構(gòu)將問題分解為三層：批處理層，服務(wù)層和速度層，從而實(shí)時解決了在任意數(shù)據(jù)上計(jì)算任意函數(shù)的問題。

該建議使大多數(shù)人為批處理，速度/處理和查詢部署了單獨(dú)的基礎(chǔ)架構(gòu)/框架，這很好，因?yàn)樗试S您“為每個作業(yè)使用正確的工具”。 這導(dǎo)致了諸如“ RAD Stack”之類的問題。 人們?yōu)槊恳粚舆x擇一種技術(shù)。 （例如，速度= Storm，批處理= Hadoop和服務(wù)= Impala）

但是，如果您生活在這樣的環(huán)境中，則它們需要大量資源，因?yàn)檎麄€系統(tǒng)之間的重復(fù)使用很少。 我相信人們越來越開始質(zhì)疑各層之間的區(qū)別 。 其他人則提出了統(tǒng)一Lambda架構(gòu) 。

最近，我發(fā)現(xiàn)自己處于統(tǒng)一主義者的陣營中……

在HMS，幾年來我們一直在迭代Lambda架構(gòu)。 我們有Storm，Hadoop和實(shí)時Web服務(wù)層。 這些功能均充當(dāng)數(shù)據(jù)攝取機(jī)制。

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

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

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

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

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

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

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

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

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

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

考慮以下對Lambda體系結(jié)構(gòu)的“傳統(tǒng)”解釋：

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

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

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

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

由于缺乏更好的術(shù)語，我們一直將其稱為Delta體系結(jié)構(gòu)，因?yàn)檎麄€系統(tǒng)專注于根據(jù)任何和所有處理范例進(jìn)行的狀態(tài)增量更新。

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

我們也有未解決的問題-

我們可以執(zhí)行嵌入式拓?fù)鋯?#xff1f;

這樣做有意義嗎？

有關(guān)更多詳細(xì)信息，請查看我在Storm NYC聚會中所做的演示， 數(shù)據(jù)管道和Lambda體系結(jié)構(gòu)的改進(jìn) 。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。