在之前的数据同步中，好比咱们想实时获取数据库的数据，通常采用的架构就是采用第三方工具，好比canal、debezium等，实时采集数据库的变动日志，而后将数据发送到kafka等消息队列。而后再经过其余的组件，好比flink、spark等等来消费kafka的数据，计算以后发送到下游系统。

在国内，用的比较多的是阿里巴巴开源的canal，咱们可使用canal订阅mysql的binlog日志，canal会将mysql库的变动数据组织成它固定的JSON或protobuf 格式发到kafka，以供下游使用。

canal解析后的json数据格式以下：

{
  "data": [
    {
      "id": "111",
      "name": "scooter",
      "description": "Big 2-wheel scooter",
      "weight": "5.18"
    }
  ],
  "database": "inventory",
  "es": 1589373560000,
  "id": 9,
  "isDdl": false,
  "mysqlType": {
    "id": "INTEGER",
    "name": "VARCHAR(255)",
    "description": "VARCHAR(512)",
    "weight": "FLOAT"
  },
  "old": [
    {
      "weight": "5.15"
    }
  ],
  "pkNames": [
    "id"
  ],
  "sql": "",
  "sqlType": {
    "id": 4,
    "name": 12,
    "description": 12,
    "weight": 7
  },
  "table": "products",
  "ts": 1589373560798,
  "type": "UPDATE"
}

简单讲下几个核心的字段（属性）:

type : 描述操做的类型，包括‘UPDATE’, 'INSERT', 'DELETE'。
data : 表明操做的数据。若是为'INSERT'，则表示行的内容；若是为'UPDATE'，则表示行的更新后的状态；若是为'DELETE'，则表示删除前的状态。
old ：可选字段，若是存在，则表示更新以前的内容，若是不是update操做，则为 null。

在国外，比较有名的相似canal的开源工具备debezium，它的功能较canal更增强大一些，不只仅支持mysql。还支持其余的数据库的同步，好比 PostgreSQL、Oracle等，目前debezium支持的序列化格式为 JSON 和 Apache Avro 。

debezium format：

{
 "before": {
   "id": 111,
   "name": "scooter",
   "description": "Big 2-wheel scooter",
   "weight": 5.18
 },
 "after": {
   "id": 111,
   "name": "scooter",
   "description": "Big 2-wheel scooter",
   "weight": 5.15
 },
 "source": {...},
 "op": "u",
 "ts_ms": 1589362330904,
 "transaction": null
}

flink cdc connector

对于上面的架构，咱们须要部署canal（debezium）+ kafka，而后flink再从kafka消费数据，这种架构下咱们须要部署多个组件，而且数据也须要落地到kafka，有没有更好的方案来精简下这个流程呢？咱们接下来说讲flink提供的cdc connector。

这个connector并无包含在flink的代码里，具体的地址是在https://github.com/ververica/flink-cdc-connectors里，详情你们能够看下这里面的内容。

这种架构下，flink直接消费数据库的增量日志，替代了原来做为数据采集层的canal（debezium），而后直接进行计算，通过计算以后，将计算结果发送到下游。

使用这种架构是好处有：

减小canal和kafka的维护成本，链路更短，延迟更低
flink提供了exactly once语义
能够从指定position读取
去掉了kafka，减小了消息的存储成本

MySQLTableSource

在MySQLTableSource#getScanRuntimeProvider方法里，咱们看到，首先构造了一个用于序列化的对象RowDataDebeziumDeserializeSchema，这个对象主要是用于将Debezium获取的SourceRecord格式的数据转化为flink认识的RowData对象。咱们看下RowDataDebeziumDeserializeSchem#deserialize方法，这里的操做主要就是先判断下进来的数据类型（insert 、update、delete），而后针对不一样的类型（short、int等）分别进行转换，

最后咱们看到用于flink用于获取数据库变动日志的Source函数是DebeziumSourceFunction，且最终返回的类型是RowData。

也就是说flink底层是采用了Debezium工具从mysql、postgres等数据库中获取的变动数据。

changelog format

当咱们从mysql-cdc获取数据库的变动数据，或者写了一个group by的查询的时候，这种结果数据都是不断变化的，咱们如何将这些变化的数据发到只支持append mode的kafka队列呢?

因而flink提供了一种changelog format，其实咱们很是简单的理解为，flink对进来的RowData数据进行了一层包装，而后加了一个数据的操做类型，包括如下几种 INSERT,DELETE, UPDATE_BEFORE,UPDATE_AFTER。这样当下游获取到这个数据的时候，就能够根据数据的类型来判断下如何对数据进行操做了。

好比咱们的原始数据格式是这样的。

{"day":"2020-06-18","gmv":100}

通过changelog格式的加工以后，成为了下面的格式：

{"data":{"day":"2020-06-18","gmv":100},"op":"+I"}

也就是说changelog format对原生的格式进行了包装，添加了一个op字段，表示数据的操做类型，目前有如下几种：

+I：插入操做。
-U ：更新以前的数据内容：
+U ：更新以后的数据内容。
-D ：删除操做。

kafka connector和kafka-upsert connector的区别：

先创建一个kafka connector（sql）

CREATE TABLE KafkaTable (
  `user_id` BIGINT,
  `item_id` BIGINT,
  `behavior` STRING,
  `ts` TIMESTAMP(3) METADATA FROM 'timestamp'
) WITH (
  'connector' = 'kafka',
  'topic' = 'user_behavior',
  'properties.bootstrap.servers' = 'localhost:9092',
  'properties.group.id' = 'testGroup',
  'scan.startup.mode' = 'earliest-offset', // 消费的offset位置，也可以是latest-offset
  'format' = 'csv'
)

kafka connector就是kafka中数据是怎么样的，KafkaTable表中的数据就是什么样（kafka中的数据就是表数据导进去的，比如新建一个表连接器为kafka，然后往这个表insert数据就是往kafka中导入）

kafka中表的数据是这种格式：

{"user_id":"1","client_ip":"192.168.12.1","client_info":"phone","pagecode":"1001","access_time":"2021-01-23 11:32:24","dt":"2021-01-08"}
{"user_id":"1","client_ip":"192.168.12.1","client_info":"phone","pagecode":"1201","access_time":"2021-01-23 11:32:55","dt":"2021-01-08"}

kafka-upsert

首先我们要知道，kafka是只能往里面append数据的，不存在删改里面的数据情况

再解释下什么是changelog类型kafka，就是kafka topic中的消息（每一个来的数据）是带有一个属性的，这个属性标记数据是Insert、update before、update after、delete的，再根据主键来进行对sink kafka topic中的数据进行具体的操作，是插入，还是更新，还是删除。

当作为数据源时，upsert-kafka Connector会生产一个changelog流，其中每条数据记录都表示一个更新或删除事件。更准确地说，如果不存在对应的key，则视为INSERT操作。
如果已经存在了相对应的key，则该key对应的value值为最后一次更新的值。

用表来类比，changelog 流中的数据记录被解释为 UPSERT，也称为 INSERT/UPDATE，因为任何具有相同 key 的现有行都被覆盖。另外，value 为空的消息将会被视作为 DELETE 消息。

当作为数据接收器时，upsert-kafka Connector会消费一个changelog流。它将INSERT / UPDATE_AFTER数据作为正常的Kafka消息值写入(即INSERT和UPDATE操作，都会进行正常写入，
如果是更新，则同一个key会存储多条数据，但在读取该表数据时，只保留最后一次更新的值)，并将 DELETE 数据以 value 为空的 Kafka 消息写入（key被打上墓碑标记，表示对应 key 的消息被删除）。
Flink 将根据主键列的值对数据进行分区，从而保证主键上的消息有序，因此同一主键上的更新/删除消息将落在同一分区中。

上面的key指的是你建表时指定的primary key，不是kafka的key

flinkcdc笔记

flink cdc connector

MySQLTableSource

changelog format

kafka connector和kafka-upsert connector的区别：

kafka-upsert

猜你喜欢