3. 数据源接入：API、数据库、文件，以及那些让你头疼的稳定性问题
数据产品化，第一步就是把数据接进来。听起来简单，对吧？
但我在这个坑里摔过好几次。有一次，一个核心报表突然停了，查了半天，发现是上游API改了字段名，连个通知都没有。还有一次，数据库连接池爆了，整个数据管道直接瘫痪。
说白了，数据源接入是地基。地基不稳，上面盖多高的楼都没用。今天我们就聊聊，怎么把这个地基打扎实。
3.1 常见数据源类型：API、数据库、文件
先看看我们平时最常碰到的三种数据源。每种都有自己的脾气，得顺着毛捋。
| 数据源类型 | 典型场景 | 接入方式 | 我踩过的坑 |
|---|---|---|---|
| API | 第三方服务、内部微服务 | HTTP/REST、gRPC、WebSocket | 限流、鉴权过期、字段变更 |
| 数据库 | 业务库、日志库、数仓 | JDBC/ODBC、CDC、数据同步工具 | 连接数打满、慢查询拖垮主库 |
| 文件 | 日志文件、CSV/Excel、Parquet | FTP/SFTP、对象存储、消息队列 | 文件格式不统一、编码问题 |
3.1.1 API 接入
API 接入，我个人习惯先做两件事：限流策略和重试机制。为什么？因为第三方API不会惯着你。我曾经对接过一个广告平台的API，对方QPS限制是100，我这边并发一高，直接返回429。后来我加了令牌桶限流，配合指数退避重试，才算稳定下来。
3.1.2 数据库接入
数据库接入，最怕的就是影响业务。你想想看，你的数据抽取任务把业务库的CPU打满了，业务方不找你拼命才怪。
我的做法是：只读从库，或者用CDC（Change Data Capture）方式。CDC的好处是，它通过解析binlog来捕获变更，对源库几乎无侵入。嗯，这里要注意，CDC的延迟需要监控，别等到数据延迟了几个小时才发现。
3.1.3 文件接入
文件接入看起来最“土”，但坑最多。我记得有一次，合作方传过来的CSV文件，字段分隔符一会儿是逗号，一会儿是竖线，还有一次直接用了制表符。解析程序直接崩了。
后来我定了个规矩：所有文件接入，必须先做格式校验。校验通过才进入处理流程，不通过直接告警并退回。
3.2 数据源接入的稳定性问题
稳定性，是数据产品化的生命线。数据源一旦不稳定，下游所有依赖都会跟着抖。我总结了三类最常见的稳定性问题：
- 连接中断：网络抖动、服务重启、防火墙策略变更。
- 性能瓶颈：数据量突增、慢查询、连接池耗尽。
- 数据异常：字段为空、格式错误、重复数据。
怎么解决？我画了一张图，把核心思路理清楚了。
3.3 数据源变更管理
数据源变更，是数据产品化过程中最容易被忽视的风险点。你想想看，上游数据库加了个字段，或者API改了响应结构，你的数据管道可能直接就断了。
我见过最夸张的一次，是上游把某个字段的类型从int改成了string，结果下游所有数值计算全部报错。修复花了两天，业务影响巨大。
3.3.1 变更的类型与影响
| 变更类型 | 示例 | 影响程度 | 应对策略 |
|---|---|---|---|
| 新增字段 | API响应增加一个字段 | 低（通常兼容） | 下游按需适配，无需紧急处理 |
| 删除字段 | 数据库表删除一列 | 高（直接报错） | 立即告警，检查下游依赖 |
| 字段类型变更 | int → string | 高（数据解析失败） | 需要数据清洗层做类型转换 |
| 接口地址变更 | API endpoint 迁移 | 极高（连接中断） | 配置中心动态更新，灰度切换 |
3.3.2 我的变更管理流程
我个人习惯用一套标准流程来应对变更，说白了就是四个字：感知、评估、适配、验证。
- 感知：通过Schema Registry或元数据监控，自动检测数据源结构变化。我建议用Avro或Protobuf这类带Schema的序列化格式，变更时能自动对比。
- 评估：变更来了，先评估影响范围。是只影响一个字段，还是整个数据管道都要改？我会拉一个依赖关系图，看看哪些下游任务会受影响。
- 适配：根据评估结果，修改数据接入层的映射逻辑。这里要注意，不要直接改源数据，而是在接入层做一层适配转换。
- 验证：在测试环境跑一遍全链路数据，对比变更前后的数据一致性。没问题了再上线。
3.4 总结一下
数据源接入，说白了就是三个关键词：稳定、可控、可追溯。
- 稳定：靠连接管理、限流熔断、数据校验来保证。
- 可控：靠变更管理流程，让每一次变更都经过评估和验证。
- 可追溯：靠日志和监控，出了问题能快速定位和恢复。
嗯，这些说起来简单，做起来需要一点一滴的积累。但只要你把基础打好了，后面的数据产品化之路，会顺畅很多。