在第一部分（Part I）中，我们探讨了 Medallion 架构的分层设计——Bronze、Silver、Gold。每一层都承担关键角色：将数据从 Bronze 层的原始态逐步转化为 Gold 层可被消费的精炼形态。在该部分中，我们也强调了健壮数据模型的重要性以及精确业务需求的收集，突出二者之间的紧密关联。
我们将继续深入这些主题，同时把重心转向实践：通过一个端到端的动手实现教程来应用所学。一家虚构公司即将开启数据新征程，将作为实践示例。该场景会一步步引导你构建自己的 Medallion 架构，并包含可运行的代码片段与配置要点。
NOTE
即便你并不打算亲自跟做本教程，第二部分（Part II）依然值得阅读：书中贯穿的考量、最佳实践与模式能够提供大量价值。
为什么主要采用与厂商无关、可移植的方案？目前在公共领域，关于端到端落地 Medallion 架构的实操示例仍相对稀缺。许多资料要么太理论、太宏观，要么只聚焦某一环节，导致从业者难以在真实端到端场景中套用。我的目标是通过这份完整的循序实现指南弥合理论与实践之间的鸿沟。
在整个练习中，你将主要以 Microsoft Fabric 为例。尽管还有其他服务可选，但沿着 Fabric 的流程走一遍，能获得可迁移到其他平台的技能与基础理解。
创新更新迅速，服务与功能不断变化。因此我聚焦于成熟且可移植、不易剧变的能力，例如 Apache Airflow、（Azure）Data Factory、Spark、PySpark 与元数据驱动方法。这些工具通用、跨环境适配。事实上，本书所有代码片段我已在其他基于 Spark 与 Delta Lake 的服务上测试过，同样有效。
TIP
你也可以用 Azure Databricks 完整走完学习路径。包含 Unity Catalog 在内的详细搭建指南见我的博客；你也可考虑直接跳到第 5 章。
无论选择哪条路径，本书的学习方法在很大程度上都是厂商无关的。因此，我们讨论的原则、最佳实践与代码同样适用于采用 Spark 与 Delta Lake 的其他厂商。贯穿全书的主线是 Medallion 架构，它提供了通用基础。
本章将从搭建基础设施开始这段实践旅程；随后在第 5、6、7 章中按顺序构建各层：先 Bronze，再 Silver，最后 Gold。
不过，这份指南远不止“照做步骤”。每一组步骤之后，我们都会暂停反思：讨论 Medallion 架构在更广阔语境中的定位、可选方案等，帮助你深化理解。
我们的案例：Oceanic Airlines
在探索 Medallion 架构时，我们以一家虚构公司 Oceanic Airlines 为例。该公司拥有庞大的航线网络，正计划通过构建新一代湖仓（lakehouse）架构来升级其数据管理体系。
这项计划从一系列业务工作坊启动，参与者涵盖 IT、运营、客服与财务等部门干系人。工作坊帮助识别新架构的具体数据诉求与期望。在权衡多种选项后，Oceanic Airlines 决定在其方案中采用 Microsoft Fabric（见图 4-1）。
图 4-1 高层架构设计示意图：拟议方案
接下来我将引导你搭建基础。我们会从 Microsoft Fabric 的部署与配置入手，并给出在 Bronze 层中高效摄取数据的设计考量与最佳实践。循序渐进的步骤能为你的数据架构打下坚实地基。
认识 Microsoft Fabric
Microsoft Fabric 是一个 SaaS 模式的数据与分析平台，面向工程师、数据科学家与业务分析师提供协同环境，支持 Apache Spark 与 Delta Lake 等常见技术。
与许多数据服务类似，Fabric 提供托管的 Web 界面，并与 Microsoft Entra ID 等服务集成。例如，通过 Entra ID，用户可使用个人账户登录 Fabric，并可配置多重身份验证与其他安全措施。
图 4-2 展示了 Fabric 的欢迎界面，它将不同的功能体验整合到同一平台。我们先从 域（Domains） 、工作区（Workspaces） 与算力容量（Capacities） 等核心组件开始。
图 4-2 Microsoft Fabric 的各类体验：数据转换、分析、洞察生成，以及可视化与报表能力
域（Domains）
随着数据的爆炸式增长，组织更加重视面向场景的组织与治理。Fabric 通过 域 来促进从集中式向分布式数据管理的转变。
在 Fabric 中，你可以将与某个组织单元（如部门或业务项目）相关的制品与数据归拢在同一域下。例如，可分别为销售、财务、市场建立独立域，以保持隔离，确保数据完整性与安全。
需要注意：域是 Fabric 中最高抽象层，采用授权委派模型。各业务单元可按需制定自身规则与限制。将数据分组到域时，会将其与工作区与容量进行关联。
工作区与容量（Workspaces and Capacities）
工作区（Workspace）是 Fabric 中的协作环境，数据从业者可在此创建和共享各类条目，例如 Lakehouse、Warehouse、Notebook 与报表。每个工作区隶属单一域，并向终端用户发布制品（如在 Power BI 中创建与使用仪表板与报表）。这种以工作区为中心的协作与共享方式，与 Azure Databricks、Synapse Analytics 等服务的做法相似。
在基础设施侧，每个工作区都关联一个容量（Capacity） ——可理解为一组通用计算资源池。在 Fabric 中，容量同时也扮演许可证角色：为各种活动分配所需资源池。换言之，你购买一定数量的计算力（以 Capacity Units 计量）。
容量有不同规格/SKU（如 F2、F16、F64），支持订阅制或按量付费（可创建容量、运行负载、然后暂停容量）。这些容量托管在你的 Azure 租户中，由 Microsoft 全权托管，底层虚拟机对用户不可见。一个容量可分配给一个或多个工作区（见图 4-3）。
图 4-3 Azure 租户、Fabric 容量与 Fabric 工作区之间的关系
OneLake
OneLake 是 Fabric 的主存储层，底层采用 Azure Data Lake Storage (ADLS) Gen2，并以 Delta 表格式为默认存储格式。
当在租户级启用 Fabric 后，OneLake 会在所有工作区自动可用，便于不同类型的计算工作负载访问同一份数据。这对 Lakehouse 与 Warehouse 等基于 Delta 的引擎尤其有用。存储层同时与 Power BI 集成，可分析大数据集；从 Spark 到 Power BI 的工具链无需复制数据即可协同——例如，数据工程师在 Lakehouse 中创建 Delta 表后，Power BI 开发者即可即时用于报表。
OneLake 还提供轻量级的数据虚拟化层，可创建指向其他存储位置的Shortcut（快捷方式），目标既可以在 OneLake 内，也可以在外部（如 Azure 或 AWS）。
除了 Shortcut，Fabric 还提供镜像（Mirroring）功能，用于实时复制数据库快照。例如，图 4-4 展示了对 Cosmos DB 与 Azure SQL Database 等的镜像。镜像能几乎实时同步副本，并将其以 Delta 格式存入 OneLake，开箱即用。其思路与**变更数据捕获（CDC）**类似。
简言之：Shortcut 适合连接 Delta Lake、Iceberg 等开放格式的数据；而Mirroring 更适用于 Azure SQL 等专有格式。图 4-4（参考自 James Serra）展示了 OneLake 如何连接到不同来源。
图 4-4 参考图：Microsoft Fabric OneLake 连接多种来源的方式（James Serra）
OneLake 是 Fabric 生态中的统一存储层，并与工作区集成，使用户能够在不同类型的工作负载中访问与操作数据。后续小节我们将进一步介绍这些工作负载类型。
使用 Spark 进行数据工程（Data Engineering with Spark）
数据工程（Data Engineering）是 Microsoft Fabric 的核心工作负载类型之一。在这一体验中，用户可以利用 Apache Spark 来处理分析项目中的数据，覆盖数据集成、数据仓库、数据科学与商业智能等场景。我们将在构建 Medallion 架构时主要使用该工作负载类型，因为 Spark 是数据处理与分析的热门之选。
在数据工程体验中（见图 4-5），有一种称为 Lakehouse 的条目/实体类型，用户可在其中存储与管理数据。
图 4-5 数据工程工作负载总览：可立即访问 Lakehouse、Notebook、Environment 等条目
借助 Lakehouse，Microsoft 省去了手动创建存储账户、容器与文件夹结构的步骤。要开展数据工程，只需创建一个 Lakehouse（或 Warehouse） 并开始处理数据。平台会在后台自动配置所需资源与 SQL 端点并替你托管基础设施。
NOTE
Microsoft Fabric 的 Lakehouse 实体用于构建湖仓架构，但二者并非完全同义！Lakehouse（湖仓）是一种融合数据湖与数据仓库要素的现代数据架构（见第 1 章）。而在 Microsoft Fabric 中，Lakehouse 实体是该生态内的一种具体实现形态，包含存储、SQL 端点与其他配置项。也就是说，Lakehouse 实体是在 Fabric 内构建湖仓架构的载体。
在 Microsoft Fabric 中，Lakehouse 实体是不同类型数据（结构化与非结构化）的共享环境。它支持存储与管理 CSV、XML、JSON、Parquet 等多种格式；而通过平台创建的表默认采用 Delta Lake 格式。重要的是：Lakehouse 的所有底层数据都存放在 OneLake 中，因此可被其他工作负载或用户共享。
你可以通过数据工程体验访问与操作 Lakehouse，其界面与其他基于 Spark 的服务类似。在这里，你可以编写 Notebook、创建表并执行 Python 代码。该体验与托管的 Apache Spark 计算平台集成，一切都运行在无服务器（serverless）的 Spark 池上。
Lakehouse 实体还支持Schema（模式）的创建，这与其他 Spark 系服务管理 Schema 的概念相似。Schema 便于将表分组组织，提升数据发现与访问控制的粒度；同时也可用于按数据源分区上架、隔离特定活动，或在一个 Lakehouse 实体内部引入子层。例如，你可以创建一个 oceanic 模式，并将相关表移入其中，便于统一访问。以下示例展示了在 Lakehouse 中使用 Python 在某个 Schema 下创建表：
df.write.mode("Overwrite").saveAsTable("oceanic.sales")
Lakehouse 层面也提供安全控制：你可以将权限授予特定用户或用户组，仅暴露某个 Lakehouse 或其中对象，而无需开放整个 Workspace 及其组件。
Lakehouse 实体还与 Fabric 的生命周期管理集成。它们存放元数据与数据本身，Workspace 中的其他对象可以引用这些内容。比如，你可以将一个 Lakehouse 实体接入代码仓库（Azure DevOps 或 GitHub），通常只跟踪元数据，不纳入实际数据。
概括来说，Lakehouse 将 Spark、SQL 端点、文件存储与基于 Delta 的表与 Schema打包为一个一致的实体。接下来看看另一种工作负载类型：数据仓库（Data Warehousing） 。
使用 T-SQL 的数据仓库（Data Warehousing with T-SQL）
Warehouse 实体与 Lakehouse 类似，但提供了独立的数据仓库工作负载，你可以在其中开发与执行 SQL 脚本。与 Lakehouse 一样，Warehouse 的数据也存储在 OneLake 中，并使用同样的 Delta 格式。
Lakehouse 与 Warehouse 的关键差异在于处理引擎。¹ Warehouse 采用分布式处理引擎，通过 T-SQL（SQL 语言的专有扩展）来支持多表事务。T-SQL并不适用于 Apache Spark；而 Spark SQL 是 Spark 的一个模块，用于以交互式 SQL 查询处理结构化数据。
当你的数据处理需要复杂事务，或者工程师团队更熟悉 T-SQL 时，Warehouse 可能是更佳选择；若团队更擅长 Spark，或你更看重互操作性与开放标准，则应优先考虑 Lakehouse。
Fabric 的 Warehouse 旨在跨多张表管理复杂事务，虽然其语言与处理引擎不同于 Spark Lakehouse。同时，仓库引擎会借助V-order 优化来提升表的读取性能。理解这些差异，有助于你为具体需求选择合适的工具。下面继续了解 Fabric 的其他工作负载类型。
其他 Fabric 工作负载类型（Other Fabric Workload Types）
Lakehouse 与 Warehouse 与 Fabric 的其他工作负载深度集成。例如，Data Factory 工作负载可用于编排与自动化数据搬运与转换；Real-Time Intelligence 工作负载可实时接入来自 Azure Event Hubs 或 Azure IoT Hub 的数据，然后将其处理并写入 Lakehouse、Warehouse 或 KQL（Kusto Query Language）数据库（更适合实时/时序数据）。这类集成也扩展到 Power BI 或 Fabric Data Science：例如 Notebook 体验内置 Data Wrangler，可用于数据准备并生成 Python 代码，进一步服务于 Lakehouse 或 Warehouse。
各个工作负载面向不同的数据处理需求，具备各自能力，但所有处理引擎都与默认采用 Delta 表格式的 OneLake 存储架构无缝集成。这让你可以在不同工作负载间直接复用数据而无需复制，有时也称作 zero-ETL 方法。
接下来，我们将动手搭建平台的基础设置，即实现 Medallion 架构所需的底座。
奠定基础（Setting Up the Foundation）
回到我们的 Oceanic Airlines 示例。开始使用 Microsoft Fabric 的第一步是部署它，这需要一个 Azure 订阅：
- 登录你的 Power BI 租户：
https://app.powerbi.com。 - 点击右上角 Settings（设置） 。
- 在 Governance and insights（治理与洞察） 部分选择 Admin portal（管理门户） 。
- 前往 Tenant settings（租户设置） ，在设置区域顶部找到 Microsoft Fabric。
- 展开 Microsoft Fabric 选项并启用。
启用后，你可以决定 Fabric 是对租户内所有人开放，还是仅对特定安全组用户开放。更详细的指导可参考 Microsoft 文档以及图 4-6。
启用 Microsoft Fabric 后，可访问 https://app.fabric.microsoft.com。你将看到 Microsoft Fabric 的欢迎页。
图 4-6 Microsoft Fabric 管理开关：供使用 Power BI 的组织启用 Fabric
要充分使用 Fabric 的全部功能，你还需要相应的容量（Capacity） 。
配置容量（Setting up Capacities）
为了体验 Fabric 功能，你可能可以从试用期开始。在 Help and support（帮助与支持） 设置中查看是否有类似“Users can try Microsoft Fabric paid features”的试用选项。试用有助于零成本评估能力。
若要购买，登录 Azure Portal 并创建一个新的资源组。进入 Azure Marketplace 搜索 Microsoft Fabric，选择合适的 Fabric SKU（本练习选用 F4，性价比高），并部署到新建的资源组。此方式可让你将 Fabric 无缝集成进工作流。
配置域（Setting up Domains）
进入 Admin portal，点击 Domains 选项卡。选择 Create new domain，在弹窗中输入新域名（例如 “Sales”），指定域管理员，然后点击 Create。
域创建完成后，在左下角找到 Microsoft Fabric 图标。点击该图标可在不同的体验之间切换。本教程请选择 Data Engineering。
配置工作区（Setting up Workspaces）
选择 Data Engineering 后，页面将刷新，左侧会出现 Workspaces。在此创建三个工作区：开发（dev） 、测试（test） 、生产（prod） 。为每个工作区选择包含 Fabric 容量的授权模式（如 Trial 或 Premium），并将这些工作区关联到你的 Sales 域。
TIP
若要在环境间推广工件并实施 CI/CD，请参阅 Fabric 文档中的部署管理。
选择新建的开发工作区。打开后它是空的，可以开始你的项目。接着进入 Workspace settings，启用 Users can edit data models（见图 4-7）。对另外两个工作区重复此操作。
图 4-7 数据模型编辑功能（最后一个复选项）：允许你通过 Power BI 语义模型在 Lakehouse 内为表建立关系
启用后，你就能在第 7 章构建语义模型时，用 Power BI 语义模型为 Lakehouse 中的表创建关系。
创建 Lakehouse（Creating Lakehouses）
工作区准备就绪后，在开发工作区中创建一个 Lakehouse 实体用于存储与管理将进入 Medallion 架构的数据。
前往 Data Engineering 首页，新建名为 “Bronze” 的 Lakehouse，创建时勾选 Lakehouse schemas。约 20 秒后 Lakehouse 准备就绪，初始为空。在 Tables 下会看到一个默认的 “dbo” 模式（schema），这是固定存在的，无法更改或删除。
按同样步骤再创建两个 Lakehouse：Silver 与 Gold。它们分别对应 Medallion 架构的三层存储。完成后，界面应类似图 4-8。
图 4-8 工作区总览：展示三个 Lakehouse 层
在单个 Lakehouse 实体内创建多个 schema（逻辑表分组）是最佳实践，主要用于更好的组织管理与安全控制。这样还能避免命名冲突：你可以在不同层中使用来自各源系统的同名表。
至此，你已为 Oceanic Airlines 成功搭建了基础服务：容量、域、工作区与 Lakehouse。回顾一下我们完成的步骤与设计：
- 容量（Capacities）
你首先创建了运行工作负载所需的容量。容量是获取数据处理作业所需计算资源的关键。 - 域（Domains）
你为 Oceanic Airlines 创建了 Sales 域。域是主要的管理边界，用于管理某一业务板块的所有数据相关项目。 - 工作区（Workspaces）
你在 Fabric 中建立了用于数据处理作业的 Dev/Test/Prod 三个工作区，并将它们关联到 Sales 域，从而确保数据与工件在同一业务单元内集中管理。 - Lakehouse 资源
你部署了 Bronze/Silver/Gold 三个 Lakehouse 条目——它们代表不同的数据处理与精炼阶段，是你的数据架构骨干。
接下来的小节将讨论容量、域与工作区的设计考量，然后再谈 Lakehouse 与 Warehouse。同时也会关注存储账户，因为其他基于 Spark 的平台仍依赖它们进行数据存储。理解这些设计要点之后，我们将开始接入第一批数据源。需要注意的是，Azure Databricks 与 Synapse Analytics 也采用类似概念，因此你在此获得的知识可迁移到其它数据平台服务。
容量考量（Capacity Considerations）
在设置 Fabric 时，选择合适的计算资源来运行数据处理作业至关重要。本练习选用的 F4 SKU 适合简单的批处理 ETL（不涉及宽表大规模 shuffle）且服务于少量用户。
随着需求扩大，可考虑部署多套容量以更高效应对不同类型的工作负载：例如为日常任务配置标准预留容量，同时为临时/轻量作业配置更小且按需计费的容量。通过在不同集群间分摊工作负载，你可以同时优化成本与性能，并让架构更弹性以应对演进中的需求。
域考量（Domain Considerations）
在 Fabric 的初始设置中，你已经创建了第一个域。域是组织层面的逻辑分组，用于在某个职能或业务领域内承载所有相关工件和数据（例如 notebooks）。对于大型组织而言，这能按业务能力/职能/部门来分组数据，便于依据各自法规、限制与需求来治理。
以 Oceanic Airlines 为例，它在多个业务单元拥有众多团队，如机场管理、行李管理、销售、财务、市场、运营等。此时，一个域可以代表一个部门（如 Sales）。域的用户与工作区管理权限可委派给指定的域管理员或贡献者。域还可设子域，例如 “Sales” 下细分为 “Sales Consumers” 与 “Sales Businesses”。
企业所需域的数量并无定式：有的公司业务域繁多且差异大；有的公司规模较小或在大规模数据管理方面尚不成熟，可能选择较少的域，由更大的团队负责更多数据集。我们会在第 11 章结合架构扩展再深入讨论。
需要强调：域主要用于分隔管理/行政职能，并不直接决定谁能访问数据或其他工件。安全与访问管理是在其他层面处理的，下一节将继续探讨。
工作区（Workspace）方面的考量
在 Microsoft Fabric 中，**Workspaces（工作区）**至关重要，它们是协作中枢：用户在其中进行数据接入、数据工程、机器学习、数据发现与报表等各类活动。对工作区中工件的管理并非 Fabric 独有；Synapse Analytics 与 Azure Databricks 等服务也采用了类似的工作区范式来简化运维、提升效率。
工作区会连接到特定的 Region（区域） 、Capacity（容量）以及版本控制系统，这些连接对代码与工件的管理至关重要。将工作区绑定到某一容量（而容量本身绑定到某一地区）即可实现就地存储，从而确保所有数据与工件存放在指定地区。这对需要遵循严格“数据地域隔离”法规的跨国企业尤为重要。比如，若业务部门必须在欧洲与美国之间分隔数据，使用多个工作区即可有效满足该诉求。因此，一个业务域在多地部署本地化平台实例时，可能会运行多个工作区。³
正如你已了解到的，工作区需要绑定容量。在多个工作区之间有策略地对齐与分配容量，能进一步提升效率：例如，用同一个容量单元承载多个团队的开发工作区；或为高负载的生产环境配置专属容量。增加工作区数量，也是一种在同一业务域内优化与隔离计算密集型工作负载的有效方式。
工作区还会集成版本控制系统，用于管理部署流程并在开发 / 测试 / 生产阶段实现关注点分离。建议各阶段都拥有独立工作区，这对 CI/CD 管道尤为重要。对于 Medallion 架构，将所有代码与工件（如 Lakehouse）放入单一工作区通常更便于管理。你也可以按层拆分到不同工作区，但这会让 CI/CD 变复杂，因为你需要同时管理多个工作区及其工件。
与其他基于 Spark 的服务类似，工作区也是安全边界，用来管理权限与角色（如 admin、member、contributor、viewer），每种角色都具备特定权限与限制。工作区还能隔离活动或分发数据。例如，在生产环境中新建一个工作区，并通过只读的 shortcut 指向其他工作区，为特定用户提供受限的探索性访问，从而促进团队间数据共享。
此外，工作区还附带托管身份（Managed Identity） ，以便安全访问其他服务。比如，一个新建的工作区可以限制仅与某些架构组件通信（如连接到本地数据源的 VNet）。这对需要严格数据隔离或具备特定数据治理要求的组织尤其有用。
使用多个工作区还有其他好处：为不同团队设置独立工作区，可通过环境隔离来增强专注度与安全性。我常见的一类场景是：一个团队负责所有数据接入与落地（因为接入环节复杂度高），数据经清洗与整理后再供其他团队使用；这些团队通常在各自的工作区中专注其项目（见图 4-9）。
图 4-9 由单一团队负责全部数据接入与落地（小型组织中较常见）
在我们的示例中，Oceanic Airlines 起初在单一工作区内管理所有数据处理作业，工程师在其中开发与协作。随着组织扩张与项目增多，你可能会新增多个工作区（例如专门用于测试与生产），以便更有效地管理不同项目与团队，契合增长与演进中的需求。我们将在“Medallion 架构数量”章节再回到这个话题。
Lakehouse 实体方面的考量
本章开头简要介绍了 Lakehouse 与 Warehouse，它们是 Fabric 中结构化数据存储的关键工作负载实体，也是构建 Medallion 架构不可或缺的组件。典型的 Medallion 架构包括三层/区域，每层对应不同的数据质量等级——层级越高，数据质量越高。
在 Microsoft Fabric 中，最佳实践是每一层对应一个独立的 Lakehouse 实体。这要优于在单个 Lakehouse/Warehouse 中用多个 schema 来承载所有层。原因在于，独立的 Lakehouse/Warehouse 自带独立的 SQL 端点，便于更细粒度地控制不同端点的访问权限。于是，一个标准的 Medallion 架构至少需要三个实体：Bronze 的 Lakehouse、Silver 的 Lakehouse，以及 Gold 的 Lakehouse 或 Warehouse。
开发 / 测试 / 生产（DTP） 的部署流程通常会涉及克隆工作区。每个环境至少包含三套 Lakehouse/Warehouse，因此三套环境合计约 9 个 Lakehouse。数量看似不少，但完全可管理——你还能针对每个环境、每一层的 Lakehouse 分配不同的容量。
每个实体的访问权限可以单独配置。例如，你可以为某一层的 SQL 端点开放只读权限；这对于仅需访问 Gold 层高质量数据的用户，或需要排查 Bronze 生产环境数据但不必访问其他层的开发者，非常实用。
Lakehouse 也提供了额外的隔离与防护。设想一个大型域团队管理了众多应用，但并非所有成员都该访问全部原始数据；又或多个小团队同时做数据接入，你希望避免它们写入同一位置。此时，为各团队设置独立的 Lakehouse/Warehouse，即可实现自治与边界清晰。
想要成功落地 Medallion 架构，标准化对齐十分关键：它能让新团队快速上手。例如，要求每个工作区都遵循统一的 Lakehouse 实体布局；采用具描述性的命名规范，能反映工作区或项目；并将部署脚本化，把工作区与 Lakehouse 等必需项打包自动创建。
根据你的设计需求，一个工作区里可能不止 三座 Lakehouse（Bronze/Silver/Gold）。事实上，任意一层都可以由多座 Lakehouse组成，以便更好地组织与管理数据。例如，Bronze 或 Gold 层可由多组带前缀/标识的 Lakehouse构成，以清晰界定其用途与内容。这种方式能在每层内部获得更大的灵活度与访问控制。
要全面理解数据管理，建议你去了解其他基于 Spark 与 Delta Lake的服务如何处理其数据生命周期（尤其是使用 Azure Data Lake Storage 的服务）。借鉴这些做法，有助于你更好地集成各类服务，打造健壮高效的数据生态。
存储账户方面的考量
在搭建 Azure Databricks、Synapse Analytics 或 Azure HDInsight 等基于 Spark 的服务时，选择合适的存储账户策略至关重要。以 Databricks 为例，你可以采用**单一 ADLS 账户 + 三个容器（Bronze/Silver/Gold）**的模式：数据集中放在一处，并按层分容器管理。
TIP
《The Hitchhiker’s Guide to the Data Lake》是构建企业数据湖（含 ADLS 与存储账户配置）方面的全面指南。
当然，你可以偏离上述默认做法。对于小型项目且数据管理简单，单一存储账户往往足够，便于管理与访问。对于大型项目，你可能需要多个存储账户以满足组织或安全方面的隔离诉求：每个数据工程团队拥有独立存储账户，并在账户中用多个容器区分各层；这样更易实施访问控制与数据治理。
另一种是本地域 + 中央的混合模型。可同时设置域内存储账户与中央共享存储账户：每个域内部署专属存储账户用于域内处理（涵盖 Bronze/Silver/Gold 的活动，仅供域内使用，不对外暴露）；同时由中央部门维护一个共享存储账户，用于向其他域分发最终数据产品（通常是 Silver 的源对齐数据产品或 Gold 的汇总/消费者对齐数据产品）。此设计既保证了域内灵活性，又能对跨域数据交换进行统一治理。第 11 章会给出一个务实示例。
此外，还有很多理由会让你偏离“单湖默认方案”，例如：
- 组织结构：按部门划分数据所有权
- 多区域部署：满足数据属地化要求
- 避开 Azure 限额：突破订阅或服务限制
- 差异化 Azure 策略：为每个数据湖定制策略
- 成本归集：以独立订阅拆分计费
- 敏感数据隔离：对敏感数据施加更严格控制
- 环境隔离：为开发/测试/生产分设数据湖
- 降低时延：将数据湖放到更靠近用户或应用的一侧
- 最小权限：仅对必要资产授予高权限
- 治理与合规：满足多样化监管需求
- 部门诉求：特定团队需要专用数据湖
- 灾备能力：跨区域部署，保障可用性
- 差异化服务级别：按数据类型拆湖以优化成本与性能
想进一步了解为何以及何时要采用多数据湖，可阅读 James Serra 的《When to Have Multiple Data Lakes》。
至此，我们已经完成基础平台的搭建并讨论了关键设计考量：工作区、Lakehouse 实体与存储账户的组织与治理方式。下面将快速回顾部署步骤与 Fabric 的要点，然后在第 5 章继续构建 Bronze 层。
结论
本章为你梳理了 Microsoft Fabric 的落地要点——这是一套可高度定制、能够适配不同组织需求的平台。我们讨论了如何对齐 域（Domain） 、工作区（Workspace） 与 Lakehouse 实体。
为你的 Medallion 架构打基础，建议遵循以下策略：
- 按层次组织资源：将 Lakehouse 实体归入工作区，再将工作区归入相应的域进行治理与隔离。
- 评估弹性与成本：评估工作负载的弹性以提升性价比；考虑购买预留计算并将不同工作区与合适的 Capacity Unit 类型进行策略性绑定。
- 制定组织规范：为团队提供工作区与 Lakehouse 数量的建议上限，推动在全组织范围内采用统一命名规范。
像 Microsoft Fabric 这样的数据分析平台，配置项与考量点众多，给组织的工作负载管理带来不小挑战。因此，需要一支经验丰富的数据工程团队进行有效运维与治理。建议从小处切入、聚焦重点，循序渐进地扩展。同时，通过演示、每周午餐分享、每月团建等方式与其他团队保持常态化互动，既能促进协作与创新，也能帮助平台更好地对齐组织的整体目标。
在第 5 章中，我们将继续以 Microsoft Fabric 为例，转向构建 Bronze 层。
