云南某公安局承担着区域公共安全、治安管理和一线业务支撑等工作。随着数据应用持续深入，案情追踪、线索比对、综合研判等业务越来越依赖及时、准确的数据支撑。
为了让一线业务人员更快获取最新数据，团队需要将不同业务系统中的数据及时汇集到高性能查询平台，并尽可能降低同步延迟对查询、研判和决策的影响。
围绕这一需求，该公安局使用 CloudCanal 对 PostgreSQL、MySQL 到 StarRocks 的数据链路进行了实时化改造。项目从部署到第一条链路跑通仅用 1 天。上线后，数据同步从半小时级延迟优化至近乎 0 延迟，相关运维工作量减少约 90%。
数据为什么要快
该公安局现有数据架构主要涉及 PostgreSQL、MySQL 和 StarRocks。
MySQL 存储用户信息、操作日志及业务录入数据，PostgreSQL 用于接收外部共享的数据，StarRocks 则承担高性能实时查询。不同来源的数据进入 PostgreSQL 和 MySQL 后，需要实时同步至 StarRocks，业务部门才能及时查询分析数据，为民警做决策提供依据。
对于一般的数据分析或报表，半小时以上的数据延迟或许可以接受。但在对时效要求较高的公共安全业务场景中，几分钟的延迟也可能影响民警获取信息和开展研判的节奏。
因此，这条链路不仅要保证数据最终到达，团队更关心数据能否持续、稳定地快速到达，并在数据库或服务器发生异常后能尽快恢复同步。
旧方案遇到的问题
在引入 CloudCanal 之前，该公安局先后尝试过 DataX 和 Flink。两类工具都解决了部分问题，但在长期运行中也暴露出各自的边界。
DataX：定时同步难以满足实时性要求
DataX 更适合批量迁移和周期性数据同步。原有链路采用每半小时执行一次任务的方式，将新增数据同步到 StarRocks。
这种方式可以完成数据汇集，但新产生的数据必须等待下一轮调度才能进入目标端。随着业务对实时查询的要求提升，DataX 定时同步已经难以满足团队对低延迟链路的需求。
Flink：实时性提升，但稳定性成问题
为了降低同步延迟，团队也尝试使用 Flink 搭建实时同步链路。相比 DataX，Flink 在实时性方面有所改善，但稳定性又成了新问题。
根据实际运行情况，原有 Flink 任务平均每周会出现一次崩溃，需要技术人员检查任务状态、排查异常原因，并手动恢复链路。
运维压力攀升
在使用 DataX 和 Flink 时，运维人员需要编写大量配置文件和执行脚本。不同数据库之间的连接器也需要自行适配。原有任务通常按照"一张表对应一个任务"的方式管理，表越多，配置、检查和排障工作就越复杂。
同时，任务配置、运行状态和日志信息分散在不同环境中，缺少统一的任务管理、监控和告警入口。许多问题需要熟悉配置和代码的研发人员参与处理，日常维护对个人经验依赖较高。
因此，团队希望寻找一种新的实时同步方案，在保证低延迟和稳定性的同时，降低任务配置和运维门槛。
为什么选择 CloudCanal
这次选型中，该公安局重点关注三个指标，实时性、稳定性和易用性。
团队对 Flink、DataX、Kettle 和 CloudCanal 等方案进行了比较，最终选择 CloudCanal，主要基于以下几方面的原因。
第一，CloudCanal 对 MySQL、PostgreSQL 到 StarRocks 的实时同步链路有较好的适配能力，可以覆盖项目中的所有数据源。
第二，CloudCanal 能够以极低延迟持续进行数据同步 ，并支持全量与增量一体化，能够帮助团队更顺畅地完成从历史数据初始化到实时增量同步的切换。
第三，任务配置、表选择、状态查看和运行监控都可以在图形化界面中完成，减少了大量配置文件和执行脚本的编写工作。
第四，CloudCanal 支持断点续传 和任务恢复。在数据库或服务器发生异常后，任务可以在恢复后继续同步，降低人工排查和补数据的压力。
在正式上线前，团队通过 PoC 对吞吐、延迟和数据库兼容性进行了验证。测试结果满足每秒 5 万条的吞吐需求，并保持近乎无感知的数据延迟，同时满足 MySQL、PostgreSQL 与 StarRocks 之间的数据同步需求。
一天跑通首条链路，一周投入生产
技术指标通过验证后，项目进入部署和上线阶段。
该公安局采用 Docker 方式部署 CloudCanal。从开始部署到第一条数据链路跑通仅用 1 天 ，从测试到正式投入生产约 1 周。
项目最终建立了 PostgreSQL 到 StarRocks、MySQL 到 StarRocks 两类核心实时同步链路。正式切换过程顺利，没有出现需要额外处理的问题。链路上线后主要由运维人员维护，日常工作以查看任务状态和简单巡检为主。
效果与价值
数据更快，民警研判更及时
在公共安全业务场景中，数据的实时性直接影响查询、追踪和研判的效率。
例如在案情追踪、线索比对和综合研判过程中，业务人员往往需要尽快获取最新数据。根据该公安局数据团队反馈，在打击犯罪相关业务中，几分钟的数据延迟也可能会导致错过最佳时间窗口。
引入 CloudCanal 后，PostgreSQL 和 MySQL 中的数据可以持续同步至 StarRocks，数据同步延迟近乎为 0，从而将数据延迟对民警查询、研判和决策的影响降到最低。
实时任务更稳定
过去使用 Flink 进行实时同步时，任务平均每周会出现一次崩溃，需要相关人员介入处理。更换 CloudCanal 后，同步任务保持平稳运行，未再出现原有的周期性崩溃问题。运维人员不再需要频繁处理任务中断、重启和恢复等问题，链路稳定性明显提升。
故障恢复更快
正式运行过程中，该公安局曾遇到因突发停电、服务器宕机、硬盘故障等情况，导致源端或目标端数据库崩溃。数据库恢复后，CloudCanal 通过断点续传 快速恢复同步任务，并且经过验证，未发现数据丢失。
运维工作减少 90%
引入 CloudCanal 后，日常运维从脚本驱动转向图形化管理。运维人员可以统一配置多表同步任务，并直接查看任务运行情况，不再需要在配置文件、执行脚本和运行日志之间来回排查。
根据该公安局数据团队反馈，相关运维工作量减少约 90% ，目前仅需一名运维人员每天进行简单巡检。
新旧方案对比
| 对比维度 | 原有方案 | 使用 CloudCanal 后 |
|---|---|---|
| 数据延迟 | DataX 每半小时执行一次 | 几乎 0 延迟 |
| 任务稳定性 | Flink 平均每周崩溃一次 | 未再出现原有周期性崩溃问题 |
| 任务配置 | 依赖配置文件和执行脚本 | 通过图形化界面配置 |
| 多表管理 | 一张表对应一个任务 | 一个任务可统一配置多张表 |
| 数据库适配 | 连接器需要自行适配 | 可连接 MySQL、PostgreSQL 和 StarRocks 等多种数据源 |
| 故障恢复 | 需要人工排查和处理 | 数据库恢复后可断点续传 |
| 运维投入 | 依赖研发及运维人员 | 工作量减少约 90% |
让数据及时到达
该公安局本次数据链路改造，并不是一次简单的同步工具替换，更是数据如何更及时、更稳定地到达业务一线。
DataX 能够完成周期性数据汇集，却难以满足实时性要求。Flink 可以构建实时链路，但稳定性、连接器适配和任务维护带来了持续的工程投入。
CloudCanal 将实时同步、多表配置、监控告警和故障恢复统一到一个可视化平台。数据延迟从半小时级降低到几乎 0 延迟，同步任务保持平稳运行，运维工作量减少约 90%。
对于正在使用 DataX、Flink 或自研脚本维护数据同步链路的团队来说，如果同步任务已经面临延迟高、任务分散、连接器适配复杂、故障恢复依赖人工等问题，CloudCanal 可以提供一条更轻量、更稳定的实时同步路径。
如果你也关注实时数据同步、数据迁移与数据集成，欢迎关注我们，我们会持续分享更多来自真实业务场景的实践案例。