重庆渝中区企业网站建设公司,公司做网站推广的价格,排名优化课程,东营市报名系统网站设计公司最近#xff0c;一群人要求我详细介绍我为我们的书《分布式实时计算的风暴蓝图》撰写的Druid / Storm集成。 德鲁伊很棒。 风暴很大。 两者一起解决了实时维查询/聚合问题。 实际上#xff0c;人们正在将其视为主流#xff0c;将其称为RAD Stack #xff0c;并添加了“ La… 最近一群人要求我详细介绍我为我们的书《分布式实时计算的风暴蓝图》撰写的Druid / Storm集成。 德鲁伊很棒。 风暴很大。 两者一起解决了实时维查询/聚合问题。 实际上人们正在将其视为主流将其称为RAD Stack 并添加了“ Lambda Architecture”标签。 老实说也许有更好的方法。 Lamda Architectures的以下假设一直困扰着我。 摘自Nathan关于Lambda体系结构的文章 实时计算任意数据集上的任意函数是一个艰巨的问题。 没有哪个工具可以提供完整的解决方案。 相反您必须使用各种工具和技术来构建完整的大数据系统。 lambda体系结构将问题分解为三层批处理层服务层和速度层从而实时解决了在任意数据上计算任意函数的问题。 该建议使大多数人为批处理速度/处理和查询部署了单独的基础架构/框架这很好因为它允许您“为每个作业使用正确的工具”。 这导致了诸如“ RAD Stack”之类的问题。 人们为每一层选择一种技术。 例如速度 Storm批处理 Hadoop和服务 Impala 但是如果您生活在这样的环境中则它们需要大量资源因为整个系统之间的重复使用很少。 我相信人们越来越开始质疑各层之间的区别 。 其他人则提出了统一Lambda架构 。 最近我发现自己处于统一主义者的阵营中…… 在HMS几年来我们一直在迭代Lambda架构。 我们有StormHadoop和实时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
