Lambda架构可重计算、容错的代价：同一套算法要实现两遍并保证一致

Lambda架构把系统拆成批处理层（批量处理数据、生成离线结果）、实时处理层（实时处理增量数据、生成在线结果）、服务层（合并离线和在线结果对外提供服务）三层，这个结构直接带来了几项重要优点：因为原始数据不可变，任何时候重新跑一遍批处理计算都能得到正确结果，这意味着系统天然具备”可重计算”能力——出现程序Bug或系统故障，只需要针对不可变的原始数据重新计算一遍，就能修复计算结果，这个可重计算能力进一步转化成了容错能力；同时批处理和实时处理各自独立运行，天然实现了复杂性分离和读写分离。但这些优点是有代价的，而且代价相当显著：因为同一个业务需求要分别在批处理系统和实时处理系统里各自实现一遍算法逻辑，开发工作量直接翻倍，更麻烦的是这两套独立实现的逻辑必须保证结果口径一致——批处理算出来的和实时处理算出来的，最终在服务层合并时不能互相矛盾，这个一致性维护的成本会随着算法本身复杂度的提升而持续放大；此外团队还要同时开发、运维、调试两套完全独立的技术平台（批处理平台和流处理平台），这也是一笔长期存在的隐性成本。这个案例给出了一条评估架构方案的现实提醒：一个架构方案带来的能力提升（可重计算、容错、复杂性分离）往往有对应的隐藏成本（双倍开发工作量、跨系统一致性维护），选择一个架构方案之前，不能只看它解决了什么问题，还要认真评估它的代价会不会随着系统规模和团队复杂度增长而被持续放大——Lambda架构”两套逻辑要保持一致”这个代价，正是后来Kappa架构试图彻底消除的核心痛点。