필사 모드: 数据治理・Lineage・PII 完全指南：OpenLineage、Collibra・Atlan・DataHub、Unity・Polaris、GDPR 与韩国个人信息保护法（2025）

Season 5 Ep 7 — 在 Ep 1–6 中，数据变得越来越多、越来越复杂。Ep 7 是相反的一条轴 —“如何治理它”。不管理数据，数据就会反过来支配公司。

• Prologue — “我们公司的客户邮箱到底散落在几个地方”
• 第1章 · 数据治理的定义
  • 1.1 治理的四条轴
  • 1.2 为什么现在重要
  • 1.3 治理的光谱
• 第2章 · OpenLineage — 血缘的标准
  • 2.1 身份
  • 2.2 结构
  • 2.3 集成
  • 2.4 示例事件
  • 2.5 价值
• 第3章 · 四大数据目录
  • 3.1 Collibra
  • 3.2 Atlan
  • 3.3 DataHub
  • 3.4 Alation
  • 3.5 其他
  • 3.6 对比
• 第4章 · 技术目录 — Unity/Polaris/Glue
  • 4.1 Unity Catalog
  • 4.2 Polaris
  • 4.3 AWS Glue Data Catalog
  • 4.4 Nessie / Gravitino
  • 4.5 业务目录 vs 技术目录
• 第5章 · PII — 定义与识别
  • 5.1 PII 的定义
  • 5.2 自动识别工具
  • 5.3 识别方式
  • 5.4 分类等级
• 第6章 · PII 保护 — 脱敏・令牌化・加密
  • 6.1 脱敏
  • 6.2 令牌化（Tokenization）
  • 6.3 哈希与匿名化
  • 6.4 加密
  • 6.5 Dynamic Masking 示例（Snowflake）
• 第7章 · 法规 — GDPR、韩国 PIPA、AI Act
  • 7.1 GDPR（欧盟，2018–）
  • 7.2 韩国个人信息保护法（PIPA）
  • 7.3 韩国 AI 基本法（2024–）
  • 7.4 其他法规
  • 7.5 共同原则
• 第8章 · Data Subject Request (DSR)
  • 8.1 请求类型
  • 8.2 实现难度
  • 8.3 实务模式
  • 8.4 AI 与训练数据
• 第9章 · AI 时代的治理扩展
  • 9.1 模型目录
  • 9.2 提示词与智能体目录
  • 9.3 训练数据来源追踪
  • 9.4 AI 结果审计
  • 9.5 与法规的衔接
• 第10章 · 实战架构 — 治理整合
  • 10.1 分层
  • 10.2 策略示例
  • 10.3 审计
  • 10.4 自动化
• 第11章 · 韩国企业的治理现实
  • 11.1 现状
  • 11.2 合规应对
  • 11.3 挑战
  • 11.4 参考案例
• 第12章 · 八个失败案例
  • 12.1 PII 暴露在 BI 仪表盘上
  • 12.2 没有血缘的故障处理
  • 12.3 删除请求处理了一个月
  • 12.4 数千张不知道责任人的表
  • 12.5 有目录，但是空的
  • 12.6 访问权限碎片化
  • 12.7 外包人员可以访问全部 PII
  • 12.8 AI 训练数据来源不明
• 第13章 · 十个反模式
  • 13.1 “治理以后再说”
  • 13.2 只有目录，没有责任人
  • 13.3 PII 识别只有几行正则
  • 13.4 对备份的合规要求漠不关心
  • 13.5 用手写文档维护 Lineage
  • 13.6 没有 Data Contract 就随意改上游
  • 13.7 缺少对外共享的管控
  • 13.8 审计日志保存期太短
  • 13.9 同时并行多个目录工具
  • 13.10 把 AI 与 ML 放在治理之外
• 第14章 · 检查清单 — 数据治理 12 项
• 第15章 · 下一篇预告 — Season 5 Ep 8：“Observability 2025 (Logs・Metrics・Traces + LLM)”

Prologue — “我们公司的客户邮箱到底散落在几个地方”

2025 年 CTO 最难回答的问题：

• 客户邮箱存在于多少张表、多少个系统里
• 其中做过 PII 脱敏的有多少
• 用户说“把我的数据删掉”时，该从哪里开始删
• 这个仪表盘上的数字来自哪一份源数据

如果四个问题的答案都是“不知道”，那么这家公司同时背负着合规风险和产品质量风险。本文整理的是能让你回答这四个问题的工具与流程。

第1章 · 数据治理的定义

1.1 治理的四条轴

• 目录（Catalog）：我们究竟有哪些数据
• Lineage：从哪里来，到哪里去
• 质量（Quality）：这些数据可信吗
• 安全与合规（PII・RBAC）：谁能看到，保留多久

1.2 为什么现在重要

• 数据栈的碎片化（Ep 1–6）让管理复杂度激增
• EU AI Act、GDPR、韩国个人信息保护法的持续收紧
• AI 模型对数据进行训练与推理 → 著作权与 PII 问题
• 客户与员工行使数据权利的情况增多

1.3 治理的光谱

• 目录：以读取为主，供员工检索
• Active governance：强制执行策略，阻断违规
• Federation：多云、多数据库的统一管理

第2章 · OpenLineage — 血缘的标准

2.1 身份

• 2020 年开源，隶属 LF AI & Data 基金会
• 数据血缘（Lineage）的行业标准规范
• 提供 Python・Java・OpenAPI 参考实现

2.2 结构

• Job：执行单元（Airflow DAG・dbt run・Flink job）
• Run：Job 的一次执行实例
• Dataset：输入与输出数据集
• Event：START/COMPLETE/FAIL 事件

2.3 集成

• 支持 Airflow、dbt、Spark、Flink、Dagster、Prefect
• Marquez（参考实现的元数据存储）
• Datakin → Astronomer 提供 SaaS 支持
• DataHub・Atlan・Collibra 接收 OpenLineage 事件

2.4 示例事件

{
  "eventType": "COMPLETE",
  "job": {"name": "dbt.fact_orders"},
  "run": {"runId": "..."},
  "inputs": [{"name": "raw.orders"}, {"name": "raw.customers"}],
  "outputs": [{"name": "analytics.fact_orders"}]
}

2.5 价值

• 自动采集血缘 → 减轻人工编写文档的负担
• 可在工具之间迁移
• 故障分析与影响面评估

第3章 · 四大数据目录

3.1 Collibra

• 2008 年，比利时 → 企业级治理的最强者
• 专注金融、公共部门与制药
• 业务术语表（Glossary）与策略管理是强项

3.2 Atlan

• 2018 年，印度 → 亲和现代数据栈
• 与 dbt・Snowflake・Databricks 的集成极为出色
• 协作能力与 UX 优秀

3.3 DataHub

• 2020 年源自 LinkedIn → Apache
• 开源，可自托管
• 由 Acryl Data（商业 SaaS）提供支持

3.4 Alation

• 2012 年 → 面向企业的协作型目录
• 定位为 Data Intelligence Platform

3.5 其他

• Secoda、Castor（→ CoreView）、OpenMetadata、Amundsen（Lyft）
• Informatica Data Governance、IBM Watson Knowledge Catalog

3.6 对比

第4章 · 技术目录 — Unity/Polaris/Glue

4.1 Unity Catalog

• Databricks 的治理层
• 2024 年开源（Unity Catalog OSS）
• 统一管理 Table・Volume・Model・Function
• Delta 与 Iceberg 都支持

4.2 Polaris

• Snowflake 开放的 Iceberg REST 目录
• 2024 年开源
• 可从外部引擎访问
• 把治理与目录结合在一起

4.3 AWS Glue Data Catalog

• AWS 的默认目录
• 支持 Iceberg・Delta・Hudi
• 与 Lake Formation 结合实现权限与审计

4.4 Nessie / Gravitino

• Nessie：类似 Git 的分支与标签
• Gravitino：元数据联邦（整合多个目录）

4.5 业务目录 vs 技术目录

• 技术目录：引擎与查询使用的元数据
• 业务目录：人使用的语义、责任人、SLA
• 2025 年两者的打通（OpenLineage・OpenMetadata）已成标准

第5章 · PII — 定义与识别

5.1 PII 的定义

• Personally Identifiable Information
• 直接识别（姓名・居民登记号・卡号）
• 间接识别（出生日期+地区・IP・Cookie ID）
• 敏感信息（健康・宗教・倾向）

5.2 自动识别工具

• AWS Macie, Google DLP, Azure Purview：云端 DLP
• Privacera, BigID, OneTrust：企业级专业方案
• Presidio (Microsoft)：开源
• Snowflake Data Classification：DW 内置

5.3 识别方式

• 正则表达式（卡号・居民登记号）
• 基于词典（姓名・地址）
• ML 分类器（包含上下文）
• 列采样 + 熵分析

5.4 分类等级

• Public / Internal / Confidential / PII / Sensitive PII / Regulated
• 按等级差异化制定访问、日志留存与加密策略

第6章 · PII 保护 — 脱敏・令牌化・加密

6.1 脱敏

• 邮箱：john@***.com
• 卡号：**** **** **** 1234
• 姓名：张*东 或 张OO
• Dynamic Data Masking：查询时按用户展示不同内容

6.2 令牌化（Tokenization）

• 用无意义的令牌替换 PII，映射关系单独存放在保险库（Vault）
• 在保留可分析性的同时，把泄露时的影响降到最低
• Vault：HashiCorp Vault、AWS KMS + 自研服务

6.3 哈希与匿名化

• SHA-256 等单向哈希：可分析，但无法还原原文
• k-anonymity、l-diversity、differential privacy
• 用于医疗与公共数据

6.4 加密

• At rest：S3 SSE、磁盘加密
• In transit：TLS
• Column-level：Parquet Modular Encryption
• Field-level：在应用侧加密后再存储

6.5 Dynamic Masking 示例（Snowflake）

CREATE MASKING POLICY mask_email AS (val STRING)
RETURNS STRING ->
  CASE WHEN CURRENT_ROLE() IN ('ADMIN') THEN val
       ELSE REGEXP_REPLACE(val, '.+@', '***@')
  END;

ALTER TABLE customers MODIFY COLUMN email
  SET MASKING POLICY mask_email;

第7章 · 法规 — GDPR、韩国 PIPA、AI Act

7.1 GDPR（欧盟，2018–）

• 数据主体权利（访问・删除・可携・更正・拒绝处理）
• 必须明示 Legal basis（同意・合同等）
• DPIA（影响评估）、DPO（数据保护负责人）
• 违规时可处全球营业额的 4% 或 2000 万欧元

7.2 韩国个人信息保护法（PIPA）

• 2011 年制定，2020 年与 2023 年修订
• 处理个人信息须取得同意并明示目的
• 2023 年修订：强化数据主体权利（查阅・删除・可携）
• 引入以营业额 3% 为上限的罚款
• 由个人信息保护委员会负责监管

7.3 韩国 AI 基本法（2024–）

• 高风险 AI 的事前影响评估
• 负责任的 AI 开发与运营指南
• 经营者的报告义务

7.4 其他法规

• 美国的 HIPAA、GLBA、CPRA（加利福尼亚州）
• 新加坡 PDPA、日本 APPI
• 按行业：金融监督院、医疗法、电子金融监督规程

7.5 共同原则

• 目的限制：禁止用于收集目的之外的用途
• 最小收集：只收集必要的部分
• 保存期限：达成目的后即销毁
• 主体权利：查阅・更正・删除・可携
• 透明性：公开处理情况

第8章 · Data Subject Request (DSR)

8.1 请求类型

• Access：查阅我的数据
• Rectification：更正
• Erasure（Right to be forgotten）：删除
• Portability：迁移到其他服务
• Object：拒绝处理

8.2 实现难度

• 删除数仓中该用户的行
• Lakehouse Iceberg 的 row-level delete
• 备份与日志的处理
• 数据已进入 ML 训练集的情况（要重新训练吗?）
• 已共享给第三方的数据

8.3 实务模式

• 数据地图（Data Map）：含有 PII 的表与位置清单
• Unique ID：用每位用户的唯一 ID 检索全部系统
• DSR 工作流工具：OneTrust・TrustArc・Osano
• 日志与备份策略：法定期限过后自动销毁

8.4 AI 与训练数据

• 从训练数据中删除某个人在原理上就很困难
• 解决办法：假名化・匿名化・Synthetic data
• Machine unlearning 的研究仍在推进

第9章 · AI 时代的治理扩展

9.1 模型目录

• 公司在用的模型清单
• 版本・数据・性能・许可证・审计
• MLflow・Databricks Model Registry・Weights & Biases・HuggingFace Hub

9.2 提示词与智能体目录

• 系统提示词的版本
• 智能体的工具与权限
• Ep 11（LLMOps）的延伸

9.3 训练数据来源追踪

• 著作权与许可证的文档化
• 数据集卡片（Dataset Card）
• 被要求审计时能拿出原始依据

9.4 AI 结果审计

• 响应日志・引用・决策依据
• 为 Postmortem 保留可复现性

9.5 与法规的衔接

• EU AI Act：高风险模型的质量管理与文档
• 韩国 AI 基本法：影响评估

第10章 · 实战架构 — 治理整合

10.1 分层

• 采集：Kafka・Fivetran・Airbyte → OpenLineage 事件
• 转换：dbt・Spark → 自动发出 OpenLineage
• 存储：Iceberg・Delta + 目录（Unity/Polaris/Glue）
• 治理：DataHub/Atlan/Collibra 接收并整合
• 策略：Unity/Lake Formation/Ranger/OPA
• PII：Macie/Privacera/DLP

10.2 策略示例

• Raw：原始数据，限制访问，保留 90 天
• Silver：脱敏 + 令牌化，保留 1 年
• Gold：聚合结果，基于权限的脱敏，保留 3 年以上
• 备份：加密，法定期限过后自动销毁

10.3 审计

• 所有查询与 DDL 的日志
• 访问异常检测（异常时间・IP・数据量）
• 季度审计报告

10.4 自动化

• PR 合并时执行治理检查 CI
• 新表 → 自动分类并指定责任人
• 访问申请 → 审批工作流

第11章 · 韩国企业的治理现实

11.1 现状

• 金融与公共部门：自建 + Collibra/Informatica 混用
• 大企业：DataHub 开源版 → 内部分支
• 中型企业与创业公司：Atlan・Secoda 的采用在增加
• 可观测性与 PII 专用工具仍处于早期阶段

11.2 合规应对

• 个人信息保护委员会的审计与罚款案例增多
• 金融保安院的指南
• 公共数据三法（个人信息・信用信息・信息通信网）

11.3 挑战

• 网络隔离环境下的目录建设
• 韩语元数据支持
• 遗留 DW 的历史难以自动采集
• 人才不足：治理专职人员稀缺

11.4 参考案例

• Toss：在内部数据平台中整合 DSR 与目录
• Kakao：PII 自动分类流水线
• Naver：治理标准团队 + 自研目录
• 三星 SDS・LG CNS：面向企业客户的治理 SI 套件

第12章 · 八个失败案例

12.1 PII 暴露在 BI 仪表盘上

没有 dynamic masking，实名直接暴露 → 被审计指出问题。

12.2 没有血缘的故障处理

为了搞清“这个指标为什么不对”，花掉半天。

12.3 删除请求处理了一个月

纯手工操作，多个系统的同步删除失败。

12.4 数千张不知道责任人的表

不知道该去问谁。

12.5 有目录，但是空的

初次建设之后无人维护，与现实脱节。

12.6 访问权限碎片化

10 个数据库各管各的 RBAC，中央管理宣告失败。

12.7 外包人员可以访问全部 PII

审计违规。

12.8 AI 训练数据来源不明

遇到著作权纠纷或监管调查时毫无还手之力。

第13章 · 十个反模式

13.1 “治理以后再说”

规模越大越难推倒重来。从一开始就把地基打好。

13.2 只有目录，没有责任人

只是有文档，却没有责任。

13.3 PII 识别只有几行正则

需要同时配合 ML 分类器与采样。

13.4 对备份的合规要求漠不关心

“销毁期限已过，但备份里还留着”的事故。

13.5 用手写文档维护 Lineage

应引入自动采集（OpenLineage）。

13.6 没有 Data Contract 就随意改上游

所有下游消费方全部损坏。

13.7 缺少对外共享的管控

S3 桶被公开、邮件附件外发。

13.8 审计日志保存期太短

无法满足监管要求。

13.9 同时并行多个目录工具

没有整合，只有重复管理。

13.10 把 AI 与 ML 放在治理之外

2025 年这就是最大的风险。

第14章 · 检查清单 — 数据治理 12 项

• 整合数据目录（业务 + 技术）
• 基于 OpenLineage 的血缘自动采集
• 明示表与模型的责任人与 SLA
• PII 自动识别与分类流水线
• 脱敏・令牌化・加密策略
• DSR 工作流与处理时限
• 权限与审计日志的集中化
• 数据契约 · 变更流程
• 法定保存与销毁策略
• AI 与 ML 领域的治理（模型、数据来源）
• 法规映射（GDPR・PIPA・AI Act・行业法规）
• 员工培训与向管理层汇报

第15章 · 下一篇预告 — Season 5 Ep 8：“Observability 2025 (Logs・Metrics・Traces + LLM)”

如果说治理讲的是“如何管理数据”，那么可观测性讲的就是“系统和数据实际运转得怎么样”。

• OpenTelemetry 的成熟
• Metric・Log・Trace 三大信号的整合
• Grafana Cloud・Datadog・New Relic・Splunk・Honeycomb・SigNoz
• Tempo・Loki・Mimir・Jaeger・Zipkin
• LLM 可观测性（LangFuse・LangSmith・Phoenix・Helicone，Ep 6 的延伸）
• SLO・SLI 与 error budget
• 混沌工程与韧性
• 韩国企业的可观测性技术栈
• “可观测性不是保险，而是产品质量”

“没有可观测性就没有运维” — 这是 2025 年基础设施的默认值。

下一篇文章再见。

总结：2025 年的数据治理由目录 + Lineage + 质量 + PII 与合规四条轴构成。OpenLineage 成为血缘的标准，Collibra・Atlan・DataHub・Alation 是目录的四大选项，Unity・Polaris・Glue 承担技术目录。PII 通过识别、分类、脱敏、令牌化、加密五个阶段来管理，GDPR、韩国 PIPA 与 AI Act 构成监管的三角。AI 时代的治理已经扩展到模型、提示词乃至训练数据，而数据主体权利（DSR）必须依靠自动化工作流。韩国企业面临网络隔离、韩语元数据与遗留系统整合的挑战，能否配备治理专职人员将成为下一代竞争力。“不去管理，就会被管理” — 这就是数据治理在 2025 年的法则。