2023 年 8 月 16 日～18 日，第 14 届中国数据库技术大会（DTCC 2023）于北京隆重召开，拓数派受邀参加本次大会，PieCloudDB 技术专家邱培峰在大会做了《云原生虚构数仓 PieCloudDB ETL 方案设计与实现》的主题演讲，具体介绍了 PieCloudDB 的 ETL 计划总体设计与实现，剖析了 ETL 工具 pdbconduct 及相干数据库内核扩大。
图为拓数派 PieCloudDB 技术专家邱培峰
对于数据库用户而言，ETL 的重要性显而易见。ETL（Extract, Transform, Load），即数据的抽取、转换和加载，简略了解为数据库的数据导入过程。ETL 的实质是不同零碎（数据组织模式）之间的数据挪动 。ETL 的过程有助于数据库用户实现数据的高效治理和优化。它确保数据库中的数据不仅仅是存储在其中，还通过了精心的解决，以满足用户的需要。
1 云原生环境下的 ETL
随着云原生时代的到来，经济实惠且可轻松扩大的对象存储解决方案成为满足用户对高弹性、高性价比需要的首选。传统 ETL（Extract, Transform, Load）是一种将数据从源零碎抽取、荡涤、转换，最初加载到指标零碎中进行剖析的过程。 传统 ETL 的特点是吞吐量大，批量加载性能十分好 ，毛病是对源端和指标零碎影响较大，通常是在非业务顶峰进行，因此会有较大的数据提早，通常为 T+1。
CDC（Change Data Capture）是指实时或者准实时捕捉数据库或文件系统中发生变化的数据，并将其同步到其余数据系统中，同时确保数据的一致性和准确性。CDC 通常通过解析源端日志的形式实现，对源零碎影响较小，且有较低的时延 。但对指标零碎，尤其是剖析性数据库，相比于批量模式，会带来较大的数据更新开销。即使如此，CDC 形式在数据同步方面利用越来越宽泛；同样的，传统的 ETL 模式在很多场景仍有不可代替的劣势。
无论 ETL 还是 CDC 都是把数据复制作为指标的，因而不可避免的会造成肯定水平的数据冗余，也存在造成数据不统一的危险；而基于湖仓技术的一写多读，zero-ETL 等技术能够齐全打消数据复制造成潜在冗余和不统一危险。 对立 ETL、CDC 和湖仓技术正是 PieCloudDB Database 的 ETL 计划的指标之一。
PieCloudDB 存算拆散的架构使得不同零碎能够间接共享同一份底层数据，防止了繁琐的数据抽取、转换和加载过程。目前，PieCloudDB 反对间接读取对象存储上的 Parquet 等格局的文件，实现了数据共享和拜访方面提供了便捷性 。
某些理论场景下会产生 ETL 需要，例如同一份底层原始数据应用不同零碎查问时，或为不同类型的查问特化的零碎会有不同的存储形式等。 因而，在进行 ETL 的方案设计时须要思考以下几个因素 ：
- 多种数据源 ：须要思考不同零碎和数据源（如生产 IoT 数据）的多样性，确保可能从不同起源（事务型数据库，HDFS，Kafka 等）抽取数据，应答不同零碎的数据接入需要。
- 多种数据格式 ：数据可能以多种格局存在：如 CSV、JSON、Parquet、二进制等。确保 ETL 流程具备解决不同格局数据的能力，可能解析、转换和对立这些数据以适应指标零碎的要求。
- 通用的数据处理 / 转换 ：使数据可能被标准地荡涤、加工和转换，以满足不同零碎的须要。这将进步数据品质并缩小冗余的转换逻辑。
- 唯一性和事务性保障：确保在数据加载过程中保护数据的唯一性和事务性。防止反复数据的导入，同时在 ETL 过程中实现事务管制，确保数据的完整性。
- 断点续传 ：在 ETL 过程中，通过记录和复原解决状态，防止数据失落或反复解决。
- 错误处理 ：可能捕捉、记录和解决在 ETL 过程中呈现的谬误，包含数据格式谬误、连贯问题等，保证数据的完整性和可靠性。
这些因素的设计将帮忙确保数据在从抽取到加载的整个过程中失去适当解决，为数据驱动的决策和剖析提供松软的根底。
2 PieCloudDB ETL 计划总体设计与实现
2.1 PieCloudDB ETL 计划的总体设计
充分考虑到云原生时代的 ETL 需要，PieCloudDB 的 ETL 计划总体设计次要包含三个方面：
- 任务调度总控 pdbconduct：在 ETL 流程中，工作的调度和协调由 pdbconduct 负责。pdbconduct 充当着总控角色，治理工作的排程、执行程序和依赖关系。通过 pdbconduct，不同的 ETL 工作能够被智能地调度，确保整个数据流程的无效运行。
- 数据源提取（插件 / 客户端工具）：数据源提取阶段波及从业务零碎的原始数据库中获取数据。这须要开发插件和工具，以确保从业务零碎中高效导出数据。这些插件和工具可能与不同业务零碎进行连贯，从中抽取数据，而后将其转换成适宜 ETL 流程的格局。
- 计算节点 Foreign Table 和 Formatter 解耦 ：在计算节点上运行 Foreign Table 是 ETL 过程的外围。这一步骤将从业务零碎中提取的数据传输到 PieCloudDB 中，并在计算节点上保护不同的数据格式。Foreign Table 容许将数据映射到数据库表中，为数据的转换和解决发明了环境。
通过这三个方面的设计，PieCloudDB 的 ETL 计划可能实现工作的无效调度、从业务零碎提取数据以及在计算节点上解决数据的指标 。整个流程确保了数据从业务零碎到 PieCloudDB 的顺畅传输，并为数据的转换和解决提供了必要的根底。这使得数据在被集成、转换和加载的过程中放弃了准确性和一致性，为后续剖析和利用提供了高质量的数据资源。
2.2 PieCloudDB ETL 执行流程
当在 PieCloudDB 上开启 ETL 工作时，具体流程如下图所示：
- 源零碎连贯和数据提取 ：首先，与源零碎建设连贯，执行 SQL 查问或其余高频操作，以提取所需数据。这一步骤有助于从源零碎获取须要进行 ETL 的数据。
- 数据传输到两头零碎 ：提取的数据能够间接传输到两头零碎，其中两头零碎能够是源零碎的本地磁盘、PieCloudDB 的磁盘，或者其余两头存储地位。这一步骤有助于长期存储数据，以便后续解决。
- 两头零碎解决 ：两头零碎可能是云存储或服务器（例如 Kafka），具体抉择依据业务场景的须要进行配置。在两头零碎中，为后续的 Foreign Table 筹备数据。
- Foreign Table 连贯 ：在筹备好的数据上，通过 Foreign Table 的连贯机制，将数据映射到 PieCloudDB 中。这一步骤使得数据能够在 PieCloudDB 的环境下被进一步解决和剖析。
- 数据加载及验证 ：能够进行数据的转换和解决，同时确保云存储上的文件是否合乎预期，进行必要的验证和查看，以确保数据的完整性和正确性。
依据业务需要，任务调度总控 pdbconduct 会在适当的工夫按需触发 ETL 工作，从源零碎中提取所有须要进行解决的数据。这一步确保所需数据可用于后续的解决。
一旦数据导出实现，pdbconduct 将相应的 SQL 语句发送到 PieCloudDB 的管制节点。这些 SQL 语句可能包含数据转换、加载或其余操作，以筹备数据进入 PieCloudDB 的环境。
在 PieCloudDB 管制节点执行 SQL 语句后，pdbconduct 收集执行后果，记录工作的进度以及任何可能的错误信息。这能够帮忙监测工作的状态，并在呈现问题时迅速采取适当的措施。如果在执行过程中呈现谬误，pdbconduct 将记录所有错误信息，并依据须要采取相应的补救措施。
2.3 INSERT/MERGE 模式
PieCloudDB 的 ETL 反对 INSERT 和 MERGE 两种常见的数据处理模式。用户能够依据业务需要、数据更新频率、和数据变动状况抉择 INSERT 模式或 MERGE 模式。
2.3.1 INSERT 模式
INSERT 模式是将源零碎中的数据直接插入到 PieCloudDB 中的一种模式。在这种模式下，从源零碎中提取的数据会被逐行或逐批插入到 PieCloudDB 中的对应表中。INSERT 模式实用于对数据进行批量导入，或者当数据变动较小，且新增记录为次要操作时。INSERT 模式的劣势在于简略间接，反对单纯的导入场景，特地善于与现有数据没有逻辑关联的时序数据流。
- 步骤 1：获取原始数据
首先，针对特定的数据源，须要开发适配器或插件，以便 PieCloudDB 可能连贯到该数据源。可能须要开发 PostgreSQL 扩大来反对数据源的通信和数据格式解析。
接着，管制节点将读取数据源信息（包含连贯参数、认证信息、数据抽取规定等），决定是否将工作进行拆分来进步并发性和效率，接着生成工作信息（查问语句、工作依赖关系等）。最初，计算节点依据工作信息读取数据源，并将原始数据和元信息返回给管制节点。
通过这些步骤，INSERT 模式下的 ETL 流程将数据从数据源中获取，并通过 Foreign Table 的形式插入到 PieCloudDB 中。
CREATE FOREIGN TABLE foreign_table(meta text, raw bytea);
SELECT meta, raw FROM foreign_table; - 步骤 2：数据的筹备和解析
通过步骤 1，从 Foreign Table 中获取的原始数据须要通过解析和转换，以适应外部行格局。而这个转换过程通常是通过 Formatter 实现的。
PieCloudDB Formatter 会先对 Foreign Table 中取得的原始数据进行解析，依据数据的格局（如 CSV，JSON，XML 等），将原始数据分解成可操作的数据单元（字段、行、列等）。
接着，PieCloudDB Formatter 会将解析后的数据进行转换，以适应 PieCloudDB 的外部的行格局，生成须要的各列。
CREATE FUNCTION formatter(input bytea) RETURNS user_type …;
SELECT meta, raw FROM foreign_table
LATERAL JOIN formatter(raw); - 步骤 3：数据的转换
在步骤 3 中，会对步骤 2 中解析出的列执行数据转换操作，以确保数据的准确性和一致性，使数据可能顺利插入 PieCloudDB 表中，为后续的剖析和利用提供牢靠的数据根底。
SELECT r.a, r.b+r.c, func(r.d) … FROM (SELECT meta, raw FROM foreign_table
LATERAL JOIN formatter(raw) AS r) sub; - 步骤 4：插入指标表
通过后面三个步骤，数据曾经实现了筹备和转换，此时，将在步骤 4 中实现插入指标表。
INSERT INTO table
SELECT r.a, r.b+r.c, func(r.d) … FROM (SELECT meta, raw FROM foreign_table
LATERAL JOIN formatter(raw) AS r) sub; - 步骤 5：插入历史表，反对断点续传
最初，为了反对断点续传，会将数据插入历史表，以保留数据的变更历史（新增、更新和删除操作），从而实现对断点续传的反对。
INSERT INTO history
SELECT meta FROM foreign_table; 2.3.2 MERGE 模式
PieCloudDB 的 ETL MERGE/UPSERT 模式反对 CDC（Change Data Capture）场景 。这种模式可解决具备操作类型、逻辑主键和程序键的数据，以实现数据的插入、更新和删除操作。
在 MERGE 模式下，数据须要蕴含操作字段（OP，即 INSERT/UPDATE/DELETE）、逻辑主键和程序键。当逻辑主键不存在时，模式会执行 INSERT 操作；当逻辑主键已存在时，会执行更新或删除操作。程序键用于确定操作的程序，在解决多个操作时，依据程序键确定操作的执行程序，以避免操作间的抵触。MERGE 模式容许解决反复数据，但不能够有事务逻辑谬误。
- 步骤 1：数据解析和导入长期表
首先，从内部数据源获取的原始数据通过解析，以获取蕴含操作字段（OP）、逻辑主键（LPK）和程序键（OK）等的数据。接着将解析后的数据导入到与指标表类型雷同的长期表中。这个长期表用于存储待合并和更新的数据。
SELECT r.a, r.b+r.c, func(r.d) … FROM (SELECT meta, raw FROM foreign_table
LATERAL JOIN formatter(raw) AS r) parsed; - 步骤 2：长期表外部去重
在长期表外部，对于具备雷同逻辑主键（LPK）的行，依据程序键（OK）抉择保留 OK 最大的那行，确保只保留程序键最大的惟一记录。
INSERT INTO temp_table
SELECT all_columns FROM (SELECT *, row_number() OVER PARTITION BY lek
ORDER BY ok DESC FROM parsed
) AS no_dup WHERE no_dup.row_number = 1; - 步骤 3：指标表删除 PK 匹配行
在指标表中，依据逻辑主键（LPK）进行匹配，删除与长期表中的数据具备雷同逻辑主键的记录。这确保了数据的更新操作。
DELETE FROM table USING temp_table
WHERE table.pk = temp_table.pk; - 步骤 4：插入指标表，实现 merge
将通过去重和操作解决后的数据插入到指标表中，实现数据的合并和更新。插入操作可能波及 INSERT、UPDATE 或 DELETE 操作，依据数据的操作字段（OP）决定。
INSERT INTO table SELECT all_columns
FROM temp_table; 在实现 MERGE 后，同 INSERT 模式一样，会记录历史信息，这里就不再赘述。
最初, 让咱们通过一段 视频解说及 demo 更加具象地理解一下这个过程。