Materialized Lake Views in Microsoft Fabric: When Your Medallion Fits in a SELECT Statement

CREATE [OR REPLACE] MATERIALIZED LAKE VIEW [IF NOT EXISTS]

[workspace.lakehouse.schema].MLV_Identifier

[(CONSTRAINT constraint_name CHECK (condition) [ON MISMATCH DROP | FAIL], ...)]

[PARTITIONED BY (col1, col2, ...)]

[COMMENT “description”]

[TBLPROPERTIES (”key1”=”val1”, ...)]

AS select_statement

CREATE OR REPLACE MATERIALIZED LAKE VIEW silver.cleaned_order_data

(

CONSTRAINT valid_quantity CHECK (quantity > 0) ON MISMATCH DROP

)

PARTITIONED BY (category)

COMMENT “Cleaned order data joined from products and orders”

AS

SELECT

p.productID, p.productName, p.category,

o.orderDate, o.quantity, o.totalAmount

FROM bronze.products p

INNER JOIN bronze.orders o ON p.productID = o.productID

ALTER TABLE bronze.orders SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

ALTER TABLE bronze.products SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

REFRESH MATERIALIZED LAKE VIEW silver.cleaned_order_data FULL;

import fmlv

from pyspark.sql import functions as F

@fmlv.materialized_lake_view(

name=”LH1.silver.customer_silver”,

comment=”Cleaned & enriched customer silver MLV”,

partition_cols=[”year”, “city”],

table_properties={”delta.enableChangeDataFeed”: “true”},

replace=True

)

@fmlv.check(name=”non_null_sales”, condition=”sales IS NOT NULL”, action=”DROP”)

def customer_silver():

df = spark.read.table(”bronze.customer_bronze”)

cleaned_df = df.filter(F.col(”sales”).isNotNull())

enriched_df = cleaned_df.withColumn(”sales_in_usd”, F.col(”sales”) * 1.0)

一些值得了解的 PySpark 潜在问题：

- 在撰写本文时，PySpark MLV 仍处于预览阶段。

- 目前，由 PySpark 编写的 MLV 始终执行完整刷新。PySpark 的最佳刷新方式已在路线图中，但尚未实现。

- @fmlv 装饰器不支持动态参数或变量。所有参数必须硬编码。

- 不能从 PySpark 临时视图（createOrReplaceTempView）创建 MLV – 引擎无法看到会话作用域的视图。请使用物理 Delta 表或其他 MLV 作为数据源。

- 不要删除定义 MLV 的笔记本。没有它，计划刷新将失败。

因此，如果你的转换可以清晰地用 SQL 表达，那么从性能角度来看，SQL 仍然是更好的选择。PySpark MLV 解锁了仅靠 SQL 无法实现的场景。

### 4. 原地更新（Replace）

业务逻辑发生变化。一个筛选条件发生偏移。一个连接增加了一列。一个聚合添加了一个指标。在预览阶段，更新 MLV 定义需要删除并重新创建，这会丢失刷新历史并迫使下游消费者重新连接。

现在，通过 Replace 功能，你可以原地更新 MLV 的定义。Fabric 会验证新的逻辑，将其替换进去，并保留视图的身份、元数据和血缘关系。下游依赖关系保持不变。适用于 SQL（CREATE OR REPLACE）和 PySpark（replace=True）。

这是那些“低调”的 GA 特性之一，虽然没有头条新闻，但对日常使用非常重要。如果你曾经在生产运行时需要协调删除和重新创建一个被大量使用表，你一定知道其中的痛苦。有了这个功能，这种痛苦将不复存在。

### 5. 更强的数据质量

数据质量约束在 MLV 中并不是什么新东西，但在 GA 阶段，它们得到了重大升级。现在你可以：

- 使用基于表达式的逻辑，结合多个列

- 在单个规则中应用算术和内置函数

- 调用会话作用域的用户自定义函数，用于在 Python 而非 SQL 中实现的验证逻辑

结合自动生成的数据质量报告，你将获得接近内置数据可观测性层的功能。你可以快速发现哪些规则最常失败，影响了哪些视图，以及随时间推移趋势如何变化，而无需构建单独的监控管道。

## 血缘视图 – 免费获取依赖关系

当一个 MLV 引用另一个（或一个表）时，Fabric 会自动推断这种关系。无需手动配置，也无需外部编排工具。这些依赖关系是从你的 SQL 中发现的。

这个依赖关系图会成为你湖仓中的可视化血缘。每个节点代表一个转换。箭头显示执行顺序。Fabric 确保当青铜数据到达时，青铜到白银的 MLV 首先运行，然后白银到黄金的 MLV 会针对刚刚更新的白银数据运行。

这就是声明式方法真正发挥作用的地方。你不是在编写流水线。你不是在定义编排。你只是写出每一层应该是什么样子，Fabric 会自动确定顺序。声明式方法的美妙之处就在于此。

一些有用的行为需要了解：

- 独立视图可以并行运行

- 错误会集中显示，而不是在笔记本单元格输出中丢失

- 当运行进行时，血缘视图会每两分钟自动刷新一次

- 所有快捷方式在血缘视图中都被视为源实体

- 您可以将自定义的 Spark 环境附加到 materialized lake views 的血缘关系中，以在刷新过程中优化性能和资源使用。

## 数据质量 – 已声明！

我上面已经提到过这一点，但它值得单独成节，因为这是使 MLVs 与手工构建的管道有所不同之处之一。

每个 MLV 都可以附加一个或多个数据质量约束：

两种操作类型：

- DROP – 违规的行将被移除，计数会记录在血缘视图中，管道将继续运行

- FAIL – 刷新会在第一个违规处停止。如果您没有指定，这也是默认行为

如果存在多个约束且配置了两种行为，FAIL 优先级更高。

违规情况会出现在血缘视图和运行详情中。很好，但实际中这到底是什么样子呢？在数据质量报告中，您将看到按约束、按视图、随时间变化的计数。因此，如果一个通常删除 0.1% 行的约束突然删除了 15% 的行，您将看到这一峰值，并确切知道是哪条规则失败了，以及它属于哪个视图。这是您原本必须手动构建的质量信号。

微软文档还指出，新的基于表达式的约束支持内置的 Spark/SQL 函数，如 UPPER()、LOWER()、TRIM()、COALESCE()、INITCAP() 和 DATE_FORMAT()，因此您的 CHECK 条件可以不仅仅是简单的比较。

## MLVs 的优势与局限

MLVs 并不是万能的解决方案。微软文档在这一点上非常直接，明确指出了它们适用的场景和不适用的场景。

使用 MLVs 的情况包括：

- 频繁访问的聚合（如每日总计、月度指标），其中预计算的结果比重新运行昂贵的查询更有效

- 需要跨多个大型表进行复杂连接，并且所有消费者都需要一致性的场景

- 您希望以统一、声明性方式应用的数据质量规则

- 从多个来源组合数据并受益于自动刷新的报表数据集

- 鸢尾设计模式 – 从青铜层到白银层再到黄金层，定义为 SQL 转换

不使用 MLVs 的情况包括：

- 查询仅运行一次或很少 – 预计算不会有所帮助

- 转换已经很简单且很快

- 您需要非 SQL 逻辑，如机器学习推断、API 调用或复杂的 Python 处理 – 笔记本仍然更合适（尽管 PySpark MLVs 正在逐步弥合这一差距）

- 您需要流处理的亚秒级延迟 – 这属于实时智能的领域

在这里，我想补充一个个人的见解。我目前正深入参与一个微软 Fabric 项目，其中白银层的设计选择 – 数据仓库与 Lakehouse（使用 MLVs） – 正在桌面上激烈讨论。而我不断回到的一个观点是：MLVs 并不像一些人所描述的那样与数据仓库竞争。它们实际上是在与您原本会在 Lakehouse 中构建的笔记本和管道的混乱结构竞争。如果您团队已经精通 SQL，并且转换自然地存在于 SELECT 语句中，那么在基于 Lakehouse 的架构中将 MLVs 作为白银层的论点确实是强有力的。

## 细节 – 在投入之前需要了解的内容

如果我把 MLVs 描述成万能的解决方案，那对您来说是一种误导。它们确实有一些重要的限制，其中一些会对您的架构产生影响：

- 不支持跨湖仓的血缘关系和执行 – 所有来源、MLV 和依赖项必须位于同一个湖仓中。如果你使用 Fabric 数据仓库表作为数据源，必须首先在你的湖仓中为其创建一个快捷方式。

- 不支持 DML 语句 – 你无法对 MLV 执行 INSERT、UPDATE 或 DELETE 操作。数据仅由 SELECT 语句生成。

- 定义中不支持时间旅行查询 – VERSION AS OF 和 TIMESTAMP AS OF 不被允许。

- SQL 定义中不支持 UDF – 尽管 PySpark 的编写方式通过会话作用域的 UDF 填补了这一空白。

- 不支持临时视图作为数据源 – SELECT 可以引用物理表和其他 MLV，但不能引用临时视图。这也适用于 PySpark：createOrReplaceTempView() 的输出对 MLV 引擎不可见。

- 在计划刷新期间，会话级别的 Spark 属性不适用 – 应该在湖仓或工作区级别进行设置。

- 模式名称的大小写很重要 – 不支持全大写的模式名称。请使用混合大小写或小写。

- 区域可用性 – 截至本文撰写时，MLV 在美国南部中央地区不可用。

对于大多数数据管道来说，以上限制都不是决定性的问题。但在你将架构提交给 MLV 并在中途发现这些限制之前，了解这些信息是很有必要的。

## 总结

如果你一直在 Fabric 中使用笔记本和管道构建勋章设计模式，那么 MLV 值得认真考虑。它们将五个层面合并为一个声明式层。依赖关系管理是自动的。数据质量是内置的。血缘关系是可见的。并且从 FabCon Atlanta 开始，它们已经具备了生产就绪的条件。

微软的路线图非常明确：PySpark 编写的 MLV 的最佳刷新功能即将到来，更多的 SQL 操作符将具备增量刷新资格，并且与 Fabric 其他工作负载的更深入集成也在进行中。这是一个里程碑，而不是终点 – 我很期待看到 MLV 在接下来几个季度的发展，特别是在 PySpark 增量刷新和微软可能讲述的跨湖仓故事方面。

我将记住的两个要点是：

- 如果你的 ELT 中的 “T” 是 SQL，那么它现在写起来、安排执行以及信任起来都变得容易得多。

- MLV 并不会取代每一个笔记本、每一个管道或每一个数据仓库。但对于需要血缘关系、刷新和内置数据质量的声明式转换，它们现在已成为 Microsoft Fabric 中一个合法的默认选择。

感谢阅读！

撰写人

查看 Nikola Ilic 的所有文章

数据架构

,

数据建模

数据科学

Microsoft Fabric

Sql

分享这篇文章

- 在 Facebook 上分享

- 在 LinkedIn 上分享

- 在 X 上分享

Towards Data Science 是一个社区出版物。提交你的见解以触达全球受众，并通过 TDS 作者支付计划获得报酬。

更新为你的实际提交 URL

为 TDS 写作

✦ 结束 CTA ✦