数据采集是企业数据价值链的“第一公里”，是构建一切数据分析、BI报表和AI应用的基础。
在过去的二十年里，传统ETL（Extract, Transform, Load）工具以其强大的稳定性和对结构化数据库（如Oracle, MySQL）的深度支持，牢牢占据着这一领域。然而，随着“现代异构”数据源的爆炸式增长，从SaaS API到NoSQL数据库，从IoT流数据到Web日志，数据采集的版图已然重塑。本文将深入探讨“异构”为数据采集带来的根本性挑战，并分析为什么传统ETL工具的架构基因，使其在应对这些挑战时显得力不从心。
1. "数据采集"的演变：从ETL到EL(T)
要理解“困局”，我们必须首先回顾“常规”。
在经典的数据仓库时代，数据采集的范式是ETL：
- Extract（抽取）： 从各个业务系统（OLTP）数据库（如ERP的Oracle库、CRM的SQL Server库）中，批量抽取数据。
- Transform（转换）： 在一个专用的“ETL服务器”（Staging Area）上，对数据进行清洗、转换、集成（如JOIN、CASE WHEN、聚合）。这是最“重”的一步。
- Load（加载）： 将转换后的、干净的、标准化的数据，加载到企业数据仓库（如Teradata, DB2）中，供BI报表使用。
以Informatica, DataStage, Kettle, SSIS为代表的传统ETL工具，是为这个流程“量身定制”的。它们的核心假设是：数据源是结构化的、内部的、批处理的。
然而，随着云数据仓库（Snowflake, BigQuery）和数据湖（S3, Hadoop）的兴起，ETL范式开始向EL(T)转变。即先把原始数据（Extract）原封不动地加载（Load）到数据湖/仓中，然后再利用云平台强大的算力进行转换（Transform）。
这个转变虽然简化了“T”的流程，但对“E”（Extract/Ingestion）提出了指数级增长的复杂性要求。数据源不再是“几台内部数据库”，而是“N个异构端点”。
2. “现代异构”：到底“异”在哪里？
“异构”不仅仅是“多种数据库”，它代表了来源、结构和速度的全面分化。传统ETL工具的架构，正是被这“三座大山”压垮的。
2.1 源的异构：从“内部DB”到“外部API”
这是最根本的转变。传统ETL的“语言”是JDBC/ODBC，而现代数据源的“语言”是HTTP/API。
- 传统数据源： MySQL, Oracle, PostgreSQL。它们位于企业内网，可信、高速、协议标准（SQL）。
- 现代数据源：
-
- SaaS API： 企业正在大量使用外部SaaS服务。Salesforce的客户数据、JIRA的项目数据、钉钉的审批数据、Stripe的支付数据——这些核心数据全部 “在云端、在外部” 。
- 微服务 API： 企业内部的微服务架构，也意味着数据以API而非共享数据库的形式存在。
这种转变带来的挑战是灾难性的：传统ETL工具是“DB原生”的，而不是“API原生”的。用一个JDBC思维的工具去对接HTTP API，就像让一个潜水艇去飞，极其“水土不服”。
2.2 结构的异构：从“二维表”到“N层JSON”
传统ETL处理的是VARCHAR(50), NUMBER(10,2)构成的二维表。数据结构是刚性的、预先定义好的。
- 现代数据结构：
-
- 半结构化 (JSON/XML)： 几乎所有的API返回的都是JSON格式。JSON是嵌套的、多层的。一个字段的值可能是一个数组，数组里又是一个对象。
- NoSQL数据库： MongoDB (BSON/JSON文档), Redis (Key-Value), Elasticsearch (JSON)。它们天生就是“非二维”的。
挑战在于： 传统ETL的“转换”引擎是为“行”和“列”设计的。当它遇到一个嵌套JSON时，唯一的办法就是“拍平”，这个过程极其繁琐、性能低下，且极度脆弱。一旦SaaS厂商在API的JSON里增加了一个嵌套层，整个ETL任务可能就会崩溃。
2.3 速度的异构：从“T+1批处理”到“实时流”
传统ETL是“批处理”的。它们被设计为在业务低峰期（如凌晨2点）启动，运行几小时，完成T+1的数据同步。
- 现代数据速度：
-
- 流数据 (Streaming)： Kafka, RabbitMQ中的消息队列。数据以“事件”（Event）的形式持续不断地涌入。
- 日志数据 (Logs)： Nginx/SLB的Web访问日志，需要实时分析用户行为。
- IoT数据： 生产线上的传感器数据、智能设备的心跳包，需要毫秒级响应。
挑战在于： 传统ETL工具的执行引擎是“有始有终”的 。而流处理需要的是“永远在线”的“消费者”。
强行让一个批处理工具去“模拟”流处理（例如设置一个每5秒钟运行一次的“微批次”），不仅效率低下，而且在状态管理、故障恢复和背压处理上存在根本性的架构缺陷。
3. 传统ETL工具的“三重困局”
面对上述“异构”挑战，传统ETL工具之所以陷入困局，并非功能不强，而是其“基因”——即架构设计——决定了它的天花板。
3.1 困局一：“连接器”的诅咒
传统ETL厂商的核心盈利模式之一是售卖“连接器”（Connector）。一个Oracle连接器、一个SAP连接器，价格不菲。
- 问题是： 它们永远跟不上现代SaaS的迭代速度。市面上有上万个SaaS应用，厂商不可能为每一个都开发一个专用连接器。
- 妥协方案： 它们会提供一个“通用的REST API连接器”。但这是一个陷阱，因为它将最复杂的工作留给了用户：
-
- 身份认证（Auth）： 你需要自己处理OAuth 2.0的Token刷新。
- 分页（Pagination）： 你需要自己手动配置如何处理limit, offset或next_token。
- 速率限制（Rate Limit）： 你需要自己处理API的QPS限制，否则任务会因429 Too Many Requests而失败。
- JSON解析： 如前所述，你需要自己设计复杂的“拍平”逻辑。
这使得“连接”一个新API的成本，几乎等同于“手写代码”。
3.2 困局二：“重客户端”的手工作坊模式
这是在运维和协作上的困局。
许多经典ETL工具（如Kettle/Spoon, SSIS）都采用了C/S（客户端/服务器）架构。开发者必须在本地Windows电脑上安装一个“重客户端”设计器，通过拖拽（Drag-and-Drop）来设计ETL“作业”（Job）。
这种“手工作坊”模式在现代企业环境中是灾难性的：
- 版本失控： 作业文件（如.ktr, .dtsx）保存在哪里？是开发者的C盘吗？如何进行Git版本管理？
- 协作困难： 两个人无法同时修改一个作业文件。
- 运维噩梦： “在我的机器上是好的”。开发环境（Win 10）和生产环境（Linux Server）的驱动、依赖库不一致，导致部署失败。
3.3 困局三：“批处理”的基因
如前所述，批处理的“基因”决定了它们无法真正拥抱流处理。它们的世界观是“数据是静止的”，按时去“拉”即可。
而现代数据采集的世界观是“数据是运动的”，需要7x24小时去“接”。这需要一个完全不同的架构，如Actor模型、背压机制、Checkpoints等，而这些是传统ETL工具所不具备的。
4. 结论：
“现代异构”的挑战是系统性的：API优先、JSON主导、实时流动。
传统ETL工具的困局也是系统性的：它们建立在DB优先、二维表主导、批处理为王的“黄金时代”之上。用昨天的武器，打不赢今天的战争。
我们需要的不再是“安装在个人电脑上的ETL设计器”，而是一个能够应对“异构”挑战的“现代化数据采集平台”。
