flink sql在实时数仓中，关联hbase维表频繁变化的问题

最新推荐文章于 2025-06-30 00:02:25 发布
原创 最新推荐文章于 2025-06-30 00:02:25 发布 · 1.8k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#flink #大数据

博主使用Flink SQL搭建实时数仓，架构为Kafka关联HBase维表后写入ClickHouse，HBase维表频繁变化。遇到了异步IO性能不足、缓存一致性问题、写入HBase无法保证有序以及维表更新不及时导致关联数据为空等问题，寻求解决思路和方案。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在用flink sql在做实时数仓，架构大概是kafka关联hbase维表，然后写入clickhouse。hbase维表是频繁变化的

现在遇到的几个比较棘手的问题：

  • 1、自己在实现AsyncTableFunction做异步io的时候，发现性能还是不够。后来就加入本地缓存，但是缓存一致性出现问题，不知道该如何解决
  • 2、写入hbase的时候，是批量写的，无法保证有序，维表频繁变化的话，顺序不对，会造成结果有问题
  • 3、hbase维表，可能5s后才会更新，但是此时kafka数据流已经过去了，关联的数据都是空

不知道，针对上面的场景，有什么好的解决思路或者方案？

Flink——芒果TV的实时数仓建设实践
爱吃辣条的博客
02-29 1838
Flink——芒果TV的实时数仓建设实践
优化 Apache Flink 中的维表 Join 策略：探索最佳实践和技巧
数据与算法架构提升之路专栏
01-12 1983
总体来讲，关联维表有六个基础的方式： （1）查找外部数据源关联 （2）预加载维表关联（内存，状态） （3）冷热数据储备（算是1和2的结合使用） （4）维表变更日志关联（广播也好，其他方式的流关联也好） （5）Temporal Table Join （6）Lookup Table Join
hbase使用、运维、改进(不断更新)
热门推荐
bluekeyv的专栏
03-07 1万+
刚刚看了google jeff dean 在新的一年里发表的演讲，讲到各种系统配合使用完成海量数据处理任务。深有感触：http://t.cn/zYE89gn 。2013年，依然会专注hbase研究，并以此为基础扩展，对hbase衍生的一些特性和产品进行深入研究，例如replication、phoenix。从传统的离线计算（hadoop、hive），到实时流式计算系统（storm、s4），创新应用性
Flink流关联频繁更新的维表解决方法探索
weixin_41870706的博客
02-10 3076
目的 实时解析处理用户的注册，实名，申额，支用等用户业务流程数据binlog，计算用户生命周期的相应指标到Kudu中，并且需要将当用户指标数据发生变更后也要同时推送到kafka 给其他业务做增量计算，根据这些实时指标，进行后续实时营销等信息推送。 背景介绍 用户在app上进行简单注册后，会赋值给用户一个userid，但是后续实名等发生具体业务后，会给用户分配一个custno与userid映射关系相关联，接下来用户的所进行的业务例如绑定银行卡，人脸识别，申额，支用，还款等...
HBase踩过的坑——持续更新
weixin_34375054的博客
11-06 748
1.HBase数据热点问题 问题描述： 在某一个时刻，电池数据表的以某些规则开头的数据，比如M12******，这些电池一直在上报数据，由于HBase的存储是按照字典顺序排序的，所有某一时刻，相似规则的数据落在了同一个region上，造成了数据热点。 解决方法： 我们采取的是rowkey散列+预分区的方式：http:...
Flink：动态表上的连续查询
大数据星球-浪尖
06-25 5098
用SQL分析数据流越来越多的公司在采用流处理技术，并将现有的批处理应用程序迁移到流处理或者为新的应用设计流处理方案。其中许多应用程序专注于分析流数据。分析的数据流来源广泛...
Flink 使用 broadcast 实现维表或配置的实时更新
http://www.54tianzhisheng.cn/
04-02 5016
通过本文你能 get 到以下知识：Flink 常见的一些维表关联的案例常见的维表方案及每种方案适用场景，优缺点案例：broadcast 实现维表或配置的实时更新一、案例分析维表服务在 ...
Flink SQL 优化实战 - 维表 JOIN 优化
cloudbigdata的博客
05-27 7239
从源码层面分析维表 Join 原理及调优方案
滴滴基于 Flink 的实时数仓建设实践
数据库技术
09-04 568
随着滴滴业务的高速发展，业务对于数据时效性的需求越来越高，而伴随着实时技术的不断发展和成熟，滴滴也对实时建设做了大量的尝试和实践。本文主要以顺风车这个业务为引子，从引擎侧、平台侧和业务侧各个不同方面，来阐述滴滴所做的工作，分享在建设过程中的经验。 1.实时数仓建设目的 随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要，商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息， 对企业的决策运营策略调整有很大帮助。 其次从智能商业的角度来讲，数据的结果代表了用户的反馈，
用Flink打造实时数仓：生产环境中的“坑”与“解药”
最新发布
大模型大数据攻城狮的专栏
06-30 704
使用Flink的StreamingFileSink配置合理的滚动策略（如基于文件大小或时间），合并小文件。代码示例。
基于开源的flink对其实时sql进行扩展；主要实现了流与维表的join
08-08
基于开源的flink，对其实时sql进行扩展；主要实现了流与维表的join
【flink理论】动态表：关系查询处理流的思路：连续查询、状态维护；表转换为流需要编码编码
hiliang521的博客
11-15 739
主要讲了： flink维护一个动态表来处理不断变化的流查询，这需要维护状态。 动态表转换为流或输出时需要进行流的编码
Flink动态表的连续查询（Continuous Queries on Dynamic Tables）
javawins的专栏
01-25 790
Apache Flink 非常适用于流分析应用程序，因为它支持事件时间语义，确保只处理一次，以及同时实现了高吞吐量和低延迟。因为这些特性，Flink 能够近实时对大量的输入数据计算出一个确定和精确的结果，并且在发生故障的时候提供一次性语义。 Flink 的核心流处理 API，DataStream API，非常具有表现力，并且为许多常见操作提供了原语。在其他特性中，它提供了高度可定制的窗口逻辑，不...
FlinkSQL hbase连接器读取数据失败问题
TreeCode的博客
08-17 1061
sql： tEnv.executeSql("DROP TABLE IF EXISTS ywb_source"); tEnv.executeSql( "CREATE TABLE ywb_source (\n" + " rowkey STRING,\n" + " info1 ROW<name STRING>,\n" +
【FLINK】实时流读取维表（二）Async I/O
Zsigner的博客
01-18 714
1、aysnc i/o 的设计 The following diagram illustrates how the streaming records are processed while arriving at AsyncWaitOperator recovering from task failover snapshotting state being emitted by Emitter Thread 来源：FLIP-12: Asynchronous I/O Design and Imp
Flink系列Table API和SQL之：动态表、持续查询、将流转换成动态表、更新查询、追加查询、将动态表转换为流、更新插入流(Upsert)
zhengzaifeidelushang的博客
12-31 3117
Flink系列Table API和SQL之：动态表、持续查询、将流转换成动态表、更新查询、追加查询、将动态表转换为流、更新插入流(Upsert)
flink-sql消费kafka实时关联hbase获取维度信息
weixin_43803793的博客
11-09 2121
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime); // env.setParallelism(1); // 1、创建表执行环节 StreamTableEnvironment tableEnv = St..
flink 实时查数据库引发的异常
anita9999的博客
12-12 2328
1.flink实时从kafka接收数据，插入mysql ,引用 HikariDataSource dataSource=BaseConf.baseMysqlDs(); Connection connection=HikariCpPool.getConnect(dataSource); 没有关闭数据库连接，插入一万条数据，创建一万条连接，造成mysql连接数过多，数据库异常 ...
Flink之异步I/O案例（二）异步查询MySQL数据库
IT_但丁的博客
03-12 2631
文章目录一、需求思考1、通过异步查询Mysql中的以下数据：2、思考二、代码实现1、添加依赖2、主线代码3、异步查询的MySql的Function四、技术点 一、需求思考 1、通过异步查询Mysql中的以下数据： 2、思考 Mysql不支持异步查询，那该怎么办呢？ 创建线程池和数据库连接池，来实现异步的并发查询。 这样异步查询中，一个请求就是一个线程，一个请求对应一个连接。 二、代码实现 1...
数仓中的DIM层怎么同步到数仓中
04-01
<think>好的，用户现在问的是数仓中的DIM层如何同步到数仓中。首先，我需要回顾一下之前讨论的内容，之前用户询问了数仓分层的好处，现在则是具体到DIM层的同步方法。DIM层即维度层，主要用于存储维度数据，比如用户、商品、时间等维度信息。 用户可能的背景是数据工程师或者相关岗位，需要了解维度数据同步的具体方法。他们可能在实际工作中遇到了如何高效、准确地将维度数据从源系统同步到数仓的问题。因此，用户的需求不仅仅是知道步骤，还包括不同方法的优缺点、适用场景以及注意事项。 接下来，我需要考虑DIM层同步的常见方法。通常包括全量同步、增量同步、CDC（变更数据捕获）、双写机制等。每种方法都有其适用的情况，比如全量适用于数据量小或变化频繁的情况，增量适用于数据量大但变化少的情况，CDC适用于需要实时同步的场景，双写则可能用于新旧系统过渡时期。 另外，用户可能关心如何保证数据一致性、处理缓慢变化维（SCD）的问题，比如类型1覆盖历史，类型2保留历史版本。这些都是在同步过程中需要考虑的细节。 还需要提及同步工具，比如Sqoop、DataX、Flink CDC等，以及调度系统的配合，比如Airflow或DolphinScheduler，确保同步任务的自动化执行。同时，数据质量监控也是不可忽视的部分，比如校验数据量、主键唯一性、数据一致性等。 用户可能还希望了解实际的应用场景，例如在电商系统中如何同步用户维度数据，结合具体案例来说明不同同步方法的选择和操作步骤。 在回答时，需要结构清晰，分步骤说明每种同步方法，对比优缺点，给出实际例子，并强调注意事项，如数据一致性、性能优化、历史数据处理等。这样用户能够根据自身情况选择最合适的同步策略，并了解实施过程中可能遇到的问题及解决方法。</think>数据仓库中的DIM层（维度层）同步是构建一致性维度模型的关键环节，主要通过**维度数据从业务系统到数仓的标准化映射与更新**实现。以下是DIM层同步的核心方法、技术选型与典型实现流程： --- ### 一、DIM层同步的3种核心模式 #### 1. **全量同步（Full Load）** - **适用场景** - 维度表数据量较小（如$dim\_date$时间维度表） - 业务系统无法提供增量变更记录 - **实现步骤** ```sql -- 示例：每日全量覆盖用户维度表 TRUNCATE TABLE dim_user; -- 清空现有数据 INSERT INTO dim_user -- 全量插入最新数据 SELECT user_id, name, gender, address, create_time FROM source_user_db.user_info; ``` - **优点**：实现简单，保证数据一致性 - **缺点**：资源消耗大，不适合大数据量表 #### 2. **增量同步（Incremental Load）** - **适用场景** - 维度表有明确更新时间戳字段（如`update_time`） - 业务系统支持增量查询（如MySQL的`WHERE update_time > last_sync_time`） - **实现步骤** ```sql -- 示例：按更新时间增量同步 INSERT INTO dim_user SELECT user_id, name, gender, address, create_time FROM source_user_db.user_info WHERE update_time > '2023-10-01 00:00:00'; -- 获取上次同步后的变更 ``` - **优点**：资源消耗低，适合大表 - **缺点**：依赖源系统时间戳准确性，可能遗漏无更新时间字段的变更 #### 3. **CDC同步（Change Data Capture）** - **适用场景** - 需要实时/准实时同步（如用户画像实时更新） - 业务系统支持Binlog或类似日志（如MySQL Binlog、Oracle Redo Log） - **技术实现** - **工具选择**：Debezium（捕获Binlog）、Flink CDC、Maxwell - **处理流程**： 1. 解析数据库日志获取增删改事件 2. 转换日志事件为维度表结构 3. 写入DIM层并处理SCD（缓慢变化维度） ```sql -- SCD Type2处理示例（保留历史版本） UPDATE dim_user SET end_date = CURRENT_DATE WHERE user_id = 'U1001' AND end_date = '9999-12-31'; INSERT INTO dim_user VALUES ('U1001', '张三', '男', '北京', '2023-01-01', CURRENT_DATE, '9999-12-31'); ``` - **优点**：支持实时同步，数据延迟低 - **缺点**：技术复杂度高，需要处理事务一致性 --- ### 二、DIM层同步技术选型对比 | 同步方式 | 工具示例 | 延迟 | 适用场景 | 复杂度 | |------------|-----------------------|---------|----------------------------|--------| | **全量同步** | Sqoop、DataX | 天级 | 静态维度（地区、日期） | 低 | | **增量同步** | Airflow定时SQL | 小时级 | 中低频变更维度（商品类目） | 中 | | **CDC同步** | Debezium + Kafka | 秒级 | 高频变更维度（用户信息） | 高 | --- ### 三、典型实现流程（以电商用户维度表为例） #### 1. **数据抽取** - **源系统**：MySQL业务库的`user_info`表 - **字段映射**： | 源字段 | 目标维度字段 | 转换规则 | |----------------|--------------------|-------------------------| | `id` | `user_id` | 直接映射 | | `name` | `user_name` | 去除前后空格 | | `birthday` | `age` | `YEAR(NOW()) - YEAR(birthday)` | | `province` | `province_code` | 关联地区维度表$dim\_region$ | #### 2. **数据清洗** - **去重**：根据`user_id`去重，防止脏数据 ```sql SELECT user_id, MAX(update_time) AS latest_time FROM staging_user GROUP BY user_id HAVING COUNT(*) > 1; -- 检测重复数据 ``` - **空值处理**： ```sql -- 将空地址标记为未知 UPDATE dim_user SET address = '未知' WHERE address IS NULL; ``` #### 3. **SCD处理（缓慢变化维度）** - **Type1（覆盖历史）**：直接更新字段 ```sql UPDATE dim_user SET address = '上海市' WHERE user_id = 'U1001'; ``` - **Type2（保留历史）**：插入新版本并标记时间范围 ```sql -- 关闭旧记录有效期 UPDATE dim_user SET end_date = '2023-10-01' WHERE user_id = 'U1001' AND end_date = '9999-12-31'; -- 插入新记录 INSERT INTO dim_user VALUES ('U1001', '张三', ..., '2023-10-01', '9999-12-31'); ``` #### 4. **数据加载** - **批量加载**：使用`INSERT OVERWRITE`（Hive）或`TRUNCATE + INSERT`（MySQL） - **实时更新**：通过Kafka将CDC事件写入HBase或ClickHouse --- ### 四、注意事项 1. **一致性保障** - 使用事务保证抽取-转换-加载的原子性 - 在分布式系统中采用两阶段提交（2PC） 2. **性能优化** - 对大表采用分区同步（如按`create_time`按月分区） - 使用列式存储（Parquet/ORC）减少I/O压力 3. **历史数据处理** - 定期归档过期维度版本（如将$dim\_user$中`end_date < '2020-01-01'`的数据迁移到历史库） 4. **数据质量监控** - 校验数据量波动（如`COUNT(*)`日环比变化超过10%时告警） - 检查主键唯一性（`SELECT user_id, COUNT(*) FROM dim_user GROUP BY user_id HAVING COUNT(*) > 1`） --- ### 五、典型架构示例 ``` 业务系统MySQL │ ↓ Binlog Kafka（实时传输变更事件） │ ↓ Flink CDC ODS层（原始用户数据） │ ↓ ETL处理 DIM层（标准化用户维度表） │ ↓ 关联引用 DWD事实表（如$fact\_order$关联$dim\_user$） ``` 通过合理选择同步策略与SCD处理方式，DIM层可有效支撑“用户画像分析”“多维度交叉分析”等核心场景。
评论 7
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

雾岛与鲸

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值