最近，一群人要求我详细介绍我为我们的书《分布式实时计算的风暴蓝图》撰写的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