数据仓库离不开数据采集，这些开源工具真的好用

做数据仓库这些年，我越来越觉得一件事：仓库本身再漂亮，模型再规范，如果数据进不来，或者进来的数据乱七八糟，后面全白搭。数据采集这事儿，表面上看起来就是把数据从A搬到B，实际上坑特别多。今天就想聊聊为什么数据仓库一定要重视数据采集，以及现在真正能落地的一些开源工具。

先说个真实的场景。前几年我们帮一个零售客户搭数仓，业务方天天喊着要看全渠道销售分析。当时仓库的维度建模、主题域划分都做得很认真，结果上线后发现，线上订单数据能及时进来，线下门店的销售流水却经常晚一天甚至两天。业务同事直接说：这个数仓有什么用？我还不如直接去ERP查。后来一排查，问题就出在采集链路上——线下数据是每天晚上批量导出CSV，再通过定时任务上传，网络抖动或者文件格式稍有变化就会失败，而且没有重试和监控。这件事让我印象很深：数据采集不是“附属功能”，它直接决定了数仓能不能用起来。

数据仓库为什么特别依赖数据采集？说白了就三点。

第一，数据源太杂。现在几乎没有哪家公司的数据只来自一个系统。业务系统、日志、埋点、第三方API、物联网设备、Excel手工报表……全都要进仓。这些源的数据格式、更新频率、访问方式完全不一样。有的是关系型数据库，有的是MongoDB，有的是消息队列，有的只能给你个HTTP接口。数仓再怎么设计，也得先把这些数据稳稳地接进来。

第二，时效性要求越来越高。以前很多分析是T+1就够了，现在很多场景要近实时甚至实时。比如风控、库存预警、实时大屏，数据晚半小时可能就没意义了。批量同步那种老方法开始吃力，CDC（变更数据捕获）和流式采集变得越来越常见。

第三，数据质量问题会在采集环节被放大。源头数据本来就有脏数据、重复、缺失，如果采集过程中再丢字段、乱码、时间戳对不上，后面清洗和建模会非常痛苦。很多时候我们以为是数仓的问题，回头一看，其实是采集的时候就出了问题。

所以，一个靠谱的数据采集方案，至少要解决这几个问题：能对接多种数据源、支持批量和实时、有容错和重试机制、能监控和告警、最好还要能做简单的转换和过滤。

说到开源工具，这几年确实涌现了不少。我按自己用过和听同事反馈比较多的，挑几个聊一聊。

先说Apache Kafka。严格来说Kafka是消息中间件，但在数据采集场景里用得非常广。很多公司把业务系统的变更事件或者日志先打到Kafka，再由下游消费者写入数仓或者数据湖。它的好处是高吞吐、可水平扩展，而且生态很成熟。Flink、Spark Streaming、Kafka Connect这些都能跟它很好配合。不过Kafka本身不负责“拉”数据，你需要有生产者把数据推过来。如果源系统是数据库，通常还要配合Debezium这类CDC工具。Debezium基于日志的方式捕获变更，对源库压力相对小，支持MySQL、PostgreSQL、Oracle等，用下来还比较稳。我们有个项目用Debezium + Kafka + Flink做实时同步，延迟能控制在秒级，业务侧基本满意。

另一个我比较推荐的是Apache NiFi。NiFi的可视化程度很高，拖拖拽拽就能搭一个数据流。它自带很多处理器，能连数据库、文件、HTTP、Kafka、S3等等，还支持背压、优先级队列这些高级功能。对于需要做一些轻量转换、路由、过滤的场景特别合适。我们有次帮客户从多个门店的本地文件服务器定期拉销售数据，用NiFi配了一下就搞定了，运维同事也觉得好上手。缺点是大规模高并发的时候性能不如纯代码方案，而且集群运维有一定成本。

Airbyte这几年热度很高。它主打的是“连接器市场”，官方和社区已经做了很多现成的source和destination，接常见的SaaS、数据库、文件都比较方便。UI也比较现代，配置起来比传统ETL工具轻松不少。我们试用过几个连接器，像从Salesforce、Google Analytics、MySQL往数仓同步，基本能跑通。它支持全量和增量，也有一些转换能力。不过我个人感觉，复杂场景下还是得写自定义连接器，而且社区连接器的质量参差不齐，上生产前一定要自己压测和验证。另外它默认是偏批量的，实时能力目前还不如专门的流处理框架。

如果更偏向中国本地的环境，DataX和Canal这两个绕不过去。DataX是阿里开源的，专做异构数据源离线同步，支持的读写插件非常多，配置也相对简单。很多国内公司的离线数仓采集层还在用它或者它的二开版本。Canal则是专注MySQL binlog的解析，可以把变更实时推到Kafka、RocketMQ或者直接写库。这两个工具文档和案例都比较多，踩坑资料也好找。

还有一个值得提的是Singer。它的设计理念很轻量：用简单的JSON协议定义source和target，很多公司基于它做了自己的采集平台。Airbyte早期也受它影响。如果你的团队喜欢自己掌控代码，Singer的模式挺适合二次开发。

除了这些专门做采集的工具，Flink和Spark本身也经常被用来做数据采集和同步。尤其是Flink，CDC能力现在很强，可以直接连数据库做实时同步，而且有状态管理、Exactly-Once这些保障。我们有几个实时数仓项目，直接用Flink CDC从业务库同步到Kafka或Iceberg，链路更短，维护起来反而简单。

说了这么多工具，实际选型的时候我一般会问自己几个问题：

数据量有多大？是批量为主还是实时为主？源系统对性能敏感吗？团队对运维和代码的接受程度如何？有没有现成的连接器能用？

如果数据量中等、源比较标准、团队不那么强，Airbyte或者NiFi这类可视化工具上手快。如果实时要求高、数据量大，Kafka + Debezium/Flink CDC的组合更稳妥。国内环境里DataX和Canal依然很实用。很多时候不是选一个工具就能解决所有问题，常见的做法是批量和实时分开：离线用DataX或Spark，实时用CDC + 消息队列。

另外有几点踩过的坑想提醒一下。

第一，监控一定要做。采集任务失败了如果没人知道，过几天业务才发现数据不对，那时候已经晚了。至少要有任务成功/失败告警、数据量异常告警、延迟告警。

第二，不要迷信“全自动”。再成熟的工具，遇到源系统表结构变更、权限调整、网络策略变化，都可能出问题。最好有人工兜底的机制，或者至少有清晰的故障处理流程。

第三，数据质量检查尽量前移。采集的时候就做基本的字段校验、空值检查、主键冲突检查，比进仓后再清洗要划算得多。

第四，权限和安全别忽视。很多采集工具需要直接连生产库，权限开太大风险很高。能用只读账号就用只读，能走从库就走从库，CDC的方式通常比直接查库更友好。

最后想说，数据采集看起来是底层工作，但它直接影响上层分析和决策的可信度。很多数仓项目做得半死不活，真正的问题往往不在建模，而在“数据进不来”或者“进来的数据不可信”。把采集这一层做扎实了，后面很多事情会顺很多。

以上是我这些年的一些实践体会，不一定全面，也欢迎有经验的朋友一起交流。工具在不断演进，但核心原则其实没变：稳定、可控、可观测。选对工具只是第一步，把流程和规范建起来，才是长期能跑下去的关键。