kappa架构的本质可以说是只依赖一套流处理系统来作为大数据处理解决方案。
一、概括起来，kappa架构包括两个层级
1、消息传输层
这一层有如下特点
- 持久性——数据可任意设定存储时间
- 分布式——数据分布式存储
- 数据可重放——数据可以被replay，从头重新处理
- 高性能——能够提供高性能数据读写访问
有了这几点保证之后，数据便可以在某个需要限度内全量存储，这可将生产者和消费者解耦，并进行分布式容错以提高可用性，可重放很重要，这确保了在必要情况下系统可进行重算。
消息传输层的意义在于弹性容纳并提供流计算引擎的输入数据，并在必要时从头开始读取重新计算，从而获得可靠结果。
通常使用消息队列如Kafka来作为消息传输层。
2、流处理层
这一层即是大数据流处理引擎，可用于进行流分布式实时计算。理想情况下，流处理层也应该具备如下特点
- 低延迟——保证快速响应
- 高吞吐——同时处理庞大数据量
- 具有容错与恢复能力——保证系统稳定可用
- 一致性保证——适用任何强一致性需求的应用(如金融级需求)
如今比较流行的大数据处理系统要数基于Spark引擎的Spark Streaming、Struct Streaming还有Flink、Storm了。我们看看业界最常用的Spark和Flink在流处理这方面的高下！在延迟方面Flink要更胜于Spark流处理。另一方面，在一致性方面Flink借鉴 Chandy-Lamport 分布式快照算法实现的Asynchronous Barrier Snapshots算法来提供一致性保证而Spark流处理无法保证。
这里我的另一点体会是，Flink是连续运算符长运行的计算模式，所以其在失败时进行状态重放，从断点继续往下执行即可，而批次的处理却不可以，批次的重新处理时其加载的仍然是批。
二、然后我们来看几个概念
1、幂等性
幂等性也就是指相同的操作无论执行多少次，均会产生一样的结果。
这里为什么提到幂等性呢？因为分布式中的一致性通常是难以保证的，因为伴随着分布式的一致性而来的除了耗资源还产生延迟以及网络通信问题。所以如Spark流处理输出时是无法保证Exactly-once（失败时部分已经写出、而还有部分未写出，重启时从上一个检查点开始，造成部分重复），这个时候可以通过幂等输出来解决。
举个例子，在往kafka写出时，可以通过外部存储的唯一键来辅助
设置enable.auto.commit为false，在幂等写出时再手动提交，这样便可保证写入到kafka中的数据不会重复。
2、Exactly-once语义
Struct Streaming的微批次处理模式中声称的exactly-once语义并不是说输入数据只被处理一次，因为Spark引擎支持任务重试（根据沿袭图），所以很有可能task失败导致数据重新被加载再次处理。这里的exactly-once实际是指不管执行多少次，其最终的执行结果都是一样的。
三、kappa的优缺点
这个在前边的文章已有描述，但其核心优点即是无需维护离线批计算、实时计算两套系统，对于业务开发也只需一套程序即可，不用担心因两套系统导致的执行结果不一致。另外，其从头开始计算的能力也是主要考虑的其不足的一点。