拆解大数据总线平台DBus的系统架构

大体来说，Dbus支持两类数据源：

• RDBMS数据源
• 日志类数据源

一、RMDBMS类数据源的实现

以mysql为例子. 分为三个部分：

• 日志抽取模块
• 增量转换模块
• 全量拉取模块

1.1 日志抽取模块（Extractor）

mysql 日志抽取模块由两部分构成：

• canal server：负责从mysql中抽取增量日志。
• mysql-extractor storm程序：负责将增量日志输出到kafka中，过滤不需要的表数据，保证at least one和高可用。

我们知道，虽然mysql innodb有自己的log，mysql主备同步是通过binlog来实现的。而binlog同步有三种模式：Row 模式，Statement 模式，Mixed模式。因为statement模式有各种限制，通常生产环境都使用row模式进行复制，使得读取全量日志成为可能。

通常我们的mysql布局是采用 2个master主库（vip）+ 1个slave从库 + 1个backup容灾库 的解决方案，由于容灾库通常是用于异地容灾，实时性不高也不便于部署。

为了最小化对源端产生影响，我们读取binlog日志从slave从库读取。

读取binlog的方案比较多，DBus也是站在巨人的肩膀上，对于Mysql数据源使用阿里巴巴开源的Canal来读取增量日志。这样做的好处是：

• 不用重复开发避免重复造轮子
• 享受canal升级带来的好处

关于Canal的介绍可参考：https://github.com/alibaba/canal/wiki/Introduction 由于canal用户抽取权限比较高，一般canal server节点也可以由DBA组来维护。

日志抽取模块的主要目标是将数据从canal server中读出，尽快落地到第一级kafka中，避免数据丢失（毕竟长时间不读日志数据，可能日志会滚到很久以前，可能会被DBA删除），因此需要避免做过多的事情，主要就做一下数据拆包工作防止数据包过大。

从高可用角度考虑，在使用Canal抽取过程中，采用的基于zookeeper的Canal server高可用模式，不存在单点问题，日志抽取模块extractor也使用storm程序，同样也是高可用架构。

不同数据源有不同的日志抽取方式，比如oracle，mongo等都有相应的日志抽取程序。

DBus日志抽