1. 企业数据湖需求分析与AWS服务选型
建设企业数据湖，第一步不是打开控制台创建S3桶，而是把"业务要什么、数据长什么样、规模会涨到多大、监管允许怎么用"这四件事问清楚。需求分析的质量直接决定后续选型是否返工：一个只按"先建湖再说"思路搭起来的架构，往往在半年后因为权限模型撑不住、查询引擎选错、流批链路割裂而被迫重构。本节围绕需求调研的四个维度展开，并给出AWS数据湖相关服务的适用边界与一份可填写的选型决策矩阵。
一、四个必须先量化的需求维度
业务目标决定数据湖的"用途画像"。常见目标可归为四类：报表与BI（要求低延迟交互查询、强一致口径）、自助式探索分析（要求schema灵活、按需计费）、机器学习特征工程（要求大批量扫描、与训练框架集成）、实时风控与监控（要求秒级端到端延迟）。同一个湖可以同时服务多类目标，但必须明确哪一类是主目标，因为它决定存储格式、分区策略和计算引擎的优先级。
数据源类型决定接入方式。结构化数据（MySQL、PostgreSQL、Oracle等业务库）通常走CDC或批量抽取；半结构化数据（JSON日志、Kafka消息、API响应）需要schema推断与演化能力；非结构化数据（图片、音视频、PDF）直接以对象形式落湖，靠元数据目录管理。要逐源记录：源系统、抽取频率、单次增量大小、是否含PII、是否有主键与更新时间戳。
数据量级与增长趋势决定存储分层与计算规格。建议按"当前全量 + 日增量 × 保留周期"估算。例如某零售企业：订单库全量800GB、日增12GB；埋点日志日增300GB、保留13个月；则一年后原始层规模约为 800GB + 12GB×365 + 300GB×395 ≈ 123TB（含副本与中间层会更高）。这个量级直接排除"单机数据库硬扛"的方案，指向对象存储 + 分布式计算。
合规要求决定权限与治理的复杂度。需明确：数据驻留区域（是否必须留在某一Region）、加密要求（静态/传输/密钥自管）、PII字段清单、审计留存年限、跨境传输限制。合规约束往往是选型的硬性否决项，例如要求列级权限与集中审计时，仅靠S3桶策略就不够，必须引入Lake Formation。
二、AWS数据湖服务的能力边界
把候选服务按"在数据湖中承担的角色"分类，比逐个背功能更容易选对：
- S3：存储底座。所有数据以对象形式落地，配合分区、生命周期策略、版本控制、加密。它是唯一不可替代的一层。
- Glue：元数据目录（Data Catalog）+ 无服务器ETL。负责爬取schema、维护表定义、跑Spark/Python作业做清洗转换。
- Lake Formation：集中权限与治理层。提供表/列/行级权限、跨账户共享、基于标签的访问控制，是合规场景的关键组件。
- Athena：无服务器交互式SQL查询，直接查S3，按扫描量计费。适合探索分析与低频报表。
- Redshift：数据仓库，适合高并发、复杂JOIN、固定口径的BI报表，可与S3通过Spectrum或零ETL集成。
- EMR：托管Hadoop/Spark集群，适合大规模批处理、需要精细调优或已有Spark生态迁移的场景。
- Kinesis：实时流接入（Data Streams / Firehose），适合秒级数据管道。
- MSK：托管Kafka，适合已有Kafka生态、需要多消费者组与高吞吐持久化的场景。
关键判断逻辑是：存储统一用S3，元数据统一用Glue Catalog，权限统一用Lake Formation，而计算与接入层按负载特征选择。批处理优先Glue（无服务器、成本低）或EMR（可控、重负载）；交互查询在Athena与Redshift之间按"扫描量 vs 并发量"取舍；实时接入在Kinesis与MSK之间按"是否已有Kafka"取舍。
三、选型决策矩阵
把上面的判断固化成一张可填写的矩阵，团队在评审时逐行打勾即可。下表以某零售企业数据湖为例，列出典型负载与推荐服务，并给出关键取舍理由。
| 负载场景 | 数据特征 | 推荐服务 | 备选 | 取舍理由 |
|---|---|---|---|---|
| 业务库批量入湖 | MySQL全量800GB，日增12GB | Glue ETL + S3 | EMR | 无服务器、按需计费，日增量小无需常驻集群 |
| 埋点日志实时接入 | 日增300GB，秒级延迟 | Kinesis Data Streams + Firehose | MSK | 无Kafka存量，Kinesis运维成本更低 |
| 自助探索分析 | Parquet分区表，查询频率低 | Athena | Redshift Spectrum | 按扫描量计费，无集群闲置成本 |
| 固定口径BI报表 | 高并发、复杂JOIN、SLA严格 | Redshift | Athena + 物化视图 | 并发与复杂查询性能更可控 |
| ML特征工程 | TB级扫描、Spark生态 | EMR + Glue Catalog | Glue | 需要精细调优与自定义库 |
| PII列级权限 | 含手机号、身份证字段 | Lake Formation | S3桶策略 + IAM | 桶策略无法做到列级与集中审计 |
四、一个可复用的调研清单
在项目启动会上，用下面这份清单逐项确认，可以避免后期返工。每项都要有明确答案，不能留"待定"：
- 主业务目标是什么？次要目标有哪些？各自的延迟与并发要求？
- 数据源清单：源系统、抽取方式（CDC/批量/流）、频率、单次增量大小。
- 数据量估算：当前全量、日增、保留周期、是否含副本与中间层。
- 合规约束：驻留Region、加密方式、PII字段、审计留存年限、跨境限制。
- 权限模型：需要表级、列级还是行级？是否跨账户共享？
- 查询模式：交互式还是批处理？扫描量级与并发峰值？
- 团队技能：是否已有Spark、Kafka、SQL调优经验？
- 成本边界：月度预算上限，以及可接受的按量计费波动范围。
把这份清单的答案填入决策矩阵，选型结论就自然浮现。需要强调的是，选型不是一次性动作：当数据量从TB级涨到PB级、或合规要求从"内部审计"升级为"等保三级"时，计算层与治理层都可能需要调整。因此架构上要保留替换空间——存储与目录保持稳定，计算与接入层做成可插拔，这样后续演进才不会推倒重来。