Databricks发布制造业数据与AI产品价值链方案
Databricks博客阐述如何用零拷贝共享、Lakehouse Federation和Unity Catalog把制造企业分散在MES、ERP、QMS等系统中的数据连接起来，使跨阶段追溯问题变成一次查询。
AI解读：Databricks这篇博客本质上是一份产品能力说明：制造企业查一个质量缺陷，往往要在MES、过程历史库、供应商质量系统、QMS和 8D记录之间来回导数据、开单据，而Databricks想卖的是把这套流程变成一条SQL查询。
关键机制有三个：数据不必全部搬进Databricks，可以用零拷贝Open Sharing和Lakehouse Federation原地查询；用序列号、批次号或零件号作为跨系统连接键；再用Unity Catalog统一治理联邦数据和镜像数据。
受影响最大的是两类人：工厂质量工程师和采购分析师。他们以后不必等报表或找数据专家，可以直接用自然语言提问，但答案的可靠性取决于企业是否提前把KPI、度量口径和连接关系定义好——博客自己也强调，没有治理好的语义层，对话式查询不可信。
博客给出了一个已经落地的参照：梅赛德斯-奔驰韩国采用了这套模式。但全文以产品能力介绍和演示为主，没有公开查询速度、缺陷追溯耗时缩短比例或成本节省数字，实际效果还需企业自己验证。
Databricks在博客中提出，制造企业最难回答的问题往往是跨阶段的：哪一批供应商来料进入了受影响的产品？这个缺陷以前出现过吗？纠正措施是否有效？哪些客户或服务工单可能受到影响？但调查这些问题所需的数据通常分散在工厂、职能部门和系统边界之间。Databricks认为，解决方式不是给每个阶段各建一套孤立报表，而是把产品价值链上的数据连接起来，并用统一的治理和业务上下文让这些信息可用。
产品价值链覆盖从研发到售后服务的各阶段系统
博客把制造业产品价值链定义为从原材料和创意到交付给客户并在现场获得支持的全流程，连接研发与工程、采购、生产与质量、物流与供应链、销售与营销、售后与现场服务。
每个阶段运行各自的系统：研发与工程使用PLM、CAD、CAE与仿真、测试数据、需求管理和工程BOM；采购使用ERP采购、source-to-pay、合同、供应商风险和供应商门户；生产与质量使用MES、SCADA/PLC数据、过程历史库、QMS/LIMS和维护系统；物流与供应链使用ERP、WMS、TMS、计划系统、EDI和远程信息处理；销售与营销使用CRM、CPQ、定价、经销商管理、营销自动化和电商；售后与现场服务使用服务管理、保修、备件计划、互联产品数据、诊断和工单。
跨系统查询是真正的问题所在
博客用两个例子说明现状。工厂质量工程师要判断废品率飙升是批次、机器还是设置造成的，是否仍在发生，以前是否见过这个缺陷、修复是否有效，以及为什么某工厂同一零件的报废率远高于另一工厂。这些问题横跨MES记录、过程历史库数据、供应商和SQM数据、QMS历史、8D记录，往往还涉及多个工厂实例。
采购分析师要判断哪些关键零件依赖一个已被标记为交付风险的单一供应商，某供应商的准时率和质量表现是否在近期订单中下滑，以及如果该供应商出问题，哪些产品、工厂和未结订单会受影响。这些问题横跨ERP采购和source-to-pay记录、合同、供应商风险信息和供应商门户。Databricks称，目前回答这些问题意味着开单据、人工导出，并依赖少数专家；把数据集中起来并用序列号、批次号或零件号作为连接键后，追溯就变成一次查询。
Databricks给出的四项平台能力
博客称，连接价值链不需要对每个源系统做一次破坏性迁移。通过零拷贝Open Sharing和Lakehouse Federation，组织可以访问源系统中的数据，而不必为每个用例新建ETL管道或副本；当适合镜像时，连接器和云对象存储提供将数据带入湖仓的路径。
四项关键能力分别是：第一，池化或联邦源数据，质量工程师和采购分析师的问题都可以在不新增每问题ETL副本的前提下查询；第二，用Lakeflow做编排和精炼，把原始输入变成受治理的金表，通常经过Bronze、Silver、Gold层；第三，用Unity Catalog作为镜像和联邦数据的单一控制面，提供统一的权限模型、完整血缘以及覆盖数据、模型和AI代理的发现能力，Unity Gateway用于控制AI访问、开销以及对代理、工具、模型和MCP的可观测性；第四，代理能力，包括连接数据的AI同事Genie One、基于企业数据构建AI代理的Agent Bricks，以及让任何人用自然语言创建代理和应用的Genie App Builder。
自然语言查询依赖受治理的业务语义
博客提出，提升数据素养最快的方法是让人直接和数据对话，不用学查询语言、开单据或等报表。但对话式界面本身不够，答案必须建立在业务认可的受治理定义之上。
博客举了采购场景的例子：“哪些关键零件依赖一个现已被标记为交付风险的单一供应商”这样的问题，可能需要了解SAP特定的表头、连接和业务规则；采购分析师不应为了调查它而变成数据专家。Purchasing Genie Demo把模式拆成三步：准备受治理数据、构建专家代理，然后在supervisor下组合成一个受治理的应用并共享。这种模式把需要技术专长的工作（准备和治理数据）与业务用户应当自己能做的工作（提问、审阅答案、采取行动）分开。
在KPI报表场景中，当KPI定义位于受治理的语义层，BI工具和AI使用同一套业务逻辑；Genie Agents使用这些可信定义在职能内回答问题，Agent Bricks把它们组合成跨职能的基于角色的代理。博客称，结果是同一个问题每次得到同一个答案。博客提到梅赛德斯-奔驰韩国在实践中应用了这一模式。
实施路径与已给出的连接键选择
博客给出的三步实施路径是：第一，用Unity Catalog作为单一控制面，把数据池化一次并治理一次，覆盖镜像和联邦数据源；第二，以共享标识符作为连接键，让价值链一个环节的发现能驱动另一个环节的行动，使端到端追溯变成查询，具体用哪种标识符取决于领域，有的用序列化单元和VIN，流程制造用批次号；第三，让人们和数据对话，把自然语言访问建立在受治理的业务语义之上。
FAQ部分补充，制造商不需要把所有源数据迁移到Databricks，数据可以在源系统中原地查询并被Unity Catalog治理。追溯被定义为连接制造过程步骤、产品、材料和运营记录，支持从受影响产品向后追溯或从可疑材料向前追溯。LTAP指Lake Transactional/Analytical Processing，即在同一个受治理平台上运行分析和事务工作负载。平台支持批流一体，高吞吐机器和车辆遥测可以作为连续低延迟流接入；数据接入方式包括Zerobus Ingest的推送式流、Lakeflow Connect的托管连接器和变更数据捕获，以及Auto Loader和Structured Streaming；Delta表存储在云对象存储上，运行于AWS、Azure和Google Cloud，数据以Delta Lake和Iceberg等开放格式落地。