iceberg flink upsert 流式数据入湖

最新推荐文章于 2024-07-08 15:28:28 发布

原创

最新推荐文章于 2024-07-08 15:28:28 发布 · 1.4k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#flink #大数据 #big data

本文介绍了如何使用Flinkv2创建一个名为`sample_uniq_test01`的Hive表，详细列出了表的结构和分区信息，包括主键、格式版本、元数据管理等配置。同时，展示了插入数据到表中的操作，强调了主键在分区上的重要性。后续可以将Flinkkafka表接入此流程。

-- flink v2

CREATE TABLE `sample_uniq_test01` (

`id` BIGINT NOT NULL,

`data` VARCHAR(2147483647),

PRIMARY KEY (`id`) NOT ENFORCED

) PARTITIONED BY (`id`)

WITH (

'format-version'='2',

'catalog-database' = 'test001',

'write.upsert.enabled'<

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

小皮蛋儿子

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

【大数据入门核心技术-Iceberg】（八）Iceberg与Flink基本Shell操作

10-18

352

1）上传hive connector到flink的lib中2）启动hive metastore服务3）创建hive catalog重启flink集群，重新进入sql-client>uri: Hive metastore的thrift uri。(必选)>clients:Hive metastore客户端池大小，默认为2。(可选)>warehouse: 数仓目录。

Apache Iceberg：解决Spark中的UPSERT问题

m0_62153576的博客

04-08

275

通过上述步骤，我们可以利用Apache Iceberg在Spark中实现数据的UPSERT操作。Iceberg不仅解决了数据更新和插入的问题，还提供了更好的数据管理和查询性能。无论是数据仓库还是大数据分析平台，使用Iceberg都可以大大简化ETL工作流中的数据维护任务。

参与评论您还未登录，请先登录后发表或查看评论

第二章 Flink集成Iceberg的集成方式及基本SQL使用

qq_27924553的博客

02-06

2655

Flink集成Iceberg的集成方式及基本SQL使用

初识 Apache Iceberg 及自动化 Iceberg 表维护（小文件治理）

weixin_39750695的博客

07-05

2479

Apache Iceberg 架构迁徙及自动化小文件治理方案

Spark内容分享(二十五)：Spark读写Iceberg在腾讯的实践和优化

之乎者也·的博客

01-03

2608

ZOrder可以认为是sort的变种，在Spark中，单列的sort对文件的过滤是比较友好的，但如果sort by多列的话，会首先对column0做sort，然后column0相同的时候再做column1的sort，所以如果过滤的where条件是column1或者column2的时候文件过滤效果就不是很好。于是我们就做了一个列的生命周期管理，就是在query的时候会把查询了哪些列报告给数据治理服务，数据治理服务会做一个统计，用户可以设置对应的列被查询多少次才认为它是有价值的。这是一个数据治理服务的总览。

Flink集成Iceberg简介

Swordfall的博客

03-17

5795

1. 概述 Apache Iceberg is an open table format for huge analytic datasets. Iceberg adds tables to Presto and Spark that use a high-performance format that works just like a SQL table. 官方的定义，iceberg是一种表...

Iceberg从入门到精通系列之十三：Flink DataStream 往Iceberg表写入数据，实现append、upsert、overwrite

zhengzaifeidelushang的博客

07-02

2078

Iceberg从入门到精通系列之十三：Flink DataStream 往Iceberg表写入数据，实现append、upsert、overwrite

数据湖之 Flink Spark 集成 iceberg

weixin_50213935的博客

07-08

1677

数据湖之 Flink Spark 集成 iceberg一、iceberg优点二、安装部署三、iceberg集成flink四、hive查询iceberg表五、spark集成iceberg表一、iceberg优点提供ACID事物，上游数据写入即可见，提供了 upsert、merge into 能力支持计算引擎有 Spark、Flink、Presto 以及 Hive 支持 Parquet、Avro 以及 ORC 等存储格式增量读取处理能力：支持通过流式方式读取增量数据，支持 Structed Strea

探究flink-stream如何增量的读取iceberg table

Cmainlove的专栏

11-11

4247

从iceberg的官方文档上可以看到如下介绍：实例程序中设置了startSnapshotId，介绍说可以从指定的快照版本号开始读取增量的数据。那么笔者的问题来了： flink-stream如何增量的读取iceberg table？ flink本身肯定没有增量读取iceberg的能力，这是提供框架层的方法，在源码iceberg/flink/src/main/java/org/apache/iceberg/flink/source/中找到了StreamingReaderOperator.java类，继承了f

精选资源

Iceberg新一代数据湖技术实践.pdf

10-16

Iceberg新一代数据湖技术实践 Iceberg是新一代数据湖技术实践的重要组件，它解决了数据湖技术中的多种挑战，提供了高性能、灵活的数据存储和分析解决方案。数据湖技术的定义和特点：数据湖技术是一种集中、...

iceberg upsert 主键问题建表语句参考

weixin_44236758的博客

07-08

1137

hivesql 执行iceberg建表语句。

flink写数据到iceberg

weixin_42354436的博客

07-10

666

flink写数据到iceberg

基于Delta Lake的Upserts数据湖方案

Allenzyg的博客

10-18

598

想要实现某条记录的变更，就需要读取对应的文件并进行重写，效率极低，而且容易引起数据不一致和冲突。一方面读取找到的文件的全部内容，与待更新的表进行full outer join，并按照规则更新字段，存储到delta的数据目录，并标记为新增；传统方案需要读取所有的数据，把新的事件追加到会话中，重新写入。，change data capture 变更数据捕获：移动端和web端基于传统数据库实现低延迟的微服务，困难是各个数据库的数据如何统一分析，因此数据分析师需要构建各种ETL把数据汇总到统一的数据湖中。

Flink + Iceberg打造流批一体的数据湖架构

03-10

6604

对于数据湖架构来说，数据文件在HDFS的分布组织是由写入任务决定的，而对于分布式数仓来说，数据一般是通过JDBC写入，数据的存储组织方式是由数仓本身决定的，所以数仓可以按照对于查询更加友好的方式组织数据的存储，比如对数据文件定期compact到合适的大小或者对数据进行合理排序和分组，对于大规模的数据来说，数据的优化组织可以大大提高查询的效率。在这里需要做一个概念上的澄清：数据湖关注的是对原始数据高效、灵活的处理，DWD 及其他数仓分层是充分设计的数据模型，它并不符合我们对数据湖的定义和需求。

Flink系列Table API和SQL之：动态表、持续查询、将流转换成动态表、更新查询、追加查询、将动态表转换为流、更新插入流(Upsert)

zhengzaifeidelushang的博客

12-31

3231

Flink系列Table API和SQL之：动态表、持续查询、将流转换成动态表、更新查询、追加查询、将动态表转换为流、更新插入流(Upsert)

Flink系列之：Upsert Kafka SQL 连接器

zhengzaifeidelushang的博客

12-20

3228

更准确地说，数据记录中的 value 被解释为同一 key 的最后一个 value 的 UPDATE，如果有这个 key（如果不存在相应的 key，则该更新被视为 INSERT）。总之，这段代码的作用是通过Kafka连接器创建两个表，并将"pageviews"表中的数据计算出每个地区的pv和uv，并插入到"pageviews_per_region"表中。这段代码是用来创建两个表，一个是"pageviews_per_region"，另一个是"pageviews"，并定义了它们的结构和连接器。

实时数仓|以upsert的方式读写Kafka数据——以Flink1.12为例

jmx_bigdata的博客

01-13

6534

在某些场景中，比如GROUP BY聚合之后的结果，需要去更新之前的结果值。这个时候，需要将 Kafka 消息记录的 key 当成主键处理，用来确定一条数据是应该作为插入、删除还是更新记录来处理。在Flink1.11中，可以通过 flink-cdc-connectors 项目提供的 **changelog-json format **来实现该功能。关于该功能的使用，见之前的分享Flink1.11中的CDC Connectors操作实践。在Flink1.12版本中，新增了一个 upsert connecto

实践数据湖iceberg 第三十七课 kakfa写入iceberg的 icberg表的 enfource ,not enfource测试

spark_dev的博客

07-22

2045

测试 iceberg读取kafka的数据，能否根据kafka上的id，入湖时，自动更新iceberg的数据，对这个场景进行测试测试结果：不能

数据湖08：Apache Iceberg原理和功能介绍

渡江客涂鸦板

07-23

8466

Iceberg是一种开放的数据湖表格式。可以简单理解为是基于计算层（Flink , Spark）和存储层（ORC，Parqurt，Avro）的一个中间层，用Flink或者Spark将数据写入Iceberg，然后再通过其他方式来读取这个表，比如Spark，Flink，Presto等。...............

Flink如何通过Iceberg表格式实现实时数据与Hive历史数据的ACID合并？

最新发布

09-19

<think> 我们正在讨论如何通过Flink和Iceberg实现实时数据与Hive历史数据的ACID合并。根据引用内容，Iceberg支持高频率的增量写入（如每分钟甚至30秒），而Hive的增量写入通常以partition为单位且时间间隔较长（15分钟以上），频繁写入会导致partition膨胀问题。因此，使用Iceberg可以避免这个问题，同时实现流批一体的数据处理。关键点： 1. **ACID合并**：Iceberg支持ACID事务，这意味着在合并实时数据和历史数据时，可以保证操作的原子性、一致性、隔离性和持久性。 2. **Flink写入Iceberg**：Flink可以通过Iceberg的Sink将实时数据写入Iceberg表。 3. **与Hive历史数据合并**：Iceberg表格式可以兼容Hive，因此我们可以将Hive表迁移到Iceberg表，或者创建新的Iceberg表，然后通过Flink将实时数据写入同一个Iceberg表，从而实现实时数据与历史数据的合并。具体步骤： ### 1. **创建Iceberg Catalog（引用[4]）** 首先，我们需要创建一个Iceberg Catalog，它将Iceberg表与Hive Metastore关联起来。这样，Hive就可以查询Iceberg表。在Flink SQL中创建Catalog的示例： ```sql CREATE CATALOG iceberg_catalog WITH ( 'type'='iceberg', 'catalog-type'='hive', 'warehouse'='hdfs://localhost/user/hive/warehouse', 'uri'='thrift://localhost:9083' ); ``` 这个Catalog会使用Hive Metastore（通过Thrift连接）来管理表，并且数据存储在HDFS的指定路径下。 ### 2. **将Hive表迁移为Iceberg表（可选）** 如果已有Hive表，我们可以将其迁移为Iceberg表格式。Iceberg提供了迁移工具（如`spark-sql`或`flink`）来执行此操作。迁移后，原有的Hive表数据就可以被Iceberg管理。或者，我们可以创建一个新的Iceberg表，然后通过ETL将Hive历史数据导入到这个Iceberg表中。 ### 3. **使用Flink写入实时数据到Iceberg表** 在Flink中，我们可以通过SQL或DataStream API将实时数据写入Iceberg表。以Flink SQL为例： ```sql -- 使用上面创建的Catalog USE CATALOG iceberg_catalog; -- 创建Iceberg表（如果尚未存在） CREATE TABLE IF NOT EXISTS my_table ( id INT, name STRING, event_time TIMESTAMP, PRIMARY KEY (id) NOT ENFORCED ) WITH ( 'format-version'='2', 'write.upsert.enabled'='true' ); -- 从Kafka读取实时数据（举例） CREATE TABLE kafka_source ( id INT, name STRING, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'test_topic', 'properties.bootstrap.servers' = 'localhost:9092', 'scan.startup.mode' = 'earliest-offset', 'format' = 'json' ); -- 将实时数据写入Iceberg表（UPSERT操作） INSERT INTO my_table SELECT id, name, event_time FROM kafka_source; ``` 注意： - 在创建Iceberg表时，我们启用了`write.upsert.enabled`，这允许我们根据主键（这里是`id`）进行更新插入（UPSERT）操作。 - 通过这种方式，当实时数据到来时，如果表中已存在相同的`id`，则会更新该行数据（根据主键合并），否则插入新行。 ### 4. **ACID合并的实现** Iceberg通过以下机制实现ACID： - **原子性（Atomicity）**：每次写入会生成一个新的快照（snapshot），提交操作是原子性的，即要么整个快照生效，要么不生效。 - **一致性（Consistency）**：每个快照都包含完整的数据文件列表，确保查询只能看到已提交的快照。 - **隔离性（Isolation）**：写操作不会阻塞读操作，读操作总是读取最近已提交的快照。Iceberg支持快照隔离（Snapshot Isolation）。 - **持久性（Durability）**：数据文件一旦写入不可变，元数据存储在可靠的存储（如HDFS）中。因此，当Flink作业持续写入实时数据时，每个检查点（Checkpoint）都会提交一个新的Iceberg快照，从而实现实时数据的增量合并。同时，历史数据（已经存在于Iceberg表中的数据）不会被覆盖，而是通过快照机制保留历史版本。 ### 5. **小文件合并（引用[3]）** 在实时写入过程中，可能会产生大量小文件，Iceberg提供了小文件合并的机制。我们可以通过执行`OPTIMIZE`命令（或者通过Flink Action）来合并小文件： ```sql CALL iceberg_catalog.system.rewrite_data_files('my_table'); ``` 需要注意的是，合并小文件是一个后台操作，它不会影响数据的实时写入（除非提交被阻塞，如引用[3]提到的，这是社区正在优化的问题）。 ### 6. **查询数据** 由于Iceberg表已经注册到Hive Metastore，因此可以通过Hive、Spark、Flink或Presto等引擎查询数据。例如，在Hive中： ```sql SELECT * FROM my_table; ``` 查询将返回实时数据与历史数据合并后的结果。总结：通过Flink将实时数据以UPSERT方式写入Iceberg表，Iceberg的ACID特性和快照机制保证了实时数据与历史数据的合并是可靠且一致的。同时，Iceberg支持高频率的增量写入，避免了Hive分区膨胀的问题。引用： - Iceberg支持高频率写入（对比Hive）[^1] - Flink+Iceberg实现流式入湖[^2] - 小文件合并的优化[^3] - 创建Iceberg Catalog[^4] §§相关问题§§ 1. Flink写入Iceberg时如何避免小文件问题？ 2. Iceberg表如何支持时间旅行（Time Travel）查询？ 3. 在Flink中如何配置Iceberg Sink以实现Exactly-Once语义？ </think> ### Flink通过Iceberg实现实时数据与Hive历史数据ACID合并的方法 #### 一、核心原理：Iceberg的ACID能力 Iceberg通过**原子性快照（Atomic Snapshots）** 和**乐观并发控制（OCC）** 实现ACID事务： 1. **原子提交** 每次写入生成新数据文件，仅当元数据文件提交成功时新数据才可见 $$ \text{Commit Sequence} = \text{BaseMetadata} + \Delta\text{Files} \rightarrow \text{NewSnapshot} $$ 2. **快照隔离** 查询始终读取完整快照，写入冲突时自动重试（如引用[3]提到的commit优化）[^3] #### 二、实施步骤 ##### 步骤1：创建统一Catalog（引用[4]） ```sql CREATE CATALOG iceberg_catalog WITH( 'type'='iceberg', 'catalog-type'='hive', 'warehouse'='hdfs:///user/hive/warehouse', 'uri'='thrift://hive-metastore:9083' ) ``` 此Catalog使Iceberg表在Hive中可见，实现历史数据兼容[^4] ##### 步骤2：Hive历史表迁移为Iceberg格式 ```bash # 使用Spark迁移（保留原有分区） spark.sql( "CALL spark_catalog.system.migrate('old_hive_db.history_table')" ) ``` 迁移后原Hive查询不受影响，但获得ACID能力（如引用[1]对比所示）[^1] ##### 步骤3：Flink实时写入设计 ```java // 启用UPSERT模式（主键合并） Table icebergTable = tableEnv.from("iceberg_catalog.db.realtime_table") .createTemporaryTable("realtime_view"); tableEnv.executeSql( "INSERT INTO iceberg_catalog.db.unified_table " + "SELECT user_id, event_time, data FROM kafka_source " + "/* 自动合并重复主键 */"); ``` 关键配置： ```properties write.upsert.enabled=true # 启用主键更新 write.format.parquet.compression=zstd ``` #### 三、流批数据合并机制 1. **增量合并流程** ```mermaid graph TB Hive[历史数据] -->|迁移| IcebergTable Flink[实时流] -->|UPSERT写入| IcebergTable IcebergTable -->|快照S1| Query1[批查询] IcebergTable -->|快照S2| Query2[流查询] ``` 2. **一致性保障** - **版本对齐**：批处理读取固定快照（`snapshot-id=12345`） - **流式增量**：Flink通过`flink.iceberg.writer-mode=append-only`追加变更 - **自动合并**：后台任务压缩小文件（引用[3]优化点）[^3] #### 四、实践案例：用户行为分析 **场景**：合并Hive中的历史订单与实时点击流 ```sql -- 创建统一视图（Iceberg V2格式） CREATE TABLE unified_user_behavior ( user_id BIGINT PRIMARY KEY NOT ENFORCED, historical_orders INT, realtime_clicks INT ) WITH ('format-version'='2'); -- 批量导入历史数据（Hive→Iceberg） INSERT INTO unified_user_behavior SELECT user_id, COUNT(*) AS historical_orders, 0 FROM hive_catalog.orders GROUP BY user_id; -- 流式更新实时行为 INSERT INTO unified_user_behavior SELECT user_id, 0, COUNT(*) FROM kafka_clicks_stream GROUP BY user_id; ``` #### 五、性能优化建议 1. **分区策略** 混合分区提升查询效率： ```sql PARTITIONED BY ( days(ts), -- 时间分区 bucket(16, user_id) -- 哈希分桶 ) ``` 2. **小文件治理** - 定时执行合并（引用[3]社区方案） ```python # 每小时合并小文件 from pyiceberg.operations import RewriteDataFiles RewriteDataFiles().execute(table) ``` - Flink Checkpoint时触发合并（`commit.manifest.target-size-bytes=33554432`） 3. **查询加速** ```sql -- 时间旅行查询历史状态 SELECT * FROM unified_table FOR SYSTEM_VERSION AS OF 123456 -- 指定快照ID ``` #### 六、注意事项 1. **元数据管理** Hive Metastore需升级至3.x支持Iceberg（解决`DESCRIBE FORMATTED`兼容问题） 2. **并发控制** 当批处理与流写入并发时，需配置： ```properties commit.retry.num-retries=5 commit.retry.min-wait-ms=1000 ``` > 通过上述方案，可实现分钟级延迟的实时流与TB级历史数据的ACID合并，避免Hive分区膨胀问题（如引用[1]所述）[^1]，同时保障查询一致性[^2]。