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

更大的分布式数据库实际上，我们可以将企业中的所有数据、数据流以及数据系统合起来看作是一个巨型分布式数据库。所有原始数据表就是数据库中的基础数据；所有面向查询的系统都是基于这个数据库之上建立的索引，如 Redis、ElasticSearch、Hive tables 等等；流式处理系统，如 Flink、Storm、Samza ，是这个数据库中基于触发器的实体化视图机制 (trigger-and-view materialization mechanism)；日志系统就是数据库的操作日志，记录数据的变化。
实践中，为了解决特定领域问题的数据系统层出不穷，主要原因在于要构建一个通用的分布式数据库难度巨大，将问题投影到具体的某个场景上能减小系统设计的复杂度，使得系统的构建变得容易。
拆分还是合并？这个巨型分布式数据库的未来会向什么方向发展？作者认为有 3 种可能：
当前状态的延续，不同的系统继续处于割裂发展的状态，用非系统性的方案解决系统之间的数据集成问题
所有系统逐渐走向一统，也就不存在系统之间的数据集成问题
将开源项目视作乐高积木，每个团队根据需求构建自己的巨型分布式数据库
重要的积木：日志在构建企业独特的巨型分布式数据库时，如果有了日志这块积木，其它系统的设计复杂度将得到降低。具体地说，日志系统可以用来：

序列化并发更新，处理数据一致性问题
支持节点间数据复制
向外部系统提供事务提交的语义
向外部系统提供日志订阅功能
向故障节点提供故障恢复能力
解决数据负载在节点间的平衡问题
…

解决了这些问题，巨型分布式数据库的查询层就只需要完成索引构建、暴露统一 API 的工作。抽象地思考，这个系统可以简单地分为两部分， Log 和 Serving Nodes：

本文插图
所有的数据直接写入 Log (或被 Serving Nodes 代理) ，然后所有的 Serving Nodes 通过订阅 Log 来建立索引，向外提供数据服务。这种设计就是以日志为中心 (log-centric) 的设计：

本文插图
这个系统本身可以直接通过流处理器 (stream processor) ，将日志流直接或与其它数据结合，一同提供给其它索引服务。尽管 Kafka、BookKeeper、Pulsar 这些都是日志服务的候选，但这里所述的以日志为中心的设计仅仅是一种思想，你甚至可以利用类似 DynamoDB 来构建这样的日志服务，只不过你可能需要做一些额外的工作来支持日志应该提供的功能和保证。
日志与流处理、批处理数据集成数据集成 (Data Integration) 的意思是：
让企业中的所有服务和系统能访问其需要的任意企业数据
我们可以类比马斯洛需求层次理论，将企业对数据的需求也看作是一个金字塔状的结构：