Medallion 架构详解：铜牌、银牌和金牌层

大多数数据团队失败，并不是因为他们无法收集数据。他们失败是因为原始数据到达时混乱、重复且不一致，而且没有一种有纪律的方法将其转化为分析师和模型可以信任的东西。Medallion 架构是大多数现代数据平台用来解决这一问题的模式，它通过三个逐步变得更干净的层来移动数据：铜牌、银牌和金牌。

本指南以数据工程师需要理解的方式解释该模式、每一层的行为、数据如何在它们之间实际移动，以及外部来源的网页数据作为原始铜牌输入进入整体图景的位置。

本文内容：

• 什么是 Medallion 架构，以及 Databricks 为什么使其流行起来
• 铜牌、银牌和金牌层各自做什么，以及谁会使用它们
• 数据如何借助表格式、ACID 事务和变更数据捕获在各层之间移动
• 外部数据和网页数据作为铜牌来源进入该模式的位置
• 最佳实践、常见陷阱，以及该模式产生价值的用例

什么是 Medallion 架构？

Medallion 架构是一种用于在湖仓内部组织数据的设计模式，使数据从铜牌流向银牌再到金牌时，其结构和质量在每个阶段都得到提升。这个名称借用了奖牌的比喻：数据以低价值的原始铜牌进入，并被优化为更有价值的银牌，然后是金牌。你也会看到它被称为多跳架构，因为每条记录在适合消费之前都要经过几次跳转。

该模式由 Databricks 与其湖仓范式和 Delta Lake 表格式一起推广，后者于 2019 年开源。湖仓结合了数据湖的低存储成本与数据仓库的可靠性特性，例如 ACID 事务和架构强制执行。Medallion 架构是赋予该湖仓清晰信任流的组织原则。它现在是一个跨平台惯例：同样的铜牌、银牌和金牌语言出现在 Databricks、Microsoft Fabric 和 Snowflake 文档中。

核心思想很简单。你不是在一个不透明的步骤中清洗数据，而是保留一份永久的原始副本，然后在各个阶段对其进行优化，其中每个阶段都有明确的契约。这种分离正是该模式如此持久的原因，也是下面所有内容的基础。

数据团队为什么采用它

Medallion 架构之所以占有一席之地，是因为它同时解决了几个问题。

增量式、可检查的数据质量。 质量是在多个阶段中改进的，而不是通过一个难以推理的单一转换来完成。每一跳都有明确的任务，所以当某些东西看起来不对时，你知道该检查哪一层。

从原始数据重新处理。 因为铜牌层是永久的历史归档，所以你可以随时重建银牌和金牌表，而不必回到源系统。如果某个转换存在 bug，或者业务逻辑发生变化，你可以从铜牌重放，而不是重新收集可能已经不可用的数据。

血缘和可审计性。 铜牌保留原始载荷，这为你提供了一份取证记录。合规和审计团队可以将控制面板中的任何数字追溯到它所来自的确切原始记录。

跨消费者的关注点分离。 不同层服务于不同受众。数据工程师和运营团队在铜牌和银牌层工作。分析师和数据科学家在银牌层工作。业务分析师、高管和应用程序使用金牌层。

多消费者服务。 一个干净的银牌实体可以为许多金牌表提供数据，因此财务、运营和营销可以各自从同一个可信来源构建自己的消费就绪视图。

这也是该模式与 ELT 思维方式天然契合的原因。你先加载原始数据，然后在平台内部转换它，而不是在数据落地之前转换所有内容。如果你想复习更广泛的摄取流程，ETL 管道的解释和数据管道架构概览都可以清晰映射到 Medallion 模型。

三个层的详细说明

从概念上看，流程是线性的：原始数据落入铜牌，优化为银牌，并在金牌中塑造成可供消费的形态。

flowchart LR
    S["External and web sources"] --> B["Bronze: raw, as-is, append-only"]
    B --> SI["Silver: cleaned, conformed, deduplicated"]
    SI --> G["Gold: aggregated, business-level"]
    G --> C["BI, dashboards, ML, applications"]

数据在从铜牌移动到银牌再到金牌时逐步得到优化。

铜牌层：原始且不可变

铜牌是来自外部源系统的所有内容的着陆区。它的表按原样镜像源的形状，并添加少量额外的元数据列，用于记录加载时间戳和写入该行的进程等细节。这里的优先事项是捕获速度、源的持久历史归档、清晰的血缘，以及以后无需再次读取原始系统即可重新处理的选择。

铜牌有几个定义性属性。它包含数据原始格式中的原始状态。它以增量方式追加，并随时间增长。它作为单一事实来源，精确保留数据到达时的保真度。它旨在用于下游处理，而不是直接供分析师访问。

一个关键的实现细节是：在铜牌层，你通常不强制执行类型。Databricks 建议将大多数字段存储为 string、VARIANT 或 binary，以防止上游出现意外的架构变化。实际上，铜牌是读时模式。你先捕获，后解释，这正是当源架构不受你控制时你想要的方式。铜牌来源可以是流式和批量输入的任意组合，包括 Amazon S3、Google Cloud Storage 和 Azure Data Lake Storage 等云对象存储，Kafka 和 Kinesis 等消息总线，以及联合系统。

银牌层：已清洗且已统一

银牌是铜牌记录被匹配、合并、统一和清洗的地方，清洗到足以为业务提供其核心实体、概念和交易的单一连贯视图。可以想象主客户记录、去重后的交易和交叉引用表。通过将来自许多来源的数据调和为一种一致形状，银牌成为支持自助分析、临时报告、高级分析和机器学习的层。

这里通常发生的操作很具体：架构强制执行、空值和缺失值处理、去重、乱序和延迟到达记录的解决、数据质量检查、架构演进、类型转换和连接。这也是你开始真正数据建模的地方，通常使用更规范化、写入性能更好的结构。在这个阶段跟踪数据质量指标，正是可信银牌层与美化版铜牌副本之间的区别。

一个坚定的最佳实践是：不要从摄取直接写入银牌。如果你跳过铜牌并直接写入银牌，你会引入来自架构变化和损坏源记录的故障，并且会失去重放能力。银牌应始终至少包含每条记录的一个经过验证、未聚合的表示，这样无需下钻到原始铜牌，也仍然可以进行详细分析。

金牌层：业务就绪

金牌保存消费就绪、特定项目的数据。这里的模型更加反规范化，并针对更少连接的快速读取进行调优，最终转换和业务规则也在这里落地。它是展示层工作的主场：客户和库存分析、分群、销售报告等等。实际上，你通常会在这一层发现 Kimball 风格的星型架构或 Inmon 风格的数据集市。

金牌代表高度优化的视图，用于驱动控制面板、机器学习和应用程序。数据通常经过大量聚合，并被过滤到特定时间段或区域。由于单个业务域很少适合一种形状，许多团队会构建多个金牌表，例如财务、运营和 HR 的独立视图，全部派生自同一个银牌基础。

下表总结了三层的差异。

数据如何在各层之间移动

Medallion 架构是一种逻辑模式，但它建立在一组特定的物理机制之上。完整图景如下：许多来源为铜牌提供数据，数据在湖仓内部通过银牌和金牌得到优化，许多消费者从金牌读取。

flowchart LR
    subgraph SRC["Sources"]
        WEB["Web data via Bright Data"]
        DB["Databases and apps"]
        MB["Message buses: Kafka, Kinesis"]
    end
    subgraph LH["Lakehouse: Delta, Iceberg, or Hudi on Parquet"]
        BRONZE["Bronze: raw, append-only"] --> SILVER["Silver: cleaned, conformed"] --> GOLD["Gold: business aggregates"]
    end
    subgraph CON["Consumers"]
        BI["BI and dashboards"]
        ML["ML and AI"]
        APP["Applications"]
    end
    WEB --> BRONZE
    DB --> BRONZE
    MB --> BRONZE
    GOLD --> BI
    GOLD --> ML
    GOLD --> APP

一个参考 Medallion 栈：许多来源落入铜牌，通过银牌和金牌优化，并服务许多消费者。

表和文件格式。 这些层通常构建在开放表格式之上，而开放表格式位于云对象存储中的 Parquet 文件之上。Delta Lake 是 Databricks 和 Microsoft Fabric 上的原生格式：在内部它将数据存储为 Parquet，但它添加了事务日志和统计信息，提供超越普通 Parquet 的可靠性和性能。当多引擎互操作性很重要时，Apache Iceberg 是同样强大的替代方案，而 Apache Hudi 非常适合大量 upsert、变更数据捕获型摄取。这三者都提供了该模式所依赖的 ACID 保证。

ACID 事务。 该架构保证数据通过验证和转换时的原子性、一致性、隔离性和持久性。这正是防止失败作业留下半写入且损坏的表的机制，而当许多管道并发读取和写入时，这一点极其重要。

增量加载和变更数据捕获。 你很少在每次运行时重新处理所有内容。Delta Lake 的 Change Data Feed 让下游层只消费发生变化的内容。例如，你可以在银牌表上启用该 feed，并用它在每次运行时增量更新金牌聚合，而无需完全刷新。铜牌层的增量摄取是一种成本和延迟权衡：连续流式处理延迟最低、成本最高，触发式增量加载成本较低但增加延迟，而全量批量加载延迟最高。

幂等性。 铜牌摄取应是幂等的，因此重新运行加载不会创建重复项或丢失数据。仅追加设计加上银牌层的去重，使安全重放成为可能。

编排、批处理和流处理。 Apache Spark 等工具处理铜牌到银牌、银牌到金牌的转换，既支持批处理，也支持结构化流模式。Spark Declarative Pipelines、Microsoft Fabric materialized lake views 和 Snowflake tasks 等声明式框架减少了在层之间移动数据的样板代码。Apache Airflow 等编排器协调运行。这个Airflow 和 Spark 管道演练展示了一个使用 Airflow 进行调度、使用 Spark 进行转换的编排模式实例，而这篇 Spark 结构化流处理 指南展示了一个流式变体。

值得注意的是，Medallion 词汇并非通用。流行的转换框架 dbt 将项目构造成 staging、intermediate 和 marts 层。这些关注点与铜牌、银牌和金牌非常接近，但名称不同，因此在阅读文档时不要假设这两套词汇可以互换。

网页数据进入的位置：铜牌层

这是大多数架构图轻描淡写的部分：外部数据实际上来自哪里，又如何以可用状态落入铜牌？

铜牌层被定义为所有外部源系统的着陆区，Databricks 明确将 S3、GCS 和 ADLS 等云对象存储列为有效的铜牌来源。这就是外部收集的网页数据适配的接缝。竞争对手定价、产品目录、公开公司记录、搜索结果和评论数据都是原始输入，应以原始形式进入铜牌，并保留其怪异之处和不一致性，留给银牌层解决。

这正是 Bright Data 发挥作用的地方。Bright Data 是一个网页数据平台，可以大规模收集公开网页数据，并以原始、结构化文件交付，这使其成为天然的铜牌层来源。这种对齐是直接的：Bright Data 交付到的目的地，正是湖仓平台视为铜牌输入的那些云对象存储。

flowchart LR
    W["Public web: sites, SERPs, marketplaces"] --> BD["Bright Data ingestion: Web Scraper API, Datasets, Data Firehose"]
    BD -->|"JSON, NDJSON, CSV, Parquet"| L["Cloud storage: S3, GCS, Azure, or Snowflake"]
    L --> BR["Bronze layer: raw, preserved as source of truth"]
    BR --> SV["Silver: clean and conform"]
    SV --> GD["Gold: serve analytics and ML"]

Bright Data 交付的外部网页数据作为铜牌层落入云存储，然后向上流经银牌和金牌。

根据你需要批量、按需还是连续数据流，有几种方式可以为铜牌提供数据：

• 网页抓取工具 API 将任何网站转化为结构化数据端点，拥有 437+ 个预构建爬虫工具，并以 JSON、NDJSON 或 CSV 返回数据。它是新鲜铜牌记录的按需触发器。
• 即用型数据集提供来自数百个热门域名的预收集数据，可立即下载或按计划刷新。这是进入铜牌的批量路径。
• Data Firehose 将连续、实时的网页记录流直接交付到 Amazon S3、webhook 或流，这适合流式铜牌摄取模式。
• 搜索引擎 API 提供结构化搜索引擎结果，这是竞争情报和生成式引擎监控管道的常见铜牌输入。
• 抓取浏览器 处理 JavaScript 密集型网站，提供静态收集会遗漏的渲染页面数据。
• 对于专用 feed，公司数据 API 和精选的 AI 与 LLM 数据集提供可直接放入管道的垂直数据，而 网页归档 API 为时间序列铜牌表提供历史快照。

交付方式让这一切变得清晰。Bright Data 数据集可导出为 JSON、NDJSON、CSV、XLSX，以及重要的 Parquet，即湖仓表原生使用的列式格式。交付目的地包括 Amazon S3、Google Cloud Storage、Microsoft Azure Blob Storage、Snowflake、Google Cloud Pub/Sub、SFTP、webhook 和直接 API 下载。实际上，这意味着计划任务数据集可以按重复节奏以 Parquet 形式落入你的 S3 铜牌 bucket，而无需编写粘合代码。无代码抓取工具 Studio进一步扩展了这一点，让你能够可视化构建爬虫工具，并将输出直接加载到 S3、GCS、Azure、BigQuery 或 Snowflake。

有两个原则可以使这忠实于 Medallion 模式。第一，保留原始载荷。将提供商的输出按交付原样落入铜牌，包括你尚未使用的字段，这样你就保留了完整的取证记录。第二，在银牌而不是铜牌中规范化。日期格式、货币、字段映射和跨来源去重都属于银牌跳转，无论外部提供商如何构造其数据。如果你正在批量路径和按需路径之间做决定，数据集与网页爬虫 API的比较是一个有用起点，结构化与非结构化数据入门也是如此。

可靠性在这里比其他任何地方都更重要，因为一个悄然失败的铜牌来源会污染其上方的每一层。Bright Data 报告称，在一项对 11 家提供商的独立基准测试中，其平均成功率为 98.44%，并由一个 400M+ IP、合乎道德来源的住宅代理网络以及 99.99% 正常运行时间目标作为支撑。对于有治理要求的团队，Bright Data 保持 GDPR、CCPA、SOC 2 Type II 和 ISO 27001 合规，并且只收集公开可用数据，这正是铜牌层审计轨迹应该捕获的那种来源证明。

一个实操示例：从原始抓取到金牌表

当你可以运行它时，理论更容易被信任。下面是一个基于小型真实网页产品数据样本的最小 Medallion 管道：来自 Amazon US 和 UK 实时搜索结果、跨三个类别收集的十二条商品列表。代码刻意保持简单，所以突出的是模式，而不是工具。

铜牌。 将行按收集时的原样落地。价格仍然是字符串，货币混杂，没有任何内容被清洗或删除。

import pandas as pd

# Bronze: raw scraped rows, landed as-is with ingestion metadata
bronze = pd.DataFrame(scraped_rows)
bronze["_ingested_at"] = "2026-06-23T00:00:00Z"

银牌。 将价格解析为数字，将所有内容规范化为 USD，解码标题中的 HTML 实体，删除没有可用价格的行，并对同一产品被捕获多次的情况进行去重。

import html, re

def to_usd(price_raw, gbp_rate=1.27):        # 1.27 is an illustrative fixed rate
    if not price_raw:
        return None                          # no price, the row cannot be trusted
    is_gbp = "£" in price_raw
    value = float(re.sub(r"[^0-9.]", "", price_raw.replace(",", "")))
    return round(value * gbp_rate, 2) if is_gbp else round(value, 2)

silver = bronze.copy()
silver["price_usd"] = silver["price_raw"].map(to_usd)
silver["rating"] = silver["rating"].astype(float)                    # text rating to number
silver["product_name"] = silver["product_name"].map(html.unescape)   # & becomes &
silver = silver[silver["price_usd"].notna()]                         # drop unpriced rows
silver = silver.sort_values("price_usd").drop_duplicates("product_name")  # dedup

金牌。 将干净记录聚合成控制面板或模型实际查询的业务视图。

gold = (
    silver.groupby("category")
    .agg(
        products=("product_name", "count"),
        avg_price_usd=("price_usd", "mean"),
        min_price_usd=("price_usd", "min"),
        max_price_usd=("price_usd", "max"),
        avg_rating=("rating", "mean"),
    )
    .round(2)
    .reset_index()
)

注意各层吸收了什么，因为这正是真实管道必须面对的内容。这是 2026 年 6 月 23 日收集的一个小型真实样本，GBP 到 USD 的数字是说明性的固定汇率，而不是实时转换。三个真实伪影到达铜牌并在银牌得到解决：一条商品列表没有价格并被删除，同一个 Apple AirPods Pro 3 产品同时从 US 和 UK 页面被捕获并被去重为单条记录，带有原始 HTML 实体（如 &）的标题被解码为纯文本。这些清理都不属于铜牌，铜牌的唯一任务是保留到达的内容。这种职责分离正是该模式的全部意义。

湖仓工具生态系统

Medallion 模式在一组熟悉的工具中实现。它们彼此并不可互换，但一个可工作的架构通常会组合其中几个。

• Databricks 是提出湖仓范式和 Medallion 架构的商业湖仓平台，原生支持 Delta Lake，并提供声明式管道工具。
• Delta Lake 是一种开源表格式，在 Parquet 之上添加 ACID 事务、架构强制执行、时间旅行和变更数据捕获。
• Apache Spark 是分布式计算引擎，可在批处理或流式处理中运行铜牌到银牌、银牌到金牌的转换。
• Apache Iceberg 是一种开放表格式，当多个引擎需要读取同一批表时备受青睐。
• Apache Hudi 是一种开放表格式，具有强大的记录级 upsert 和增量拉取支持，常见于变更频繁的铜牌层。
• Snowflake 原生支持该模式，包括用于金牌层的托管 Iceberg 表。
• dbt 是许多团队用来构建银牌和金牌层的 SQL 优先转换框架。
• Microsoft Fabric 在 OneLake 上原生实现 Medallion 架构，并以 Delta Lake 为标准。

如果你的平台是 Snowflake 或 Google Cloud，Bright Data 与 Snowflake Cortex以及 Vertex AI 加搜索引擎 API 工作流的集成指南展示了铜牌交接的上下文。

最佳实践

少数约定区分了干净实现和脆弱实现。

• 不要从摄取写入银牌。 始终先将原始数据落入铜牌，这样架构变化和损坏记录就不会破坏你的优化表。
• 让铜牌保持宽松类型。 将大多数字段存储为 string、VARIANT 或 binary，这样上游架构漂移就不会丢失数据。
• 在可以的情况下以流的方式读取铜牌。 对于仅追加来源，流式读取可保持低延迟；将批量读取留给小型数据集。
• 始终在银牌中保留一条未聚合记录。 聚合属于金牌，因此银牌可在许多消费者之间复用。
• 不要强迫金牌实时化。 金牌针对频繁查询、批量刷新的聚合进行了优化。为低延迟工作负载改造它往往会创建脆弱且昂贵的管道。
• 按层命名表。 像 catalog.bronze.table、catalog.silver.table、catalog.gold.table 这样的命名空间，可以一眼传达任何表的信任级别。

常见陷阱和批评

该模式很稳健，但它经常被误用，以至于失败模式已有充分记录。

跳过铜牌。 当外部数据看起来已经很干净时，这很诱人，但跳过铜牌会移除审计轨迹和重新处理能力。当其背后没有原始记录时，你的银牌层语义会悄然改变。

把银牌当作金牌。 当团队直接在银牌中构建业务 KPI 和重型聚合时，不同团队会以不同方式定义指标，并且没有一个单一权威版本。将聚合保留在金牌中。

像生产数据一样读取原始铜牌。 铜牌未经验证，通常很混乱。将控制面板指向它会导致重复计数和不一致结果。铜牌是历史记录，而不是分析的事实来源。

跨层纠缠。 当管道在各层之间泄漏职责时，例如将原始事件直接摄取到金牌中，单个架构变化可能会级联影响整个栈。

对僵硬应用该模式也存在合理批评。正如一项分析所说，对所有来源应用僵硬的三层结构，会在某些数据集不需要大量清洗时导致低效，而顺序分层会增加实时用例可能无法容忍的延迟。实践者社区对此的回应是在某些设计中提出额外层，例如铜牌前的着陆区，或金牌之上的白金层，用于运营和机器学习服务。

健康的理解方式是，Medallion 架构是一个灵活框架，而不是一项强制要求。Databricks 本身表示，遵循 Medallion 架构是推荐的最佳实践，但不是要求，Delta Lake 项目也将其描述为一个可选、灵活的框架。使用适合你的查询模式和消费者的层数与命名。

常见用例

在原始输入混乱且许多消费者需要可信输出的地方，该模式的价值最为明显。

• 竞争定价和电商情报。 从许多零售商收集的产品和价格数据按原样落入铜牌，在银牌中被规范化和去重，并为金牌价格跟踪和品类控制面板提供数据。
• AI 和机器学习训练数据。 网页规模文本和结构化数据以原始形式落入铜牌，在银牌中被清洗和去重，并在金牌中塑造成模型就绪特征。实际步骤在这篇用于机器学习的网页抓取指南中介绍，更广泛的策略则在 AI 数据飞轮文章中说明。
• 市场和另类数据研究。 来自许多来源的外部信号在银牌中统一为单一研究视图，然后聚合为金牌指标。
• 搜索和 SERP 监控。 连续搜索结果流进入铜牌，在银牌中结构化，并汇总为金牌可见度和声量份额指标。
• 企业画像和客户丰富。 公司数据 feed 在银牌层丰富内部记录，为销售和营销生成金牌表。

对于这些用例背后的工程管道，AWS Glue ETL、AWS Step Functions、Kubeflow 管道、Mage AI 管道以及将实时网页数据连接到 Tableau的演练各自展示了一条真实的铜牌到服务路径。提取步骤本身的基础知识在这篇数据提取入门中介绍。

结论

Medallion 架构经久不衰，是因为它为团队提供了一种共享语言，用于一次一个有纪律的跳转，将原始数据转化为可信数据。铜牌保留真相，银牌使其一致，金牌使其有用。该模式的效果取决于输入其中的原始数据，这就是为什么可靠、结构良好的铜牌来源不是细节，而是基础。

对于外部数据和网页数据，这个基础正是 Bright Data 的契合点：生产级收集，以 JSON、CSV 或 Parquet 直接交付到你的湖仓已经视为铜牌的云存储中。准备好用可靠的网页数据为你的铜牌层供数了吗？开始免费试用，看看原始网页数据能以多快速度流入你的管道。

常见问题

Q: 用简单的话说，什么是 Medallion 架构？

它是一种在湖仓中组织数据的方式，使数据在穿过三层时变得更干净、更有用。原始数据落入铜牌层，在银牌层被清洗和标准化，并在金牌层聚合为业务就绪表。每一层都有明确任务，这使数据质量更易于管理和审计。

Q: 铜牌、银牌和金牌层之间有什么区别？

铜牌按数据到达时的原样保存原始数据，仅追加且未转换，作为永久事实来源。银牌保存已清洗和统一的数据，并应用去重、架构强制执行和连接，使数据可信且一致。金牌保存聚合后的业务级数据，为特定报告、控制面板、机器学习和应用程序进行建模。

Q: Medallion 架构和 ETL 一样吗？

不一样，但它们有关联。ETL 描述提取、转换和加载数据。Medallion 架构是一种分层模式，用于组织这些转换发生的位置。在湖仓中，它通常遵循 ELT 风格，即先将原始数据加载到铜牌中，然后在平台内部分阶段转换为银牌和金牌。

Q: 我总是需要所有三层吗？

不需要。Databricks 将 Medallion 架构描述为推荐的最佳实践，而不是要求。一些到达时已经干净的数据集可能不需要大量银牌步骤，而一些实时用例会有意绕过流程的部分环节。层数和命名应适合你的查询模式和消费者。主要警告是，跳过铜牌会移除你的原始审计轨迹和重新处理能力。

Q: 我应该为 Medallion 表使用什么文件格式？

大多数实现使用 Delta Lake、Apache Iceberg 或 Apache Hudi 等开放表格式，它们都位于云对象存储中的 Parquet 文件之上。这些格式添加了 ACID 事务、架构强制执行和时间旅行，而这些是该模式所依赖的。Delta Lake 是 Databricks 和 Microsoft Fabric 上的原生格式，而当多个引擎读取同一批表时，Iceberg 很常见。

Q: 外部数据或网页数据如何适配 Medallion 架构？

外部数据和网页数据是铜牌层输入。你将原始收集数据，例如产品、定价、搜索或公司数据，以其原始形式落入铜牌，然后在银牌中对其进行规范化和去重。因为湖仓平台将 S3、GCS 和 Azure 等云对象存储视为有效的铜牌来源，所以 Bright Data 这样的提供商可以将网页数据以 JSON、CSV 或 Parquet 形式直接交付到这些存储中，在那里它成为铜牌层。

Q: Medallion 架构绑定于 Databricks 吗？

Databricks 与湖仓范式和 Delta Lake 一起推广了该术语，但该模式并不专属于它。同样的铜牌、银牌和金牌语言用于 Microsoft Fabric 和 Snowflake 文档中，而底层开放表格式可在许多引擎上运行。该模式是一种通用惯例，而不是单一供应商的产品。