数据集成到底在集成什么？数据库、API、文件、消息队列一次讲清

很多人第一次接触数据集成会把它理解成一句话把一个系统的数据搬到另一个系统。ERP订单同步到数仓CRM客户数据进入数据平台Excel导入数据库再把第三方平台的数据通过接口拉回来看起来似乎都是“搬数据”。但真正做过企业数据项目就会发现把数据搬过去往往只是最容易的一步。真正困难的是ERP每10分钟产生一次新订单怎么只拿变化的数据接口一天只能调用一定次数几十万条记录怎么完整拉下来供应商每天发来的Excel字段突然变了怎么办实时订单通过Kafka进入平台以后如果重复消费会不会导致销售额算两遍所以数据集成真正集成的并不只是数据。它实际上是在统一不同系统之间的连接方式、数据结构、变化机制、传输节奏和异常处理规则。在正式展开之前我整理了一套《数据仓库建设解决方案》里面涉及数据架构、数据治理、数据集成等企业常见建设场景。如果正在梳理企业的数据链路、数据平台或者数据治理体系可以配合这篇文章一起看。需要自取https://s.fanruan.com/7igmg复制到浏览器一、数据集成真正解决的是“数据怎样持续流动”假设一家制造企业同时存在ERP、CRM、WMS、MES、财务系统和电商平台。客户在CRM里下单发生在ERP库存放在WMS生产进度来自MES回款又记录在财务系统。管理层想知道一个很普通的问题“这个客户下单以后为什么一直没有发货”真正回答这个问题时需要把客户、订单、库存、生产、采购甚至物流数据串在一起。因此数据集成至少要解决四层问题。第一层是连接。数据究竟存在哪里通过数据库、API、文件还是消息队列获取。第二层是变化。源系统发生变化以后下游怎样知道哪些数据是新增、哪些被修改、哪些已经删除。第三层是转换。即使两边都有“客户”字段也可能一个使用客户编码一个使用统一社会信用代码日期格式、状态代码、组织编码也可能完全不同。第四层是运行。同步任务如果凌晨2点失败是第二天人工重新跑还是能够从上次断点继续重复执行以后会不会产生两份数据所以真正的数据集成链路更接近连接数据源 → 识别变化 → 清洗转换 → 写入目标端 → 调度运行 → 异常恢复。实际项目做到后面最容易失控的往往不是某一条SQL而是企业同时维护几十甚至几百条同步链路ERP每天同步一次订单每10分钟一次库存实时同步CRM每天凌晨更新客户主数据。这类任务如果分别散落在脚本、数据库存储过程和个人电脑上一旦人员调整或者系统变更很难判断哪条链路依赖哪张表。因此不少项目会把这些任务集中放到FineDataLink里维护。数据库读取、数据转换、任务依赖和调度时间放在同一条开发链路中实际排查问题时能够直接沿着任务找到来源和去向而不是再去翻不同服务器上的脚本。这也是数据集成平台真正承担的角色不是单纯“搬数据”而是管理数据怎样长期流动。二、数据库集成真正难的是“只同步发生变化的数据”数据库是企业最常见的数据来源。ERP、CRM、财务、供应链等系统背后通常都存在MySQL、Oracle、SQL Server、PostgreSQL等关系型数据库。最粗暴的数据集成方式是每天把整张表重新读取一遍。如果订单表只有10万条这种方式可能暂时还能运行。但如果订单表已经有3亿条而企业希望每10分钟同步一次再反复扫描3亿行显然不可行。于是数据库集成真正的核心问题出现了增量。最常见的方法是利用更新时间例如昨天同步到23:59:59今天只读取之后更新的数据。但这个方法并没有想象中稳。如果某条数据更新发生在23:59:58却因为事务延迟直到00:00以后才提交就可能被漏掉如果服务器时间不一致也可能出现重复或者遗漏。因此成熟的数据集成不会只考虑“查询条件怎么写”还要考虑增量游标如何保存、任务失败以后从哪里恢复、迟到数据怎样处理、重复数据如何保证幂等。再往前一步就是CDC也就是Change Data Capture变化数据捕获。它不再频繁询问“表里有没有新数据”而是读取数据库产生的变更日志新增了一条订单订单状态从“待支付”变成“已支付”库存从100变成98。这种方式捕获的是变化本身。所以数据库集成真正存在两种思路批量抽取关注“现在表里有什么”CDC关注“刚刚发生了什么变化”。前者适合低频批处理后者更适合高频、实时或准实时同步。这也是为什么企业不能只问“能不能连数据库”更应该问这套链路准备怎样长期获取增量数据三、API集成你集成的不是数据表而是系统的“对外契约”并不是所有系统都会把数据库开放出来。尤其是SaaS系统、外部物流平台、电商平台和第三方服务通常只提供API。例如系统返回订单列表。表面看只是一次HTTP请求实际上API集成和数据库集成存在一个本质区别数据库连接以后你面对的是数据结构API连接以后你面对的是对方定义好的业务契约。对方决定你能查什么、一次查多少、多久允许调用一次。因此API集成通常要处理身份认证、Token刷新、分页、限流、超时、重试、错误码以及JSON解析。假设接口一次最多返回1000条订单而企业当天有30万条数据。那么同步链路至少要知道第1页读取成功了吗当前读到第几页第127页超时以后是全部重跑还是从第127页继续重复请求会不会重复写入下一页的游标放在哪里这时API集成实际上已经变成一个带状态的数据获取过程。还有一个经常被忽视的问题叫做接口契约变化。或者原来金额是数字后来变成字符串。接口本身可能仍然返回200但下游数据任务已经无法正常解析。所以API集成不能只监控“接口通不通”还要监控返回结构有没有变化数据量是否异常关键字段是否缺失。一些项目里订单从数据库同步、物流轨迹从第三方API获取、结果再统一进入数仓。如果全部单独写脚本后续会形成大量分散的连接程序。放到FineDataLink的数据开发任务里时API读取以后可以继续接数据解析、字段转换、关联加工和数据库写入。这样真正维护的是一整条“获取—处理—落库”链路而不是只留下一个接口调用脚本。四、文件集成最容易低估的其实是“数据交付协议”很多人会觉得企业都做数字化了怎么还在传Excel、CSV实际上文件仍然是非常常见的数据交换方式。银行对账单、供应商数据、集团下属企业报表、第三方结算数据以及历史系统迁移经常依赖CSV、Excel、TXT等文件。因为文件有一个很现实的优势双方不需要拥有能够直接互联的系统。例如供应商约定每天22:00以前把当天销售明细上传到SFTP目录。看起来只是“读取CSV”。但实际运行以后会出现大量问题昨天20列今天突然21列金额原来是数字今天有人填了“—”文件应该22:00到结果23:30才上传昨天的文件重新上传一次文件上传过程中就被下游任务读取。因此文件集成真正集成的并不是CSV本身而是一套数据交付协议什么时候交付放在哪个目录文件怎样命名每个字段代表什么重复文件怎样识别异常文件怎样隔离处理完成后怎样归档。也就是说文件只是载体规范才是真正的接口。数据库主要解决系统内部结构化数据流动API解决系统之间受控访问而文件往往解决的是弱连接情况下的批量数据交换。五、消息队列从“同步数据”变成“传播业务事件”前三种方式大多数时候仍然属于一种思路下游主动去拿数据。消息队列则反过来。订单创建以后上游不需要等待别人查询而是直接发布一个事件Kafka、Pulsar等消息系统解决的就是这种持续发生的事件流。因此消息队列特别适合实时订单、设备IoT数据、物流轨迹、支付事件、库存变化、实时风控等场景。但很多人会误以为用了Kafka就等于实现了实时数据集成。真正上线以后麻烦才刚刚开始。最典型的问题是重复消费。假设系统收到“订单A支付100元。”消费者已经把100元写进实时销售表但在提交消费位置之前突然宕机。系统恢复以后这条消息可能再次被读取。如果处理逻辑只是那么同一笔订单就会被计算两次。因此实时数据集成真正关心的是事件是否丢失、是否重复、顺序是否正确、失败以后能否重新消费。这也是at-most-once、at-least-once以及exactly-once这些概念背后的真实业务问题。企业同时存在离线和实时链路以后这种复杂度还会继续增加。例如订单明细每天通过数据库批量同步而支付事件和库存变化通过Kafka进入实时链路。实际维护FineDataLink时两类任务往往会放在同一个数据集成体系中一边维护周期性的批处理任务一边承接CDC或消息数据再分别进入明细层、实时指标层或者下游业务系统。这里真正需要解决的不是“实时是不是比离线高级”而是不同数据应该按照自己的变化速度进入对应链路。每天变化一次的数据没有必要秒级同步库存预警如果第二天才更新又失去了业务意义。六、数据库、API、文件、消息队列到底应该怎么选真正成熟的数据架构不会要求所有系统统一使用一种接入方式。因为四种方式解决的问题完全不同。数据库适合大量、结构化、企业内部可直接访问的数据。核心问题是增量、CDC和同步性能。API适合系统边界明确或者数据库不能直接开放的场景。核心问题是认证、分页、限流和接口契约。文件适合低频、批量以及组织之间弱耦合的数据交换。核心问题是交付规范和异常文件管理。消息队列适合连续发生且时效要求高的业务事件。核心问题是顺序、重复、消费进度和恢复能力。所以真正做数据集成选型时不应该先问“用数据库还是API”而应该先问四个问题。数据由谁控制如果是企业内部核心数据库可以考虑直接同步如果属于外部SaaS通常只能走API。数据量有多大每天几亿条交易记录和每天几百条供应商数据显然不应该采用同样的方案。数据多久变化一次客户主数据可能每天更新一次订单每分钟变化设备数据则可能每秒产生数千条。业务多久必须看到变化这最终决定链路应该是T1、小时级、分钟级还是实时。因此同一个企业里完全可能同时存在ERP历史订单通过数据库批量初始化新增订单通过CDC持续同步第三方物流通过API获取供应商结算通过Excel交付库存变化通过Kafka实时进入平台。这不是架构混乱而是不同数据按照不同特征选择了不同的流动方式。结语理解数据集成最容易犯的错误就是把它看成A系统 → B系统。真正的数据集成其实应该继续向下追问数据怎样产生变化怎样被发现多久同步一次失败以后怎样恢复字段变化以后谁来处理下游怎样知道拿到的数据完整可信所以数据库、API、文件、消息队列虽然看起来是四种技术背后解决的其实是同一个问题让不同系统中的数据以确定的规则、确定的节奏和可追踪的方式持续流动。真正成熟的数据集成体系也不应该只看“我们已经接入了多少套系统。”更值得关注的是增量有没有漏失败能不能补重复数据能不能识别上游变化能不能发现整条链路能不能追踪。当企业开始管理这些问题时数据集成才不再是一次性的接口开发。而真正成为了企业数据平台中长期运行的数据供应链。