数据是新的石油。
—— Clive Humby
在本章中，我们将先介绍数据治理及其重要性。如果你已经对数据治理有总体了解，并且认同它在分析领域的关键作用，可以直接跳到“湖仓一体的曙光”。如果你已熟悉湖仓（lakehouse）范式与 Databricks 平台，则可以直接阅读“Databricks Unity Catalog：实现统一治理”。
数据治理简介
2021 年 10 月 28 日，SafetyDetectives 的一支网络安全团队发现了一个未加保护的 Amazon S3 存储桶，里面包含一百多万份文件。除其他内容外，该存储桶中还包括哥伦比亚和秘鲁部分机场员工的可识别个人信息（PII）以及敏感公司数据。尽管这些文件可追溯到 2018 年 11 月，但没人知道该存储桶在公共互联网上暴露了多久。显然，这个 S3 存储桶属于一家在全球设有分支机构、总部位于瑞典斯德哥尔摩的知名安保服务公司 Securitas。
这并非个例。2019 年 7 月，Capital One 因云防火墙配置漏洞遭遇数据泄露，超过 1 亿条客户记录被非法访问。又一例与 Amazon S3 存储桶错误配置相关的事件发生在 2022 年 3 月，土耳其廉价航空公司飞马航空（Pegasus Airlines）的大量敏感数据被曝光，原因被认为是人为失误。被曝光的数据接近 2300 万个文件；一旦落入不法分子之手，数千名乘客与机组人员都将受到影响。例如，这些个人信息可能被用于实施身份盗用与金融欺诈。此外，个人数据的曝光违反了土耳其《个人数据保护法》（LPPD），可能招致罚款。
不幸的是，此类事件并不罕见。多项研究表明，“人为错误”是网络安全事故的主要根因。根据 Verizon 于 2022 年发布的《数据泄露调查报告》（DBIR），82% 的泄露事件涉及人为因素。Gartner 预测，在不久的将来，重大网络事件中超过一半将由人才短缺或人类失误导致。
鉴于这一趋势，我们需要以“以人为本”的方式改进安全流程与实践。换言之，人一定会犯错，因此我们必须提高出错难度，并设置护栏，在错误不可避免时最大限度降低影响。这需要实施多项措施，例如在安全主题上进行教育与赋能、加固网络、落地零信任安全模型，以及建立健全的数据治理实践。
从本质上讲，数据治理是一种在数据全生命周期内对组织数据进行管理的综合方法，确保其可用性、可用性（易用度）、质量、完整性与安全性。
数据治理的关键组成包括：
- 政策与标准
- 数据质量管理
- 元数据管理
- 访问控制与安全措施
- 数据全生命周期管理与数据血缘追踪
- 审计与合规性监控
有效数据治理的收益
恰当的数据治理实践通过多种关键机制，显著降低数据泄露与安全事件的风险，例如：
建立清晰的政策与管控
为数据全生命周期管理制定清晰、完备的政策与控制措施，包括：
- 实施强有力的访问控制与认证流程，确保只有获授权人员才能访问数据及相关资产。
- 强制执行数据分级分类与风险评估，识别并优先保护高风险数据资产。
- 制定数据处理政策或指南，明确数据应如何被安全地存储、处理、传输与处置（销毁）。
强化数据安全措施
通过以下方式支撑并提升组织整体安全态势：
- 要求或推动部署健壮的安全措施，如加密、防火墙与入侵检测系统。
- 实施数据最小化实践，减少整体攻击面与潜在泄露影响。
- 强制开展定期安全审计与风险评估，主动识别并修补潜在漏洞。
- 建立事件响应计划，以便快速处置安全事件并降低损害。
营造安全意识文化
超越技术层面的管控，通过下列方式让员工成为组织的“人形防火墙”，而非安全事件的薄弱环节：
- 定期组织员工培训与意识提升活动，普及数据安全最佳实践与保护敏感信息的重要性。
- 在全组织范围内明确数据管理的角色与职责，构建数据安全问责机制。
部署完善、有效的数据治理还将带来以下附加收益：
- 改善数据质量与可靠性
- 增强法规合规性
- 基于可信数据做出更优决策
- 提升运营效率
- 降低数据管理成本
- 增强消费者信任
接下来，我们先更深入地了解数据的生命周期，以理解数据治理面临的挑战。
数据的生命周期
一个组织中通用的数据生命周期可被简化为四个阶段，如图 1-1 所示：
引入（Onboarding）
即数据被收集、生成或接入之时：
- 收集：例如，用户在网站注册
- 生成：例如，机器设备的信号
- 接入：例如，来自供应商的商品目录
图 1-1. 数据生命周期的简化示意
注：这只是一个非常简化、概览级的生命周期。真实世界通常复杂得多。
处理（Processing）
数据在组织内“诞生”后，往往需要一定处理才能更可用，这一阶段称为“处理”。当然，这取决于数据引入流程本身的质量。也就是说，第一步应是确保数据质量；为此，你可能需要额外步骤，例如过滤部分数据、填补缺失值等。
其他常见的数据处理形式包括合并/融合与聚合。例如，你可能拥有多个代表现实世界同一实体的数据点，需要先识别哪些记录属于同一实体并将其合并，这被称为实体解析（entity resolution） ；它不同于数据协调（data harmonization） ——后者是将来自多源的数据统一/整合为一致的标准化格式。你也可能需要将不同数据集联合起来产生新的、更有价值的数据（一个简单例子就是表连接）。
数据聚合同样常见，通常用于提炼信息、获取洞见。有时数据的价值体现在聚合后的形态中：一旦聚合结果被计算并存储，源数据即可删除。例如，物联网（IoT）系统的传感器会产生大量细粒度数据点，常被聚合为按小时或按天的汇总，细粒度数据随后被清理以节省存储。再如高频交易平台等金融系统会产生海量数据，通常聚合为日度价格汇总；单笔成交记录在满足监管留存期后被清除。出于合规性要求，在“仅用于生成聚合结果”的场景中，达到既定用途后删除数据也是必要措施。
为满足监管要求，另一项常见措施是匿名化。匿名化程度取决于目标用例：有时需要对可识别个人信息（PII）或受保护的个人健康信息（PHI）进行完全匿名化；另一些场景则需在不完全暴露数据的前提下做去标识化处理，使其仍可用于数据产品。后续章节会深入讨论。
注释
- PII：能直接或与其他信息结合后识别到个人身份的任何信息。
- PHI：PII 的一个子集，特指医疗健康场景中与个人健康状况及医疗服务相关的信息；在美国受《健康保险携带与责任法案》（HIPAA）保护。
在役（Active duty）
无论是否经过处理，数据都会被用于应用、报表，或用于高级分析（例如训练预测型机器学习模型）。当数据被用于特定目的时，这一阶段称为“在役”。
退役（Offboarding）
一旦数据达成了既定目的且不再需要，就应根据组织政策与监管要求进行清除（purge）或归档（archive） 。在任一阶段结束后进行清除/归档也很常见。比如，有些数据仅用于校验所提供信息的正确性，那么只需在验证完成前保留即可。生命周期的最后阶段便是“退役”。
提示
若需系统学习数据治理的一般概念，Evren Eryurek、Uri Gilad 等人著的 O’Reilly 图书《Data Governance: The Definitive Guide》是不錯的参考。
对“未被治理者”的治理
直到最近，数据治理方案主要面向定义清晰、结构化的数据——换言之，治理对象通常是具有明确定义模式（schema）的表或视图。这是因为在分析领域，多数业务需求由源自 OLTP 系统的结构化数据满足。然而，据一些分析师估计，组织中 80%–90% 的数据是非结构化的，例如电子邮件、文本文件、日志、媒体文件等。受限于工具与技术、合规性顾虑以及普遍缺乏相关专业能力，非结构化数据尽管量大，却大多未被有效利用，最终沉积为所谓的“数据沼泽”。
但这一局面正因 AI 的崛起而迅速改变。许多组织对 AI 兴趣高涨，并认识到通过机器学习等 AI 技术利用非结构化数据，能够在数据驱动决策中取得显著优势。AI 正在改善既有业务结果，同时创造新的机会与收入来源。例如，AI 可以分析市场趋势、客户反馈与其他数据，从而发现开发新产品与服务的机会。
说明
本书中所说的 AI，泛指所有高级分析范式，包括预测/处方分析、传统机器学习以及生成式 AI。
非结构化数据使用的增长与 AI 领域的快速发展，为数据治理实践带来了新挑战。以往未被使用的非结构化数据，也就未被治理。如今随着形势变化，数据治理的范围显著扩展，必须覆盖非结构化数据的全生命周期。用于结构化数据的政策与治理模型可能并不适用于非结构化数据，因此需要定义新政策并构建新的治理模型。
此外，组织还会创造除“数据”之外的资产。例如，基于你的数据集训练的 机器学习模型，本身就是从数据中衍生出的、具有内在价值的资产，需要被妥善存储、保护与治理。因此，数据治理还必须将这些我们称之为 AI 资产 的对象纳入范围。长期以来，这些资产几乎一直处于“未被治理”的状态，这种说法并不夸张。
应对日益严格的监管
由 AI 驱动的聊天机器人 ChatGPT 让 AI 在公众中广为人知。在此之前，AI 对多数人而言是复杂且陌生的系统。可以说，ChatGPT 民主化了 AI 应用的认知与使用。这种观念层面的转变产生了网络效应：即便是通常对技术不甚了解、关注滞后于产业发展的监管者也开始重视并着手监管 AI。欧盟已经在 2024 年 7 月发布了 《欧盟人工智能法案》（EU AI Act） ，旨在为欧盟范围内的 AI 建立统一的法律与监管框架。
在 AI 大热之前，企业就已需遵循诸如 GDPR（欧盟通用数据保护条例） 、CCPA（加州消费者隐私法案）等数据隐私法规，以保护个人数据的隐私与安全。这意味着，随着数据规模与用例不断增长，确保遵循现有与即将出台法规的重担，正在影响组织的数据战略与创新空间。因此，建立完善的数据治理架构是必要的。并且，这些法规往往措辞含糊且非技术化，企业需要自行解读并恰当落地。这给组织带来了巨大压力：既要把事情做对，也要避免陷入诉讼风险。
随着治理范围的扩大与监管标准的收紧，现代数据治理解决方案必须能够覆盖所有数据与 AI 资产，并具备快速适配最新合规要求的能力。在进一步讨论治理方案之前，我们将简要回顾数据仓库、数据湖的发展历程，以及数据湖仓（Data Lakehouse） 的曙光。
湖仓一体的曙光（The Dawn of the Lakehouse）
我们花在各种屏幕前的时间与日俱增。工作、人脉、休闲与爱好都越来越多地转移到线上。我们始终在与大量的数字设备交互，而这些设备也在不停地收集数据。即便你不在看屏幕，你的智能手机也在记录你的位置信息，智能手表在采集你的健康数据，你的汽车在存储你的驾驶行为数据。现在，不妨想象一下：全球数十亿人的数据被收集与处理的规模。随着人口增长、数字化加速、技术广泛普及，以及我们越来越倾向于与设备共处而非与自然相伴的生活方式，流入各类数据平台的数据量正呈爆炸式增长。
来自非人类实体的数据——无论有形或无形——也显著增加。我们越来越多地监测与度量一切可度量之物，包括机器、数字与实体产品，乃至自然界及其各种现象。
从组织的角度看，只要能被恰当地利用，数据越多越好。数据助力组织的核心在于：它能提供洞见，帮助做出更优决策，从而带来显著的成本节约与增长机会。节约通常体现为生产率提升与资源浪费减少；增长机会源于基于数据洞见制定的更优战略。因此，多数公司——尤其是技术导向型公司——都意识到了数据的价值，这推动了数据采集相关工具与技术的显著进步。此外，数据本身也逐渐演化为一种产品，并且有时还会作为新的实体产品的原材料——例如智能体温计与智能音箱。
从数据中获取价值（Deriving Value from Data）
数据被采集之后，下一步就是对其进行处理，使其更易被消费并从中获得洞见。被采集的数据通常首先落在与提供该服务的应用相连的某个系统中。例如，你在一家电商网站注册时，所填写的数据会存储在该网站所使用的 OLTP 数据库中。这个 OLTP 数据库可能部署在本地，也可能在云上，取决于这家电商公司的技术成熟度。若数据具备流式特性——即数据持续不断地从各源头（比如 IoT 系统）流入——那么它可能会先落在磁盘、云对象存储，或像 Kafka 这样的消息中间件上。
无论哪种情况，要对大规模数据进行分析处理，都应在与面向客户的应用相互独立的平台上完成。这样可以避免给应用施加过重负载，避免产生影响用户体验的延迟或停机。此外，你还需要具备高效、可靠地存储、处理并发布所衍生数据与相关资产的能力（见图 1-2）。
图 1-2. 数据平台的典型数据源类型与所生成的资产
在更高的抽象层面，你会从人、机器以及其他数据源摄入数据，并产出一系列有价值的资产：文件、表/视图、仪表盘以及 AI 资产。AI 资产包括用于训练机器学习模型的特征表、已训练模型等。
商业智能与高级分析（Business intelligence and advanced analytics）
更进一步地看，在分析领域主要存在两大类用例：
- 报表或商业智能（BI）
- 高级分析
BI 相关用例通常帮助组织从过去与当下获取洞见，以便规划未来。为这些用例摄入与处理的数据通常是结构清晰、模式（schema）明确的表。
而高级分析往往用于预测与处方类用例——关注点更多在未来。为此，组织会采用 AI 技术与方法。此类用例的许多常见数据源呈半结构化或非结构化特性。半结构化数据如日志文件，其格式有一致的模式与可预测的排布，但内容本身灵活可变。非结构化数据则可以是任何文件——例如多媒体文件（MP3、MP4）、图像、纯文本等——它们缺乏预定义的组织结构。当然，这并不意味着 BI 就不会使用半/非结构化数据，或高级分析就不会使用结构化数据。在理想状态下，你应拥有一个能够处理所有数据类型并支撑各种用例的平台（见图 1-3）。
图 1-3. 数据平台的源数据类别与典型用例
大数据的开端（Big data begins）
持续增加的数据量与数据多样性，催生了我们所说的大数据：
大数据是具有高体量（volume） 、高速度（velocity）和/或高多样性（variety）特征的信息资产，它们需要具备成本效益的、创新性的信息处理方式，以实现更强的洞见能力、更优的决策制定与流程自动化。
—— Doug Laney（Gartner）
留意这个定义，你会发现它不仅描述了数据的属性，还强调了对数据进行处理及其创造的价值。我们相信，Doug Laney 在 2001 年提出“大数据”概念时，就已经意识到当时的工具与技术并不足以高效处理大数据，因此才在定义中嵌入了对“创新”的要求。事实也证明，他判断得极为准确。
大数据的“三个 V”——体量、速度、多样性——为存储、处理、分析与管理数据所需的工具和技术带来了创新之路。最初，我们以为体量是驱动创新的主要因素；但最终我们认识到，多样性才是最具挑战的。这是因为许多组织意识到，过去被忽视、常常被清理或归档、从未用于分析的文本、日志、多媒体、二进制等文件中蕴含着巨大洞见。与此同时，机器学习领域的飞速发展，也让数据科学家与机器学习工程师对这些原始数据文件的需求不断增加。因此，用于应对大数据的数据平台工具与技术必须正视多样性，并据此采用全新的方法。这标志着我们在分析语境下处理数据方式的范式转变。
事实上，真正意义上的“超大规模大数据”，只存在于极少数组织中。大多数组织面对的，是异构而并非特别庞大的数据。此外，随着云上 PaaS/SaaS 的普及与“（理论上）无限扩展”的能力，至少在理论层面，体量与速度已经被显著商品化。因此，直面多样性的时机已经到来。
数据仓库与数据湖（Data Warehouses and Data Lakes）
过去二十年，业界的趋势是并行建设两类数据平台：一类支撑 BI，另一类支撑高级分析。前者称为数据仓库，后者称为数据湖。相应地，数据仓库主要处理结构化数据，而数据湖则经常处理半结构化与非结构化数据。
数据集市（data mart）是一个经策划的数据库，包含一组为某个业务单元/部门/团队（如市场、销售、工程）定制的表。它通常比数据仓库更小、更聚焦，常作为企业级数据仓库的一个子集存在。
如果把数据集市看作瓶装水——经过清洗、打包并结构化，便于直接饮用——那么数据湖更像一片处于自然状态的大水体。数据源源不断地汇入湖中，湖的使用者可以前来观察、潜入或取样。
—— James Dixon（Pentaho 前 CTO）
在高层次上，数据仓库与数据湖方案通常都包含四个主要方面：
- 摄入（Ingestion） ：从各类源系统收集数据
- 存储（Storage） ：存储以供处理与消费
- 处理（Processing） ：对数据进行转换与准备以供消费
- 服务（Serving） ：将数据提供给其他系统用于报表、分析等
常见的数据仓库解决方案包括 Microsoft Azure Synapse Analytics、Amazon Redshift、Google BigQuery、Snowflake。它们在可扩展性、性能、易用性、生态集成等方面各有所长，但鲜有在上述所有方面都“面面俱到”的。现代云原生数仓正在逐步替换 IBM DB2 Warehouse、Teradata 等传统方案，主要原因在于现代数仓在灵活性、可扩展性与易用性上显著更优。其中一个关键使能因素是计算与存储分离：二者可分别扩缩与优化，从而大幅提升性能并降低成本。还值得注意的是，某些数仓（如 Snowflake）正在向数据湖方向延展，支持处理半结构化数据。换句话说，现代数仓也在尝试覆盖高级分析用例。
HADOOP：一场“虚假的黎明”（HADOOP: A FALSE DAWN）
回到 2010/2011 年，当 Karthik 在一家金融科技创业公司开始其软件工程师生涯时，公司正在引入一项用于处理金融数据的新技术。它通过利用通用硬件与其分布式文件系统 HDFS 及处理范式 MapReduce，承诺以低成本且可扩展的方式处理大数据。这项技术就是 Hadoop。彼时，Karthik 有幸参与到这项“最前沿”技术的实践中。
Hadoop 为分析领域处理数据带来了急需的范式转变：以可负担的方式存储与处理文件，并支撑借助机器学习开展的高级分析。开源 Hadoop 的流行催生了 Cloudera、MapR、Hortonworks 等公司，主打本地化的 Hadoop 服务。那时，Hadoop 仿佛会“统治”未来几十年，而这些押注 Hadoop 的公司也像抓住了时代良机。
Hadoop 出现之时，确实缺少一种低成本处理大数据的可行方案。你可以将 Hadoop 部署在通用硬件上——把手头一批并不强劲的计算资源拼在一起，就能组成一个 Hadoop 集群。Hadoop 的数据副本与容错特性，让在这些集群上处理大数据成为可能；同时，它还可扩展，可按需增减机器。越来越多的公司因此被吸引，因为他们无需巨额投入就能从大数据中获取洞见。
Hadoop MapReduce 是一种依赖文件系统的“分而治之”技术。在 2010 年代早期，内存昂贵，将文件系统作为主要处理载体确实是“聪明之举”。但这也意味着性能并不理想。尽管如此，Hadoop 至少提供了一个能处理大数据的可行选项，总比什么都没有强。随后，形势发生变化：数据量持续激增，而内存成本下降使得在内存中以更低成本处理大数据成为现实。
快进到今天，Hadoop 俨然成为许多早期采用者急于摆脱的“遗留系统”，理由充分：它难用、不够高效、可靠性不足，并且缺乏安全与治理。不过，Hadoop 之旅的一大“意外之喜”，是催生了为弥补 MapReduce 范式局限而生的 Apache Spark。
云上数据湖（Cloud data lake）
伴随分析型数据平台的演进，过去十年中云服务的采用也显著增长。云厂商的按量计费模式（用多少、付多少）对许多组织而言是“游戏规则改变者”，尤其是无力为本地资源投入巨资的初创公司。
云数据湖允许你以原始/本地格式存放所有结构化、半结构化与非结构化数据。云提供商提供了专门的存储服务，如 Amazon S3、Microsoft Azure Data Lake Storage，你可以在其中以海量规模“倾倒”各种类型的数据。这里一个关键点是：计算与存储解耦。这意味着你可以独立地扩缩存储与计算，并在同一数据存储之上选择多样的计算引擎。尽管云原生数据湖带来诸多好处，但在元数据管理、数据治理与安全方面也存在一些挑战。
数据孤岛与破碎的治理（Data silos and fractured governance）
Karthik 曾在印度班加罗尔生活三年。那是一座机遇丰富、人口多元、气候宜人的城市。过去几十年里，它快速扩张，来自印度各地的人口大量涌入。然而，这种增长并没有与道路、公共交通、排水系统、供水等基础设施的长期规划相匹配。如今，班加罗尔地理范围庞大、人口众多，交通拥堵严重，部分地区缺水，而在强降雨时也易发生内涝。
回看多数组织的数据版图，你会发现它们很像这样一座缺乏规划的城市：系统与数据遍地开花，却缺少清晰的访问控制或安全措施。大型组织可能会为报表/BI 部署一个或多个数据仓库，每年投入数百万美元；同时，数据湖常被当作“数据垃圾场”，用来倾倒那些没人需要或不会用的数据。若再往深处看，你可能会发现一些敏感信息（如 PII）被以不符合内部政策、本地法律，甚至 GDPR 等具有域外效力的法规的方式存储或访问。工程师、科学家与分析师可能并不知道他们所用数据的来源，也不确定其质量是否可靠。
为什么会这样？原因有多方面。对于节奏极快的公司，决策者很少有时间深入评估工具与技术，预算也有限，最终往往东拼西凑多套工具以尽可能低成本地“把事情先跑起来”。这会形成技术债——即为了快速权宜之计所付出的未来成本与后果。几乎人人都计划“很快偿还”技术债，但“很快”往往难以到来。
在拥有多个业务单元的大型组织中，各 BU 往往各选各的工具与技术，且常常面对相似的用例。在一些强监管行业，引入新工具/新技术需要大量审批，也就更难跟上最新进展。而技术变革的节奏显著加快，许多组织难以同步：他们在新用例上用最新工具，却在存量系统上继续沿用旧工具。
导致数据版图“杂乱无章”的另一个常见原因，是自研 vs 采购的权衡。决策者有时会觉得从零构建更合算（例如满足某个细分场景，或基于“自研更省钱”的误判）。工程师也常对“自己造轮子”充满热情。但最终他们会发现，这类“手工制品”难以维护、扩展与定制。相对地，厂商也可能影响企业决策，卖来并不合适的方案。有时，组织也别无选择，只能用不同系统来覆盖所有分析用例，因为并非所有用例都能由单一平台承载。
以数据仓库与数据湖为例：根据用例与源数据性质的不同，需要两套不同的系统。这还可能导致数据重复，因为一些数据集同时为两套系统的用例提供“燃料”。同时拥有不同解决方案意味着要采用不同的治理与安全模型，因为需要治理与保护的数据性质不同：在数据仓库里，你需要对表实施访问控制；在数据湖里，你需要在文件层面施加控制。结果就是运维投入与成本的增加（见图 1-4）。
图 1-4. 为 BI 与高级分析分别使用异构系统所带来的挑战
湖仓范式（The Lakehouse Paradigm）
上一节强调的问题，显然呼唤一个能够覆盖所有用例、处理所有数据类型，并具备统一安全与治理模型的解决方案。湖仓范式正是为满足这一需求而生，并切实满足这些要求。
【定义：数据湖仓（Data Lakehouse）】
一种开放的数据管理架构：融合数据湖与数据仓库的优势，并同时提供统一的治理与安全模型。
湖仓范式旨在提供一个单一平台，以支持：
- 所有与数据相关的工作负载：包括 BI、高级分析等
- 各类数据的存储、处理与分析
- 统一的安全与治理模型
图 1-5. 数据湖仓以统一的治理与安全模型覆盖所有分析用例
湖仓架构（The lakehouse architecture）
尽管“data lakehouse”一词最早有据可查是在 2017 年，但类似架构早已发展多年。诸如 Cloudera 的 Impala、Facebook 的 Presto、Spark SQL 等项目，都尝试在数据湖之上提供高速 SQL 体验——本质上是让数据湖具备类似数据仓库的 SQL 能力。然而，当时的治理模型仍与数仓方案彼此分离。
实现湖仓架构并非易事。如果从零开始，第一步会是什么？你会先选择一种能够以超大规模存放多种数据类型的存储，例如 HDFS、Amazon S3、Azure Data Lake Storage。换言之，即一个能以原生格式（CSV、JSON、MP3、MP4、Parquet 等）存放文件的数据湖。这类存储通常遵循 BASE 一致性模型；而要具备类似数据仓库的能力，你需要 ACID 一致性模型。也就是说，需要一种为数据湖赋予事务能力的解决方案，使之具备类数仓/数据库的事务特性。
注释
ACID（原子性、一致性、隔离性、持久性）与 BASE（基本可用、软状态、最终一致）是数据库系统中两类不同的一致性模型，体现了在分布式系统中对一致性与可用性的不同取舍：
- ACID 优先保证一致性；BASE 优先保证可用性。
- BASE 系统通常更易进行水平扩展。
- ACID 适合需要严格数据完整性的应用；BASE 适合能容忍短暂不一致的系统。
典型 ACID 数据库：MySQL、PostgreSQL；ACID 数仓示例：AWS Redshift。典型 BASE 系统：Cassandra、Amazon DynamoDB 等 NoSQL 数据库。
这一空白由开放表格式填补：Hudi、Apache Iceberg、Delta Lake。它们为数据湖引入 ACID 事务，确保跨操作的数据一致性与可靠性，并在 Parquet 能力之上进行扩展。更准确地说，它们是数据管理框架，远不止“表格式”这么简单。例如，它们支持模式演进（在不破坏既有数据的前提下变更数据结构）、时光回溯（查询历史数据并回滚到先前版本）、以及高效的元数据管理（优化查询性能并降低海量数据集的延迟）。
随后是计算层：如 Apache Spark 这类高性能、海量可扩展的查询引擎，用于高效处理数据；查询引擎运行在与存储解耦的计算资源之上。其上叠加数据处理层，支持批处理、流处理、机器学习与其他高级分析工作负载。最后是并行的安全与治理层，用于确保数据保护与合规：其中关键方面包括访问控制、认证机制、数据加密、数据血缘、审计等（见图 1-6）。
图 1-6. 湖仓架构
湖仓实现的最佳实践之一，可能是 Databricks（成立于 2013 年的数据与 AI 公司）提供的云平台。Databricks 已帮助成千上万的组织采用湖仓架构。因此，本文将以 **Databricks 数据智能平台（Data Intelligence Platform）**为语境，深入阐释湖仓架构理念。
徽章式湖仓架构（Medallion lakehouse architecture）
Medallion 架构（亦称 multihop 架构）描述了一种分层处理的模式：数据在多级处理过程中被递进式改进与富化。该架构常用于 OLAP 工作负载，原因包括：
- 数据在通过不同处理层（校验、转换等）时，保证 ACID。
- 随着经历不同转换阶段，数据质量与可用性逐步提升。典型实现会采用 bronze（原始）/ silver（清洗/校验）/ gold（精选/富化） 等术语来标识数据质量等级。
- 处理完成的数据（通常为 gold 层）以读优化布局存储，从而高效支撑分析型工作负载。
- 流程更顺畅，数据治理更加强化。
图 1-7. 徽章式湖仓架构的示例分层
Databricks 数据智能平台（Databricks Data Intelligence Platform）
Databricks 源自 Apache Spark，最初聚焦数据工程工作负载，随后扩展到数据科学与传统 ML；近年又进入数据仓库与生成式 AI领域，覆盖了全部 BI 与高级分析用例。
Databricks 是一个统一、开放且智能的数据与 AI 平台，使湖仓架构得以覆盖所有数据与 AI 相关用例。
进一步解释如下：
- 借助湖仓范式，Databricks 通过统一平台覆盖所有数据与 AI 用例，从而弥补数据仓库与数据湖各自的局限。
- “统一”同时指对所有数据与 AI 资产生效的单一治理模型。
- Databricks 基于一系列开源技术构建：Apache Spark、Delta Lake、MLflow、Unity Catalog。
- Databricks 借助组织上下文产生的上下文智能，来加速开发（如代码辅助与调试），并在存储布局、计算配置等方面进行优化。
图 1-8. Databricks 数据智能平台的核心组件
以下对这些核心组件逐一展开：
- 云数据湖（Cloud data lake）
面向所有结构化/非结构化数据与 AI 资产的高性价比对象存储。 - 开放表格式（Open table formats）
构建在云对象存储之上的开源、优化的存储层，支持 ACID 事务、可扩展元数据管理，并统一流批处理。Databricks 以 Parquet 起步，随后推出 Delta Lake，并逐步扩展对 Apache Iceberg 与 Hudi 的支持。 - Databricks Unity Catalog
内建于 Databricks 平台的统一目录与治理能力：包含元存储、搜索与发现（数据与 AI 资产）、访问控制、血缘、审计日志等一系列高级治理特性。 - AI 引擎（AI engine）
嵌入 Databricks 平台的智能引擎，利用组织上下文加速开发（编码与调试支持），并在存储布局、计算配置等方面进行智能优化。
凭借上述能力，Databricks 平台可以承载所有数据与 AI 工作负载——也就是说，它服务于现代数据团队的全体角色：数据工程师、数据科学家、数据分析师、ML 工程师与 AI 工程师。
Databricks Unity Catalog：实现统一治理
Databricks 于 2021 年的 Data and AI Summit 上发布了 Unity Catalog。2022 年 4 月，Unity Catalog 在 Azure 与 AWS 上开启受限公测（gated public preview）。我们在 2022 年加入 Databricks 时，Unity Catalog 在企业采用方面尚处于起步阶段。元存储、与身份管理系统的集成、粗粒度访问控制等核心治理能力已经可用，但许多高级特性仍在开发中。作为一线工程师，我们见证并参与了上千家组织采纳 Unity Catalog 的历程，也亲历了它的快速演进。如今，它或许是唯一能够为所有数据与 AI 资产提供统一治理的解决方案。接下来，让我们深入了解 Databricks Unity Catalog，看看它能带来什么。
Unity Catalog 简介
Karthik 记得曾与一家大型零售组织的关键决策者（这里称他为 Bob）交流。该组织已将 Databricks 作为其核心数据平台。在 Unity Catalog 之前，Hive Metastore（HMS）被用作存储在 Databricks 上所有数据资产的元数据仓库。Bob 说服其部门的全部干系人，从传统的 HMS 迁移至 Unity Catalog。他提到，许多数据团队的同事一开始并不理解 Unity Catalog，以为它只是另一个替代 HMS 的目录，因此觉得把全部数据资产迁移到 Unity Catalog 的投入不值得。最终，Bob 澄清：Unity Catalog 远不止是一个“目录”。它内建了稳健的治理能力，可简化数据安全与访问，是 Databricks 平台不可或缺的组成部分。Bob 对他们说：“Unity Catalog 不仅仅是目录，它是 Databricks 的进化。 ”
【定义：Apache Hive】
Apache Hive 是面向 Hadoop 的分布式数据仓库与 SQL 查询语言。它允许用户使用标准 SQL 查询处理存储在云存储（AWS S3、ADLS、GCS）或本地 HDFS 上的大型数据集。
Bob 的看法完全正确。Unity Catalog 简化了在 Databricks 中存放或通过 Databricks 访问的数据的治理。此外，它是 Databricks 平台的核心组成，是平台运转的前提，因此也可称为运行时目录（operational catalog） 。同时，它还是统一且开放的解决方案，原因如下：
统一（Unified）
- 作为 Databricks 平台的一部分，Unity Catalog 可运行在各大云厂商之上。因而，只要 Databricks 纳入其多云战略，组织便可在其全部数据平台上维持统一治理。
- Unity Catalog 支持多种开源湖仓表格式：Delta、Apache Iceberg、Hudi，以及 CSV、JSON、Parquet 等，从而为所有数据格式提供统一治理。
- Unity Catalog 为所有数据与 AI 资产提供单一治理模型。
开放（Open）
- Unity Catalog 开源，可避免厂商锁定。
- 凭证下发（credential vending）使外部引擎可通过 Unity Catalog REST API 获取临时访问受 UC 治理的数据与 AI 资产，从而实现互操作性。
- 目录联邦（catalog federation）进一步增强互操作能力，支持与业界其他目录（如 AWS Glue）进行元数据交换。
注意
Unity Catalog 是开源的，可在任何云或本地环境中独立于 Databricks进行安装与使用。Databricks 也提供托管版 Unity Catalog，它是 Databricks 平台的核心部分。此外，平台中的其他组件让整体能力更加完备。简而言之：Unity Catalog 开源软件（OSS）是一个统一的数据与 AI 目录；而 Databricks Unity Catalog 是在 Databricks 上实现的数据与 AI 资产统一治理方案。
在 Databricks 语境（以及略超出该语境）下，Databricks Unity Catalog 是一套治理解决方案。它并不包含某些传统数据治理工具提供的全部功能（如数据保管人工作台、合规报表等）。不过，其中一些能力（例如合规报表）可以基于 Unity Catalog 的特性与元数据进行定制开发。Unity Catalog 还能与数据生态中的其他工具良好集成。许多组织会配合使用 Collibra、Alation、Atlan 等企业数据目录来满足全组织范围的数据治理需求。
数据与 AI 资产的访问控制
Unity Catalog 的治理模型包含对数据与 AI 资产的访问控制——换言之，即 Unity Catalog 所保护的对象（见图 1-9）。
图 1-9. 在 Unity Catalog 中，可对数据与 AI 资产同时施加访问控制
数据与 AI 资产包括：
- Tables（表） ：按行列组织的数据集合。
- Views（视图） ：基于一个或多个表/视图创建的只读对象。
- Volumes（卷） ：由任意文件组成的逻辑实体。
- Models（模型） ：使用 MLflow 框架打包的 AI 模型。
- Functions（函数） ：由用户定义并保存的逻辑单元，返回标量值或一组行。
- External catalogs/databases（外部目录/数据库） ：可引入自有数据库、数据仓库或目录，如 AWS Glue。
核心治理功能
先来看 Unity Catalog 为数据与 AI 资产治理提供的核心功能：
- 认证（Authentication）
与 Microsoft Entra ID（原 Azure AD） 、Google、Okta 等外部身份提供商集成，用于身份认证。 - 数据编目（Data cataloging）
提供元存储（metastore） ，对全部数据与 AI 资产进行编目。 - 授权（Authorization）
对身份主体进行授权，以控制访问数据与 AI 资产。 - 数据可发现性（Data discoverability）
已编目的数据与 AI 资产及其元数据（如标签）支持自然语言搜索。 - 审计日志（Audit logs）
对编目对象的各类操作会被自动记录并可用。 - 血缘（Lineage）
对表、视图、卷与模型等所有数据与 AI 资产自动生成并可在 Databricks 平台内访问数据血缘。
高级治理功能
借助 Unity Catalog，Databricks 平台内可解锁下列高级治理能力：
- 细粒度访问控制（RLS/CLM）
支持对表实施行级安全（Row-Level Security, RLS）与列级脱敏（Column-Level Masking, CLM） ，常用于涉及敏感数据的用例。 - 基于属性的访问控制（ABAC）
基于身份、资源、请求等属性进行条件式访问控制。ABAC 能力更强、可扩展性更好，便于满足复杂治理需求。 - 质量监控（Quality monitoring）
以自动化方式在表级监控数据的统计属性与质量。一旦数据集出现异常或问题，可通知相关干系人并帮助及时修复。
后续章节将对 Unity Catalog 的每项特性做深入讲解，并给出最佳实践与示例。
Databricks 平台架构（Databricks Platform Architecture）
我们将 Databricks Unity Catalog 描述为一套治理解决方案，但若要从系统架构角度理解它，就需要先介绍 Databricks 平台本身的架构。
在高层视角下，Databricks 平台包含四个主要组件。最重要的组件是你——也就是访问平台的用户与应用。平台自身则分为第二与第三个组件：控制平面（control plane）与计算平面（compute plane） 。最后一个组件是存储层，用于持久化你的全部数据与 AI 资产。见图 1-10。
图 1-10. Databricks 平台的高层与简化架构
控制平面（Control plane）
你与平台交互时接触的第一个接口就是控制平面。平台的关键服务都运行在这里：包括Web 应用、用于计算实例编排的服务、Unity Catalog 服务等。该层负责用户认证与授权。即便通过 API 与平台交互，控制平面也始终是第一接触点。
计算平面（Compute plane）
所有计算处理都在计算平面完成。换言之，所有工作负载都运行在计算平面；其中大多数运行在 Apache Spark 集群上。集群由若干计算实例构成，包含一个 driver 节点和零个或多个 executor 节点，通过 Apache Spark 框架执行工作负载。Databricks 在所有计算实例上提供经精选配置的**Databricks Runtime（DBR）**运行环境。
注释
Apache Spark 长期以来都是 Databricks 平台产品的核心组成。但也有一些最新的 Databricks 产品能力（如模型服务或微调服务）并不使用 Spark。
Unity Catalog 的组成（Unity Catalog components）
下面从 Databricks 平台内部结构出发，剖析 Unity Catalog。当我们称 Databricks Unity Catalog 为治理解决方案时，可以把它视为 3 个主要组件的组合：UI、Unity Catalog 服务、DBR。
- UI
Unity Catalog 的 UI 嵌入在 Databricks UI 中。你可以在其中发现数据与 AI 资产、创建这些资产、控制访问、打标签、监控等。 - Unity Catalog 服务
运行在 Databricks 平台控制平面中的核心组件，负责落实各类治理功能。例如，当用户对受 Unity Catalog 编目的资产发起查询时，UC 服务会校验该用户是否拥有访问权限并据此响应。Unity Catalog REST API 也属于该服务的一部分。 - Databricks Runtime（DBR）
运行在所有 Databricks 管理的计算实例上的核心软件工件集合，经专门设计并持续更新，以显著提升工作负载的性能与安全性。Unity Catalog 的部分治理能力在 DBR 层面实现——例如细粒度访问控制是在计算侧执行的，因此 DBR 起着关键作用。要在 Databricks 中使用 Unity Catalog，需要满足最低 DBR 版本；而某些新功能还要求升级计算实例使用的 DBR 版本。
注释
在 Databricks 计算实例上使用 Unity Catalog 需要 DBR 11.3 或更高版本。但建议至少使用 DBR 13.3（长期支持 LTS）或更新版本，因为该 LTS 版本增加了许多重要的 UC 功能。总体建议：始终选择最新的 DBR LTS 版本，以获得最新的受支持功能。
数据共享与协作（Data Sharing and Collaboration）
现代治理的一个重要方面，是必须考虑边界之外的需求。此前我们看到，治理最大挑战之一在于打破组织内部的孤岛并促进协作。产生孤岛/边界的原因很多：组织结构、地域差异，以及数据战略中固有的因素（如多云架构），还有监管要求、历史原因，甚至内部政治。无论原因如何，治理方案的设计都应兼顾各个独立实体（团队、部门、业务单元）的需要，并寻求在至少部分方面实现统一与标准化。
设想一下：彼此在运营上相互独立的各个实体拥有一套共同语言，可以与其他实体顺畅沟通。换言之，他们获得一个统一接口与相似流程，基于共同的技术栈在组织内外共享与消费数据与 AI 资产。并且，即便跨越边界进行共享，他们仍能保持质量并实施治理。这将使组织能够实现标准化且协作的治理路径，甚至在大型组织内落地如 Data Mesh（数据网格） 之类的数据架构。
这在 Delta Sharing 的帮助下成为可能。Delta Sharing 是一种开放协议，用于安全的数据共享。由于它是开源的，你可以将其独立部署与使用；在 Databricks 上，它以托管方式提供，并且需要 Unity Catalog。换言之，在 Databricks 平台上，Unity Catalog 通过 Delta Sharing 实现安全数据共享。Delta Sharing 协议就像是不同实体可以采纳并利用的数据共享“共同语言”。基于此，各实体可以定义相似的流程，而 Databricks 则成为贯穿全局的共同平台。
Delta Sharing 也是 Databricks 其他协作型产品的基石，即 Databricks Marketplace 与 Databricks Clean Rooms。
- Databricks Marketplace：一个开放的“发布/消费数据产品”的市场，界面友好，面向业务用户。
- Databricks Clean Rooms：组织内外不同实体之间进行协作的安全私有空间。Clean room 提供一个可在不牺牲隐私与安全的前提下组合含敏感信息数据集的环境。
第 8 章将进一步深入 Delta Sharing、Databricks Marketplace 与 Databricks Clean Rooms。
总结（Summary）
本章阐明了为什么治理至关重要：随着数据体量与多样性及其应用场景不断增长，保障与治理数据的重要性也随之提升。现代问题需要现代化的数据解决方案——我们看到，将数据仓库与数据湖能力统一的诉求，催生了数据湖仓。作为湖仓实现的最佳范例，Databricks 平台及其核心组成 Unity Catalog，显著简化并统一了数据与 AI 的治理。
接下来的章节将覆盖 Unity Catalog 的各个方面，以及 Databricks 平台的部分能力。我们会引入一个虚构组织 Nexa Boutique（NB） 作为贯穿示例，帮助读者更好地理解。现在，让我们在 Databricks 平台的语境下，开启对湖仓范式、Unity Catalog 与 Delta Sharing的探索之旅吧。
