数据库
首页 > 数据库> > MySQL 到 ElasticSearch 宽表构建和同步CloudCanal实战

MySQL 到 ElasticSearch 宽表构建和同步CloudCanal实战

作者:互联网

简述

CloudCanal 2.0.X 版本近期支持了宽表构建能力,在数据预处理领域向前走了一步。

方案特点

本文以 MySQL 到 ElasticSearch6 单事实表双维表为案例,介绍 CloudCanal 宽表构建和同步的操作步骤。

技术点

打宽表的必要性

关系型数据库为了应对在线业务对于并发、毫秒级响应,同时操作相对趋向 kv 化,一般基于关系范式进行设计,通过外键或约定外键(非物理约束)进行关联。

当业务需求涉及到多张关联表(业务运营、报表、BI 需求),查询表的先后顺序成为操作响应时间的关键要素,但排列组合式种类随关联表数量(n)增加会膨胀非常快(n!),导致查询效率低下。

关联表数量排列种类
22
36
424
5120
6720
75040
840320
10403200
114435300

数据库或者数仓做 join 查询(特别是5张表以上),最难的事情变成了如何从这么多可能性中(搜索空间)找到最好的那一个。

数据迁移和同步 以相对比较小的代价,将多张关联表进查询库或者数据仓库之前,通过反查或者窗口等待变更数据做关联,打成一张宽表写入对端,显著减轻后续查询对于 SQL 优化器的要求。

宽表的种类和方式

这里的宽表种类指其数据来源表种类(常见但不全面),常见的我们分 事实表维度表,比如订单表被定义成事实表,用户表被定义成维度表,商品表被定义成维度表。

一般事实表和维度表数据具备类似 n:1 的关系,也就是 1 个用户会有 n 个订单 (1个订单属于1个用户),1 个商品也会存在 n 个订单 (1个订单会关联 1 个或有限个数商品)。

打宽表的方式有多种,根据场景,最常见的包含以下两种

CloudCanal 目前打宽表的方式主要通过反查实现,对于多流 join , 实际上也可以通过反查实现,只是可能缺乏数据一致性。

举个 '栗' 子

前置条件:

开发宽表代码

打包

自定义代码包

添加数据源

任务创建

校验数据

数据变化规律

FAQ

维表变化后怎么办?

目前我们提供的基础模式,维表变化不会直接触发事实表更新,因为这个基本上意味着大规模对端数据变更,可能影响对端数据服务稳定性。所以源端触发事实表更新(比如变更一个时间字段),带上最新的维表数据进行对端数据刷新。

另外对于维表数据的删除,如果触发事实表更新从而刷新对端数据,则默认置为null。

不会开发 java 代码怎么办?

如果能打包不会 java 开发,在 cloudcanal-data-process 寻找相应模版,修改配置即可。

如果不能打包也不会开发,找 CloudCanal 同学协助。

如果遇到出错或者问题怎么办?

如果会 java 开发,建议打开任务的 printCustomCodeDebugLog 观察输出的数据是否符合预期,如果不符合预期,可以打开任务的 debugMode 参数,对数据转换逻辑进行调试。

如果不会 java 开发, 找 CloudCanal 同学协助。

还支持其他数据源么?

这个是 CloudCanal 通用能力,只要源和目标之间实现了全量迁移和增量同步,即支持。

总结

本文简单介绍了如何使用 CloudCanal 进行 MySQL -> ElasticSearch 的宽表构建,以最常见的单事实表多维表方式举例。各位小伙伴,如果觉得还不错,请点赞、评论加转发吧。

更多精彩

社区快讯

CloudCanal-免费好用的企业级数据同步工具,欢迎品鉴。 了解更多产品可以查看官方网站http://www.clougence.com CloudCanal社区https://www.askcug.com/

标签:CloudCanal,事实,ElasticSearch,维表,MySQL,数据,宽表
来源: https://blog.csdn.net/wankaimingzj/article/details/122346301