4. 数据摄取模式与工具选型
数据湖的第一道工程决策，不是选存储，而是选“数据怎么进来”。同一批业务数据，用错摄取方式，后续会持续付出代价：批量文件用流式通道会浪费成本，CDC 用定时全量抽取会造成源库压力与目标端重复计算，IoT 高频小包直接落 S3 会产生大量小文件。因此本节按三类摄取模式展开：批量摄取、流式摄取、数据库 CDC，并给出工具选型与工程实现要点。
一、批量摄取：DataSync、Storage Gateway、Snowball
批量摄取处理的是“已经存在、成批到达”的数据，典型对象是文件、对象存储前缀、NAS 共享目录、备份集。它的核心矛盾是传输带宽、数据量与首次全量时间。
AWS DataSync 适合在线批量迁移与持续同步。它在源端部署 Agent（VM 或 EC2），通过 NFS/SMB/HDFS 读取，写入 S3、EFS、FSx。工程要点：一是任务计划，用 Schedule 做增量同步，例如每 15 分钟扫描一次变更；二是带宽限流，用 BytesPerSecond 避免占满生产专线；三是验证模式，VerifyMode=ONLY_FILES_TRANSFERRED 可减少校验开销。示例参数：源 NAS 约 8 TB，专线 200 Mbps，理论传输时间约 8×1024×1024×8 / 200 ≈ 33554 秒 ≈ 9.3 小时，实际因小文件与校验通常按 1.3～1.6 倍估算，约 12～15 小时。判断是否完成，看 DataSync 任务的 FilesTransferred、BytesTransferred 与 CloudWatch 的 BytesVerified 是否一致。
Storage Gateway 适合“本地应用继续用文件/块协议，但数据要进云”的混合场景。文件网关把 S3 桶挂载为本地 NFS/SMB 共享，写入先落本地缓存，再异步上传。它解决的是低延迟本地访问与云端持久化并存，而不是一次性大批量搬迁。工程要点：缓存盘容量决定未上传数据的缓冲上限，带宽决定上传速度；若缓存盘打满，本地写入会失败，因此必须监控 CachePercentUsed。
AWS Snowball 适合离线大批量。当数据量达到几十 TB 到 PB、专线带宽不足或不允许长期占用时，用物理设备寄送。示例：100 TB 数据，专线 100 Mbps 理论上传约 100×1024×1024×8 / 100 ≈ 8388608 秒 ≈ 97 天，而 Snowball Edge 通常几天内完成本地拷贝并寄回。判断依据是设备作业状态 In transit to AWS 与 S3 导入完成后的对象数量、校验和。
二、流式摄取：Kinesis Data Streams、MSK、IoT Core
流式摄取处理“持续产生、要求低延迟”的数据。核心矛盾是吞吐、分区顺序、消费者扩展与端到端延迟。
Kinesis Data Streams（KDS） 是全托管服务，按分片计费。每个分片写入上限 1 MB/s 或 1000 条记录/s，读取上限 2 MB/s。工程要点：分区键决定分片分布，热点键会导致单分片限流；用 Provisioned 模式需按峰值预留，用 On-Demand 模式可自动扩缩。示例：若峰值 8 MB/s，至少需要 8 个分片；若记录平均 1 KB，则 8000 条/s 也需至少 8 个分片。判断是否健康，看 WriteProvisionedThroughputExceeded 与 ReadProvisionedThroughputExceeded 是否持续大于 0。
Amazon MSK 是托管 Kafka，适合已有 Kafka 生态、需要多消费者组、需要更长保留期或更复杂消费逻辑的场景。工程要点：分区数决定并行度，副本数决定可用性；建议 min.insync.replicas=2 配合 acks=all 保证不丢；用 auto.create.topics.enable=false 避免误建主题。MSK 的运维重点是 Broker 磁盘、分区均衡与消费者 Lag。
AWS IoT Core 面向设备接入，支持 MQTT、HTTPS、LoRaWAN。工程要点：用 Thing、证书、策略做设备身份与权限；用规则引擎把消息路由到 KDS、S3、Lambda 或 Timestream。示例：10 万台设备，每台每 10 秒上报 200 字节，则平均吞吐约 100000×200/10 = 2 MB/s，需评估规则引擎与下游 KDS 分片是否匹配。
三、数据库 CDC：AWS DMS
CDC 处理“源库持续变化、需要近实时同步”的场景。DMS 通过读取源库日志（MySQL binlog、PostgreSQL WAL、Oracle redo/archive log、SQL Server CDC）捕获 INSERT/UPDATE/DELETE，写入 S3、KDS、MSK 或目标库。
工程要点：第一，源库必须开启相应日志并保留足够时长，否则 DMS 无法回溯；第二，先做全量加载（Full Load），再切到 CDC，切换点要保证一致性；第三，目标端 S3 建议按 schema/table/日期/小时 分区，并用 Parquet 格式减少存储与扫描；第四，处理 DDL 变更，DMS 对部分 DDL 支持有限，需配合 Schema 演进策略；第五，监控 CDCLatencySource 与 CDCLatencyTarget，前者是源库日志读取延迟，后者是写入目标延迟，两者持续增长说明复制跟不上。
示例：MySQL 订单表约 2 亿行，日变更约 500 万行。全量加载用 DMS 并行加载 8 个线程，按 200 GB 数据、目标 S3 估算数小时；CDC 阶段平均 60 行/s 峰值 500 行/s，单复制实例 dms.c5.2xlarge 通常可承载。判断是否达标：目标端 S3 的 cdc 前缀下文件持续新增，且 CDCLatencyTarget 稳定在秒级。
四、工程实现中的关键判断
选型之后，真正决定成败的是参数与监控。批量摄取要关注传输时间估算、限流、校验一致性；流式摄取要关注分片/分区数、热点键、消费者 Lag；CDC 要关注日志保留、全量与增量切换、DDL 处理、延迟指标。
一个常见的组合是：历史数据用 Snowball 或 DataSync 一次性入湖，增量文件用 DataSync 定时同步，数据库变更用 DMS CDC 写入 KDS，再由 Lambda 或 Firehose 落 S3；IoT 设备数据经 IoT Core 规则引擎直接路由到 KDS 或 S3。这样既覆盖了全量、增量、实时三类来源，也避免了用单一工具硬扛所有场景。
最后给出一个可执行的检查清单：源端日志是否开启并保留足够时长；目标端分区与文件大小是否合理（建议单文件 128 MB～512 MB）；是否配置了限流与重试；是否监控了 DataSync 的 BytesVerified、KDS 的 WriteProvisionedThroughputExceeded、MSK 的消费者 Lag、DMS 的 CDCLatencySource/Target。这些指标稳定，才说明摄取链路真正可用。