@Rays
2016-10-20T21:22:36.000000Z
字数 1338
阅读 1798
摘要： LinkedIn认为Lambda架构中固有地存在着开发和运维上的复杂性，为此其目前采用了一种结合使用Kafka和Samza的解决方案。该方案考虑了流处理中所存在的事件延迟到达、数据流乱序、在线数据实验等挑战，并将进一步给出对鲁棒性和高级操作功能的支持。
正文：
供职于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），用做对事件序列反应方式的一种高层描述。