数据中台对接：多系统数据汇聚与分发的架构设计

一个客户有ERP、CRM、MES、WMS四套系统，老板要求做一个数据看板实时展示经营状况。数据分散在四个系统里，格式不统一，更新频率也不同——这就是数据中台对接的典型场景。

一、数据采集：按数据特性选策略，别一刀切

多系统数据汇聚的第一步是采集，而采集策略应该按数据特性分类。交易类数据（订单、支付记录）要求实时性，用CDC（变更数据捕获）方式从数据库binlog实时抓取；主数据（物料、客户档案）变更频率低，用定时全量同步就够了；日志类数据（操作记录、设备状态）量大但对实时性要求不高，用批量ETL在凌晨低峰期处理。

判断标准：数据延迟容忍度在1分钟以内的走实时通道，1小时以内的走准实时批量，1天以内的走离线ETL。别给所有数据都上实时同步，成本和复杂度会翻几倍。

二、中间层处理：数据清洗与标准化

数据汇聚到中台后，不能直接用。需要经过三层处理：第一层是清洗，去掉空值、重复值、格式异常数据；第二层是标准化，把不同系统的同一业务概念统一编码，比如ERP里叫“客户编码“，CRM里叫“客户ID“，中台里统一为“customer_code“；第三层是加工，按业务需求生成宽表或指标表，供下游消费。

一个实操建议：在标准化层维护一张“数据字典映射表“，记录每个源系统字段到中台标准字段的转换规则。源系统字段变更时，只改这张表，不动处理逻辑。把映射规则和代码解耦，后期维护成本会大幅降低。

三、数据分发：推拉结合，按消费方能力选择

数据中台处理完的数据要分发给下游系统。分发方式取决于消费方的能力。BI看板类应用支持高频查询，适合用API接口按需拉取；数据仓库类应用适合批量推送，定时把数据打包发送；实时监控大屏需要推送模式，数据一更新就推到前端。

分发链路必须做两件事：一是版本管理，每次分发的数据带上版本号，消费方可以判断数据是否是最新的；二是断点续传，分发失败后能从上次成功的位置继续，不用全量重推。

数据中台对接的本质不是技术问题，是数据治理问题。架构设计再好，源数据质量不行也白搭。所以在动手对接之前，先花两周把源系统的数据质量摸一遍底，这个投入绝对值。