原文地址： https://debezium.io/blog/2021/10/20/using-debezium-create-data-lake-with-apache-iceberg/
欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.
利用德贝兹和阿帕奇冰山一起创建一个数据湖
到2021年10月20日 伊斯梅尔·西姆塞克
脱贝唑 冰原 数据蛋糕 湖边小屋
如今,为分析、报告或机器学习需求建立数据库是一种常见的做法。
在这篇博文中,我们将描述一个建立数据湖的简单方法。该解决方案使用的是基于Debezns的实时数据管道,支持酸事务、SQL更新,并且具有高度的可伸缩性。也不需要阿帕奇卡夫卡或阿帕奇火花应用程序来构建数据提要,从而降低了整个解决方案的复杂性。
让我们先简单描述一下数据湖的概念: 数据湖 通常是一个中央存储的数据,包括原始的源系统数据、传感器数据、社会数据等"。您可以按原样存储数据,不必首先处理数据,然后运行不同类型的分析。
德贝兹服务器冰山
由于操作数据通常存在于关系数据库或Nosql数据存储中,问题是如何将数据传播到数据湖中。在这里 德贝兹服务器冰山 项目的到来:基于Debezum和阿帕奇冰山,它可以让您处理来自源数据库的实时数据更改事件,并将它们上传到冰山支持的任何对象存储。所以让我们仔细看看这两个项目。
脱贝唑 是一个用于更改数据捕获的开源分布式平台。Debezum从数据库的事务日志中提取更改的事件,并通过事件流平台将其传递给消费者,使用不同的格式,如JSON、阿帕奇阿沃罗、谷歌协议缓冲区等。在大多数情况下,德贝兹与阿帕奇卡夫卡和卡夫卡连接。但是,通过Debezum服务器,也是其他通讯基础设施的用户,比如"运动",google酒吧/子,脉冲星可以从Debezum的更改数据捕捉功能中获益。在这里你可以看到 支助目的地 .
阿帕奇冰山 是一个"大型分析数据集的开放表格式"。冰山使用高性能的表格格式,就像一个SQL表一样工作,为计算引擎添加了表格,包括SASS、TIINO、普雷斯托布、弗林克和蜂巢。"它支持酸插入以及行级删除和更新。它提供了一个JavaAPI来管理表元数据,如模式和分区规格,以及存储表数据的数据文件。
阿帕奇冰山有一个概念 数据和删除文件 .数据文件是冰山使用的文件后,现场保持实际数据.删除文件是用于编码现有数据文件中删除的行的不可变文件。这就是冰山删除/替换不可变数据文件中的单个行而不改写文件的方式。在德贝兹服务器冰山的情况下,这些是不可变的 阿帕奇地板 文件,一种被设计为"与CSV或TSV文件等基于行的数据相比,有效和有效的平面柱状存储格式"的格式。
阿帕奇冰山消费者
德贝司服务器提供一个SPI 安装新的接收器适配器 这是创造阿帕奇冰山消费者的延伸点。
图片来自官网原文
图1体系结构概述:德贝齐斯服务器和阿帕奇冰山
冰山消费者将疾病控制中心的变化事件转换为冰山数据文件,并使用冰山JavaAPI将其提交到目的地表。它将每个德贝兹源主题映射到一个目标冰山表。
当找不到给定的冰山目的地表时,使用者使用更改事件架构创建它。此外,事件模式用于将更改事件本身映射到一个等价的冰山记录。因为这个,debezium.format.value.schemas.enable 配置选项必须设置。一旦德贝兹变更事件记录到冰山记录中,则从数据中删除该模式。
在高层,更改事件处理如下。每批收到的活动:
事件按目标冰山表分组;每个组包含来自单一源表的更改事件列表,共享相同的数据架构
对于每个目的地,事件被转换为冰山记录
冰山记录被保存为冰山数据和删除文件(只有当使用者使用升级模式运行时才创建删除文件)
文件被提交到目的地的冰山表(即:上载至目的地储存库)
经过处理的更改事件,标记为经过处理的DEBeZ铵
下面是一个完整的例子配置,用于使用与冰山适配器:
debezium.sink.type=iceberg
run with append mode
debezium.sink.iceberg.upsert=false
debezium.sink.iceberg.upsert-keep-deletes=true
debezium.sink.iceberg.table-prefix=debeziumcdc_
debezium.sink.iceberg.table-namespace=debeziumevents
debezium.sink.iceberg.fs.defaultFS=s3a://S3_BUCKET);
debezium.sink.iceberg.warehouse=s3a://S3_BUCKET/iceberg_warehouse
debezium.sink.iceberg.type=hadoop
debezium.sink.iceberg.catalog-name=mycatalog
debezium.sink.iceberg.catalog-impl=org.apache.iceberg.hadoop.HadoopCatalog
enable event schemas
debezium.format.value.schemas.enable=true
debezium.format.value=json
complex nested data types are not supported, do event flattening. unwrap message!
debezium.transforms=unwrap
debezium.transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
debezium.transforms.unwrap.add.fields=op,table,source.ts_ms,db
debezium.transforms.unwrap.delete.handling.mode=rewrite
debezium.transforms.unwrap.drop.tombstones=true
更新和追加模式
默认情况下,冰山消费者以更新模式运行(debezium.sink.iceberg.upsert 开始true)。这意味着在源表中更新行时,目标行将替换为新的更新版本。当一个行从源中删除时,它也从目标中删除。当使用"升级"模式时,目的地的数据与源数据保持相同。升级模式使用冰山等量删除功能,并创建删除文件使用的数据事件(从源表的主键派生)的键。为了避免重复数据,对每个批进行重复删除,只保留记录的最后一个版本。例如,在单个事件中,同一记录可能出现两次:一次是插入时,另一次是更新时。使用升级模式,记录的最后一个提取版本总是存储在冰山上。
请注意,当源表没有定义主键时,也没有其他可用的密钥信息(例如:一个唯一的键或一个定义在Debezum中的自定义消息键),使用者使用append 该表的模式(见下文)。
使用更新插入模式保存删除记录
对于某些用例,保留删除的记录作为软删除是有用的。通过设置debezium.sink.iceberg.upsert-keep-deletes 选择true .此设置将在目标冰山表中保留最新版本的删除记录。将其设置为错误将从目标表中删除删除的记录.
附加模式
这是最简单的操作模式,通过设置实现debezium.sink.iceberg.upsert 到false .当使用带有附加模式的Debezum服务器冰山时,所有接收到的记录都被附加到目标表中。不删除重复数据或删除记录。通过附加模式可以分析记录的整个变化历史。
也有可能消耗实时事件 数据压缩 然后用单独的压实作业。冰山支持压缩数据和元数据文件以提高性能。
优化批处理尺寸
Debez铵提取并实时传递数据库事件,这可能会导致冰山上表格的提交太频繁,生成太多的小文件。对于批处理来说,这并不是最好的,特别是当一个接近实时的数据源是足够的时候。为了避免这个问题,可以增加每个提交的批处理大小。
在启用MaxBatchSizeWait 模式,冰山消费者使用德贝司指标优化批处理规模。它周期性地检索Debezns的内部事件队列的当前大小,并等待直到它到达max.batch.size .在等待时间内,在内存中收集到(在Debezns的内部队列中)。这样,每个提交(处理的事件集)处理更多的记录和一致的批处理大小。最大等待和检查间隔通过debezium.sink.batch.batch-size-wait.max-wait-ms 和debezium.sink.batch.batch-size-wait.wait-interval-ms 财产。这些设置应该与德贝司的debezium.source.max.queue.size 和debezium.source.max.batch.size 财产。
以下是所有相关设置的一个例子:
debezium.sink.batch.batch-size-wait=MaxBatchSizeWait
debezium.sink.batch.batch-size-wait.max-wait-ms=60000
debezium.sink.batch.batch-size-wait.wait-interval-ms=10000
debezium.sink.batch.metrics.snapshot-mbean=debezium.postgres:type=connector-metrics,context=snapshot,server=testc
debezium.sink.batch.metrics.streaming-mbean=debezium.postgres:type=connector-metrics,context=streaming,server=testc
increase max.batch.size to receive large number of events per batch
debezium.source.max.batch.size=50000
debezium.source.max.queue.size=400000
创建额外数据湖层
此时,数据湖的原始层已经加载完毕,包括数据复制和近实时管道功能。在顶部构建管理层(有时称为分析层或数据仓库层)变得非常简单明了。在分析层,原始数据是为满足分析需求而准备的;通常原始数据是重组、清理、版本化(见下面示例)、聚合和业务逻辑可以应用。通过可伸缩的处理引擎使用SQL是进行这种数据转换的最常见方式。
例如,有人可以很容易地使用 火花SQL (或预先准备好的文件、文件、文件等) 逐渐变化的维度 ,最常用的数据仓库表类型:
MERGE INTO dwh.consumers t
USING (
-- new data to insert
SELECT customer_id, name, effective_date, to_date('9999-12-31', 'yyyy-MM-dd') as end_date
FROM debezium.consumers
UNION ALL
-- update exiting records. close end_date
SELECT t.customer_id, t.name, t.effective_date, s.effective_date as end_date
FROM debezium.consumers s
INNER JOIN dwh.consumers t on s.customer_id = t.customer_id AND t.current = true
) s
ON s.customer_id = t.customer_id AND s.effective_date = t.effective_date
-- close last records/versions.
WHEN MATCHED
THEN UPDATE SET t.current = false, t.end_date = s.end_date
-- insert new versions and new data
WHEN NOT MATCHED THEN
INSERT(customer_id, name, current, effective_date, end_date)
VALUES(s.customer_id, s.name, true, s.effective_date, s.end_date);
可能需要用新的数据定期更新额外的数据湖层。最简单的方法是使用SQL更新或删除语句。这些SQL操作也是 冰山支持 :
INSERT INTO prod.db.table SELECT ...;
DELETE FROM prod.db.table WHERE ts >= '2020-05-01 00:00:00' and ts < '2020-06-01 00:00:00';
DELETE FROM prod.db.orders AS t1 WHERE EXISTS (SELECT order_id FROM prod.db.returned_orders WHERE t1.order_id = order_id;
UPDATE prod.db.all_events
SET session_time = 0, ignored = true
WHERE session_time < (SELECT min(session_time) FROM prod.db.good_events));
总结和贡献
从德贝兹和阿帕奇冰山来看, 德贝兹服务器冰山 为您的数据湖设置一个低延迟的数据摄入管道非常简单。这个项目完全是开源的,使用的是阿帕奇2.0许可证。德贝兹服务器冰山仍然是一个年轻的项目,还有很多改进。请随意测试,给出反馈,打开功能请求或发送拉请求。你可以看到更多的例子,开始尝试冰山和火花 这个项目 .