1. 课程导入与全景认知
在多数已经上云的组织里，数据往往不是"没有"，而是"散落在不同团队手里"。业务分析团队需要用户行为数据做增长模型，风控团队需要交易流水做实时拦截，算法团队需要特征宽表做模型训练，而数据本身却分别由订单系统、支付系统、埋点平台、CRM 等不同团队维护。跨团队数据共享要解决的，正是"数据在别人手里、但我要用"这一根本矛盾。它不是简单的文件拷贝，而是一套涉及权限、治理、成本、时效与合规的系统工程。
一、业务驱动：为什么必须跨团队共享
推动跨团队共享的力量通常来自四个方向。第一是分析需求聚合：单一团队的数据只能回答局部问题，只有把订单、支付、行为、客服工单拼在一起，才能回答"哪类用户流失风险最高"这类复合问题。第二是消除数据副本：如果每个消费方都从生产库导出全量数据，会形成大量冗余副本，既浪费存储，又让口径难以统一。第三是时效性要求：风控、推荐、运营看板对数据新鲜度的要求从 T+1 逐步提升到分钟级甚至秒级，靠人工导出已无法满足。第四是合规与审计：数据一旦离开生产团队，谁在什么时间、以什么方式、访问了哪些字段，都必须可追溯，否则无法通过内部审计与外部监管。
这四点决定了共享方案不能只追求"能拿到数据"，还要同时满足口径一致、权限最小、时效可控、成本可解释、行为可审计五个约束。理解这五个约束，是后续选择 AWS 服务的基本判断依据。
二、技术挑战：共享为什么比想象中难
跨团队共享的难点集中在五个层面，可以用一张关系图来建立整体印象。
这五类挑战并非彼此独立。例如为了满足时效性而选择"不复制、直接查"，就会把权限与审计压力集中到共享层；为了降低消费方门槛而放宽权限，又会削弱合规性。因此共享方案本质上是一组权衡，而不是单一最优解。
三、AWS 服务矩阵：各司其职
AWS 并没有一个叫"数据共享"的单一服务，而是由多个服务组合成能力矩阵。理解每个服务的定位，比记住服务名更重要。
| 能力层 | 代表服务 | 在共享中的职责 |
|---|---|---|
| 存储与格式 | S3、Parquet、Iceberg | 承载共享数据本体，决定分区与开放格式 |
| 元数据 | Glue Data Catalog | 统一表结构、分区与位置，是共享的"目录" |
| 权限治理 | Lake Formation、IAM | 表/列/行级授权，跨账号访问控制 |
| 查询与计算 | Athena、Redshift、EMR | 消费方按需读取，无需搬运数据 |
| 安全与审计 | KMS、CloudTrail、Macie | 加密、访问留痕、敏感数据发现 |
| 跨账号通道 | RAM、资源策略、LF 跨账号授权 | 建立账号间的受控共享关系 |
一个常见的误区是把共享等同于"给 S3 桶加个跨账号策略"。实际上，仅开放 S3 权限会让消费方看到原始文件路径，却无法通过 SQL 查询；而只配置 Glue 目录又缺少数据访问授权。真正可用的共享，需要存储权限、目录权限、数据权限三者同时到位，这也是本课程后续反复强调的主线。
四、学习路径与实战目标
本课程按"认知—建湖—授权—消费—治理—协作"的递进关系展开。前几章先建立数据湖与目录的基础，中间章节深入 Lake Formation 的权限模型与跨账号共享，随后进入消费侧查询优化与成本控制，最后落到多团队协作规范、审计与故障排查。
完成本课程后，你应当能够独立完成以下实战目标：
- 为一个跨团队场景设计共享架构，明确生产方、共享层、消费方的边界；
- 使用 Glue 爬取并注册表，配置分区与开放格式；
- 通过 Lake Formation 实现表级、列级乃至行级授权，并完成跨账号共享；
- 让消费方用 Athena 或 Redshift Spectrum 直接查询共享数据，避免全量复制；
- 通过 CloudTrail 与 Lake Formation 日志定位"谁访问了什么、为何被拒绝"；
- 对共享方案做成本与时效评估，给出可解释的取舍依据。