CloudCanal 2.0.X 版本近期支持了宽表构建能力在数据预处理领域向前走了一步。
方案特点
本文以 MySQL 到 ElasticSearch6 单事实表双维表为案例介绍 CloudCanal 宽表构建和同步的操作步骤。
关系型数据库为了应对在线业务对于并发、毫秒级响应同时操作相对趋向 kv 化,一般基于关系范式进行设计通过外键或约定外键非物理约束进行关联。
当业务需求涉及到多张关联表(业务运营、报表、BI 需求)查询表的先后顺序成为操作响应时间的关键要素但排列组合式种类随关联表数量(n)增加会膨胀非常快(n!)导致查询效率低下。
关联表数量 | 排列种类 |
---|---|
2 | 2 |
3 | 6 |
4 | 24 |
5 | 120 |
6 | 720 |
7 | 5040 |
8 | 40320 |
10 | 403200 |
11 | 4435300 |
数据库或者数仓做 join 查询特别是5张表以上最难的事情变成了如何从这么多可能性中搜索空间找到最好的那一个。
数据迁移和同步 以相对比较小的代价将多张关联表进查询库或者数据仓库之前通过反查或者窗口等待变更数据做关联打成一张宽表写入对端显著减轻后续查询对于 SQL 优化器的要求。
这里的宽表种类指其数据来源表种类(常见但不全面)常见的我们分 事实表 和 维度表,比如订单表被定义成事实表用户表被定义成维度表商品表被定义成维度表。
一般事实表和维度表数据具备类似 n:1 的关系也就是 1 个用户会有 n 个订单 (1个订单属于1个用户)1 个商品也会存在 n 个订单 (1个订单会关联 1 个或有限个数商品)。
打宽表的方式有多种根据场景最常见的包含以下两种
CloudCanal 目前打宽表的方式主要通过反查实现对于多流 join , 实际上也可以通过反查实现只是可能缺乏数据一致性。
进入工程目录使用命令进行打包
% pwd /Users/zylicfc/source/product/cloudcanal/cloudcanal-data-process % mvn -Dtest -DfailIfNoTests=false -Dmaven.javadoc.skip=true -Dmaven.compile.fork=true clean package
目前我们提供的基础模式维表变化不会直接触发事实表更新因为这个基本上意味着大规模对端数据变更可能影响对端数据服务稳定性。所以源端触发事实表更新比如变更一个时间字段带上最新的维表数据进行对端数据刷新。
另外对于维表数据的删除如果触发事实表更新从而刷新对端数据则默认置为null。
如果能打包不会 java 开发在 cloudcanal-data-process 寻找相应模版修改配置即可。
如果不能打包也不会开发找 CloudCanal 同学协助。
如果会 java 开发建议打开任务的 printCustomCodeDebugLog 观察输出的数据是否符合预期如果不符合预期可以打开任务的 debugMode 参数对数据转换逻辑进行调试。
如果不会 java 开发, 找 CloudCanal 同学协助。
这个是 CloudCanal 通用能力只要源和目标之间实现了全量迁移和增量同步即支持。
本文简单介绍了如何使用 CloudCanal 进行 MySQL -> ElasticSearch 的宽表构建以最常见的单事实表多维表方式举例。各位小伙伴如果觉得还不错请点赞、评论加转发吧。