InfoQ|重新思考日志：业务系统竟然是一个大数据库？( 三 )

本文插图
每个数据源都可以按照它的日志来建模，将数据源上发生的事件看作是连续的日志事件，即所谓的日志流。所有需要这些数据的系统就各自去订阅日志流，各自按照自己的需求、节奏来选择消费数据的量和速度。
批处理与流处理书中提到一个很不错的例子：人口普查。人口普查的做法很像归并排序，先在最低级别的行政区域内挨家挨户搜集信息，聚合数据，然后逐层向上汇报，最终得到人口估计值。但这个过程通常十分漫长，每一层级人口数据的聚合都需要等待下级汇报的结果，等到最终得到人口普查结果时，其实又已经有很多人口出生了。这是典型的批处理场景。如果是流式处理该怎么做？每当有一个人出生或死亡，就直接上报到统计中心，由统计中心动态地聚合数据，理想情况下可以得到人口在每个时刻的规模。这就是典型的流处理场景。
日志与 ETL、数仓数据仓库以适合离线数据分析的方式将企业内部的所有数据结构化地集成到一起，这是一个伟大的想法。数仓的建设需要周期性地从各种源数据库中抽取 (Extract) 数据，转化 (Transform) 成更好理解的形式，最后加载 (Load) 进中心化的数据仓库。一个存储所有企业数据的中心数据仓库内部拥有许多等待挖掘的价值。
然而，这种通过批处理的将数据整合到一起的方式并不能解决所有问题，其短板在于，一些消费数据的系统需要更加实时的反馈，比如搜索引擎建立索引、推荐系统持续优化、监控系统实时观察。将数据集成到一起的思想仍然是伟大的，但我们也许能够找到弥补批处理方案缺点的其它方案，来满足特点不同的数据需求，这就是日志为中心的方案。

本文插图
在这样的设计中，原来在 ETL 中的数据转化的工作应该放到哪个位置？大致有以下几种选择：

数据生产者在将数据写入日志系统前
对原始日志进行实时流式处理
在最终加载到数据消费系统时

其实这里我们并不需要做三选一的决定，而是将 ETL 的工作分类后分别放入这三部分中。数据生产者在生产数据时，需将数据转化成与系统内部逻辑无关的数据结构；在实时流式处理的过程中，可以将数据补充 (如 join) 的工作放入其中；在数据消费系统可以做最终的数据聚合 (aggregation) 。
日志与流处理为什么需要日志日志与流处理是两个互相独立的概念。我们可以让分布式系统中的不同进程直接通信，直接实现流处理，那么我们为什么需要日志？有三个方面原因：

每个数据集可以被多个需求方订阅
维护单个消费者消费数据的先后顺序
提供缓冲区，让生产和消费的过程解耦

The Lambda ArchitectureNathan Marz 基于以日志为中心的思想，提出了 Lambda Architecture ，来同时满足流处理和批处理需求，如下图所示：

本文插图
数据流同时被打向两个系统，流处理系统和批处理系统。你需要分别在流处理系统和批处理系统实现两次相同的写入处理逻辑，两个系统处理后写入最终向外提供查询接口的数据库中 (可能是不同的数据库) 。 Lambda Architecture 的好处在于，原始的输入数据会被原封不动地保留，同时也为重处理 (reprocessing) 留下空间，重处理是很重要的的功能，逻辑会随着业务变化而变化，这时候就需要对历史数据重处理，解决存量问题。
Lambda Architecture 的劣势在于需要维护两份类似的处理逻辑，一份用于流处理，一份用于批处理。当然也许你希望基于流处理和批处理再抽象出一层通用语言，就能复用逻辑。但这并不现实，即便是 ORM 的场景，将不同关系型数据库的接口聚合，都会遇到各种抽象泄漏的情况，就更不用说这种底层差异更大的数据系统场景了。