相对于传统的hadoop这样的batch分析平台，流式分析的优点就是实时性， 即可以在秒级别延迟上得到分析结果 。
当然缺点是, 很难保证强一致性，即exactly-once语义 （在海量数据的前提下，为了保障吞吐量，无法使用类似事务的强一致性的方案）。
一般流式分析平台都会promise较弱的一致性，即least-once语义，保证数据不丢但允许数据重复。
但这只是在正常的情况下，当流式分析的任一环节发生故障，整个流被堵塞时，会导致层层队列被打满，最终仍然是会丢数据的。
所以对于流式分析平台，如果要保证一致性，必须借助外部的replay的能力。
原理其实很简单，既然流式分析没法保证一致性，那么我们就用hadoop存全量数据，通过batch数据分析来保证强一致性。
流式分析只用来计算实时热数据，而冷数据由离线计算来做，用户查询的时候，只需要把两份数据做下merge。
从严格意义上讲，这个不能算beat cap，因为只是结合batch分析的强一致性和流式分析的高可用性而形成的架构。
但确实给流式分析如何保证一致性，提出了一个非常有建设性的方案。
lamda架构的缺陷也很明显，太复杂，太重，需要搭建实时和离线两套系统，对运维而言成本过高。
并且由于kafka的数据存在磁盘上，是可以被重复读取的，这也是kafka在流式场景下更优于其他队列中间件的原因。
1. 用流式job_n去实时计算热数据，结果存入table_n，可以用于用户实时查询 。
2. 在需要的时候（发生故障数据部分丢失或处理逻辑发生变化）开启流式job_n+1来处理全量数据，存入table_n+1，当数据catch up的时候，把用户流量切到table_n+1 。
3. 删除job_n和table_n。
这个架构比较轻，并且确实可以在很大程度上解决流式分析平台的一致性问题，也可以用做参考。
但是对于我们的场景，这个方法太理想化：
原因是数据量太大，存储7天的日志需要近2pb的磁盘空间（kafka需要做replica）。
如果要在可接受时间范围内replay完这些数据，所需要的分析资源也是很难满足。
并且线上业务做数据源的切换也不是那么简单的事。
所以我们的思路是，补全丢失的数据，而非replay全量数据。
步骤1. 重置线上job至kafka latest offset，读最新的数据。
用线上job去补旧数据，会很影响用户的体验，因为实时流量本身就很大，catchup的速度会比较慢，会导致用户长时间看不到最新日志。
步骤2. 找出需要补全数据。
这步方法有很多，我们的方法是，
用monitorbolt提供实时业务监控，我们可以知道服务什么时候异常，什么时候恢复（秒级别）。
步骤3. 启动catchup job，从earliest offset开始读。
通过配置在处理bolt里设置时间过滤条件，只处理规定时间范围内的数据，其余的数据全部丢弃。
步骤4. 数据恢复后，停止catchup job。
这个方案可以解决数据不丢的需求，当然这个方案也并不完美，问题如下，
1. 无法保证exactly-once，只能保证least-once
因为发生异常的10小时中，还是有比较少量的日志数据是被成功写入的， replay时，这部分数据会重复。
2. 读取了部分不需要被replay的数据
为了简单处理，我们的catchup job是从earliest offset开始读的，并在业务bolt里面进行过滤。
更好的方式，是定期在kafkaspout中对已处理的offset做checkpoint（比如分钟级别），
然后恢复的时候，可以从某个checkpoint开始读，这样更精确些，但方案上会复杂很多。
我们最终通过这种方案找回了丢失的用户sql日志，可以作为一种思路给大家借鉴。
cap理论对于流式处理仍然奏效，并没有被beat。
对于流式处理这样强调高数据可用性的场景，要保证数据的强一致性是需要依赖于外部系统的replay能力的，并且对于海量数据是要付出很大的资源代价的（存储和处理）。
实战中，我们通过一定tradeoff，可以做到在有限资源的情况下，保证流式处理中发生故障时，仍然可以保证least-once的一致性。
本文章摘自博客园，原文发布日期：2015-07-30