Reimagining Data Modeling on the Lakehouse: Introducing Vibe Data Modeling

在湖仓架构上重新构想数据建模：推出Vibe数据建模 | Databricks博客

跳至主要内容

解决方案

2026年7月6日

在湖仓架构上重新构想数据建模：推出Vibe数据建模

用普通英语描述您的业务需求。数小时内即可在Databricks上获得生产就绪的银层数据模型，而非数月。

作者：Amr Ali、Cary Moore、Roberto Bruno Martins和Abhijit Tilak

摘要

• Vibe数据建模现已推出：这是一个原生Databricks、由LLM驱动的智能体，能够直接根据您用普通英语描述的业务需求，生成分析用的银层业务模型。

• 从提示到部署模型仅需数小时，取代传统需要6至36个月手工构建银模型，或裁剪通用行业模板的项目。

• 通过自然语言迭代：每次“vibe”都会生成一个新版本模型，经过251条强制性规则验证，由两个架构师角色评审，通过闭环智能体循环修复，并重新部署到Unity Catalog。任何版本都不会被覆盖。

• 一个逻辑模型，多种物理布局：可将同一模型渲染为一个目录、按部门划分的目录，或按领域划分的目录。无需重新构建。

数据建模面临的挑战

在每个分析架构中，银层决定成败。BI工具和仪表板从金层读取数据；金层由银层构建。银层模型是所有分析师、数据科学家和BI工具依赖的基础。如果银层混乱、缺乏治理或存在大量重复数据，其上所有内容都会变得更难实现、更慢、更昂贵。

实现银层模型一直是个难题。大多数组织要么需要6个月到3年手工构建银层模型，要么购买通用行业模板（如保险行业的ACORD、医疗行业的FHIR、零售行业的ARTS、电信行业的TM Forum SID），然后花费9到12个月进行裁剪、重命名和重新连接。模板是整个行业平均水平的产物：通常只有20%到40%的内容相关，且是为特定业务构建的。这两种路径都无法满足现代数据产品快速交付的需求。

今天，我们宣布推出Vibe数据建模

Vibe数据建模是一个多模型LLM智能体，能够将您用普通英语描述的业务需求转化为完整、受控、可部署的银层数据模型。它以单个笔记本形式交付：四个控件、一次运行、在Unity Catalog中即可完成完整部署。如果您对生成结果不满意，可通过普通英语进行“vibe”调整，直到符合预期。

• 数小时而非数月：在两小时内即可部署最小可行模型，一个下午即可完成扩展覆盖模型。

• 100%贴合您的需求：使用您的术语、部门和领域定义，而非行业平均水平。

• 构建即可信：251条强制性规则、两次架构师评审，以及在部署前通过闭环智能体循环验证模型。

• 原生Unity Catalog部署：模式、表、外键、分类标签、指标视图、RDFS本体、DBML图表和示例数据，所有内容均同步生成并版本化。

用户反馈是最高权威

整个智能体遵循一个核心原则：您的指令具有最高优先级。在控件中、model_vibes中或业务描述中的明确指令，将超越流程中所有启发式规则、评分公式、门禁机制和LLM意见。如果您明确要求“恰好10个领域”，任何层级分类器都不可能添加第11个。

优先级金字塔：用户反馈始终胜出；其他所有内容都服务于这一目标。

从灵感变为数据模型

在四个控件背后，代理运行一个包含四个阶段的流程：它理解你的输入，自上而下设计模型，通过关系和指标连接模型，然后进行部署。每个阶段在进入下一阶段前都会进行验证，因此只有通过验证的阶段才能继续推进。在底层，这是一个多模型集成系统：一个大型思考模型负责推理和评审，一个大型工作模型生成大量产品和属性，较小的模型处理领域、标签和示例数据，而一个评审模型则根据统一标准对竞争方案进行评分。清单具有自我修复能力，会降级表现不佳的模型，并在模型恢复健康后重新启用它。

四个阶段，生成-验证-推进，由251条规则、两次架构师评审和一个封闭的代理循环进行管理。

模型的组织方式

每个模型都遵循相同的结构，从上到下：组织、部门、领域、子领域、产品、属性。最顶层是几乎所有组织都拥有的三个部门：运营（他们做什么）、业务（他们服务谁）和企业（他们如何运作）。运营和业务是核心，企业是支持性的少数部分。领域是一个拥有独特概念集的有界上下文；产品是领域专家能识别的真实业务概念（如发票、订单），而不是管道或分析；每个属性都必须通过验证才能获得其位置。

六层层级结构。部门包含领域；领域包含子领域和产品；产品拥有属性。

三个部门。运营和业务部门至少包含80%的领域；企业部门是支持性的20%或更少。

单一数据源与清晰的图结构

两个结构性保证确保模型的连贯性，且均受到强制约束。单一数据源意味着一个概念只能由一个产品拥有；客户在customer.customer中被定义一次，其他所有内容都通过外键引用它。关系形成有向无环图：外键从子节点指向父节点，不会形成循环，没有产品被孤立，当主键确定时冗余列会被规范化处理。

单一数据源：一个概念，一个所有者。清晰的有向无环图：外键从子节点指向父节点，不会形成循环。

保障可信性的规则

代理在20个组别中执行251条规则。结构性规则是确定性门禁，它们读取真实模型字典，因此无法通过说服改变判断结果，这些规则在模型构建过程中运行，并在安装门禁阶段再次针对已部署模型执行。运行报告的质量评分由模型本身计算得出，而非LLM的自我评估。

251条规则分布在20个组别中；当修复是机械性时会自动修复。

代理循环：生成、验证、以不同方式重试

单次LLM运行的结果从不被视为最终结果。循环生成一次具体尝试，将其与确定性门禁和静态分析进行验证，失败时会改变策略而非重复尝试。未满足的需求和结构性残留（非规范化键、跨领域重复、未连接或循环的外键）会路由到沙盒修复步骤，再通过验证返回。单调性守卫会撤销任何使模型变差的运行，因此模型只能改进或保持不变。

生成、验证、以不同方式重试。发现的问题会路由到沙盒修复步骤，再通过验证返回。

如何验证灵感

当您进行迭代时，请求会被解析为结构化的验证需求（VREQs），每个需求都是一个独立的、可检查的指令。每个需求由沙盒化的修改器执行，并独立验证，尽可能实现确定性：验证过程会读取实际模型和物理 Unity Catalog，而不是询问语言模型变更是否发生。运行结果会报告合规性评分，未验证的内容会被重新排队，而不是被静默丢弃。

每个灵感都会转化为验证需求，逐一应用，然后分别与实际模型和目录进行验证。

两个架构师关卡

规则用于捕捉机械性错误；架构师关卡用于捕捉结构性不当。领域架构师会独立审查每个领域；全局架构师会审查整个模型，检查跨领域重复、单一数据源违规和结构完整性。发现的问题会自动应用，并标记为已落地、回归或被阻止，审查会重复运行最多八次直至干净。

领域架构师审查每个领域；全局架构师审查整个模型。审查会重复运行直至干净。

一次运行的产出

• 一个逻辑模型（model.json），包含所有领域、产品、属性、外键和分类标签。

• Unity Catalog 中的物理部署：模式、表、外键（信息性）和分类标签。

• Unity Catalog 指标视图：可在产品上复用的 KPI 定义，适用于 AI/BI 仪表板和 Genie。

• 用于语义工具和 AI 代理的 RDFS 本体，以及用于 dbdiagram.io 的 DBML 文件。

• 针对同一模型生成的合成样本数据，以及完整的管道日志和建议优化的 next_vibes 文件。

model.json：单一数据源

代理生成的所有内容都源自一个文件，即 model.json。物理部署、本体、DBML 图表、指标视图、样本数据、文档和 next_vibes 建议都是从它生成的。没有任何内容被重复编写，因此逻辑模型和所有下游产物永远不可能出现偏差。

model.json 是权威的。所有其他产物都由它生成。

在 Unity Catalog 中落地的内容

当您设置部署目录时，领域会变为模式，产品会变为 Delta 表，属性会变为列；外键作为信息性约束应用；分类标签（PII、术语表、来源）在构建过程中应用；指标视图则部署在顶部。

逻辑模型.json 转化为真实的 Unity Catalog 对象：模式、表、列、约束、标签和指标视图。

两个范围：MVM 和 ECM

大多数团队在第一天不需要所有领域，因此代理会从同一引擎生成两个范围。最小可行模型是精简的核心，优先构建；扩展覆盖模型则是覆盖整个业务的完整模型。您可以构建任一模型，将 ECM 缩小为 MVM，或将 MVM 扩展为 ECM，且缩小过程由语言模型引导以保护核心产品。

MVM 和 ECM 是同一模型的两个范围，受相同规则和架构师关卡约束。

持续优化直至契合

优化过程正是 Vibe 数据建模得名之处。v1 是基础模型，它持续向前演进，永不横向扩展：不会覆盖任何版本，每次迭代均可审计和回滚。变更有三种意图模式：手术式（精确修复）、整体式（全局应用）和生成式（创建新内容），所有模式均受相同规则和审查约束。

每个 vibe 操作都会在相同的质量机制下，以三种意图模式之一生成一个新版本。

一个代理，六种操作

同一个笔记本不仅能构建首个模型。操作控件可选择六种操作中的一种，所有操作共享相同的规则、架构门控和代理循环。

一个代理实现的六种操作：构建、vibe、收缩、扩展、安装和生成示例数据。

如何对版本进行 vibe 操作（VOV）

要对现有版本进行 vibe 操作，请选择“版本的 vibe 建模”操作，指定要构建的版本，并用纯英文编写更改内容（或粘贴 next_vibes.txt 中的建议）。代理会将其解析为 VREQ，基于该版本重新运行流水线，并生成一个新编号版本；原始版本保持不变。

对版本进行 vibe 操作的步骤：选择操作、选择版本、编写变更、运行。新版本会被创建；原有版本保持不变。

一个逻辑模型，多种物理布局

逻辑模型是一个独立的产物；物理布局是通过一个控件单独控制的决策。同一模型可以渲染为一个目录、每个部门一个目录或每个领域一个目录。如果治理规则发生变化，只需重新部署到不同规范；逻辑模型保持不变。

一个逻辑模型，三种有效的物理布局。切换规范无需重新构建。

行业模板并不足够

通用模板的论点始终是提供先发优势。但通过实践发现，这种先发优势需要耗费九到十二个月的时间进行适配和重命名。模板是行业的平均模型，按其构造方式，它并不对应任何实际业务。Vibe 数据建模能以你的术语生成模型，包含你的部门和领域，可在数小时内完成，并通过与其他模型相同的规则进行验证。

通过代理构建的示例模型

同一个行业无关的代理已在多个不同领域生成完整的业务扩展覆盖模型，每个模型都引用了其行业公认的规范。下方数字是开源仓库中已发布的参考模型数量。

通过代理在电信、航空、零售和医疗领域构建的参考扩展覆盖模型。

现已可用

参考实现是一个单独的 Databricks 笔记本：agent/dbx_vibe_modelling_agent.ipynb。填写四个核心控件并运行即可；其余部分将根据你的行业自动选择默认值。

四个控件，一次运行。其余部分会为你的行业选择合理的默认值。

一个具体的起点：这里是我们用于生成制造模型的提示语，以及我们发送的第一个纯英文 vibe 以优化结果。

你的初始提示语，以及用于优化结果的第一个 vibe。

• 参考仓库（github.com/databricks-industry-solutions/lakehouse-industry-data-models）：包含代理笔记本、调度器、测试框架、40+ 开源参考模型，以及涵盖设计、集成、质量门控和规则目录的指南。

• 《Vibe 数据建模白皮书》：完整描述每个流水线阶段的技术细节、完整的规则目录、架构评审方法论和集成架构。

如果团队已经花费数月时间推进 Silver 层项目却未交付，这是我们找到的最快落地路径。用纯英文描述你的业务，获取模型，迭代直至匹配需求，最终投入生产。

将最新文章直接发送到您的邮箱

订阅我们的博客，即可将最新文章直接发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"