目录
Lambda架构由Twitter的首席科学家Nathan Marz提出。这种架构试图平衡延迟、吞吐量、容错性和系统复杂性四个方面，以满足大数据和实时数据处理的需求。Lambda架构主要由三个层次组成：
批处理层（Batch Layer）：负责处理大量的历史数据，生成批处理视图。
速度层（Speed Layer）：负责处理最新的数据，生成实时视图。
服务层（Serving Layer）：负责将批处理视图和实时视图合并，提供最终的数据视图。
这种架构的主要优点是能够处理大规模的数据，并能对新数据进行实时处理。但是，由于需要维护两种处理机制（批处理和实时处理），所以系统的复杂性也相对较高，缺点如下：
1)同样的需求需要开发两套一样的代码
这是 Lambda 架构最大的问题，针对同一个需求需要开发两套代码，一个在批处理引擎上实现，一个在流处理引擎上实现，在写好代码后还需构造数据测试保证两者结果一致，另外，两套代码对于后期维护也非常麻烦，一旦需求变更，两套代码都需要修改，并且两套代码也需同时上线。
2)集群资源使用增多
同样的逻辑需要计算两次，整体占用资源会增多。虽然离线部分是在凌晨运行，但是有可能任务多，在凌晨时造成集群资源使用暴增，报表产出效率就有可能下降，报表延迟对后续展示也有影响。
3)离线结果和实时结果不一致
在此架构中经常我们看到次日统计的结果比昨晚的结果要少，原因就在于次日统计结果和昨日统计结果走了两条线的计算方式：次日统计结果是按照批处理得到了更为准确的批量处理结果。昨晚看的结果是通过流式运行的结果，依靠实时链路统计出的实时结果（实时结果统计累加），牺牲了部分准确性。对于这种来自批量和实时的数据结果对不上的问题，无解。
4)批量计算 T+1 可能计算不完
随着物联网时代的到来，一些企业中数据量级越来越大，经常发现夜间运行批量任务已经无法完成白天 20 多个小时累计的数据，保证早上上班前准时出现数据已成为部分大数据团队头疼的问题。
5)服务器存储大
由于批流两个过程都需要将数据存储在集群中，并且中间也会产生大量临时数据，会造成数据急速膨胀，加大服务器存储压力。
Kappa架构由LinkedIn的数据工程师Jay Kreps提出。Kappa架构是对Lambda架构的一种简化，它只有一个处理层——实时处理层。
在Kappa架构中，所有的数据都被视为实时数据流，通过实时处理系统进行处理。当需要处理历史数据时，只需要将历史数据重新注入到数据流中即可。
Kappa架构的主要优点是架构简单，只需要维护一种处理机制，降低了系统的复杂性。同时，由于所有数据都是实时处理，所以能够实现更低的数据处理延迟。但是，这种架构也有其局限性，比如处理大规模的历史数据时可能会面临一些挑战