中国联通网络资源湖仓一体应用实践

摘要：本文整理自中国联通技术专家李晓昱，在 Flink Forward Asia 2024 行业解决方案专场的分享。主要介绍中国联通网络资源中心依托 Flink+Paimon 湖仓一体新架构，破解传统数仓处理百亿级数据的瓶颈，内容分为以下四个部分：

1、中国联通网络资源中心简介

2、现状和挑战

3、基于 Flink + Paimon 湖仓一体新架构

4、效果及规划

一、项目简介

中国联通网络资源中心作为全球规模领先的集约化资源管理平台，承载全国 31 省域的网络资源数据、骨干网及国际出口网络等百余类异构数据资源，管理规模达百亿级实体实例。其核心业务是通过物理网络数字化映射技术，将光接入网、核心交换设备等物理基础设施转化为高精度数字模型，构建全域网络资源图谱，实现从信息化设备到智能化数字网络的升级。

二、现状 & 挑战

作为通信行业先行者，中国联通率先实现网络资源数据的全国性集约化平台建设，数据实例达百亿。随着数据量的激增和业务需求的多样化，传统数仓在面对海量数据处理时显得力不从心。历史架构通过 DataX 及 DTS 增量数据捕获变更，将分布式数据库全增量数据接入到 HDFS，采用 MOR 视图表合并实现数据版本控制。

该方案存在以下几个瓶颈：

1. 在进行 CDC 同步时，DTS 的并发能力使得增量订阅链路的并发同样受限。当数据量大幅增加时，增量同步便无法满足业务需求，进而出现严重的延迟现象；

2. 采用 MOR 合并机制下，虽然降低写入压力，但采用 Hive 视图合并需对所有数据进行大量排序操作，获取最新版本数据，在一写多读场景下，造成了计算资源的大量浪费；

3. 资源数据的不定期更新，导致小文件、历史文件的堆积，对于此类文件的运维操作耗时长，效率低，大量小文件会造成集群 Name Node 压力；

4. 分布式数据库，在网络设备维修的实际业务中存在分片键字段值变更，会导致数据更新时产生乱序。

三、基于 Flink + Paimon 湖仓一体新架构

3.1 架构概述

我们采用 Flink + Paimon 湖仓一体架构解决以上问题，整体链路如下图。架构主要分为三个部分：全增量数据接入、数据归档、数据压缩合并。

全增量数据接入：

• 全增量接入均采用 Flink CDC 实现对上游数据的读取接入；

• 全量采用整库同步 Action 实现自动建表、整库同步；

• 增量拆分成 2 步骤

  ① 数据标准化订阅转发 ：实现上游实例对接单边保序的日志流输出、进行消息初步转换以及数据实时合流计算解决数据乱序

  ② 增量写入 Paimon PK 湖表中：采用按省分区、固定分桶、sequence.field 设置 PK 表，实现增量、全量的双通道的无缝衔接。

数据归档链路：

• 将增量数据持续追加写入 Paimon AO 数据湖表中，实现按省分区、动态分桶以及基于 Watermark 进行 AO 表的 Tag 生成。

数据压缩合并：

• 使用 Dedicated Compaction 进行整库压缩，启动独立的压缩作业，避免写入时执行压缩导致吞吐量不稳定。

在实现湖仓一体架构链路搭建过程中，解决了已有的问题以及实现了新场景的适配，主要核心的挑战如下：

3.2 挑战 1 - CDC 乱序

（1）问题描述：分布式数据库分片健修改，导致 CDC 数据乱序

如下图中左侧所示，数据分片更新时产生+D +I 消息，由于数据分库分表导致先输出+I 后输出+D，数据产生乱序。

（2）解决方案：基于 Watermark + State + TimerService 多流保序合并

如上图中右侧所示，按照单边时间戳单调递增及分片键变更局部时间一致原则，合理地过期晚到数据（图中黄色标识为设置过期状态，绿色标识为保留原始状态），实现合流后数据的实时一致性。通过 Sink 算子将保序后的数据投递至消息队列中，以输出一条经过保序合流后的目标数据源。在实际多实例场景下，会出现多实例的反复更新，根据实际更新情况适配 6 种场景，实现仅约 10M 级别的 State 存储，保障数据顺序吐传。

3.3 挑战 2 - 全+增 Schema Evolution

（1）问题描述：多个全量写入 Schema 冲突

我们采用整库全量同步实践过程中发现，各省分源端模型的 Schema 存在差异化，当前社区 0.9 版本仅支撑实现 CDC 场景同类型 Schema Evolution。

（2）解决方案：全量 Schema Evolution 实现到全增量一体化 CdcSchemaCommonUtils

我们不仅实现对全量同步 Schema Evolution 改造，在此基础上将 Schema Evolution 全增量逻辑整合，形成了 CdcSchemaCommonUtils，如此，不论是全量同步还是增量同步，均有效解决了其同步过程中 Schema 不一致带来的困扰。

3.4 挑战 3 - Schema Compatibility

（1）问题描述：在多写入场景下，源端 Schema 变更时间不一致，导致字段类型冲突无法写入增量数据

如下图原本定义为 int 字段，随着业务需求的变化，需要改成 string。但在实际情况中，各个省份的变更进度不一致，有的省份已经完成了类型变更，有的省份还保持着原来的类型。然而增量消息的同步并不会因为这种变更而停止，它会持续不断地进行，导致后续未变更省分增量数据无法写入，产生异常冲突。

（2）解决方案：多场景写入 Schema Compatibility 实现

通过实现 Schema Compatibility 指定可兼容的场景，比如：对于 Int -> String 是可兼容的场景，而 Sting -> Int 是非法的，保障在多写入场景下，源端字段类型冲突的问题，导致数据无法更新。

四、效果及规划

湖仓一体新架构方案，解决了数据乱序问题，端到端数据一致性达 100%，此外性能也显著的提升，具体效果如下：

中国联通通过湖仓一体架构的应用实践，实现了百亿级网络资源数据的全局一致性治理与分钟级实时分析能力。该方案为通信行业海量异构数据的集约化管控提供了可复用的技术范本，未来将持续探索流式数仓与智能运维的深度融合，驱动运营商数字化基础设施向更高阶的智能化阶段演进。

更多内容

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：新用户复制点击下方链接或者扫描二维码即可 0 元免费试用 Flink + Paimon实时计算 Flink 版（3000CU*小时，3 个月内）了解活动详情：https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc