一、Databus同步问题

二、Mysql全量同步问题

1.离线全量同步速度慢

    在每天/每小时全量抽取上亿大表时，若并发高会致使 mysql 负载满从而影响业务，若并发低则抽取时间可能超过 30 分钟，进而影响数据链路的时效性

2.实时链路问题排查困难

    实时链路通过 Kafka 存储，使得问题排查较为困难。以往需要在服务器消费上亿 Kafka 数据或者导入 ck 去排查数据问题，此过程查询费时费力。如今通过分钟级写入数据湖，能够通过 SQL 直观地分析数据，提升了解决问题的效率

3.离线、实时两套链路问题

    由于当前数仓采用 Lambda 架构，实时数据和离线数据分别存储于不同介质中，从而因同时使用两套技术栈引发以下几个问题： 

（1）计算数据可能存在差异

（2）数据口径难以统一

（3）需要开发两套代码，造成开发资源的浪费

4.数据冗余和资源浪费问题

（1）mysql 入仓采用分区方式存储，每天/每小时存储一份 mysql 全量数据，并非所有表都需要历史镜像，从而导致数据存在冗余

（2）数仓 ODS 层存在多次同步同一张 mysql 表的情况，造成存储、传输、Mysql 资源的浪费

一、同步工具

由于期望业务数据能够实时入湖，为实现这一目标，在技术上选择了业界主流框架 Flink。因此，需要使用基于 Flink 的同步工具，以支持高途线上任务的稳定运行

1.同步工具对比

2.同步工具选择

    对以上开源和商业工具进行了调研，结合公司的现状，决定与腾讯云合作，采用全托管的腾讯数据集成工具来支持同步数据入湖。数据集成是基于 Flink 打造的全托管同步工具，解决了上述提及的问题，能够释放高途在开发和运维方面的人力投入。在近一年的测试及线上使用期间，共同对数据集成进行改造，解决了使用同步工具时遇到的几十个问题，目前基本实现线上可用，但仍需与腾讯共同完善

3.数据同步架构

    由于此前的同步方式是通过 Waterdrop 和 Databus 进行，存在诸多上述提及的问题。新设计的架构以Flink-cdc作为底座，在此底座之上构建了自动化同步、监控告警、数据质量校验等功能，最终集成于我们的大航海平台。这不仅简化了开发同步任务的时间，还提高了数据的时效性，降低了资源的消耗

二、Iceberg表治理

    由于采用 Flink 技术实现 Mysql 流式入湖，Flink 每隔 5 分钟将增量业务数据写入文件系统，因此随着任务的运行，小文件数量会逐渐增多。小文件数量过多会影响查询性能，当小文件数量超过 1 千时，可能会对下游 spark 任务的使用造成影响。高途与腾讯共同经历了 3 个阶段，如今使用进入 Apache 孵化器的 Amoro 工具来解决 Iceberg 小文件治理问题

1.第一阶段

时间：2023年11月--2023年12月

在大航海定时调度平台，通过定时提交spark-sql执行存储过程对Iceberg表进行治理：

解决问题：

 （1）定时对 Iceberg 表的小文件、元数据、过期快照进行治理

 （2）因有定时治理，实时写入 Iceberg 后可正常查询

还存在的问题： 

（1）配置治理任务较为繁琐。不仅需要手动配置治理任务，还需依据每个表流量的不同，配置不同的治理间隔

（2）治理时耗费资源。每次均是全量重写表以做数据合并，需要大量内存对小文件进行合并

（3）全量同步 Kafka 写入 Iceberg 后，因小文件过多导致无法治理的问题

（4）存在治理和写入冲突问题。实时写入与定时治理同时对同一张表进行操作，因偶发冲突会造成不及时治理，影响查询速度

2.第二阶段

时间：2023年12月-2024年7月

通过腾讯提供的luoshu工具进行治理：

解决问题： 

（1）配置治理任务繁琐问题得到改善。输入 Iceberg 表即可添加治理任务

（2）定时治理得以优化。定时对 Iceberg 表的小文件、孤儿文件、元数据、过期快照等进行治理，且修改治理间隔更为便捷

（3）治理冲突有所缓解。支持拆分治理任务，在遇到写入治理冲突时，能够尽可能治理一部分小文件

（4）降低治理时资源耗费。使用弹性资源的 yarn 任务进行治理

还存在的问题： 

（1）仍需手动逐个添加治理任务，操作不便

（2）全表治理存在资源浪费情况，每次治理均为重写全表数据

（3）业务流量突增时需手动调整治理间隔，否则会影响下游使用

（4）全量同步 Kafka 写入 Iceberg 后，因小文件过多导致无法治理的问题依然存在

3.第三阶段

时间：24年8月-至今

通过由腾讯提供技术支持的 Apache Amoro 工具来实施治理：

解决问题： 

（1）手动添加治理任务的问题得以解决。实现自动扫描自动治理，无需手动配置治理任务

（2）增量小文件治理得到优化。仅对符合条件的小文件进行合并，而非整表重写，有效解决资源浪费问题

（3）业务流量突增时手动调整治理间隔的问题得到解决。流量突增时，依据小文件数量自动治理，解决了治理不及时的问题

（4）写入和治理冲突的问题得到处理。治理冲突时 3 分钟会自动重试，成功解决治理冲突

还存在的问题： 

（1）yarn 任务失败时，不自动补充资源。目前临时通过脚本检测资源并自动补充资源

（2）异常时任务隔离能力有待完善。目前临时预留分组来隔离异常治理任务

由于整库同步和数据湖技术相对先进，当前数仓伙伴在使用数据湖方面的经验较少。为了提升解决问题的效率并降低运维成本，对数个Agent工具和本地知识库进行了调研，最终选用飞书智能伙伴来实现智能问答，让用户能够自助联系机器人以获取已知问题解决办法

一、已知问题，使用飞书知识库解答

飞书文档维护知识库内容

二、未知问题解答

使用工作流搜索未知问题，并自动记录用户提问信息

工作流查找未知问题解决办法，给用户提供问题分析。支持文本、图片、文档问答

一、技术架构革新——构建湖仓一体新范式

1.时效性飞跃升级 

     通过数据湖技术重构核心链路，将S级消转推送项目数据处理时效从"小时级（5+小时）"优化至"分钟级（5分钟）"。实时增量更新机制能够为业务伙伴提供最新鲜的数据

2.离线数仓处理能力突破 

    实时处理：基于Kafka+数据湖的流批一体架构，实现秒级数据入湖与分钟级可见

    离线增强：保留原有Hive数仓优势，构建"实时数据湖+离线数仓"混合链路，支撑复杂分析场景

    增量融合：实现MySQL binlog实时解析入湖，规避每次全量同步风险

3.整库同步

    数据湖整库同步技术借助统一任务配置，实现 MySQL 全库 N 表批量入湖，采用分钟级增量同步取代全量抽数，降低源库 75%以上的负载压力，数据时效性从小时/天级提升至 5 分钟级，同时支撑离线数仓小时级建设，实现流批一体架构的升级

二、成本效益革命——资源利用率质变

1.计算资源优化 

    大表同步费用由每月 10,000+元降至 200 元。通过增量处理替代全量计算，整体所需资源大幅降低

2.存储成本下降 

    运用列式存储、快照和压缩技术，存储量相比原 Databus 表减少了一倍

3.人力成本降低

    新同步工具具备自动 schema 演进机制，减少了元数据变更维护工作，例如 mysql 加字段时，数据湖表可自动加字段

    以整库同步替代单表同步，用户配置一个任务就能同步多张 Mysql 表

三、未来规划

1.实时同步替换全量同步

    我们计划用整库实时同步任务替代全量抽取Mysql任务，使业务数据近实时入湖，用新鲜的数据服务于业务

2.借助数据湖推动湖仓一体应用

    借助数据湖的实时优势，融合离线数仓海量的数据资源，两者结合为业务提供新鲜数据和离线数据一起分析的能力。为业务打造更为精准合理的数据支撑体系