那些网站可以做问答,uugaicomlogo免费设计网站,网站优化快速排名软件,网站建设起来还需要花钱吗摘要#xff1a;Jay Kreps是Linkedln的一名在线数据架构技术高管#xff0c;在日常工作中#xff0c;Jay Kreps经常被问及有关Lambda架构的问题#xff0c;为此他结合实际经验和个人体会#xff0c;针对Lambda架构进行深度剖析#xff0c;分析了它的优缺点以及采用的替代…摘要Jay Kreps是Linkedln的一名在线数据架构技术高管在日常工作中Jay Kreps经常被问及有关Lambda架构的问题为此他结合实际经验和个人体会针对Lambda架构进行深度剖析分析了它的优缺点以及采用的替代方案。
Jay Kreps是Linkedln的一名在线数据架构技术高管其负责Linkedln开源项目包括Apache Kafka、Apache Samza、Voldemort以及Azkaban等项目。在日常工作中Jay Kreps经常被问及有关Lambda架构的问题为此他结合实际经验和个人体会把使用Lambda架构的心得总结为以下几点我们一起来看下
Lambda架构的组成
该架构的组成是这样的 在该架构中被读取的数据是不可变的在并行处理过程中数据会依次进入批处理系统batch system与流处理系统。从逻辑上看传输过程发生了两次一次是在批处理中一次是在流处理中。在查询时当这两者都返回结果后才算是完成一次完整的查询。
这个架构可以有很多的组合变化我的想法是希望它变得更简洁。例如可以把里面的Kafka、Storm、Hadoop等换成其它类似的系统惯常的做法是使用两个数据库来存储数据输出表一个用于实时优化查询另外一个用于批量优化处理。
Lambda架构的目的是为应用程序提供一个低延迟的复合异步数据传输环境例如新闻类应用经常需要进行大规模信息处理包括输入归类索引存储等操作。
我的体会是架构的引入不能照本宣科要根据实际情况进行调整优化。
优缺点分析
优点 数据的不可变性。里面给出的数据传输模型是在初始化阶段对数据进行实例化这样的做法是能获益良多的。能够使得大量的MapReduce工作变得有迹可循从而便于在不同阶段进行独立调试。强调了数据的重新计算问题。在流处理中重新计算是个主要挑战但是经常被忽视。比方说某工作流的数据输出是由输入决定的那么一旦代码发生改动我们将不得不重新计算来检视变更的效度。什么情况下代码会改动呢例如需求发生变更计算字段需要调整或者程序发出错误需要进行调试。
此外外界对于Lambda的评论还有其它观点例如说实时数据处理是固有的较批处理是高损耗低效率我对此并不赞同。诚然流处理目的框架前没有MapReduce那样成熟但是我们应该用发展的观点来看待而不是就此盖棺定论。
缺点
代码的维护需要在两个复杂的分布式系统中进行这是个困难的工作。例如说在基于分布式框架上如Storm或Hadoop中进行编程使用不同的框架就需要进行不同的处理。虽然目前有解决方案尝试从实时和批处理框架中进行抽象综合从而使得既能在高阶框架中进行编程而后又能在流处理或MapReduce中完成降阶处理操作Summingbird采用的就是这种方法。不过这样虽然在某程度上能减少编码的复杂度但是仍然没有根本性地解决问题。即使能解决二次编码问题分别在两个系统中运行和维护应用程序仍然是个艰巨的任务。所以基于不同系统而抽象得到的新系统都只能是从两者的功能交集中来进行。类似地在跨数据库系统中进行ORM(对象关系映射)也是个困难的工作。
完成的试验
在Linkedln中我们做了不少的试验。尝试建立不同类型的分布式计算框架甚至是开发出使代码能在实时或Hadoop中无缝运行的专用API。不过目前来看还不没做到完美无缺。因为多系统的编程任务实在是太艰巨了。此外API的使用会让系统的漏洞不易被发现同时对开发者有更严格的技术要求——对API的运用要足够的熟练从而能在调试或效率检视时能够对所有影响的因素做到了然于胸。
我的建议是如果你不太看重延迟问题可以尝试使用类似MapReduce的批处理框架或者是流处理框架但是最好不要同时使用除非真的有必要。
那么Lambda架构的优势是什么呢我想是它能够很好地指导如何搭建一个复杂的低延迟处理系统。例如搭建一个处理历史数据的高延迟大数据处理系统和一个低延迟的流处理系统来减少重新计算的问题。但是这应该是暂时性的未来还会存在更好的替代解决方案。
一个替代方案
很多时候惯性思维会让人觉得流处理系统在处理历史数据等大数据场合不太适合但是我觉得这可能与他们使用的系统自身限制有关。流处理其实是在数据输出的中间阶段进行的完成后再把结果返回给用户所以是具备大数据处理能力的。
例如请看下我们的一个替代方案 1. 使用Kafka或其它系统来对需要重新计算的数据进行日志记录以及提供给多个订阅者使用。例如需要重新计算30天内的数据我们可以在Kafka中设置30天的数据保留值。
2. 当需要进行重新计算时启动流处理作业的第二个实例对之前获得的数据进行处理之后直接把结果数据放入新的数据输出表中。
3. 当作业完成时让应用程序直接读取新的数据记录表。
4. 停止历史作业删除旧的数据输出表。
有别于Lambda架构上述方法是在代码改动时才进行数据重新计算。如果想加快处理速度计算作业的并行处理能力是个突破口。或许我们可以把这个架构称呼为Kappa架构虽然它真的很简易。
这个方案还能继续优化改进。很多情况下我们可以把两个数据输出表整合在一起。这样一来我们可以很快地在程序中读取历史记录和进行其它重要的针对新老版本的测调试工作。
请注意这个方法不是说让我们远离HDFS而是说我们不在HDFS中进行重新计算。详细的说明文档请点击这里进行查阅。
背景知识
对Kafka不太熟悉的读者可能理解上会有点困难。我们这里给出一些背景介绍希望对初学者有所帮助。
Kafka中是这样按序来进行日志记录的 一个Kafka“主题”包含了以下的记录集 一个流处理在使用这些数据时进行的是“偏移”量维护就是把每个分区最新加入数据的编号进行记录。所以只需使用不同的偏移量来重新执行作业就可以实现重新计算的目的。对统一数据添加第二个消息消费者其实就相当于使另外一个读者指向不同的日志位置。
Kafka提供了复制和高容错的能力使得能在便宜的商业硬件中使用特别是在TB级别的存储场合中。
写在最后
虽然在Linkedln中配合该方法的是Samza流处理系统但并不代表不能在其他系统中运用。有心的读者可以进行尝试我很乐意看到有新的方案产生。
英文出自radar.oreilly
