大数据专题
文章平均质量分 82
本专栏将围绕hadoop生态圈逐一介绍和挖掘hdfs,yarn,hbase,hive,storm,spark等技术构架。
Laurence
架构师,著有《大数据平台架构与原型实现:数据中台建设实战》一书,对大数据、云计算、数据湖、数据中台、企业级应用架构、域驱动设计有丰富的实践经验。
展开
-
Hudi 多表摄取工具 HoodieMultiTableStreamer 配置方法与示例
由于 Hudi 的 HoodieMultiTableStreamer / HoodieMultiTableDeltaStreamer 是一次处理多张 Hudi 表的写入,这些表既会有如 hoodie.deltastreamer.source.kafka.value.deserializer.class 这样相同的公共配置,也会有如 hoodie.datasource.write.recordkey.field 这样每张表每张表都不同的个性化配置,为此,HoodieMultiTableStreamer / H原创 2024-05-22 14:14:24 · 2281 阅读 · 0 评论 -
CDC 数据实时同步入湖的技术、架构和方案汇总
最近,对“实时摄取 CDC 数据同步到数据湖”这一技术主题作了一系列深入的研究和验证,目前这部分工作已经告一段落,本文把截止目前(2024年5月)的研究结果和重要结论做一下梳理和汇总。为了能给出针对性的技术方案,我们必须收敛话题,对一些技术选型做了限制,在数据库这一侧,我们以 MySQL 作为示例进行演示(PG 等其他主流数据库理论上均可行),在数据湖这一侧,我们重点关注的是 Apache Hudi。原创 2024-05-27 09:20:18 · 3790 阅读 · 0 评论 -
CDC 实时入湖方案:MySQL>Kafka Connect>Kafka & Schema Registry>Hudi ( HoodieMultiTableStreamer )
本方案的技术链路为:使用 Kafka Connect 配合 Debezium MySQL Source Connector 将 MySQL 的 CDC 数据 (Avro 格式)接入到 Kafka ,然后通过 Hudi 的 HoodieMultiTableStreamer 将摄取的 CDC 数据写入到 Hudi 表中。整个链路由 Confluent Schema Registry 控制 Schema 的变更。本文和《CDC 实时入湖方案:MySQL > Kafka Connect > Kafka & Sche原创 2024-05-20 15:25:42 · 2496 阅读 · 3 评论 -
使用 HoodieMultiTableStreamer 进行 Debezium CDC 多表同步入湖的研究报告
先介绍一下大的背景吧,我们已经能通过 Flink CDC 将整个数据库同步到 Kafka 中了,这一部分的实现方案已经汇总在了 《Flink CDC 整库 / 多表同步至 Kafka 方案(附源码)》一文中。接下来要完成的是后半程的工作:读取 Kafka 的 Debezium CDC 数据写入到数据湖的 Hudi 表中,这样就能完整地实现整个数据库同步入湖的设计目标,当然,要求还是:“源库整库 / 多表 => Kafka”是一个作业,“Kakfa => Hudi 整库 / 多表”也是一个作业,这样才有比较强原创 2024-05-18 10:15:00 · 1029 阅读 · 0 评论 -
CDC 实时入湖方案:MySQL>Flink CDC>Kafka & Schema Registry>Hudi ( HoodieMultiTableStreamer )
本方案的技术链路为:使用 Flink CDC 将 MySQL 的 CDC 数据 (Avro 格式)接入到 Kafka ,然后通过 Hudi 的 HoodieMultiTableStreamer 将摄取的 CDC 数据写入到 Hudi 表中。整个链路由 Confluent Schema Registry 控制 Schema 的变更。本文和《CDC 实时入湖方案:MySQL > Flink CDC > Kafka & Schema Registry > Hudi ( Flink Connector ) 》介绍的原创 2024-05-19 10:15:00 · 1532 阅读 · 0 评论 -
Flink 生态对 Confluent / Kafka Schema Registry 支持情况的研究报告
这几年,在流式链路上引入一个 Schema Registry 变得越来越流行,也越来越有必要, Schema Registry 能有效控制 Schema 的变更,合理推进 Schema Evolution,同时,引入它以后还能有效精简消息内容(特别是针对 Avro 格式),提升消息的传输效率,所以引入 Schema Registry 是有很多正向收益的。在 Flink 生态中,对 Confluent Schema Registry 的支持度如何呢?本文,我们来详细地梳理和总结一下。有关的组件主要是 Flin原创 2024-05-17 09:18:50 · 1512 阅读 · 0 评论 -
Hudi HoodieStreamer 报错 DebeziumSource only support SchemaRegistryProvider 解决方法
在使用 HoodieStreamer / HoodieDeltaStreamer 从 Kafka 摄取 Debezium CDC 消息并自动解析写入到 Hudi 表时,我们可能会遇到这样一个问题:org.apache.hudi.utilities.sources.debezium.DebeziumSource only support org.apache.hudi.utilities.schema.SchemaRegistryProvider 这个问题本身的解决方法很简单,但是这个问题对整个 CDC 数据原创 2024-05-16 09:38:06 · 770 阅读 · 0 评论 -
Flink CDC 的 Debezium Json 消息中文乱码的解决方法
在使用 Flink CDC 的 API 摄取 CDC 数据到 Kafka 的时候,如果使用的是 JsonDebeziumDeserializationSchema,那么会有很大概率遇到中文乱码问题,下面就是一个示例原创 2024-05-14 10:36:00 · 533 阅读 · 0 评论 -
Hudi HoodieStreamer 报错 A column or function parameter with name ts_ms cannot be resolved 解决方法
在使用 HoodieStreamer 启动一个 CDC 数据实时入湖的作业中,遇到了这样一个报错:org.apache.spark.sql.AnalysisException:[UNRESOLVED_COLUMN.WITH_SUGGESTION] A column or function parameter with name ts_ms cannot be resolved. Did you mean one of the following? [after, op, before].; line原创 2024-05-12 10:51:03 · 705 阅读 · 0 评论 -
Hudi HoodieStreamer 报错 NoSuchMethodException: MysqlDebeziumSource.<init>(...) 解决方法
在使用 Hudi 的 HoodieStreamer 或 HoodieMultiTableStreamer 接入 Debezium CDC 数据并写入 Hudi 表过程中,我们可能会遇到这样一个错误:NoSuchMethodException: org.apache.hudi.utilities.sources.debezium.MysqlDebeziumSource.(org.apache.hudi.common.config.TypedProperties, org.apache.spark.api.原创 2024-05-11 15:08:52 · 588 阅读 · 0 评论 -
Spark Structured Streaming 分流或双写多表 / 多数据源(Multi Sinks / Writes)
在 Spark Structured Streaming 中,我们有时候需要将最后的处理结果分流或双写到多张表或多个数据源(Multi Sinks / Writes),一个典型的例子是:在 CDC 数据入湖场景里,一个 Kafka Topic 上存放着整库或多张表的 CDC 消息,使用 Spark 从 Kafka 中摄取这些消息后,需要根据消息中提供的数据库名和数据表名对 CDC 消息分流,然后写到数据湖上对应的 ODS 表中,这就是一种典型的“数据分流”场景。在 Spark Structured Stre原创 2024-04-28 10:24:42 · 1530 阅读 · 0 评论 -
Maven 构建 Flink 应用程序的最佳实践(根除各种类冲突/类加载问题)
作为开发者,在构建 Flink 应用程序时的体验真是一言难尽,想必大家都曾遇到过各种 ClassNotFoundException、NoSuchMethodError 以及 Could not find any factory for identifier kafka/jdbc/hive/hudi that implements org.apache.flink.table.factories.DynamicTableFactory in the classpath 这样的错误。坦率地说,Flink 的应用原创 2024-04-27 09:43:25 · 2206 阅读 · 0 评论 -
Flink CDC / Kafka Connect 自动转换 Debezium 的 DataTime / Timpstamp 时间格式
不管是用 Flink CDC 还是 Kafka Connect (Debezium Connector),在实时获取数据库的 CDC 数据并以 Json 格式写入 Kafak 中时,都会遇到 DataTime / Timpstamp 类型的转换问题,即:原始数据库中的 DataTime / Timpstamp 的字面量是 2021-12-14 00:00:00 这种形式,但是,转换为 Json 后就变成了 1639411200000 (带毫秒位的 epoch 时间),这带来的问题是:下游表基于 Json 数原创 2024-04-26 11:02:54 · 650 阅读 · 0 评论 -
Flink: Could not find any factory for identifier kafka/jdbc/hive implements DynamicTableFactory 根治方法
运行 Flink 应用或执行 Flink SQL 时会经常遇到下面的错误:org.apache.flink.table.api.ValidationException: Could not find any factory for identifier kafka jdbc hive hudi mysql-cdc that implements ‘org.apache.flink.table.factories.DynamicTableFactory’ in the classpath.原创 2024-04-25 09:59:27 · 1065 阅读 · 0 评论 -
Flink CDC 整库 / 多表同步至 Kafka 方案(附源码)
我们此前介绍的一些 CDC 开箱即用方案往往都是一张表对应一条独立的链路(作业),需要一个独立的数据库连接,在表数量很大的情况下,会对数据库造成很大压力,同时过多的 Flink 作业会不易于管理和维护,为众多小表创建独立的采集作业也浪费了资源。此外,使用 Flink SQL 针对每张表定义 CDC 作业也是一项繁重的工作,如果能简化或省略编写大量 SQL 的工作也是一项重要的改进。所以,一种更为实用的解决方案是:使用一个 Flink 作业完成整库 / 多表的 CDC 数据接入工作。本文我们会详细介绍一下这一原创 2024-04-18 09:29:21 · 2448 阅读 · 0 评论 -
Flink CDC:使用 Flink SQL 将多表写入一个 Kafka Topic 以及 Flink 作业数量的测试
本测试要验证两个问题:Flink CDC 能否将多张表的 CDC 数据 (debezium-json 格式)写入到同一个 Kafka Topic 中?验证使用 Flink SQL 方式将多表同时写入 Kafka 时,Flink 的作业数量,首先,准备好用 Flink SQL 实现的将两张表同步到一个 Kafka Topic 中的代码原创 2024-04-17 13:27:02 · 580 阅读 · 0 评论 -
Flink 报错 ClassNotFoundException: org.apache.kafka.connect.source.SourceRecord 解决方法
在使用 Flink CDC 的 API 编写整库、多表接入 Kafka 的程序时,遇到题目所述的报错。如果是自己编写的程序,可在 IDE 中直接查找该类是否在项目的依赖声明中;如果是部署的第三方应用,可以使用如下命令确认报错的类是否在所有依赖包中都不存在原创 2024-04-17 10:52:39 · 647 阅读 · 0 评论 -
Flink CDC 的 debezium-json 格式和 debezium 原生格式是一回事吗?
这是一个很容易混淆和误解的问题,值得拿出来讨论对比一下。我们知道 Debezium 是专门用于捕获 CDC 数据的开源框架,它对接了多种数据库,同时也定义了自己的 CDC 数据交换格式,也就是常说的 `debezium` 格式。而Flink CDC 复用了 Debezium 的部分功能,也就是说:Debezium 是 Flink CDC 的底层采集工具,Flink CDC 的工程依赖会用使用到 Debezium 的 Jar 包,然后 Flink CDC 在 Debezium 基础之上,封装了额外的功能,原创 2024-04-16 14:33:11 · 1822 阅读 · 2 评论 -
如何连通私有子网中的 MSK / Kafka 集群?
MSK 集群通常都是建在私有子网中的,这给本地访问带来了很多麻烦,特别是需要在本地使用 Kafka GUI 客户端管理和读写 MSK 数据的时候。本文会给出一套解决方案。我们这里讨论的问题有一点特殊性,那就是:由于 MSK 是托管服务,它的 Broker 主机名虽然映射了一个私有的 IP 地址,但是不能通过 SSH 登录的,这是比较特殊的一个地方,另一个地方是:Kafka 集群基本都是三个以上的 Broker,它的连接地址往往是三台以上的主机+端口号,这是另一个比较特殊的地方原创 2024-04-16 13:28:18 · 740 阅读 · 2 评论 -
Flink SQL:debezium-json 格式的表一定是数据库的 CDC 数据吗?
debezium-json 格式有一种非常典型的应用场景,就是:上游(Source)是一张使用 Flink CDC 接入的关系数据库中的表,下游(Sink)是一张创建在 Kafka 上的表,这张表的 format 往往会定义为 debezium-json,以便 Flink 能获得全面的 CDC 信息用于流上的实时处理,这种场景我们在 《Flink CDC 与 Kafka 集成:Snapshot 还是 Changelog?Upsert Kafka 还是 Kafka?》 一文的 ”测试组合(1):connect原创 2024-04-15 13:23:03 · 759 阅读 · 0 评论 -
Flink:维表 Join 难点和技术方案汇总
目前看,Flink 的 “维表 Join” 主要就三种实现方式,叫法可能会有细微差别,以下是我是用更直白的语言总结的称谓:直连外部数据库进行关联;将维表加载到内存中关联;基于维表变更日志的关联。这些 Join 方案具体会使用到 Flink 的 Lookup Join、Temporal Join 等相关机制,所以在研究维表 Join 方案前,应先补齐这部分的知识,具体可参考本文末给出的本博客相关系列文章。原创 2024-03-26 09:25:39 · 1674 阅读 · 0 评论 -
Flink:“Lookup Join”和“基于处理时间的 Temporal Join”的区别
在完整介绍了 “基于处理时间的 Temporal Join” 和 “Lookup Join” 之后,作为一个简单的盘点,也是回答最初接触这两种 Join 时的疑惑,我们来分析一下两种 Join 有何异同。相同之处:时效性都较高;时间维度上的关联准确性接近;不同之处:Lookup Join 是直连数据查询的,而 “基于处理时间的 Temporal Join” 是构建在 Flink 上的动态表,变更是靠 CDC 实时同步的。原创 2024-03-24 13:14:02 · 494 阅读 · 0 评论 -
一文聊透 Flink 的 Temporal Join
Flink的Temporal Join以及Temporal Table (时态表)关系密切,在知识结构上有点混乱,可能是历史原因造成的。本文希望把所有与 Temporal Join 相关的概念进行一次统一梳理,用更规范的知识结构把 Flink 的 Temporal Join 介绍清楚,包括:以 Temporal Table DDL 方式实现基于事件时间的 Temporal Join;以 Temporal Table DDL 方式实现基于处理时间的 Temporal Join;以 Temporal Table原创 2024-03-25 08:22:24 · 2092 阅读 · 0 评论 -
Flink Temporal Join 系列 (4):用 Temporal Table Function 实现基于处理时间的关联
本文要演示的是:使用 Temporal Table Function 定义被关联表(维表),然后基于主动关联表(事实表)的“处理时间”去进行 Temporal Join(关联时间维度上对应版本的维表数据)。由于 Flink 在新版本中已经禁止使用 Temporal Table DDL 实现基于处理时间的 Temporal Join,所以通过 Temporal Table Function 实现基于处理时间的 Temporal Join 已经是唯一的手段了。该演示同样涉及三个要点:被关联的表(维表)是用 Te原创 2024-03-22 10:03:01 · 875 阅读 · 0 评论 -
Flink:Lookup Join 实现与示例代码
本文要演示的是:在流上关联一张外部表(例如 MySQL 数据库中的一张维表),用于丰富流上的数据,实际上,这正是最普遍的 ”维表 Join“ 的实现方式。通过这种方式和外部维表关联时,依然能关联到最新变化的维度数据,所以才说这是 ”维表 Join“。Lookup Join 与 《Flink Temporal Join 示例演示 (2):Temporal Table DDL + 处理时间》一文演示情形是很相似的,但不同之处在于:这里的维表是通过 JDBC 方式连接的,而文章中的 Temporal Join 方原创 2024-03-21 14:07:27 · 822 阅读 · 0 评论 -
Flink Temporal Join 系列 (3):用 Temporal Table Function 实现基于事件时间的关联
本文要演示的是:使用 Temporal Table Function 定义被关联表(维表),然后基于主动关联表(事实表)的“事件时间”去进行Temporal Join(关联时间维度上对应版本的维表数据)。该演示同样涉及三个要点:被关联的表(维表)是用 Temporal Table Function 形式定义的时态表;主动关联的表(事实表)需要定义:“事件时间”属性(但并不需要是一张版本表);Temporal Join 是使用 Temporal Table Function + LATERAL TABLE 关原创 2024-03-21 09:36:08 · 859 阅读 · 0 评论 -
使用 Flink + Faker Connector 生成测试数据压测 MySQL
使用 Flink 压测 MySQL 是一个不错的注意,或者,有时候我们需要在 MySQL 中生成一些可控的测试数据,这时使用 Flink 的 Faker Connector 就是会很简单。本文记录一下操作方法。原创 2024-03-20 13:31:35 · 936 阅读 · 0 评论 -
Flink Temporal Join 系列 (2):用 Temporal Table DDL 实现基于处理时间的关联
本文要演示的是:使用 Temporal Table DDL 定义被关联表(维表),然后基于主动关联表(事实表)的“处理时间”去进行Temporal Join(关联时间维度上对应版本的维表数据)。该演示涉及三个要点:被关联的表(维表)是用 Temporal Table DDL 形式定义,必须是一张时态表(版本表);主动关联的表(事实表)需要定义“处理时间”属性,但并不需要是一张时态表(版本表);Temporal Join 是使用 Temporal Table DDL + FOR SYSTEM_TIME AS原创 2024-03-20 09:49:35 · 638 阅读 · 0 评论 -
Flink:使用 Faker 和 DataGen 生成测试数据
DataGen 是开源 Flink 就内置的随机数据生成器;DataGen 生成的数据仅支持随机和序列值两种,且也并不是所有的数据类型都能支持随机或序列值,例如最见的一个需求:针对时间类型就不能生成指定区间内的单调递增的数值,相较而言,Faker 的功能要明显由于 DataGen,我们只需掌握 Faker 这一种数据生成器就足够了。原创 2024-03-19 10:56:33 · 964 阅读 · 0 评论 -
Flink Temporal Join 系列 (1):用 Temporal Table DDL 实现基于事件时间的关联
本文要演示的是:使用 Temporal Table DDL 定义被关联表(维表),然后基于主动关联表(事实表)的“事件时间”去进行Temporal Join(关联时间维度上对应版本的维表数据)。该演示涉及三个要点:被关联的表(维表)是用 Temporal Table DDL 形式定义,必须是一张时态表(版本表);主动关联的表(事实表)需要定义”事件时间“属性,但并不需要是一张时态表(版本表);Temporal Join 是使用 Temporal Table DDL + FOR SYSTEM_TIME AS原创 2024-03-19 08:57:41 · 590 阅读 · 0 评论 -
再谈 Flink 的“动态表”和“流表二象性”
本文再次去动态表和表流二象性做一些梳理。1.将流转换为动态表。2.在动态表上计算一个连续查询,生成一个新的动态表。3.生成的动态表被转换回流。我们会从实际代码层面把动态表的概念打通,核心问题就是:动态表的 DDL 定义了什么?持续查询又做了什么?动态表的 DDL 定义了三项核心要素:数据结构,数据源(connector),传输格式(format);从 ETL 的角度看,持续查询完成了最核心的 ETL 逻辑,从整个流式处理管道的角度看,是持续查询驱动了整个 Pipeline 运转,只有动态表的DDL,不会有任原创 2024-03-18 09:26:47 · 1086 阅读 · 0 评论 -
Flink:Temporal Table 的两种实现方式 Temporal Table DDL 和 Temporal Table Function
综合官方文档对 Temporal Joins 和 Temporal Table Function 两部分的描述可以梳理出以下重要结论:版本表的官方定义形式只有一种,就是 Temporal Table DDL,参考:声明版本表Temporal Table Function ( 时态表函数 ) 和 Temporal Table DDL 可以实现相同使用效果的时态表,可以说 Temporal Table Function ( 时态表函数 ) 相当于提供了 DDL 之外的另一种版本表的实现方式原创 2024-03-03 12:57:38 · 772 阅读 · 0 评论 -
Flink:Temporal Table Function(时态表函数)和 Temporal Join
我们知道,时态表(确切地说应该是版本表)提供了回溯历史的能力,也就是能读取一条记录过去某个时刻所对应的值。要想查询版本表在过去某个时刻对应的值,我们得在查询时把这个时间作为参数传递给版本表,但这个时间参数绝不会是一个 where 条件,它是另一个维度(时间维度)上的参数,那么用怎样的形式才能把这个时间参数合理地表达到查询中呢? Flink 使用了 UDF 的形式,主要思路就是:注册一个 UDF 来指代一张版本表,表名不能有参数,但函数可以有,这时把想访问版本表的目标时间点作为参数传给这个UDF,返回的就是当原创 2024-03-03 11:43:19 · 676 阅读 · 0 评论 -
SQL 术语:Join 中的 Build 和 Probe 是什么意思?
我们可能在一些介绍数据库 Join 档中看到 Build 和 Probe,分别代表着 Join 操作中的 右表 和 左表,为什么会有这样的称呼呢?原来它们都出自于一种叫 ”Hash Join“ 的 join 算法(常见的 Join 算法有:Hash Join、Loop Join、Merge Join)。先看一下名词解释:Hash Join:一种实现 Join 的算法,它通过在 Join 的一侧构建 Hash Table 并在另一侧不断匹配 Hash Table 来得到 Join 的结果。原创 2024-03-02 12:00:02 · 1184 阅读 · 0 评论 -
Flink:流式 Join 类型 / 分类 盘点
在Flink中,实现流之间连接的操作可以分为两类。第一类是基于原生State状态存储的Connect算子操作,这种方式可以实现低延迟的数据连接和转换;第二类则是基于窗口的JOIN操作,这种方式又可以细分为window join和interval join两种,通过对数据进行时间窗口和滑动窗口的划分,实现不同粒度的数据关联和计算。Regular Join(常规 Join)Interval Join(时间区间 Join)Temporal Join (版本表 Join基于事件时间的 Temporal Join基于原创 2024-03-27 10:41:51 · 2265 阅读 · 0 评论 -
Flink:动态表 / 时态表 / 版本表 / 普通表 概念区别澄清
根据 [ 官方文档 ] 所述,在 Flink 中,时态表和动态表是一个概念,只是强调的侧重点不同。Flink 流上的表都是动态的,也就是一直在变化,所以被称为动态表,因为动态表都会随时间发生变化,所以也被叫作了 “时态表”。而根据能否 trace (追踪) 一张时态表的变化历史,时态表会细分成:版本表 和 普通表 两种,区别就是:版本表可以追溯历史,而普通表只保存当前最新状态的数据。Flink 官方文档中说:定义了主键约束和事件时间属性(通过 WATERMARK 关键字标识)的表就是版本表,并且举例说:数据原创 2024-03-01 12:56:50 · 788 阅读 · 0 评论 -
Flink CDC 提取记录变更时间作为事件时间和 Hudi 表的 precombine.field 以及1970-01-01 取值问题
CDC 数据中的记录变更时间标记着这条记录在数据库中执行对应操作(创建/更新/删除)的时间,可以说是天然的“事件时间”,特别是对于那些本身没有记录时间字段的表来说就更加合适了。Flink 官方文档 也建议在使用 CDC 的情况下,优先使用 CDC 中的这个时间字段,这个时间更加精准。与此同时,在定义 Hudi 表时,precombine.field 也是一个非常重要的配置,显然 CDC 数据中的记录变更时间是最合适的,没有之一。原创 2024-02-27 13:36:32 · 995 阅读 · 0 评论 -
Flink SQL 中的流式概念:状态算子
传统的关系模型和 SQL 最开始都是为了批式处理而设计的,当把一个关系型查询应用到流式处理上时,在实现和转换的过程中,会有很多和批处理场景非常不同的地方,典型的例子就是:为了实现 SQL 的某些语义,Flink 必须在流上维持状态,典型的代表就是:连接、聚合 、去重 这些操作,它们都是“状态算子”,本质原因还是因为:流处理的表是无界的,流式查询是持续不停的,所以在流上维持状态是必须的。原创 2024-02-27 10:45:42 · 1411 阅读 · 0 评论 -
Flink:流上的“不确定性”(Non-Determinism)
先明确一下什么叫“确定性”:对于一个“操作”来说,如果每次给它的“输入”不变,操作输出的“结果”也不变,那么这个操作就是“确定性“的。通常,我们认为批处理的操作都是确定的,比如针对一张 clicks 表,假如表中的数据没有变化,无论我们执行多少次 SELECT * FROM clicks 操作,它的结果始终不变。但是,批处理操作并不一定总是“确定性”的原创 2024-02-24 12:56:40 · 1115 阅读 · 0 评论 -
使用 JMeter 生成测试数据对 MySQL 进行压力测试
数据库压测最主要的工作是:如何能简单地生成压测数据(Dummy Data),还要能控制好数据的取值范围,写脚本太麻烦,图形化工具收费还不通用,所以,我们选择使用老牌的压力测试工具:Apache JMeter,除了它内置了丰富的随机值生成方法外,还因为它是一个统一的压测平台,操作和配置都和其他类型的压测一致。本文以 Debezium 官方提供的 MySQL Docker镜像 中的 Inventory 数据库为示例介绍和演示压测步骤。原创 2024-02-22 12:43:09 · 1878 阅读 · 2 评论