数据湖架构基础：分层、存储与计算
聊数据湖权限，得先搞清楚数据湖长什么样。我见过不少团队，权限策略写得天花乱坠，结果连数据在哪个层、用什么格式、谁来算都没对齐——那策略就是空中楼阁。
这一章，咱们把地基夯实。说白了，就三件事：分层架构、存储格式、计算引擎。搞懂了这些，后面聊权限你才知道该锁哪里、怎么锁。
一、Bronze / Silver / Gold 分层架构
数据湖不是垃圾桶，不能什么东西都往里倒。业界主流做法是分三层：Bronze（原始层）、Silver（清洗层）、Gold（业务层）。我习惯叫它「三明治架构」——简单，但管用。
核心原则：每一层的数据权限粒度、保留策略、访问频率都不一样。权限设计必须跟着分层走，不能一把抓。
1. Bronze 层（原始数据层）
这一层存的是「原汁原味」的数据。从 Kafka、数据库 CDC、日志文件直接拉过来，不做任何清洗。格式可能是 JSON、CSV、Avro，甚至是一堆压缩包。
- 特点：数据量大、冗余多、格式杂。
- 权限策略：通常只允许数据工程师和 ETL 任务写入，分析师一般不直接碰。
- 我踩过的坑：曾经有个团队把 Bronze 层权限全放开，结果分析师直接跑 SQL 查原始日志，一个没过滤的 SELECT * 把集群搞挂了。Bronze 层，默认只写不读，除非你有明确理由。
2. Silver 层（清洗与标准化层）
数据从 Bronze 出来后，经过 ETL 作业：去重、类型转换、字段映射、脏数据过滤。Silver 层的数据是结构化、可重用的。
- 特点：格式统一（通常是 Parquet 或 Delta），分区合理，质量可控。
- 权限策略：可以开放给数据工程师和部分高级分析师，但不能直接暴露给业务用户——因为字段名可能还是技术命名（比如
col_001）。 - 避坑指南：我曾经见过 Silver 层的数据没做脱敏，手机号、身份证直接明文存着。权限策略里一定要加上列级脱敏，不然审计来了你扛不住。
3. Gold 层（业务聚合层）
这一层是给业务用户看的。数据经过聚合、宽表构建、指标计算，字段名变成业务术语（比如 user_phone 变成 联系方式）。
- 特点：数据量相对小，查询频率高，面向报表、BI、数据产品。
- 权限策略：最严格的一层。按业务域、用户角色、数据敏感度做细粒度控制。我建议 Gold 层强制启用行级安全过滤——比如销售经理只能看自己团队的业绩。
我的习惯：在权限模型里，我会把 Bronze 和 Silver 归为「技术域」，Gold 归为「业务域」。技术域用 RBAC（基于角色的访问控制），业务域用 ABAC（基于属性的访问控制）。混着用，效果最好。
下面这张图，把三层架构和权限要点串起来了：
二、数据湖存储格式：Parquet / Delta / Iceberg
格式选不对，权限策略再好也白搭。你想想看，如果存储格式不支持列级权限，你就算在引擎层做了脱敏，底层文件一读还是裸数据——那叫「假安全」。
1. Parquet
Parquet 是列式存储的「老大哥」。压缩率高、扫描快，尤其适合 OLAP 场景。
- 优点：列式存储，支持谓词下推，读数据时只加载需要的列。
- 缺点：不支持 ACID 事务，不支持行级更新。说白了，就是个「只读格式」。
- 权限相关：Parquet 本身没有权限控制能力。你得靠上层引擎（比如 Spark、Trino）来做列级权限。我建议：如果数据不需要更新，用 Parquet 就够了，别为了用新技术而用。
2. Delta Lake
Delta 是 Databricks 推出的格式，在 Parquet 基础上加了事务日志（Transaction Log）。
- 优点：支持 ACID、时间旅行（Time Travel）、Schema 演进。你可以回滚到任意历史版本。
- 权限相关：Delta 的 Transaction Log 里记录了每次操作的元数据。配合 Delta Sharing，可以实现细粒度的表级和分区级权限。
- 我个人的经验：在 Gold 层，我几乎只用 Delta。因为业务数据经常需要修正——比如昨天跑的数据有 bug，今天要重跑。Delta 的
MERGE和UPDATE操作，配合权限控制，能让你既灵活又安全。
3. Apache Iceberg
Iceberg 是 Netflix 开源的，跟 Delta 类似，但更「开放」。它不绑定任何计算引擎或云平台。
- 优点：支持隐藏分区（Hidden Partitioning）、文件级统计信息、多引擎并发写入。
- 权限相关：Iceberg 的 REST Catalog 支持基于角色的权限控制。你可以通过 Catalog 接口，对表、命名空间做 ACL。
- 避坑指南：我曾经在项目中同时用了 Delta 和 Iceberg，结果权限策略写了两套——累死人。建议统一选一种格式，别混用。如果团队 Spark 生态强，选 Delta；如果多引擎（Flink + Trino + Spark），选 Iceberg。
| 特性 | Parquet | Delta Lake | Apache Iceberg |
|---|---|---|---|
| ACID 事务 | 不支持 | 支持 | 支持 |
| 时间旅行 | 不支持 | 支持 | 支持 |
| Schema 演进 | 手动 | 自动 | 自动 |
| 列级权限 | 依赖引擎 | 原生支持 | 通过 Catalog |
| 行级更新 | 不支持 | 支持（MERGE） | 支持 |
| 多引擎兼容 | 好 | 偏 Spark | 好 |
注意：存储格式的权限能力，不等于你实际能用的权限。比如 Delta 支持列级权限，但如果你用 Spark 3.0 以下的版本，这个功能可能用不了。选格式的时候，一定要确认你的引擎版本是否支持。
三、数据湖计算引擎：Spark / Flink / Trino
计算引擎是执行权限策略的「最后一公里」。引擎不支持，策略写得再漂亮也没用。
1. Apache Spark
Spark 是数据湖的「主力军」。ETL、数据科学、流批一体，它都能干。
- 权限控制方式：Spark 本身没有内置的权限系统。你得靠外部工具：Ranger、Atlas、或者 Databricks 的 Unity Catalog。
- 我常用的做法：用 Spark SQL 的
GRANT/REVOKE语句，配合 Ranger 做列级和行级过滤。但要注意——Spark 的 SQL 权限只在 DataFrame API 和 SQL 层面生效，如果你用 RDD API 直接读文件，权限就绕过去了。 - 避坑指南：我曾经遇到一个 case：数据工程师用 Spark RDD 读 Delta 表，绕过了 Ranger 的列级脱敏。解决方案是：强制所有数据访问走 SQL 或 DataFrame API，禁止直接操作底层文件。
2. Apache Flink
Flink 主打实时流处理。在数据湖场景里，Flink 通常负责把数据写入 Bronze 或 Silver 层。
- 权限控制方式：Flink 的权限控制比较弱。它依赖外部系统（比如 Kafka 的 ACL、HDFS 的权限）来做。
- 我的建议：Flink 作业的权限，在作业提交层面控制。比如用 YARN 或 Kubernetes 的 RBAC，限制谁可以提交 Flink 作业、作业能访问哪些路径。
- 注意：Flink 写入 Delta 或 Iceberg 时，写入权限由目标格式的 Catalog 控制。所以Catalog 的权限配置一定要严格，不然 Flink 作业可能「越权写数据」。
3. Trino（原 PrestoSQL）
Trino 是交互式查询引擎，适合分析师和 BI 工具直接查数据湖。
- 权限控制方式：Trino 有内置的 Access Control 插件机制。你可以实现自己的
SystemAccessControl或ConnectorAccessControl。 - 我推荐的做法：用 Trino 的 Ranger 插件，统一管理所有表的列级和行级权限。Trino 的权限检查是在 SQL 解析阶段做的，性能影响很小。
- 避坑指南：Trino 的权限是「会话级」的。如果用户用 JDBC 连接，权限在连接建立时检查一次。如果连接池复用，可能会出现权限缓存问题。我建议关闭连接池的权限缓存，每次查询都重新检查。
我的经验总结：权限策略的落地，引擎选型占 50% 的权重。如果团队以 Spark 为主，优先用 Unity Catalog 或 Databricks 的权限模型。如果多引擎混用，用 Iceberg + Trino + Ranger 的组合，统一权限入口。
下面这张图，展示了三种引擎在数据湖分层中的典型位置：
小结
这一章的内容，说白了就是一句话：分层定边界，格式定能力，引擎定执行。权限策略不是凭空想出来的，而是从架构里长出来的。Bronze 层粗放、Silver 层标准、Gold 层精细——每一层的权限粒度，跟数据质量、使用场景是绑定的。
存储格式决定了你能做到多细的权限控制。Parquet 够用但有限，Delta 和 Iceberg 给了你更多武器。计算引擎则是权限策略的「执行者」——引擎不支持，策略就是废纸。
嗯，地基打好了。下一块砖，咱们聊聊权限模型本身——RBAC、ABAC、以及怎么在数据湖里落地。