spark streming流式计算一架构设计

      每一次分享文章都会纠结到底该从哪个地方开始讲起，为了组织语言和文章引体会想很长时间。引体写好后却没有了分享文章的欲望，最后就放弃了要写一篇文章的想法。流式计算技术分享也是想了很久，好几回编辑框都打开了最后还是放弃编写了。今天，终于决定要写一篇关于流式计算数据一致性保证的技术文档。

      因为计算延迟和数据量的问题，越来越多的团队将离线批处理任务转化成流式计算任务。在离线任务中不需要考虑数据容错以及数据一致性问题（增量计算部分设计)，一旦数据计算出现问题，再次重跑 就可以了。但是流式计算需要考虑这些繁琐的问题，在两年的流式计算任务的开发中踩了很多的坑，也做了很多方案来解决这些问题，今天决定把这些问题以及解决方案分享出来。希望对大家在设计流式计算任务时有所帮助。

      在流式计算架构设计中有两个问题必须考虑清楚才能这首进行开发，否则花费大量人力开发出来的流式计算任务，数次重启之后数据计算会出现大量误差，甚至发现不了计算误差，对整个业务线都会有很大的影响。再次重构这个代价还是相当沉重的。

      问题一：应用之间耦合性

       

     从技术角度上讲没有一个完美的架构适用于所有的场景，架构需要根据不同的场景设计不同的计算方案。大致可以将方案分为以上两大类。

第一种（左图）设计将所有相关的应用放在同一个sparkstream应用中，不同业务是不同子流（sparkStreaming)。这种设计调度起来比较方便，容错设计一次就可以了。从整体集群计算资源角度来看，对计算任务的计算资源比较节约。相同处理量和相同资源情况下，数据延迟也比较小，工作流依赖关系在代码中实现。代码更新和维护起来比较方便，当然太过庞大又会起到其他文虎。但是这种方案，却有一个致命的缺陷--业务模块间强耦合。任何一个业务需要升级或者出错，整个业务群牵连瘫痪，对于频繁更新的业务线和不稳定的集群就像是炸点一样，是不是某个点就会爆炸。

第二种（右图）将不同业务模块解耦通过kafka做消息中间件，这种设计将业务族群切分成自单独的spark streaming应用。好处是业务间耦合读比较低，同级业务出现问题或者更新代码，不会相互影响。缺点是依赖关系控制比较复杂，每个都需要设计容错模块，并且每个应用都需要预留cpu用来接受数据造成计算资源消耗大，kafka需要存储多次数据等问题。

这两种设计适用于不同的场景，做不同的偏向。

我们在开发过程中就遇到过需要使用第二中方式的场景，前端以600亿+每天的速度向kafka集群些数据。是关于运动轨迹和停留的数据，每天会产生大量的数据，去重和数据计算完之后又有80%的数据可以删除。但是后续计算花费的时间比较长，逻辑经常被变更需要经常卸载流式更新再重启。假如采用第一种策略，一旦计算遇到计算卡顿或者应用出bug，流式停止超过3小时以上，限于kafka集群容量就会自动丢弃三四个小时之前的数据。这种就需要将数据清洗和数据处理分开成两个流式应用。由于数据清洗和去重规则比较稳定，不会有大的变更且逻辑简单，卸掉应用和当即的概率比较小。可以将清洗完的数据重新写到Kafka。由于处理后数据量比较小，对于业务模块即使频繁更新，长时间下线流式应用，也不会数据丢失数据。这样就很大程度上解决了数据丢失风险和出错的概率。到达数据预处理和业务处理解耦的目的。