简述传统的数据批处理架构和Lambda架构计数

大规模的计数任务在实践中出乎意料的困难，本文主要介绍传统的批处理架构实现计数任务和基于Lambda架构实现计数。

传统的批处理架构：

持续读取数据的数据流每小时创建一次文件，这些文件通常被存储在HDFS或MapR-FS等分布式文件系统中。由调度程序安排批处理作业，用定期运行的批处理作业来实现应用程序的持续性。数据被持续地分割为文件；然后批处理作业将文件作为输入，分析计算最近生成的一个文件，然后输出计数结果，以此达到持续处理数据的效果。

这个架构主要存在以下问题：

太多独立的部分：

为了计算数据中的事件数，这种架构动用了太多的系统。每一个系统都有学习成本和管理成本，还可能存在预知不到的bug。

对时间的处理方法不明确：

假设需要设为每30分钟计数一次。这个变动涉及工作流调整逻辑，从而使DevOps问题与业务需求混淆。

预警：

假设除了每小时计数一次之外，还需要尽可能早地收到计数预警。为了做到这一点，可以在定期运行的批处理作业之外，引入Strom来采集消息流，Strom实时提供近似的计数，批处理作业每小时提供准确的计数。但是这样一来就向架构增加了他一个系统，以及与之相关的新编程模型。

乱序事件流：

在实践事件中，大多数事件流都是乱序的，即事件的实际发生顺序和数据中心所记录的顺序不一样，这就意味着本属于前一批的事件可能被错误地归入当前一批，并且批处理架构很难解决这个问题。

批处理作业的界限不清晰：

‘每小时’的定义含糊不清分个时间点实际上取决于不同系统之间的交互。充其量也只能做到大约每小时分割一次，而在分割时间点前后的事件既可能被归入前一批，也可能被归入当前一批。将数据以小时为单位进行分割，实际上是最简单的方法。

Lambda架构：

Lambda架构用定期运行的批处理作业来实现应用程序的持续性，并通过流处理器获得预警。流处理器实时提供近似结果；批处理层最终会对近似结果予以纠正。

Lambda架构存在的问题：

开发周期长：

需要维护两套分别跑在批处理和实时计算系统上面的代码，当数据源发生变更时，需要同时对俩套代码进行更改

数据口径不一致：

由于批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，需要经常进行数据核查和数据对比。

下一篇介绍一种全新的计数架构：Kappa架构