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

摘要：本文整理自中国联通技术专家李晓昱，在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%，此外性能也显著的提升，具体效果如下：

核心指标	历史方案	湖仓架构	性能提升
数据同步延迟	3h	3min	提速10倍+
业务加工效率	1h	10min	提速6倍+
数据点查	120s	3s	提速40倍+
存储成本	50T	25T	降本约50%
计算资源成本	几十T万核	几T千核	节约近10倍+

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

---

更多内容

---

活动推荐

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