一、一些基本面
虽然现在的大数据解决方案基本上已经能够取得很好的可靠性，但一致性问题仍然无法轻便、彻底地解决。
一致性：可以这么理解，对于成功写入到存储系统分区中的每一条数据，后续的对该分区任何成功处理都应该是将分区中每一条数据包含在内的。通俗来讲，就是处理成功了，处理结果都写入，处理失败了则一条结果也不写入。
显然，很多的处理情况可能并不符合这一条件！举个例子，在对一个Kafka分区单元数据进行流式处理时，处理到某个时间点时系统发生故障宕机，重启后从检查点开始处理。但此时已有部分数据已经被处理并被写入到系统中。然而实际上部分被认为成功写入的数据不能被认为是成功的！因为再处理过程仍然可能包含已经处理并被写入到存储体系的数据。
大数据流处理系统中可能的两个不符合一致性的体现
1、处理重复
因为大数据处理系统中并行任务处理的数据量都相对较大，在每个任务处理的过程中任务失败时，该任务会重新加载数据进行处理。但在失败的处理过程中，加载的数据中已经有部分数据可能是被成功处理的。这部分数据再次被处理，便造成了重复。
2、数据丢失
想一想这种情况，在任务计算完成写入到数据库的过程中，数据库不可用。就算是数据被缓存在buffer中，然后批量写入数据库，那么不管是buffer溢出还是机器崩溃，已处理的数据都不会被写入到数据库中。然而计算系统“认为”该数据已经处理完成。这便造成了数据丢失的情况。
二、解决大数据处理时的一致性问题的一种方案
lambda架构（本篇文章仅关注该架构）
lambda架构概念的最早提出当属Storm作者提出的Beat CAP文章中所展示的方案。其核心为离线全量批处理系统与实时增量处理系统的混和系统。离线和实时系统共同组成一套保证最终一致性的大数据处理系统。
1、lambda架构的出发点
- 系统能够存储不可变的、持续增长的数据（如HDFS）。
- 业务能够接受一定范围内的结果延迟（比如第二天早上能看到第一天的数据经过离线处理的结果）。
- 实时计算系统能够保证业务在一定时间限度内的时间延迟。
- 离线系统通过计算raw data（全量数据）以保证强一致性。
2、在实现上的计算方式
1）批处理系统（大时间跨度内）全量数据计算—> result view 1
2）实时计算系统（小时间跨度内）增量补偿计算—> result view 2
最终的结果呈现，需要对 result view 1 和 result view 2 进行merge合并。
3、一致性保证
且先不说这种架构的优缺点，我们先看其如何保证数据一致性。我们转而来看离线批处理和实时处理各如何操作？
lambda架构中的离线处理系统，其输入是除设定的最近时间T之外的全量输入数据，而实时流处理系统的输入是设定的最近时间T之内的数据。根据我们之前所说的不符合一致性的体现中所描述的处理重复及数据丢失情况，这一架构能做什么纠正。
关键点在于，作用于全量数据的批处理系统的计算执行结果，最终都会覆盖实时层增量计算的计算结果。于是，实时层的任何错误都将得到修正。那么实时层的计算错误及失败都能够是暂时的，不会对数据产生毁灭性的影响。
4、lambda架构的优缺点
优点：
1、其最大优点在于能够保证实时层处理出现问题之后整个计算数据不被破坏，并可以保证最终一致性。
2、实时层计算量比较小，计算成本可控，整个计算系统稳定。
3、在某些情况下，实时计算和离线计算可分开进行，避免计算高峰，能够缓解资源压力。
缺点：
1、因为要对数据进行大量存储，并且根据业务需求，两系统可能同时需要占用资源，对资源需求大。
2、部署复杂，需要部署离线及实时计算两套系统，给运维造成的负担比较重。
3、两种计算口径，业务需要根据不同口径分开编码维护，数据源的任何变化均涉及到两个部署的修改，任务量大，难以灵活应对。
4、随着数据量的急剧增加、批处理窗口时间内可能无法完成处理，并对存储也挑战巨大。
