1. AWS数据建模与分析工程导论
在传统数据中心里，数据建模往往被当作数据库设计的一个前置环节：先画ER图，再建表，然后交给开发去写SQL。但在AWS云上，数据建模的边界被彻底打开了。数据不再只落在一个关系型数据库里，而是分散在S3数据湖、Redshift数据仓库、Kinesis实时流、DynamoDB键值存储、Glue数据目录等多个服务中。这意味着，数据建模不再只是"设计表结构"，而是要回答一个更根本的问题：数据以什么形态、在什么位置、被谁、以什么方式消费，才能让分析价值最大化。
本课程的目标，是让学习者建立一套"云原生数据建模"的完整能力体系。具体来说，完成30章学习后，你应当能够：
- 理解AWS分析服务全景，知道每种服务适合承载什么形态的数据与负载；
- 针对不同分析场景（批处理、实时、交互式、机器学习）选择合适的数据模型；
- 在S3上设计分区合理、成本可控的数据湖表结构；
- 在Redshift中设计星型/雪花模型并选择合适的分布键与排序键；
- 使用Glue Data Catalog统一元数据，打通Athena、Redshift Spectrum、EMR等引擎；
- 理解流式数据建模中的时间窗口、水位线、去重与迟到数据处理；
- 在成本、性能、一致性之间做出可解释的工程权衡。
要理解这些内容，先要看清AWS分析服务的整体版图。下图按"数据产生—存储—处理—分析—消费"的链路，把主要服务放在它们各自最典型的位置上，帮助你在后续章节中快速定位每个服务在架构中的角色。
这张图不是要你背下所有服务名，而是建立一种"分层定位"的思维：当拿到一个分析需求时，先判断数据从哪来、要存成什么形态、由哪个引擎处理、最终谁消费，再回到具体服务选型。数据建模就发生在"存储层"和"处理层"的交界处——它决定了数据以什么结构落盘、以什么粒度聚合、以什么键分区。
那么，数据工程角色在AWS上具体做什么？和传统数仓工程师相比，云上数据工程师的职责明显更宽。传统角色可能只负责ETL开发和表设计；而在AWS上，一个数据工程师往往要同时关心：
- 数据接入：用DMS做CDC、用Kinesis接流、用Glue Crawler发现S3上的新数据；
- 存储设计：决定Parquet还是ORC、分区键选日期还是业务维度、要不要上Iceberg；
- 建模与转换：写Glue ETL或Spark作业，把原始数据清洗成星型模型或宽表；
- 元数据管理：维护Glue Data Catalog中的表结构、分区、列类型；
- 性能与成本：选择Redshift分布键、控制Athena扫描量、设置S3生命周期；
- 治理与安全：用Lake Formation做列级权限、用KMS加密、用CloudTrail审计。
换句话说，云上数据工程师不只是"写SQL的人"，而是数据资产的结构设计者与成本守门人。你设计的每一个分区、每一个排序键、每一种文件格式，都会直接反映在查询延迟和月度账单上。
接下来要回答一个关键问题：数据建模在云端到底有什么不同？传统建模的核心约束是"存储贵、计算相对便宜"，所以我们会尽量规范化、减少冗余。但在S3和Redshift Spectrum的世界里，存储成本极低（S3标准存储约$0.023/GB/月），而扫描计算成本相对突出。这导致建模策略发生反转：适度的冗余和预聚合，反而能大幅降低查询成本。
举个具体的例子。假设有一张10亿行的订单明细表，按天分区存储在S3上，格式为Parquet。如果业务方每天要查"各品类最近30天销售额"，有两种建模方式：
- 方式A（规范化）：只存订单明细，查询时JOIN商品维度表。每次查询扫描30个分区，约扫描30亿行中的相关列。
- 方式B（预聚合）：额外建一张按天、按品类聚合的汇总表。查询只扫描30行汇总数据，扫描量从GB级降到KB级。
方式B多占了一点存储，但把Athena每次查询的扫描量降低了几个数量级。在按扫描量计费的Athena中，这直接意味着成本从每次几美元降到几美分。这就是云上建模的典型权衡：用存储换计算，用冗余换速度。
但挑战也随之而来。第一，数据一致性更难保证：预聚合表需要和明细表保持同步，一旦ETL失败或迟到数据到达，汇总结果就可能失真。第二，分区设计容易踩坑：分区过细会产生大量小文件，拖慢查询；分区过粗则扫描量降不下来。第三，多引擎共享元数据：同一份S3数据可能被Athena、Redshift Spectrum、EMR同时读取，列类型和分区格式必须严格一致，否则会出现"一个引擎能查、另一个报错"的情况。第四，成本可见性差：S3请求费用、Glue DPU时长、Redshift集群空闲成本分散在不同账单中，不主动监控就很难定位浪费。
最后需要明确本课程的边界。我们不会深入讲解每个服务的全部管理操作，也不会把重点放在IAM策略或网络配置上。课程的核心始终是数据模型本身：表结构、分区策略、键设计、文件格式、聚合粒度、流式窗口、元数据组织。这些才是决定分析系统能否既快又省的关键，也是数据建模与分析工程在云上真正区别于传统DBA工作的地方。