Lambda架构的核心思想及其三个实际问题

Lambda架构试图回答”批处理重新处理历史数据、流处理处理最近更新，两者如何结合”：核心思路是把传入数据记录为不可变事件流（类似[[事件溯源与CDC的区别命令与事件的区分]]中的事件溯源），并行运行两套独立系统——批处理系统（如Hadoop MapReduce）和流处理系统（如Storm）——共同从这些事件衍生出读取优化视图：流处理器快速生成近似更新，批处理器随后用同一批事件生成更精确的更正版本，理由是批处理更简单不易出错、而流处理器当时被认为不够可靠难以容错，批处理能用较慢的精确算法、流处理可以用快速近似算法。这个想法推广了”在不可变事件流上建立衍生视图、按需重新处理”的原则，很有影响力，但作者指出三个实际问题：一是要在批处理和流处理两套框架里维护相同的逻辑，是显著的额外工作量，即便有Summingbird这类跨两种上下文运行的抽象库，调试调优维护两个独立系统的操作复杂度依然存在；二是流管道和批处理管道产生独立输出，需要合并才能响应用户请求——滚动窗口简单聚合容易合并，但连接、会话化这类复杂操作或非时间序列的输出合并起来就很困难；三是虽然理论上能力重新处理整个历史数据集，但大数据集上代价高昂，实践中批处理流水线往往要处理增量批次（如每小时处理一小时数据）而非重跑全部，这就引入了滞留事件、跨批次窗口这类”时间推理”问题，让批处理层变得更像流处理层，与保持批处理层简单的初衷背道而驰。