流处理和 Lamda 架构中的挑战

供职于 LinkedIn 公司流处理架构部门的 Kartik Paramasivam 在今年夏天撰写了两篇文章，解释了LinkedIn 力图在使用 Apache Samza 做数据处理中避免 Lambda 架构的原因及具体做法。

流处理是一种非常有用的技术，解决了如何从数据流中快速获取结果的问题。但是流处理技术并不能满足苛求高一致性和鲁棒性需求的用例的要求。

Lamda 架构是一种结合了批处理和流处理的解决方案，曾被广泛地采用。其基本理念是提供两条独立的数据路径，一条是使用流处理技术的速度层，提供低延迟的结果；另一条是运行任务的批处理层，对批量数据提供精确的结果。由于依赖于多种技术，并合并了两条数据路径的处理结果，所以 Lamda 架构实现很复杂。

LinkedIn 使用 Samza 处理从 Apache Kafka 流出的数据。在文章里描述的其中一个问题是事件的延迟到达。Samza 添加了一个基于 RocksDB 的键值库，实现了对输入事件的长期保存。在事件延迟到达时，由于在本地存储了足够重新计算的信息，架构将重新发送所有的结果给受到影响的计算窗口。鉴于依赖于外部存储（例如 NoSQL）就隐含着通信和序列化中的网络和 CPU 开销，基于 RocksDB 的解决方案经证明是可取的。

另一种流处理架构 Apache Flink 适合于在时间窗口上基于时间戳的计算。时间戳可以是特定于事件的，或是摄入时间戳，用于对乱序的数据流给出一致的结果。Flink 在内存中维护数据，并在接收到水印线（Watermark）事件时触发窗口计算。水印线代表了一个时钟周期，为Flink 提供了时间的概念（可以是特定于事件的）。

流处理中还存在其它的一些问题，例如如何处理由多次交付保证所导致的重复消息等。对于大部分具有内部检查点机制的架构而言，这些问题都已经得到解决。

最后一类流处理问题是以交互的方式对流经系统的数据进行实验的能力。敏捷实验在 Azure Stream Analytics 等商业产品中可用，通常是在批处理系统上使用 SQL 等高层语言执行的。

Julian Hyde 将 Samza SQL 描述为一种试图在 Samza 流处理器中应用 Apache Calcite 的尝试。由于 Samza SQL 目前依然尚未生产就绪，LinkedIn 还是使用 Hadoop 的批处理本能在离线数据上开展迭代测试。一些离线数据是从线上服务数据库中拷贝过来的，即基于 Samza 的流处理器在流处理时所查询的同一数据库。

Flinkn 也在努力实现鲁棒的流SQL 支持。2016 年8 月发布的Flink 1.1 版本支持了流数据上的过滤和合取操作。Flink 也已支持复杂事件处理（Complex Event Processing），用做对事件序列反应方式的一种高层描述。

查看英文原文： Stream Processing and Lambda Architecture Challenges

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。