跳到主要内容

4 篇博文 含有标签「用户案例」

User stories

查看所有标签

搜索引擎实时构建案例

· 阅读需 8 分钟
John Li
John Li
Chief Executive Officer

作者介绍

Ceven,德勤乐融(北京)科技有限公司 邮箱likailin@deqinyuerong.com

前言

CloudCanal 近期提供了自定义代码构建宽表能力,我们第一时间参与了该特性内测,效果不错。开发流程详见官方文档 《CloudCanal自定义代码实时加工》

能力特点包括:

  • 灵活,支持反查打宽表,特定逻辑数据清洗,对账,告警等场景
  • 调试方便,通过任务参数配置自动打开 debug 端口,对接 IDE 调试
  • SDK 接口清晰,提供丰富的上下文信息,方便数据逻辑开发

本文基于我们业务中的实际需求(MySQL -> ElasticSearch 宽表构建),梳理一下具体的开发调试流程,希望对大家有所帮助。

场景描述

MySQL 擅长关系型数据操作,我们在其中存储了 product, tag, product_tag_mapping 表数据,用以表示产品标签之间多对多关系。精简的数据结构如下:

88ae6c35-4519-4d51-b725-d05765d67b06-image.png

ElasticSearch 擅长搜索,但是并不支持不同索引间的联合查询, 所以构造宽表是业界刚需。我们存储其上的产品索引结构如下:

PUT es_product
{
"mappings" : {
"properties" : {
"id" : {
"type" : "integer"
},
"name" : {
"type" : "text"
},
"tags" : {
"type" : "nested",
"properties" : {
"id" : {
"type" : "integer"
},
"name" : {
"type" : "text"
}
}
}
}
}
}

同步策略

CloudCanal 在 同步 MySQL -> ElasticSearch 数据过程中,会兼顾全量增量两种情况,我们可以创建两个独立的任务,分别同步产品的基础信息和附加信息(即标签信息)。

  • 基础信息任务

    • 使用基本的映射关系,将 MySQL 中的 product 数据表,映射到 es_product 索引中,即可保证全量和增量的数据同步。
  • 附加信息任务

    • 创建 CloudCanal 任务将 MySQL 中的 product_tag_mapping 数据表映射到 es_product 索引中,同步过程中反查源数据库中的 tag 信息,构造宽表数据,填充进 es_product 索引,实现附加信息全量和增量的数据同步。

实现步骤

1. MySQL 表结构初始化

# 创建产品信息表
CREATE TABLE `product` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '' COMMENT '名称',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='产品信息记录表';

# 创建标签信息表
CREATE TABLE `tag` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(64) COLLATE utf8_unicode_ci NOT NULL DEFAULT '' COMMENT '名称',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='标签信息记录表';

# 创建产品标签关系表
CREATE TABLE `product_tag_mapping` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`product_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '产品ID',
`tag_id` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '标签ID',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='产品标签关系表';

2. MySQL 填充测试数据

# 填充产品信息
INSERT INTO `product` (`name`)
VALUES
('product_1');

# 填充标签信息
INSERT INTO `tag` (`name`)
VALUES
('tag_1'),
('tag_2');

# 填充产品标签关系信息
INSERT INTO `product_tag_mapping` (`product_id`, `tag_id`)
VALUES
(1, 1);

3. ElasticSearch 索引创建(也可以使用 CloudCanal 结构迁移)

PUT es_product
{
"mappings" : {
"properties" : {
"id" : {
"type" : "integer"
},
"name" : {
"type" : "text"
},
"tags" : {
"type" : "nested",
"properties" : {
"id" : {
"type" : "integer"
},
"name" : {
"type" : "text"
}
}
}
}
}
}

4. 编写自定义代码

自定义代码的项目基于 maven 构建,可以参考 示例项目 cloudcanal-sdk-demos

4.1 修改 Maven 配置

初始化的项目需要手工配置一下 pom.xml 文件,将 sdk 指向本地目录文件,代码片段如下

<dependency>
<groupId>com.clougence.cloudcanal</groupId>
<artifactId>cloudcanal-sdk</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>system</scope>
<systemPath>
/path/to/your/project/src/main/resources/lib/cloudcanal-sdk-2.0.0.9-SNAPSHOT.jar
</systemPath>
</dependency>

4.2 实现 Tag 类

public class Tag {
private int id;
private String name;

public int getId() {
return id;
}

public void setId(int id) {
this.id = id;
}

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}

4.3 实现 Processor 处理逻辑

        @Override
public List<CustomRecord> process(List<CustomRecord> list, CustomProcessorContext context) {
DataSource dataSource = (DataSource) context.getProcessorContextMap().get(RdbContextKey.SOURCE_DATASOURCE);
String stage = context.getProcessorContextMap().get("currentTaskStage").toString();

for (CustomRecord record : list) {
try (Connection connection = dataSource.getConnection(); Statement statement = connection.createStatement()) {

// 由于 ES 的嵌套结构会被认为是独立的文档,故需要填充旧的数据
ResultSet rs = statement.executeQuery("SELECT `tag`.`id`, `tag`.`name`" +
" FROM `product`.`product_tag_mapping` AS `mapping`" +
" LEFT JOIN `product`.`tag` AS `tag` ON `tag`.`id` = `mapping`.`tag_id`" +
" WHERE `mapping`.`product_id` = " + record.getFieldMapAfter().get("product_id").getValue()
);

List<Tag> tags = buildTags(rs);
if ("INCREMENT".equals(stage)) {
// 增量创建的 product_tag_mapping 处于内存中,无法通过 SQL 语句查询得到,故需要单独处理
rs = statement.executeQuery("SELECT `id`, `name` FROM `product`.`tag` WHERE `id` = " + record.getFieldMapAfter().get("tag_id").getValue().toString());
List<Tag> newTags = buildTags(rs);
tags.add(newTags.get(0));
}

ObjectMapper mapper = new ObjectMapper();
String json = mapper.writeValueAsString(tags);
Map<String, Object> tagField = new LinkedHashMap<>();
tagField.put("tags", json);
RecordBuilder.modifyRecordBuilder(record)
.addField(tagField)
.build();
} catch (SQLException | JsonProcessingException e) {
e.printStackTrace();
}
}
return list;
}

private List<Tag> buildTags(ResultSet rs) throws SQLException {
List<Tag> tags = new ArrayList<>();
while (rs.next()) {
Tag tag = new Tag();
tag.setId(rs.getInt("id"));
tag.setName(rs.getString("name"));
tags.add(tag);
}
return tags;
}

4.4 编译自定义代码包

执行如下命令编译生成自定义代码包, 之后会在 target 目录中生成 jar 文件

mvn clean package -Dmaven.test.skip=true -Dmaven.compile.fork=true

5. 创建 CloudCanal 任务

5.1 同步 product 基础数据

全量增量同步 product 信息到 es_product 索引,在此就不做具体描述,详情请参考 CloudCanal 文档。

此时查询产品数据,得到结果

787f8ce4-6ad8-4d57-8a05-5694c705fed1-image.png

5.2 扩展 product tag 数据

5.2.1 配置数据源和目标

b8b1f5ec-3e3c-4620-ba87-ba224ca265e1-image.png

5.2.2 配置规格

可去掉自动启动任务选项,以便于单步追踪调试 8b1e059d-b4cb-4795-b27e-50cb5ae2c2a3-image.png

5.2.3 配置索引映射

5a6703b0-78ac-4956-a9bf-e21da3ba004d-image.png

信息
  • 这里我们不订阅tag表的delete事件,如果订阅会把对端对应的整个doc删除
  • tag表的变更我们是采用了另外一个CloudCanal同步任务,自己去写对端ES,这样可以对tag的更新更加精细化控制
5.2.4 上传自定义代码

4b8abc11-5c10-4be5-932a-b4dfc6e7740f-image.png

f1e71074-7ce3-48ec-a162-b1814fe928bb-image.png

信息

创建任务时如果不上传自定义代码包,之后将无法上传,除非重建任务。

上传自定义代码,意味着创建特殊类型的任务,然后才会出现特殊的选项进行字段映射。

5.2.5 配置字段映射

将 id 和 tag_id 调整为 "只订阅不同步"(老版本此处会显示为仅供自定义代码使用),实现只订阅这两个字段,而不会真正写入到 ES 索引,而将 product_id 映射到对端的 id。 1ec04979-b240-4953-8026-dbecbde0c886-image.png

设置映射 _id,以指定目标 ES 索引中的 id 为 product_id

513633e9-a603-43d5-b9f1-6d6b7b0cd504-image.png

b1419349-20cc-4c4d-a09b-a75bc7a9218b-image.png

信息

product_id 字段必须做映射,否则即使配置了 _id 信息,依旧无法正常执行,会忽略 product_id 字段的值。

6. 同步结果

87ec9e06-17ac-4bed-b307-79e17cca03ea-image.png

调试自定义代码

自定义代码在开发阶段最麻烦的事情是如何高效进行调试,CloudCanal 能够比较友好的让开发在本地直接调试代码逻辑。

修改任务参数

任务详情->参数修改

f3f59272-9b6a-40f9-ac3e-618782833676-image.png

00072b56-dbe0-4ce0-939a-7e22141419d5-image.png

信息

每次修改完参数信息之后,必须点击生效配置和重启任务;

在任务详情配置中,也可以上传新的代码包,激活和重启任务后可以使用。

配置 IntelliJ IDEA Debug 模式

b29b139e-1ffb-409c-bad5-6ee7ae76863b-image.png

信息

设置好断点以后,需要先启动 CloudCanal 任务,再点击 debug 按钮,才能 Attach 到远程的 8787 端口;

CloudCanal 会一直 pending,直到有 Attachment,才会继续执行,所以不需要单步跟踪调试时,一定记得关闭调试模式,否则任务无法执行。

总结

CloudCanal 自定义代码能够拓展的能力具有不错的想象空间,我们甚至能加入一些在线业务逻辑的处理,让业务需求能够更好的满足,同时配合社区版调试也很方便。希望未来这块能力在便利功能,性能等层面有更好的表现。

参与内测

CloudCanal 会不断提供一些预览的能力,包括新数据链路, 优化能力,功能插件。本文所描述的自定义代码能力目前也处于内测阶段。如需体验,可添加我们小助手(微信号:suhuayue001)进行了解和试用。 1637115735483.jpg

宽表实时构建案例

· 阅读需 11 分钟
Barry
Chief Technology Officer

作者介绍

蒋鹏程,苏州万店掌软件技术有限公司

前言

CloudCanal 近期提供了自定义代码构建宽表能力,我们第一时间参与了该特性内测,并已落地生产稳定运行。开发流程详见官方文档 《CloudCanal自定义代码实时加工》

能力特点包括:

  • 灵活,支持反查打宽表,特定逻辑数据清洗,对账,告警等场景
  • 调试方便,通过任务参数配置自动打开 debug 端口,对接 IDE 调试
  • SDK 接口清晰,提供丰富的上下文信息,方便数据逻辑开发

本文基于我们业务中的实际需求(MySQL -> ElasticSearch 宽表构建),梳理一下具体的开发调试流程,希望对大家有所帮助。

使用案例

案例一:商品表和SKU宽表行构建

业务背景

在对接用户的小程序进行商品搜索时,需要如下几个能力

  1. 基于分词的全文索引
  2. 同时搜索不同表中的字段

需要全文索引的初衷是希望用户搜索商品的关键词就可以搜索到想要的商品。这在传统数据库中一般支持的都比较弱甚至不支持,因此需要借助 ES 分词器搜索

而第二个能力主要是由于业务数据通常分布在多个表中,但是 ES 并不能像需要关系型数据库那样联表查询,CloudCanal 自定义代码的能力则整号解决了我们多表关联的痛点。

业务流程

在使用 CloudCanal 总体的流程变得十分清晰,在 CloudCanal 层面通过订阅表结合自定义代码中的反查数据库以及数据处理,可以直接生成可以写到对端 ES 的宽表行。 17a3934d-3cb8-4682-9dc0-12d08ab69c8e-image.png

表结构

准备的 mysql 表结构如下,一个商品会对应多个 SKU,我们在对端创建好索引,其中的 sku_detail 保存一个商品关联的 SKU 信息,是一个典型的一对多场景。

ES mapping 中的字段对应主表 tb_enterprise_goods 中字段,额外新增的 sku_detail 字段就是我们需要从子表 tb_enterprise_sku 中同步的数据。

## 商品表
CREATE TABLE `tb_enterprise_goods` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(64) NOT NULL DEFAULT '' COMMENT '商品名称',
`enterprise_id` int(11) NOT NULL DEFAULT '0' COMMENT '企业id',
`goods_no` varchar(50) NOT NULL DEFAULT '' COMMENT '商家商品编号',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=9410 DEFAULT CHARSET=utf8mb4;
## SKU表
CREATE TABLE `tb_enterprise_sku` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`enterprise_goods_id` int(11) NOT NULL COMMENT '企业商品id',
`name` varchar(255) NOT NULL DEFAULT '' COMMENT 'sku{1:2,2:1}',
`sku_no` varchar(255) DEFAULT '' COMMENT '商品sku编码',
`scan_goods` varchar(255) CHARACTER SET utf8 NOT NULL DEFAULT '' COMMENT 'sku条形码',
PRIMARY KEY (`id`),
) ENGINE=InnoDB AUTO_INCREMENT=14397 DEFAULT CHARSET=utf8mb4 COMMENT='企业 sku';

ES 索引如下:

      "enterprise_id": {
"type": "integer"
},
"goods_no": {
"type": "text",
"analyzer": "custom_e",
"fields": {
"keyword": {
"type": "keyword"
}
}
},
"id": {
"type": "integer"
},
"name": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_smart",
"fields": {
"standard": {
"type": "text",
"analyzer": "standard"
},
"keyword":{
"type": "keyword"
}
},
"fielddata": true
},
"sku_detail": {
"type": "nested",
"properties": {
"id": {
"type": "integer"
},
"sku_no": {
"type": "text",
"analyzer": "custom_e",
"fields": {
"keyword": {
"type": "keyword"
}
}
},
"scan_goods": {
"type": "text",
"analyzer": "custom_e",
"fields": {
"keyword": {
"type": "keyword"
}
}
}

注:为了方便大家理解,此处表字段进行了缩减

自定义代码工作流程

36f7adfb-ece5-4411-9926-d2cd0262aa3e-image.png

自定义代码源码

public List<CustomRecord> addData(CustomRecord customRecord, DataSource dataSource) {
List<CustomRecord> customRecordList=new ArrayList<>();
String idStr = (customRecord.getFieldMapAfter().get("id")).toString();
List<EnterpriseSku> enterpriseSkuList = tryQuerySourceDs(dataSource, Integer.valueOf(Integer.parseInt(idStr.substring(idStr.indexOf("=") + 1, idStr.indexOf(")")))));
if (enterpriseSkuList.size() > 0) {
Map<String, Object> addFieldValueMap = new LinkedHashMap<>();
addFieldValueMap.put("sku_detail", JSONArray.parseArray(JSON.toJSONString(enterpriseSkuList)));
RecordBuilder.modifyRecordBuilder(customRecord).addField(addFieldValueMap);
}
customRecordList.add(customRecord);
return customRecordList;
}

public List<CustomRecord> updateData(CustomRecord customRecord, DataSource dataSource) {
List<CustomRecord> customRecordList=new ArrayList<>();
String idStr = (customRecord.getFieldMapAfter().get("id")).toString();
List<EnterpriseSku> enterpriseSkuList = tryQuerySourceDs(dataSource, Integer.valueOf(Integer.parseInt(idStr.substring(idStr.indexOf("=") + 1, idStr.indexOf(")")))));
if (enterpriseSkuList.size() > 0) {
Map<String, Object> addFieldValueMap = new LinkedHashMap<>();
addFieldValueMap.put("sku_detail", JSONArray.parseArray(JSON.toJSONString(enterpriseSkuList)));
RecordBuilder.modifyRecordBuilder(customRecord).addField(addFieldValueMap);
}
customRecordList.add(customRecord);
return customRecordList;
}

private List<EnterpriseSku> tryQuerySourceDs(DataSource dataSource, Integer id) {
try(Connection connection = dataSource.getConnection();
PreparedStatement ps = connection.prepareStatement("select * from `live-mini`.tb_enterprise_sku where is_del=0 and enterprise_goods_id=" + id)) {
ResultSet resultSet = ps.executeQuery();
BeanListHandler<EnterpriseSku> bh = new BeanListHandler(EnterpriseSku.class);
List<EnterpriseSku> enterpriseSkuList = bh.handle(resultSet);
return enterpriseSkuList;
} catch (Exception e) {
esLogger.error(e.getMessage());
return new ArrayList<>();
}
}

思路

customRecord 对象即自定义代码传入的参数,传入的 id 为子表 tb_enterprise_sku 的外键 enterprise_goods_id,查询出子表关于这个外键的所有数据,放入 addFieldValueMap 中,再利用源码提供的方法RecordBuilder.modifyRecordBuilder(customRecord).addField(addFieldValueMap),对 customRecord 进行加工。

创建任务步骤

新建源端对端数据源 660b46e7-f736-49ff-b368-63b88cb5dbb7-image.png 选择订阅表及同步到对端的索引 84454765-03f7-4b44-9304-679bb044f380-image.png 选择同步字段,选择自定义包 fcacf1a8-24c1-49e5-9d86-1f19835fbbab-image.png 完成创建任务

实现效果

{
"_index" : "live-mini_pro_enterprise_goods_sku_view",
"_type" : "_doc",
"_id" : "17385",
"_score" : 12.033585,
"_source" : {
"img" : "https://ovopark.oss-cn-hangzhou.aliyuncs.com/wanji/2020-11-30/1606786889982.jpg",
"category_name" : "无类目",
"is_grounding" : 1,
"del_time" : "2021-11-01T17:13:32+08:00",
"goods_no" : "",
"distribute_second" : 0.0,
"uniform_proportion" : 0,
"description" : "赠送私域直播流量转化平台万集&线上商城",
"video" : "",
"self_uniform_proportion" : 0,
"update_time" : "2021-11-01T17:13:32+08:00",
"allocate_video" : null,
"self_commission_properation" : 0.0,
"category_id" : 0,
"is_promote" : 0,
"price" : 0.03,
"is_distributor_self" : 0,
"limit_purchases_max_quantity" : 0,
"limit_purchases_type" : 0,
"is_del" : 0,
"is_distributor" : 0,
"activity_price" : 0.0,
"id" : 17385,
"stock" : 0,
"distribute_first" : 0.0,
"is_distribution_threshold" : 0,
"refund_configure" : 1,
"create_time" : "2021-11-01T17:13:32+08:00",
"scan_goods" : "",
"limit_purchases_cycle" : 0,
"is_sku" : 1,
"allocate_mode" : 0,
"sku_detail" : [
{
"scan_goods" : "",
"sku_no" : "",
"id" : "19943"
}
],
"enterprise_id" : 24,
"is_delivery" : 0,
"is_limit_purchases" : 0,
"name" : "测试商品测试商品测试商品测试商",
"goods_type" : 0,
"goods_order" : 0,
"ts" : "2021-11-01T17:16:42+08:00",
"delivery_price" : 0.0
}
}

案例二:订单表、商品表宽表构建

业务背景

小程序商城中需要展示猜你喜欢的商品,对猜你喜欢商品是根据用户购买商品的频率来决定,主要涉及订单表,订单商品表,用户表,商品表等,使用ES 查询同样面临多表无法 join 的问题,本案例中依然采用 CloudCanal 自定义代码同步为扁平化数据。

业务原使用技术及问题

同步 ES 的方案原先使用 logstash 的方式全量同步数据,由于数据量的问题,同步数据放在每日的凌晨,带来的问题为,数据同步不及时,并且只能是全量风险比较高。多次出现删除索引数据后并没有同步的情况。

表结构

CREATE TABLE `tb_order` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`order_sn` varchar(32) NOT NULL COMMENT '订单编号',
`user_id` int(11) NOT NULL COMMENT '用户 id',
`user_name` varchar(255) DEFAULT NULL COMMENT '用户名称',
`user_phone` varchar(11) DEFAULT NULL COMMENT '用户电话',
`store_id` int(11) NOT NULL COMMENT '门店 id',
`enterprise_id` int(11) DEFAULT '1' COMMENT '企业id',
`order_type` int(11) NOT NULL COMMENT '0:快递配送;1:门店自取; 2:美团配送即时单; 3:美团即时配送预约单;',
`order_status` tinyint(11) DEFAULT '0' COMMENT '原订单状态:1:未付款,3:待发货/待打包,5:(待收货/待取货),6:交易完成,7:订单失效,8:交易关闭, 13:用戶取消,18:商家强制关闭,19同意退款但是退款失敗(未用到),30:美团即时配送状态异常',
`total_price` decimal(10,2) DEFAULT '0.00' COMMENT '订单总价',
PRIMARY KEY (`id`,`total_goods_weight`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=18630 DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

CREATE TABLE `tb_order_goods` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL COMMENT '用户 id',
`order_id` int(11) NOT NULL COMMENT '订单 id',
`goods_id` int(11) NOT NULL COMMENT '订单商品 id',
`enterprise_goods_id` varchar(11) DEFAULT NULL COMMENT '企业商品id',
`name` varchar(512) DEFAULT '' COMMENT '订单商品名称',
`spec` varchar(100) DEFAULT NULL COMMENT '规格属性',
`img` varchar(100) DEFAULT '' COMMENT '订单商品图片',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=19159 DEFAULT CHARSET=utf8mb4 COMMENT='订单商品表';

ES 索引字段

"store_id":{
"type": "integer"
},
"user_id":{
"type": "integer"
},
"sex":{
"type": "integer"
},
"birthday":{
"type": "keyword"
},
"goods_name":{
"type": "text",
"analyzer" : "ik_max_word",
"search_analyzer" : "ik_smart",
"fields": {
"keyword":{
"type": "keyword"
}
},
"fielddata": true
},
"goods_type":{
"type": "integer"
},
"order_goods_id":{
"type": "integer"
},
"enterprise_goods_id":{
"type": "integer"
},
"goods_price":{
"type": "double"
},
"order_id":{
"type": "integer"
},
"order_create_time":{
"type": "date"
}

注:ES表结构中涉及多张表,为了方便举例,这边只贴出2张表。es_doc展示纬度为订单商品纬度。

实现流程

订阅订单表 3d95def3-3234-47f5-b626-89d95b868938-image.png 订阅字段 7574425f-6953-4640-9d0a-97c1403d07d7-image.png 画出横线的即为需要同步的字段,有一个点需要特别注意:ES 中需要展示的字段一定要勾上同步,不勾上的话在自定义代码中 add 后 也不会被同步 官方给出的解释为字段黑白名单。 这里有几个细节点,订阅的表的维度并非 ES 存储数据的维度,所以这边的 id 并不是 ES 的 _id,对于这种需要在源端同步必须传的字段,设置对端字段可以随意设置一个对端已有的字段,在自定义代码中可以灵活的去重新配置需要同步的字段。(如果设置默认,ES 的 index 会创建出这个字段,这显然不是我们想要看到的效果)

业务流程

12f805e2-e6d3-478e-b3e1-aaf989fcf59a-image.png

代码实现

查询扁平化数据

SELECT
to2.store_id,
tuc.id AS user_id,
tuc.sex AS sex,
tuc.birthday,
tog.NAME AS goods_name,
tog.goods_type,
tog.goods_id AS order_goods_id,
tog.goods_price,
tog.create_time AS order_create_time,
tog.id AS order_id,
tog.enterprise_goods_id AS enterprise_goods_id
FROM
`live-mini`.tb_order to2
INNER JOIN `live-mini`.tb_order_goods tog ON to2.id = tog.order_id
AND tog.is_del = 0
AND to2.user_id = tog.user_id
INNER JOIN `live-mini`.tb_user_c tuc ON to2.user_id = tuc.id
AND tuc.is_del = 0
WHERE
to2.is_del = 0
AND to2.id= #{占位}
GROUP BY tog.id

思路:自定义代码获取 order 表的主键后,查询上面的 SQL,先将原 customRecord 中数据删除,再以查询出的结果维度新增数据。修改的逻辑亦如此。

public List<CustomRecord> addData(CustomRecord customRecord, DataSource dataSource) {
List<CustomRecord> customRecordList=new ArrayList<>();
String idStr = (customRecord.getFieldMapAfter().get("id")).toString();
List<OrderGoods> orderGoodsList = tryQuerySourceDs(dataSource, Integer.valueOf(Integer.parseInt(idStr.substring(idStr.indexOf("=") + 1, idStr.indexOf(")")))));
RecordBuilder.modifyRecordBuilder(customRecord).deleteRecord();
if (orderGoodsList.size() > 0) {
for (OrderGoods orderGoods:orderGoodsList){
//添加需要的行和列
Map<String,Object> fieldMap=BeanMapTool.beanToMap(orderGoods);
customRecordList.add(RecordBuilder.createRecordBuilder().createRecord(fieldMap).build());
}
}
return customRecordList;
}

public List<CustomRecord> updateData(CustomRecord customRecord, DataSource dataSource) {
List<CustomRecord> customRecordList=new ArrayList<>();
String idStr = (customRecord.getFieldMapAfter().get("id")).toString();
List<OrderGoods> orderGoodsList = tryQuerySourceDs(dataSource, Integer.valueOf(Integer.parseInt(idStr.substring(idStr.indexOf("=") + 1, idStr.indexOf(")")))));
RecordBuilder.modifyRecordBuilder(customRecord).deleteRecord();
if (orderGoodsList.size() > 0) {
for (OrderGoods orderGoods:orderGoodsList){
//添加需要的行和列
Map<String,Object> fieldMap=BeanMapTool.beanToMap(orderGoods);
customRecordList.add(RecordBuilder.createRecordBuilder().createRecord(fieldMap).build());
}
}
return customRecordList;
}

private List<OrderGoods> tryQuerySourceDs(DataSource dataSource, Integer id) {
String sql="SELECT to2.store_id,tuc.id AS user_id,tuc.sex AS sex,tuc.birthday,tog.NAME AS goods_name,tog.goods_type,tog.goods_id AS order_goods_id,tog.goods_price,tog.create_time AS order_create_time,tog.id AS order_id,tog.enterprise_goods_id AS enterprise_goods_id FROM `live-mini`.tb_order to2 INNER JOIN `live-mini`.tb_order_goods tog ON to2.id = tog.order_id AND tog.is_del = 0 AND to2.user_id = tog.user_id INNER JOIN `live-mini`.tb_user_c tuc ON to2.user_id = tuc.id AND tuc.is_del = 0 WHERE to2.is_del = 0 and to2.id=";
try(Connection connection = dataSource.getConnection();
PreparedStatement ps = connection.prepareStatement(sql + id+" GROUP BY tog.id")) {
ResultSet resultSet = ps.executeQuery();
BeanListHandler<OrderGoods> bh = new BeanListHandler(OrderGoods.class);
List<OrderGoods> orderGoodsList = bh.handle(resultSet);
return orderGoodsList;
} catch (Exception e) {
esLogger.error(e.getMessage());
return new ArrayList<>();
}
}

实现效果

 {
"_index" : "live-mini-order-pro",
"_type" : "_doc",
"_id" : "359",
"_score" : 1.0,
"_source" : {
"goods_type" : 0,
"order_id" : 359,
"order_goods_id" : 450,
"order_create_time" : "2020-12-22T10:45:20.000Z",
"enterprise_goods_id" : 64,
"goods_name" : "【老客户专享】万店掌2021新年定制台历",
"sex" : 2,
"goods_price" : 1.0,
"user_id" : 386,
"store_id" : 1,
"birthday" : ""
}
}

写在最后

CloudCanal 的自定义代码很好地解决了我们多表关联同步 ES 的问题,简洁易用的界面和有深度的功能都令人印象深刻,期待 CloudCanal 更多新能力。关于 CloudCanal 自定义代码的能力,也欢迎大家与我交流。

数仓实时构建案例

· 阅读需 12 分钟
Barry
Chief Technology Officer

简述

本案例为国内某大健康领域头部公司真实案例(因用户保密要求,暂不透露用户相关信息)。希望文章内容对各位读者使用 CloudCanal 构建实时数仓带来一些帮助。

业务背景

大健康背景下,用户对报表和数据大屏的实时性能要求越来越高。以核酸检测为例,检测结果需要实时统计分析,并在决策大屏中进行可视化展现。数据的及时性直接关系到区域疫情防控的精准布施从而有效防止疫情的扩散,不容半点闪失。在此之上,业务的多样性和复杂性也对公司的研发和运维成本要求也越来越高。

例如疫情防控指挥决策大屏中,数据包括流调溯源数据、物资冷链数据、居住人口数据、重点人群数据、风险排查、隔离管控、核酸检测数据、疫苗接种数据。这些来源数据标准不一,分散的数据引发数据冗余、数据不一致、数据应用困难等问题,导致研发和运维成本的上升,需要通过一个良好的接入层将这些数据做汇总和统一管理。

在此背景下,我司在更高效数据ETL方式以及高性能数据分析工具选型方面不断尝试和创新。通过引入了 CloudCanal 和 StarRocks,在数仓建设、实时数据分析、数据查询加速等业务上实现了效率最大化。

业务架构

我司旗下拥有多款大健康产品。虽然各款产品的具体业务不同,但是数据流的链路基本一致:数据接入->数据处理与分析->数据应用

下面以 疫情防控系统 为例简单介绍其中数据流的生命周期:

  • 数据接入:首先疫情防控系统的数据主要是三个来源、人员数据、冷链数据、物资数据。这些数据经过统一标准化处理之后才能用于分析
  • 数据处理与分析:原始的数据经过整合和标准化,可以从数据分析出密接人员、密接关系图谱等信息
  • 数据应用:数据处理与分析的指标可以用于实时监控大屏、以及相关预警

e983e0f0-dfd8-4515-b2ba-d7ee0ea65860-image.png

原有技术架构以及痛点

针对疫情防控系统,我们最初选择 ClickHouse 作为分析层,通过 DataX + Flink CDC 的模式实现实时+离线数据同步。随着业务的迭代,这套架构已经无法满足我们的需求。

技术架构

12141ca7-3922-40d8-bea2-1ec34c396492-image (1).png

原有疫情防控的架构总体上分为四块,自底向上分别是:

  • 数据层:源端数据源主要是 MySQL 为主的关系型数据库。

    • 业务信息:以核酸检测业务功能为例,需要支撑单日 300万 核酸检测任务。要求支撑每秒 1000 并发

    • 技术信息:数据层采用 MySQL 主从同步,配置级架构如下:

3767de93-c8fb-48c4-81f9-85924f2609a2-image (2).png

  • 痛点:

    • MySQL 从库查询效率满足不了常规读操作,查询效率低下,急需数据查询加速
    • 研发人员大量的精力和时间放到了数据库查询优化上
    • 处理层:采用离线+实时的 lambda 架构。其中离线部分采用 DataX 和 Kettle 进行定时全量,迁移源端维表到分析层的宽表中。实时部分使用 Flink-CDC 获取增量数据,一般是用于加速中间数据和近期的热数据。离线和在线数据分别存储在 ClickHouse 不同表中,提供给业务侧查询使用。
  • 业务信息:

    • 离线:将报表、大屏、数据交换服务采用离线方式构建 DM 主题数据集市。使用到的就是Datax 工具结合实现。
    • 实时:使用 Flink CDC 将MySQL 数据1:1同步到 ClickHouse 中。程序端通过改造查询SQL将慢语句通过 ClickHouse 实现。

    技术信息: 整体架构如下

    5f4d1355-45ef-4329-a378-ce1f3f23776f-image.png

  • 痛点:

      • 报表、大屏、数据交换离线场景对数据的实时性要求越来越高。大部分场景已不适用DataX这种离线方案。
    • DataX 定时任务调度带来的运维成本和源库影响:各种定时调度任务大大增加了运维管理的难度;同时这种定时触发的 SQL 很容易产生慢 SQL 影响源端数据库的正常工作。
    • Flink CDC 通过主库 Binlog 同步时出现过锁表影响业务的情况,虽然之后替换为订阅从库解决,但是会出现延迟现象。
    • Flink CDC 运维成本较高:Flink CDC 实时同步机制需要研发人员专职进行维护。例如像源端新增字段这种DDL需求,研发需要不断调整调度任务才能确保业务正常运行。
    • 分析层:分析层会保存计算好的指标数据以及用于加速查询的中间结果数据。
  • 业务信息:

    • 搭建三台单体 ClickHouse,分别对应 报表业务、大屏业务、数据交换服务、数据查询加速。
    • 以大屏业务举例,前期由于需求变化大,研发直接使用 ClickHouse 对单表过亿的数据进行数据关联、分组统计。高并发情况下也造成 ClickHouse 出现 CPU 打满的情况。ClickHouse 慢语句如下图。

    8c921320-a124-4ca0-8b61-ce37145b26d4-image (1).png

  • 痛点:

    • 集群运维较复杂,需要使用Zookeeper 搭建ClickHouse集群,运维成本高。
    • SQL 语法不兼容 MySQL,开发上手门槛高、Join 不友好
    • 修改、删除以及数据去重性能损耗大:例如使用ReplacingMergeTree()引擎,需要处理重复数据同时去重对性能要求较高。
    • 并发能力差:单机ClickHouse在高并发下,CPU经常被拉满,出现崩溃情况。
      • 业务层:业务层主要是应用程序访问分析层的指标结果或者通过查询中间结果来加速查询性能。最终的查询结果会服务疫情防控系统的实时大屏、报表以及预警等相关数据服务。
      • Clickhouse集群运维门槛高,之前在20.3版本出现过DDL任务和查询陷入死锁BUG,造成集群故障,最后放弃集群方案。采用3个单机通过Flink-CDC负责数据同步。
  • 业务层

    • 业务信息:主要是BI业务(报表、大屏)、数据查询加速、数据交换。
    • BI业务:平台报表业务和大屏业务全部接入ClickHouse数据库。
    • 数据查询加速:通过监控MySQL慢语句将慢语句也接入ClickHouse进行查询呈现。
    • 数据交换:ClickHouse负责与第三方平台进行数据交换任务。

    数据源接入

    接入的监测数据分散在各个数据库实例和数据库中。我们遇到的问题主要是:

  • 结构迁移成本高:很多表是一对一同步的,每次需要人为在ClickHouse上进行建表,增加了数据接入的成本

  • 人工操作多:需要接入的表人工筛选成本大

  • 新增表接入不方便:新增表接入需要重新修改配置

    现有系统架构以及优势

    架构介绍

    998f1a33-c886-4624-82ba-d8c4e55a5958-image (2).png

    新架构层次划分与原有架构基本相同,我们对处理层与分析层的技术栈选型进行了一些调整。在原有架构中,我们使用DataX+FlinkCDC的方案实现了数据的实时与离线同步传输。在替换CloudCanal后,统一实时离线两套技术栈,减少了运维成本。分析层中,通过使用StarRocks替换ClickHouse,在性能,运维成本,业务扩展上也带来了极大的提升。

    新架构优势说明

    引入 CloudCanal 数据同步工具

    • 异构数据源接入效率高:提供了库表列裁剪映射、各种维度的筛选能力等
    • CloudCanal人性化的操作页面以及低代码操作方式,释放了业务线的研发人员
    • 结构迁移、全量、增量一体化
    • 监控、报警运维便利

    引入 StarRocks MPP 数据库

    OLAP 数据库产品选型

    针对于分析层的问题与挑战,我们着力于寻找一款高性能,简单易维护的数据库产品来替换已有的ClickHouse架构,同时也希望在业务层上能突破 ClickHouse 单表查询的限制,通过实时多表关联的方式拓展业务层的需求。

    目前市面上的 OLAP 数据库产品百花齐放,诸如 Impala、Druid、ClickHouse 及 StarRocks。在经过一些列的对比之后,我们最终敲定选择StarRocks替换原有的ClickHouse作为分析层的数据库引擎。

    d00ae345-1af5-46b2-accc-680928eed4db-image (3).png

    接入StarRocks

    StarRocks 是一款极速全场景MPP企业级数据库产品,具备水平在线扩缩容、金融级高可用,兼容 MySQL协议和 MySQL 生态,提供全面向量化引擎与多种数据源联邦查询等重要特性,在全场景 OLAP 业务上提供统一的解决方案,适用于对性能,实时性,并发能力和灵活性有较高要求的各类应用场景。

    经过初步的考量,我们认为,StarRocks 兼容 MySQL 协议与标准SQL,相比于 ClickHouse 对于业务开发人员更加友好。同时,强大的多表关联能力可以将原有的大宽表模型转换为星型/雪花模型,增加了建模的灵活性,更好的应对业务需求的迭代。在运维方面,自动化调度机制可以支持在线扩缩容,可以极大的减少在ClickHouse上的运维成本。

    分析层改造收益

    在引入 StarRocks 对系统进行升级改造后,极大程度的减少了原本 ClickHouse 中的慢查询。整体查询效率提升2~3倍。下面是生产环境业务中两张核心表。其中以我们一个典型的统计SQL为例,可以看到StarRocks带来了明显的性能提升。

    表名行数
    rhr_person_info3451483
    chm_children_should6036599

    ClickHouse侧执行SQL

    select count(0) from rhr_person_info a 
    inner join chm_children_should b
    on a.id=b.person_id
    where toDate(b.should_start) <= toDate('2022-03-01')
    and toDate(b.should_end) >= toDate('2022-03-02')
    and (credentials_number = '%zz%' or en_name like '%zz%')
    and create_type_code =2
    and is_deleted =0
    and district_id like '130926105%'

    StarRocks侧执行SQL

    --starrocks
    select count(0) from rhr_person_info a
    inner join chm_children_should b
    on a.id=b.person_id
    where date_format( should_start,'%Y-%m-%d') <= ('2022-03-01')
    and date_format( should_end,'%Y-%m-%d') >= ('2022-03-02')
    and (credentials_number = '%zz%' or en_name like '%zz%')
    and create_type_code =2
    and is_deleted =0
    and district_id like '130926105%'

    查询响应时间比较

    StarRocksClickHouse
    平均响应时间368ms3340ms

    在体验至极性能的同时,我们在维护性,灵活建模等方面也获得了极佳的体验:

    • StarRocks 兼容 MySQL5.7 协议和 MySQL 生态
    • 支持高并发分析查询
    • 不依赖于大数据生态
    • MPP 架构,分片分桶的复合存储模型
    • 运维简单,易用性强
    • 水平扩展,不依赖外部组件,方便缩扩容
    • 支持宽表和多表 Join 查询(复杂场景),数据查询秒级/毫秒级

    新架构效果说明

    服务器资源合理释放(以核酸检测业务为例)

    对比数据层处理层分析层
    原架构4台2台3台
    新架构2台1台3台

    人力成本的释放

    原架构在数据层和处理层研发人员工作占比为60%,每一个业务的调整需要与 DBA 一起测试查询 SQL,防止出现慢语句同时业务系统随着需求的增加经常有增加字段的需求,研发人员需要不断调整和发布 Flink CDC 调度。新架构只需要 ETL 工程师负责运维即可,体现了 CloudCanal 低代码和便捷的运维优势。

    运维成本的降低

    StarRocks 部署不需要大数据组件的支撑,部署运维都很简单。StarRocks 兼容Mysql生态,业务使用可直接使用Mysql JDBC 进行连接,不用再担心SQL语法差异问题。

    未来规划

    目前,我们已经上线了 2 个产品线的 StarRocks 集群,通过 CloudCanal 更好的实现了实时数仓的搭建,已经在公司内部进行推广,后续会有更多的应用落地。感谢 CloudCanal 团队和 StarRocks 团队提供专业的支持服务。

    参考链接

ORACLE实时同步案例

· 阅读需 4 分钟
John Li
John Li
Chief Executive Officer

作者介绍

本文作者来自天津北方汉王科技有限公司(以下简称“北方汉王”),北方汉王是由国家级区域性人才市场--中国北方人才市场(以下简称北方人才)与国内人工智能行业领域先行者--汉王科技股份有限公司(以下简称“汉王科技”)合资成立的人力资源技术与服务提供商,具备国内领先的人力资源业务技术服务能力。

业务背景

在新一代信息化系统建设的大背景下,一些老牌企业对线上办公流程要求越来越高,现有办公系统无法满足需要,研发新系统、并将老系统替换掉成为一个普遍需求。

但是这类系统功能多、影响广,在不影响公司正常运转的要求下,如何平滑切换是一个难题。本文介绍通过引入 CloudCanal ,顺利解决此类问题的实际应用和实践。

业务架构

老系统业务类型是人事管理,包含企业员工的合同管理、薪资管理、五险一金管理、人员分布管理等一系列功能。

在企业要求下,需要对人事管理系统在功能上进行新增和升级,其中涉及对老系统原有数据的重构。

技术架构

老系统数据库为 ORACLE,新系统的数据库为 MySQL,新老系统通过一台 ORACLE 数据库进行数据交换。

考虑到老系统存在如下客观问题 , 我们决定采用中间库形式进行数据交互。

  • 网络环境复杂
  • 需要生产数据持续服务和安全
  • 数据库数据使用逻辑不一致

老系统 ORACLE、中间库 ORACLE、新系统 MySQL 之间的数据流转方向和生命周期如下

  • 老系统将现有的数据表 转换格式 放入中间库,并将新产生的数据 实时同步 到中间库
  • 新系统将老系统需要的数据 实时同步 到中间库,再将中间库的数据 实时同步 回老系统数据库

数据同步方案对比

技术架构确认后,为了保证三个数据库之间数据同步达到实时、准确、稳定的效果,我们做了如下调研和对比。

初期使用 DataX

调研初期,我们首先接触到 DataX 工具,在实践中遇到如下问题

  • 生成配置文件比较繁琐,对于新手较为困难
  • 因为表结构变更,容易引起数据抽取失败
  • 适合离线数据抽取,没有增量同步

因为无法满足需求,放弃该方案。

引入CloudCanal 产品

引入 CloudCanal 产品之后,最大的感受是操作非常便利,另外可以很好的适配当下团队人员能力和运维压力,具体表现为以下几点

  • 通过界面即可完成迁移同步的配置,使用简单,上手容易
  • 结构迁移、全量、增量一体化,自动化
  • 任务管理功能完善,监控、报警一应具全,使得任务运维成本大大降低
  • 异构数据源接入效率高,提供标准的库表列裁剪映射、各种维度的筛选能力等,免去开发成本

我们在考虑 CloudCanal 在运维效率、研发成本、功能需求满足度的优势后,最终选择 CloudCanal 作为我们本次项目数据迁移同步工具。

业务成果

通过 CloudCanal 很好的解决了新老系统数据同步的问题,目前我们的新系统已经正式上线运行多月。后续会有更多的产品进行落地。感谢 CloudCanal 团队一直以来提供专业的支持服务。