4、数据源与连接：常见数据源类型（关系型、文件、API、日志），连接方式与权限管理
ETL 工程师日常工作的起点，是理解数据从哪里来、以什么形态存在、通过何种通道进入数据管道。数据源的类型决定了抽取策略、连接方式、权限模型以及故障排查路径。本章将系统梳理关系型数据库、文件系统、API 接口和日志流四大类数据源的核心特征，讲解连接配置与权限管理的最佳实践，并通过一个真实的多源数据接入案例，展示从源端调研到连接池调优的完整闭环。
4.1 关系型数据库：连接配置与抽取策略
核心原理：关系型数据库（RDBMS）是 ETL 中最传统、最稳定的数据源。其数据以结构化表形式存储，通过 SQL 进行访问。ETL 工具通常使用 JDBC（Java 平台）或 ODBC（跨平台）驱动建立连接，执行 SELECT 查询或基于日志的增量抽取。连接的本质是建立客户端与数据库服务端之间的会话，涉及网络协议、认证握手、会话参数协商等过程。
判断方法与操作流程：选择连接方式时，需评估以下要素：
- 驱动类型：优先使用数据库官方提供的 JDBC/ODBC 驱动，避免第三方驱动兼容性问题。
- 连接参数：包括主机名、端口、数据库名、用户名、密码、字符集、时区、连接超时时间等。
- 抽取模式：全量抽取（SELECT *）适用于小表或首次加载；增量抽取可使用时间戳列、自增 ID 或基于 Binlog 的 CDC（Change Data Capture）方案。
- 连接池：使用 HikariCP、Druid 等连接池管理连接，避免频繁创建/销毁连接带来的性能开销。
-- 典型 JDBC 连接串示例（MySQL）
jdbc:mysql://10.20.30.40:3306/ods_db?useSSL=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&connectTimeout=5000&socketTimeout=600004.2 文件数据源：格式识别与批式接入
核心原理：文件数据源包括 CSV、TSV、Parquet、ORC、Avro、JSON、Excel 等格式，存储于本地磁盘、SFTP 服务器、对象存储（S3、OSS、GCS）或 HDFS。ETL 读取文件时，需要解析文件格式、处理分隔符、转义符、字符编码、压缩格式（gzip、snappy）以及嵌套结构（JSON/Parquet）。文件接入天然适合批处理，通过目录监听或定时扫描触发。
操作流程：文件接入的标准流程为：
- 源端确认：确认文件路径、命名规则（如按日期分目录）、文件大小范围。
- 格式探测：读取文件头或元数据，识别分隔符、列类型、是否含表头。
- 传输通道：通过 SFTP/FTPS 安全传输，或直接从对象存储拉取。
- 校验机制：比对文件行数、校验和（MD5）、字段完整性。
- 归档与清理：处理完成后将源文件移动到归档目录，避免重复处理。
| 文件格式 | 适用场景 | 压缩支持 | Schema 演进 |
|---|---|---|---|
| CSV/TSV | 小数据量、外部系统交换 | gzip | 弱（需手动维护） |
| Parquet | 大数据分析、列式存储 | snappy/gzip | 强（内嵌 schema） |
| JSON | 嵌套结构、API 导出 | gzip | 中（需解析路径） |
| Excel | 业务报表、小规模配置 | 无 | 弱 |
4.3 API 接口与日志流：实时与准实时接入
API 接口核心原理：现代业务系统越来越多地通过 RESTful API 对外提供数据。ETL 调用 API 时，需要处理认证（、OAuth 2.0、JWT）、分页（offset/limit、cursor、page）、限流（Rate Limit）、重试机制和幂等性。API 接入适合增量拉取，但需注意接口的响应体大小和频率限制。
日志流核心原理：日志数据（如 Nginx 访问日志、应用日志、安全日志）以持续追加的方式产生，通常通过 Flume、Kafka、Logstash 或 Filebeat 采集。ETL 从 Kafka 消费日志时，需要管理 offset、处理消息顺序、应对重复消费（at-least-once）或精确一次（exactly-once）语义。日志接入适合流式处理，但也可通过窗口聚合转为微批。
# Kafka 消费者配置示例（日志接入）
bootstrap.servers=kafka-cluster:9092
group.id=etl-log-consumer
enable.auto.commit=false
auto.offset.reset=earliest
max.poll.records=500
session.timeout.ms=300004.4 权限管理与安全连接
核心原理：权限管理是 ETL 数据接入的“守门员”。ETL 账号应遵循最小权限原则，即只授予读取所需数据的权限，禁止 DDL 和写权限。对于敏感数据（如手机号、身份证），还需通过脱敏或加密传输。连接安全方面，关系型数据库应启用 SSL/TLS 加密，文件传输使用 SFTP/FTPS，API 调用必须走 HTTPS。
权限管理清单：
- 数据库账号：创建专用只读账号，仅授予 SELECT 权限，必要时限制访问特定库表。
- 文件系统：使用专用服务账号，仅授予目标目录的读权限，禁止 shell 登录。
- ：密钥存储在密钥管理服务（如 Vault、KMS）中，禁止硬编码在代码或配置文件中。
- 网络策略：通过防火墙或安全组限制源端 IP 白名单，仅允许 ETL 服务器访问。
- 审计日志：记录所有数据源访问行为，定期审查异常访问。
4.5 案例拆解：某电商平台多源数据接入优化
背景与约束：某电商平台需要将订单数据（MySQL）、用户行为日志（Kafka）、商品信息（第三方 API）和每日对账单（SFTP 上的 CSV 文件）统一接入数据仓库。初始阶段，ETL 任务频繁超时、数据延迟严重，且偶发数据重复。
初始现象与目标：订单表全量抽取耗时 40 分钟，日志消费 lag 达到 2 小时，API 调用频繁被限流，CSV 文件偶尔解析失败。目标是将订单抽取压缩到 5 分钟内，日志 lag 控制在 1 分钟以内，API 调用成功率提升至 99.9%。
关键输入数据与参数：
- 订单表：2 亿行，日增 50 万行，有 created_at 索引。
- Kafka 主题：3 个分区，日消息量 1.2 亿条。
- API 接口：每分钟限流 600 次，单次返回 100 条记录。
- CSV 文件：每日 1 个，约 300MB，含表头。
分析判断过程：通过监控发现，订单抽取慢是因为全量扫描未走索引；日志 lag 高是因为消费者单线程处理且批量大小过小；API 限流是因为未做分页拉取和本地缓存；CSV 解析失败是因为源端文件编码不一致（部分为 GBK，部分为 UTF-8）。
实际操作步骤：
- 订单抽取优化：改为基于 created_at 的增量抽取，首次全量后记录水位线，后续每次只拉取增量数据，并强制使用索引。
- 日志消费优化：将消费者并发数调整为分区数（3），max.poll.records 提升到 2000，开启自动提交但设置手动 commit 确保精确一次。
- API 接入优化：使用游标分页（cursor）替代 offset 分页，增加本地缓存（TTL 5 分钟），并实现指数退避重试（退避基数 2，最大重试 5 次）。
- CSV 解析修复：在读取文件头时自动检测编码（通过 BOM 或字节统计），统一转换为 UTF-8 后再解析。
结果对比：订单抽取耗时从 40 分钟降至 3 分钟；日志 lag 稳定在 30 秒以内；API 调用成功率提升至 99.95%；CSV 解析失败率降为 0。整体数据延迟从 T+1 缩短为分钟级。
风险与代价：增量抽取依赖数据库 binlog 或时间戳，若源表无时间戳列则需改造；API 缓存可能导致数据延迟 5 分钟，需业务方确认可接受；日志精确一次消费依赖 Kafka 事务，增加了客户端复杂度。
复盘经验：多源接入的核心不是“连上就行”，而是建立每个数据源的“健康基线”——包括正常耗时、数据量波动范围、错误率阈值。建议为每个数据源配置独立的监控看板，并设置告警规则。另外，连接配置应全部参数化，通过配置中心管理，避免环境切换时修改代码。