江苏龙网

  1. 首页 > 人文 > >

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


实践中 ， 为了解决特定领域问题的数据系统层出不穷 ， 主要原因在于要构建一个通用的分布式数据库难度巨大 ， 将问题投影到具体的某个场景上能减小系统设计的复杂度 ， 使得系统的构建变得容易 。
拆分还是合并？这个巨型分布式数据库的未来会向什么方向发展？作者认为有3种可能：
当前状态的延续 ， 不同的系统继续处于割裂发展的状态 ， 用非系统性的方案解决系统之间的数据集成问题
所有系统逐渐走向一统 ， 也就不存在系统之间的数据集成问题
将开源项目视作乐高积木 ， 每个团队根据需求构建自己的巨型分布式数据库
重要的积木：日志在构建企业独特的巨型分布式数据库时 ， 如果有了日志这块积木 ， 其它系统的设计复杂度将得到降低 。 具体地说 ， 日志系统可以用来：
序列化并发更新 ， 处理数据一致性问题
支持节点间数据复制
向外部系统提供事务提交的语义
向外部系统提供日志订阅功能
向故障节点提供故障恢复能力
解决数据负载在节点间的平衡问题
…
解决了这些问题 ， 巨型分布式数据库的查询层就只需要完成索引构建、暴露统一API的工作 。 抽象地思考 ， 这个系统可以简单地分为两部分 ， Log和ServingNodes：
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
所有的数据直接写入Log(或被ServingNodes代理) ， 然后所有的ServingNodes通过订阅Log来建立索引 ， 向外提供数据服务 。 这种设计就是以日志为中心(log-centric)的设计：
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
这个系统本身可以直接通过流处理器(streamprocessor) ， 将日志流直接或与其它数据结合 ， 一同提供给其它索引服务 。 尽管Kafka、BookKeeper、Pulsar这些都是日志服务的候选 ， 但这里所述的以日志为中心的设计仅仅是一种思想 ， 你甚至可以利用类似DynamoDB来构建这样的日志服务 ， 只不过你可能需要做一些额外的工作来支持日志应该提供的功能和保证 。
日志与流处理、批处理数据集成数据集成(DataIntegration)的意思是：
让企业中的所有服务和系统能访问其需要的任意企业数据
我们可以类比马斯洛需求层次理论 ， 将企业对数据的需求也看作是一个金字塔状的结构：
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
最底层是数据的收集和查询 ， 让所有上层服务能够以简单、标准的形式读写 。 一旦数据的最基本需求得到满足 ， 就可以基于此进一步做数据语义解析、数据理解和自动化 。
数据集成的难点主要在以下两个方面：
数据的多元化：用户行为数据、机器指标统计、IoT相关数据等
数据系统的爆炸式增长：OLAP、搜索引擎、对象存储、批处理系统、图数据库等
解决问题的方式有很多种 ， 作者认为最自然的一种方案就是采用日志：
InfoQ|重新思考日志：业务系统竟然是一个大数据库？
文章图片
每个数据源都可以按照它的日志来建模 ， 将数据源上发生的事件看作是连续的日志事件 ， 即所谓的日志流 。 所有需要这些数据的系统就各自去订阅日志流 ， 各自按照自己的需求、节奏来选择消费数据的量和速度 。
批处理与流处理书中提到一个很不错的例子：人口普查 。 人口普查的做法很像归并排序 ， 先在最低级别的行政区域内挨家挨户搜集信息 ， 聚合数据 ， 然后逐层向上汇报 ， 最终得到人口估计值 。 但这个过程通常十分漫长 ， 每一层级人口数据的聚合都需要等待下级汇报的结果 ， 等到最终得到人口普查结果时 ， 其实又已经有很多人口出生了 。 这是典型的批处理场景 。 如果是流式处理该怎么做？每当有一个人出生或死亡 ， 就直接上报到统计中心 ， 由统计中心动态地聚合数据 ， 理想情况下可以得到人口在每个时刻的规模 。 这就是典型的流处理场景 。


推荐阅读


上一篇：国防时报排头兵|无人机出没！无人车穿梭！这场演练第一次见

下一篇：跨境电商小周|shopee不值的做？详细讲解，新手做跨境电商shopee的误区