用友畅捷通在Flink上构建实时数仓、挑战与最佳实践

摘要：本文整理自用友畅捷通数据架构师王龙强在 FFA2024 分论坛-生产实践专场关于用友畅捷通在 Flink 上构建实时数仓、挑战与最佳实践的分享。内容主要为以下五部分：

一、业务背景

二、数仓建设

三、当前挑战

四、最佳实践

五、未来展望

用友旗下的畅捷通信息技术股份有限公司自 2010 年成立以来，经历了从传统软件服务向 SaaS 转型的历程，并逐步构建了自己的云服务平台。在过去两年中，基于 Apache Flink 技术框架，我们在数据仓库（数仓）建设方面取得了显著进展。面对数仓同步过程中遇到的各种挑战，团队通过不懈努力与创新尝试，成功实现了高效稳定的数据处理流程。

• 2005 年至 2012 年间，专注于提供包括 T1、T3、T6 及 T+ 在内的软件包服务。
• 2013 年起转向研发 SaaS 解决方案。
• 2014 至 2016 年期间，在数字财税领域推出“好会计”和“易代账”等产品。
• 2018 至 2019 年间，“好生意”与 T+Cloud 相继问世，标志着公司在数字化商业领域的进一步拓展。
• 自 2019 年以来，持续完善自身的云端服务体系，并推出了“好业财”。
  那么，本次分享将深入探讨我们在采用 Flink 作为核心技术支撑下的数仓实施经验以及如何克服在这一过程中所面临的技术难题。希望通过我们的案例能够为同行们提供更多有价值的参考信息！

01. 业务背景

随着业务的快速发展，数据量急剧增长，导致数据库中出现大量慢查询，严重影响了整体性能。即便是通过分库和优化索引等传统方法也难以有效提升某些报表查询的速度，有时甚至需要花费 4 到 6 分钟才能完成一次查询。此外，越来越多的应用场景要求实时数据处理能力，这不仅限于 MySQL 或 PolarDB 这样的关系型数据库，还包括 SQL Server、PostgreSQL 乃至对象存储服务 OSS 等多种数据源。面对这一系列挑战，如何保证数据链路的稳定性成为一大难题，尤其是应对数据延迟、表结构变更以及数据一致性问题时显得尤为棘手。同时，缺乏有效的监控工具使得故障排查过程变得漫长而复杂。为解决这些问题，构建高效稳定的数据处理平台迫在眉睫，以支持业务持续健康发展。

02. 数仓建设

2.1 数据规模

整个数仓的规模目前大概涵盖五大产品线：好生意、好会计、易代账、TC 以及好业财，支持多达八种不同的数据源接入。目前，系统中运行的任务数量超过 6000 个，实际任务种类达到数百个。作为一家专注于 ToB 的企业，我们管理的数据量级达到了十亿级别。

2.2 实时数据流发展历程

实时数据流技术随着业务需求的不断增长而逐步演进，大致经历了五个重要阶段，每一步都标志着技术的进步与应用场景的扩展。以下是基于阿里云产品的演变历程简要概述：

1. DTS（Data Transmission Service）阶段：初步构建了端到端的数据传输链路，采用经典的 Lambda 架构，但不支持流批一体处理及中间 ETL 转换。
2. DataHub + DataStream 阶段：引入 DataHub 作为数据聚合点，使得不同业务可通过 DataStream 接入实时数据，增强了实时 ETL 能力但仍未能解决流批一体化问题。
3. Flink SQL 阶段：实现了流批一体处理，简化了开发流程，允许通过编写简单的 SQL 语句完成复杂的数据同步任务。然而，在应对 DDL 变更、大规模字段映射以及减轻源数据库压力方面存在局限性。
4. Flink CDAS (Create Database As Stream) & CTAS (Create Table As Stream)：进一步优化了资源管理，显著降低了对源头数据库的压力，并支持 Schema Evolution 自动适应字段变化，极大地提升了运维效率和灵活性。不过，对于某些高级 ETL 操作的支持仍有限制。
5. Flink CDC 3.0：最新推出的版本，在继承前代优势基础上增加了对更复杂 ETL 逻辑的支持，包括过滤等功能。这标志着向更加全面且高效的实时数据处理解决方案迈进了一大步。

2.3 数据仓库技术架构

这是目前应用畅捷通最新的数据仓库技术架构图。可以看到有两条计算链路：一条是离线的计算链路，另一条是实时的计算链路。离线的计算链路主要通过 MaxCompute + DataWorks 实现数据的加工，数据加工处理后的结果或指标通过外表关联或 DataWorks 的数据回写至 StarRocks 构成的实时数据仓库中。实时计算链路则包括 DataStream 作业、CDC（变更数据捕获）作业、CTAS（创建表作为选择）、CDAS 以及最近上线的 Flink 数据摄入作业。目前，实时数仓主要采用 Hologres、Elasticsearch (ES) 和 StarRocks 三种技术方案，其中以 StarRocks 为主导，并计划未来逐步用其替换其他方案。

数据源主要来自业务系统及日志文件，如 PolarDB、MySQL、PostgreSQL 和 SQL Server 等数据库。完成数据同步导入后，该架构能够为智能补货、会员分群分析、热销商品推荐、客户运营等多种业务场景提供支持，并允许用户通过 BI 工具查看报表。为了确保整个流程的稳定性和准确性，架构底层实施了多种监控措施，包括但不限于结构监控、延迟监控、重启机制以及数据完整性检查，以此保证数据仓库内数据既全面又准确。

03. 当前挑战

在数仓建设过程中，我们遇到了不少挑战。去年，畅捷通分享了如何利用 Flink 进行数仓的落地实践。今天重点讲在数据链路上遇到哪些挑战，以及在这些挑战做出的措施和努力，简单分成三个部分：一是数据延迟和链路重启，二是表结构和表数据差异管理，三是流程自动化和资产盘点。流程自动化是低代码，处于刚起步，只是一个想法，目前以 SDK 的方式完成自动化的数据作业的完善。

04. 最佳实践

4.1 数据延迟+链路重启

首先看一下如何及时发现数据延迟和链路重启。经过四个阶段，首先是定时的探活、延迟、重启和报警。这个阶段刚开始接触时，各方面包括阿里云实时计算 Flink 版可能也不完善时，通过 API 或者通过 Demo 数据的插入，从而做到延迟和重启的报警。第二个阶段是 Flink 作业级别的报警配置，阿里云实时计算 Flink 版每一个作业后边都有一个报警配置，可以添加一些延迟的报警和数据重启的报警。比较麻烦的一点是线上只能是每个任务的添加。如果线上有 100、200 个任务，对这 100、200 个任务添加可能比较麻烦。

年初时用云监控报警配置，8.09 对云监控报警配置的功能进行完善，可以进行电话、短信，还有钉钉等各种方式的报警。不过在使用时发现报警全是一堆 ID，在使用时非常不方便，找不到是哪一个作业，是哪个 workspace。最新用的是 Prometheus + ARMS 的云监控报警，它拥有云监控报警的一切，报警的方式也支持。报警界面比较友好，会告诉是哪个 workspace，哪一个作业，从什么时候发生的延迟，什么时候发生的重启。

在引入监控系统之后，我们仍然面临两个主要问题：一是“少”，即担心报警信息不足，导致重要警报被忽略；二是“多”，即过多的重复和无用报警信息让处理人员变得麻木，响应速度虽然加快，但在真正出现问题时却无法及时调整。经过一年多的联调与测试，我们已经解决了报警信息不够精确的问题，现在线上出现的报警基本可以确定是链路存在问题。

各位 Flink 开发的老师过去一年中大力支持，如何面对“狼来了”的场景，结合公司现有的一套报警服务，形成自己的一套报警体系。

1. 报警触发：当 Prometheus/ARMS 检测到异常情况时（如性能下降、错误率增加等），会生成一个报警事件。
2. 同步至事件中心：该报警事件被同步到 ARMS 的事件中心。这里不仅记录了来自 Flink 的报警信息，还包括其他应用程序、数据库、MC 以及各种大数据产品的报警信息。
3. 通知处理人：基于预设规则或配置，系统自动向指定的第一责任人发送报警通知。这可以通过多种渠道实现，比如邮件、短信、电话等。

4. 处理人响应：

   • 如果第一责任人及时响应并开始解决问题，则进入问题解决阶段。
   • 若第一责任人未响应，则启动进一步的通知机制。
5. 问题解决：一旦问题得到妥善处理，相关状态将在事件中心更新，标记为已解决。

6. 未响应情况下的处理：

   • 如果在规定时间内没有收到第一责任人的响应，系统将尝试通过电话或其他方式再次联系此人。
   • 若仍无响应，则转向第二责任人进行通知。
   • 第二责任人也未能解决问题时，将进一步上报给主管。
   • 在极端情况下，如果团队全体成员都无法联系上（例如正在进行团建活动），则最终将通过紧急联系方式（如家庭成员）传达消息。
7. 报警级别与类型管理：在整个过程中，根据报警的严重程度和类型不同，采取不同的应对措施。对于特别重要的报警，可能需要立即采取行动；而对于已经有人正在处理但尚未完成的情况，则给予一定的宽容度。

如何解决？对于日常解决数据延迟大概有四种方案：

1. 自动调优：阿里提供的一种功能，包括定时调优与智能调优两种模式。定时调优可以在每天特定时间段（如早高峰）自动增加资源分配；而智能调优则基于系统性能参数动态调整资源。
2. 手动调优：当需要更精细地控制时，可以选择手动方式来增加所需资源。此外，在执行数据同步任务时，可以通过拆分作业节点来提高效率。例如，通过添加额外参数来监控每个表的具体同步状况，这有助于快速定位并排除故障点，从而加快整个链路的恢复速度。但是需要注意的是，某些参数可能会降低数据同步的速度，因此建议在发现其负面影响后予以移除。
3. 建立独立同步路径：对于大规模数据传输场景（如加盟连锁业务或 B2B/C 一体化应用），面对瞬时巨大流量冲击时，可通过创建新的独立数据同步通道从最新位置开始同步，跳过高峰期流量，以缓解现有系统的压力。

4. SQL 优化：针对数据库查询语句进行优化也是一种有效手段。网络上有大量相关资料可供参考学习。此外，当遇到需要重启数据链路的情况时，应首先依据错误日志分析问题根源。常见的故障类型主要包括源数据库读取异常、数据传输过程中出现的问题以及目标数据库写入失败等。具体来说：

   • 源端数据库问题可能涉及到 binlog 文件过期、主备切换引起的 binlog 不一致或者是服务器 ID 冲突等情况。
   • 传输过程中的问题往往是因为计算资源不足或是由于 DDL 操作导致的数据结构变化。
   • 目标端写入失败则多见于使用 StarRocks 作为存储引擎时所遭遇的各种挑战。我们团队已经积累了丰富的经验，并持续与 StarRocks 开发小组合作改进这方面的问题。特别是在处理多个源库向单个目标库同步数据的情况下，若同时发生字段变更且伴有实时写入操作，则极有可能引发链路中断。此时应当迅速识别受影响的表格，将其暂时隔离以保证其他部分正常运行，待修复后再重新启动该表的同步进程。

4.2 表结构差异

针对表结构差异和表数据差异的数据层面的问题。首先是表结构差异，表结构差异大概总结两点，出现差异的原因首先是数据链路不支持 DDL 的同步，比如 DataStream 或者 Flink SQL 不支持 DDL 同步。脚本上线有相应的程序，在脚本上线时会把链路的脚本一起加上，针对 Flink CDAS 或者 CDC 3.0 支持 Schema Evolution，支持表结构变化。

什么时候会出现表结构不一样，主要是多库对一库时，目前线上还有问题，线下因为 StarRocks 测的同学改正，最近没出现，线上还有问题。Flink CDAS 新建链路导致 Schema Change 的事件丢失，当数据来时无法触发目标数据库表结构的变化。比如 CDAS 可能有数据触发 Schema 的 Change，CDC 3.0 只要发生 Schema Change，就会把 Schema Change 同步到目标库。如果是 CDNS，目前只能由数据触发。

有时会进行重启链路，新建链路的操作。新建完一条链路，之前链路的 Schema Change 完成，数据还没过来，又新建一条链路，这条新建的链路过来数据时，事件就会丢失，不会再进行 DDL 的变化，目标端这个时候就会出现丢失。针对于支持 DDL 变化的链路，也会存在表结构差异。

如何解决？对比报警，会每天拉取 Flink 目前线上所有同步的 Flink Job 信息，会解析出所有的表以及这些表涉及的源端数据库和目标端数据库。然后根据解析出来的源端数据库和目标数据库还有一些表，进行表结构的对比，对比的结果会通过报警服务发给相应的处理人。

4.3 表数据差异

表数据差异总结两个原因，原因一是 ETL 场景，原因二是 ELT 场景。

在 ETL 场景中，进行实时的数据清洗和加载时，可能会出现一些 Bug 导致数据的差异。这可能是由于 SQL 语句的问题，在进行 Flink join 时，一些维表在 Look Up Join 时出现数据的差异。数据差异并不是指数据与原始数据不同，而是指数据没有按照预期的方式进行清理。如何解决这一问题？比如在加盟连锁、连锁店的场景，或智能补货、卖货的场景，可以针对实时数据链路的场景，进行具体链路的数据差异恢复。一般会通过每次写一个数据清理的程序，并必须制定一套数据备份方案，出现问题时执行该方案，对单个租户进行数据恢复。

在 ELT 场景中，从 MySQL 直接同步到 StarRocks 时，数据差异可能由解析数据失败造成，比如链路合并操作不当导致数据差异，或者由于数据延迟而跳过瞬时的流量。在后续进行数据合并时，需要停掉快速的链路，保留慢的链路。如果停掉慢的链路，慢的链路会回放刚刚插入的数据操作，如果紧跟着删除数据，可能会导致删除操作无法执行。如果链路合并不当，也会导致数据产生差异。

有些业务对数仓进行读写操作，有时人为的操作不当会导致数据差异。如何解决？通常需要进行数据对比。由于数据量较大，不可能每天进行全面对比，通常是被动发现，由业务方或测试反馈数据出现问题。如果数据量差距较小，可以尝试缩小到某一个数据范围，比如某个账号，然后再对差异数据进行比较和恢复。如果数据量差距较小，找到藏在成千上万条数据里的几条差异数据，可以使用一些数据挖掘和比较算法，帮助识别和定位这些差异数据。

用流程图描述对差异性数据如何做，因为差异性数据不多，比如有数据对比程序，数据对比程序首先会对数据源进行初始化，初始化可以对源端初始化同时对目标端初始化，做权限的验证或连接初始化，初始化之后，会对一些文件输出的线程进行初始化，有几个线程去标志这两个数据表不同的地方，数据不同的文件，Match 是数据相同的，一般 Match 不会输出，不会关注相同的数据，Miss 线程是目标端缺少的数据。Extra 线程是目标端多数的数据，初始化这条线程后会根据它的条数进行判断。如果在条数目前的阈值，这个条数的阈值是一万，如果这个条数没有超过阈值，直接通过 ID 排序对比直接输出。如果阈值超过一万，进行一个指纹加密。现在最大支持 50 万条数的对比，太多条数数据库的临时表内存受不了。

首先在源端和目标端初始化两个表，这两个表以 Md5 为例，Md5 的数据临时表只有两列，一列是组件，一列是 Md5 指纹加密。初始化表后，开始进行 Md5 的指纹加密计算，计算完会把某一端的 Md5 的临时表插入到另一端，一般会把源端插入到目标端，然后通过链接的方式进行比较，源端和目标端都插入到同一个数据库里，可以通过比较。如果源端临时表去 Left Join 右端的目标端临时表，如果左源端的 Md5 值不是空，并且右端的 Md5 值是空，这就是多出来的数据，找到多出来的 ID。如果它两端都不为空，并且两端的 Md5 值都相同，相同的数据就找到了。如果用目标端的临时表去 Right Join 左端的源端的临时表，如果源端的 Md5 值是空，目标端的 Md5 值不是空，目标端多出来的数据找到。最后如果两端的 Md5 值都不是空，但 ID 相同，它的 Md5 值不相同，不同的数据就找到了。

4.4 流程自动化

最后是流程自动化和资产盘点。流程自动化，首先看图片，Flink 提供越来越简便，越来越高级的 API 及使用方式，从 DataStream 到 Table API 到 SQL 再到 CDAS 和 CDC，刚开始做一些尝试，现在讲究数据分析，让数据分析成为全民参与的一项团队运动。目的很简单，想让数据同步能成为一项全民参与的团队运动。需要给没接触这方面的同学提供更为方便的工具，让他参与到这项运动中。感到同步这么简单，这么有趣，以后可能会更深入的了解，研究 Flink 方面。目标是降低数仓数据同步的使用门槛，让整个操作变得更简单。然后提高效率，减少错误，将一些固定化的操作以流程化的方式固定，会减少一些错误，后续也能提高可维护性，更容易修改同步链路，适应业务需求的变化。最后是合规性和审计，每一张表的增删记录在整个系统里会有一个留存，后续可以跟踪这些表是谁加的，什么时候加的，把这一层叫 Automatic。参与流程自动化有两种角色在系统中，一个是作业提交人员，一个是作业审核人员，比如业务的同事只需要选库，选表就行，针对到底选的是 Flink Server 作业还是 Flink CDAS 和 CTAS 作业或者选的是 Flink 数据摄入的作业，因为 Flink 是新上的功能，所以在做相应的 SDK 的开发，选完之后就会针对其他的信息进行自动化的补全，补全完后同步人员进行提交，提交完后相应的专业数据同步人员可以对作业进行审核，如果觉得没问题，对它进行资源的分配，参数的调整，从而完成整个作业的启动。

4.5 资产盘点

资产盘点是非常必要的，首先可以帮助全面梳理整个公司的现状，推动用友畅捷通的数字化转型。另外也能帮助及早发现数据问题，帮助查漏补缺，提升数据质量。最后可以提升数据治理的手段和数据使用的效率，左侧图是目前 StarRocks 的数据库和项还有表之间的关系，可以支持逐层的下断取，然后查看 StarRocks 每个数据库里支持多少项目，每个项目里边需要多少表，右边图是当前线上同步多少业务库，每个业务库有多少表的同步，也支持下端的查看。StarRocks 测会专门统计每一个 StarRocks 里的物化视图，还有表，还有其他的信息。右边会对线上所有的 StarRocks 集群所有的表的数据量进行监控，保留最近半年的数据量方便后续的追踪。最后是做 StarRocks 的物化视图的血缘分析和影响分析，因为 StarRocks 的物化视图完成数仓的分层还有数据的清理工作，不可避免会涉及到一些视图的嵌套。改底层的物化视图会影响到上层的物化视图 In Active，如果改这个可能还要兼带着改其他物化视图。给相应的同事更直观的查看需要改哪些物化视图。右边做一些每日的监控体系，每日的监控比如 Flink Job 的同步更新，或者每天的表结构的对比和物化视图的刷新，基于物化视图有时物化视图刷新失败，会人为看一下为什么失败。同步链路的表项目中是否因为每个项目会导的表不一样，看某条链路，某个项目是否缺少表等一系列监控。

05. 未来展望

关于未来展望有三点：

5.1 链路稳定性建设

首先是链路稳定性建设，后续还会继续加强链路稳定性的建设，基于实时 Flink，还有 DTS 到 DataHub 的稳定性建设后续也会加强，因为一些历史原因。以 MC 为主的离线数仓还会在公司存在一段时间，会对链路进行一个稳定性的建设，Flink 任务流程的自动化，最后是 Flink 任务的日常监控，这是其他各种维度比较重复的系列问题。

5.2 数仓建设

数仓建设未来可能会基于湖仓一体，还有数据湖方面进行一定的探索，可能会把数据先存到 Paimon 或者是 Hudi，然后 MaxCompute 或 DataWorks 进行离线数据的大批量的数据集计算，StarRocks 或 Paimon 进行实时数据的计算和加载。

5.3 双轮驱动

最后是双轮驱动，双轮驱动主要是 Olap 数据仓库和 AIGC，也就是人工智能领域。未来会深度紧密的结合AI 和相关的一些技术，融合 AI 的一些原生技术，不断实现运营和产品的流程化和自动化，推进数据资源的高效利用，还有 AIGC、数据、大模型方面的高效利用。

---

更多内容

---

活动推荐

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