保障公共安全，云南某公安局实时数据应用与实践

云南某公安局承担着区域公共安全、治安管理和一线业务支撑等工作。随着数据应用持续深入案情追踪、线索比对、综合研判等业务越来越依赖及时、准确的数据支撑。为了让一线业务人员更快获取最新数据团队需要将不同业务系统中的数据及时汇集到高性能查询平台并尽可能降低同步延迟对查询、研判和决策的影响。围绕这一需求该公安局使用 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 搭建实时同步链路。相比 DataXFlink 在实时性方面有所改善但稳定性又成了新问题。根据实际运行情况原有 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 可以提供一条更轻量、更稳定的实时同步路径。如果你也关注实时数据同步、数据迁移与数据集成欢迎关注我们我们会持续分享更多来自真实业务场景的实践案例。