从“一天一刷”到“小时级”:Procore 用 OpenSharing 重写建筑数据分发规则

来源:爱集微 #Procore# #数据共享# #建筑科技#
844

当地时间10月29日,Databricks 官方博客披露:建筑管理软件上市公司 Procore 已基于开放共享协议 OpenSharing 完成 Procore Analytics 第二代产品的重建,一举打破旧架构每日一次的数据刷新上限,实现小时级数据拉取,并向客户分发数百张治理表、管理数十万级数据共享。在建筑业这一数据割裂程度最深的行业之一,一家 SaaS 巨头把“数据出口”从 API 拉取整体切换为开放协议共享,其方法论与治理细节值得全行业参考。

一、事件聚焦:刷新上限被打破,数据目录翻倍

10月29日,Databricks 官方博客刊发《How Procore is powering construction analytics with OpenSharing》,系统披露了 Procore 基于 OpenSharing 重建其商业智能产品 Procore Analytics 的做法。这篇由 Databricks 员工 Krishan Kumar 署名的案例文章,给出了本次升级最核心的三组事实:其一,客户数据拉取频率从“每日一次”的硬上限放开为小时级;其二,OpenSharing 现已向客户分发数百张经过治理的精选表,并按客户分区维护访问控制,支撑数十万量级的独立数据共享;其三,可提取数据的目录规模实现翻倍。

Procore Analytics 是 Procore 面向客户的商业智能方案,定位是把平台上已连接的项目数据以编程方式交付到客户自有的工具链中——无论是 Power BI、Tableau,还是 Snowflake、BigQuery、客户自建的 Databricks 工作区,乃至本地部署的 SQL Server 。Procore 本身是全球领先的建筑管理软件提供商,官方企业资料显示其客户超过 17,000 家、年度用户超过 200 万,平台覆盖 150 余个国家和地区;2021年5月,公司在纽约证券交易所上市,代码 PCOR。

对终端客户而言,刷新节奏的变化直接重塑了工作方式。案例文章称,客户现在按照自身业务的节拍调度刷新,许多原本每日拉取一次的客户实际上一天拉取多次,频率取决于其下游工具的支持能力;项目经理在早晨收到高管的多处修改意见后,可以在客户会议前让实时看板完成同步——而在旧模式下,这些细节只能在会议现场口头解释。以第一代产品建成的目录规模为基准 100 计,新一代产品的等效规模达到 200。

资本市场对 Procore 的基本面亦有注解:据公司季报,2026年第二季度实现营收 3.75 亿美元、同比增长 16%;并首次达成 GAAP 口径经营盈利,GAAP 经营利润率 1%、非 GAAP 口径 21%;年度经常性收入超过 10 万美元的客户达 2,871 家、同比增长 14%。在增长与盈利同步改善的节点上重建数据分发底座,Procore 的意图不止于修补产品,而在于为下一阶段的报表、分析与 AI 能力铺设统一的管道。

 

图1  Procore Analytics 可提取数据目录规模指数(1.0 代基期=100) 

二、旧架构的天花板:API 拉取模式的成本与可靠性困境

第一代 Procore Analytics 完全早于 OpenSharing 而存在。其技术路线是:从 Procore 公共 API 抽取数据,装载进一个 Azure 数据库(后端为 SQL Server),客户对该数据库进行查询 。

这套架构能跑通,但存在一个刚性的天花板:数据刷新被限定为每日 1 次,即便客户为额外刷新付费,上限也只有每日 3 次。对于以小时为单位变化的建筑工地而言,这种滞后被案例文章称为“最大的单一限制因素”。

比刷新频率更深层的问题在成本与可靠性。面向数以万计的客户通过公共 API 拉取数据,意味着要运行深度递归调用——这类调用昂贵、脆弱,容易出现超时或触发调用限额 。换言之,旧架构的瓶颈并非某一项参数设得保守,而是“逐客户、逐接口拉取”这一分发范式本身在规模化时不可持续。这也是后来切换到“原地共享”范式时,成本、脆弱性与超时风险被一并移除的原因。

 

图2  Procore Analytics 1.0 的每日数据刷新上限 

三、新底座:Medallion 分层、两条接收路径与统一语义层

第二代 Procore Analytics 构建在 Databricks 的 Medallion(铜银金)分层架构之上。原始事件从 Procore 应用数据库与集成事件原样落入 bronze 层;silver 层完成清洗、校验与数据质量检查,产出下游一切依赖的“确认数据集”;gold 层负责聚合、优化与面向分析的建模。三个层均跨多个区域运行,使处理尽量靠近源数据;各区域的 gold 表随后汇入唯一的主分析区域,OpenSharing 正是在这里把数据扇出给客户。

接收端设计了两条路径:未使用 Databricks 的客户直接在 Procore 应用内生成 OpenSharing 令牌,以开放协议接入;已使用 Databricks 的客户只需添加自己的工作区标识,即可通过 Databricks 到 Databricks 的原生共享接收数据,全程无需搬移数据。Power BI、Tableau 等 BI 工具开箱即用,其他数仓平台的客户也可使用开放的 OpenSharing 客户端库消费同一份共享。

值得注意的工程细节有三处。其一,共享粒度下探到模式(schema)、视图、表与分区四级,并且表启用了变更数据馈送(Change Data Feed),接收方可以自行选择全量消费或仅同步自上次以来的增量——这对单表数百万条记录的场景尤为关键。其二,同一 gold 层同时驱动 Procore 应用内报表与客户提取产品,因此两边的模式与命名约定天然对齐:客户在 Procore 界面看到的数值,与提取到手里的数值同名同值。其三,Procore 没有回避数据分发的“变更管理”问题——向数千个下游客户环境供数,意味着任何破坏性变更(如字段改名、类型变更、表结构重组)都可能击穿客户的管道,这一点由专门的发布节奏机制加以约束。

从更长的技术脉络看,OpenSharing 并非凭空出现:Databricks 于2021年5月发布 Delta Sharing,将其定义为业界首个安全数据共享开放协议,并捐入 Linux 基金会;2026年6月,Databricks 宣布 OpenSharing 作为 Delta Sharing 的下一代演进,由 Linux 基金会托管,扩展了对 AI 资产(智能体技能、模型、非结构化数据)的共享,并新增 Iceberg 客户端支持。Procore 的案例,是这一开放协议在垂直行业里迄今较为完整的一次规模化落地。

四、治理与规模:数十万级共享如何管住

规模之外,本次案例更值得行业讨论的是治理设计。所有共享经由 Unity Catalog 集中治理,访问控制在用户与项目两个维度上强制执行。其结果是一个典型但此前难以低成本实现的场景:总承包商可以把项目进度共享给业主,同时将自己的财务数据保持在私密状态。

支撑这一控制的是一套自动化授权机制:一个定时作业监视新增共享与权限变更,从 Procore 应用中读取每位用户的权限,并据此与 OpenSharing 授权进行对账,最终实现按用户、按项目的强制管控,全程无需人工配置。也可以仅向特定分包伙伴共享限定在其业务范围内的数据。对于管理成百上千个并发项目的客户来说,授权的自动化程度直接决定了数据分发的边际成本。

与治理配套的是一套克制而可预期的变更纪律。Procore 最终确定:每年进行 4 次破坏性变更发布,提前六周通知;每年进行 12 次非破坏性变更发布,提前三周通知,并与公司整体发布日历对齐。把“何时可以打破兼容性”变成一个公开、有限、可预告的契约,是数据产品化区别于内部数据管道的分水岭。

组织层面同样完成了重构。旧世界中存在两条并行管道——一条服务分析、一条服务应用内报表,各自拥有独立的摄入、建模与治理;新世界将其合并为一条路径,由单一组合管道承担摄入、落地、建模与治理,再按财务等业务领域组建数据域团队,端到端负责各自领域的数据,并与相关应用团队协同处理各工具的细节,而非在分析、报表与智能团队之间重复建设。

 

图3  Procore Analytics 2.0 年度发布节奏构成 

五、影响与展望:从报表统一到 AI 数据底座

案例文章将最直接的商业成果归纳为数据可用性。第一代产品花费数年才建起基础的可提取表与字段目录,而新一代产品以不足一半的时间将目录扩展到数百张表,客户可规模化提取的数据面等效翻倍。这对 Procore 的产品节奏意义重大:新功能上线后,其数据几乎随发布即可被客户提取,不必再等待一条并行的分析管道花数个月跟进。

财务面为这场底层重构提供了注脚。Procore 2025财年营业收入为 13.23 亿美元 [P5];公司指引 2026财年营收区间为 15.10 亿美元至 15.14 亿美元,按区间高端计同比增长 14.5%,并预计 2027财年非 GAAP 经营利润率达到 25%。在从高增长转向“有质量的增长”的阶段,把数据分发从成本中心改造为产品体验的一部分,与其利润率扩张路径是同向的。

把视野放大到行业,数据基础设施的完善正在改变建筑业对 AI 的想象空间。麦肯锡研究称,生成式 AI 有望为建筑行业带来约 330 亿美元至 570 亿美元的新增年度经济价值;广联达高管在公开访谈中亦引述了同一区间。而 AI 应用的共同前提,正是案例文章反复强调的那组定语:干净的、经过建模的、被治理的、持续可用的数据。

Procore Analytics 产品经理 Matthew Guptill 在案例文章中的表述,可以被视作对这轮升级的官方定调:“OpenSharing 帮助我们提升了数据可用性,这意味着建筑业中的每一个人——从高管到项目经理再到现场人员——对自己所做的项目都有了更好的可见性。它正在帮助人们按期、按预算、安全地交付项目。” 当企业级报表、经营分析与新兴 AI 用例都从同一个可信、最新的数据源取数,而非依赖一连串一次性集成时,Procore 自创立以来“让建筑业所有人在同一平台上连接”的叙事,才算真正落到了数据这一层。

 

图4  Procore 年度营业收入:FY2025 实际与 FY2026 指引(亿美元) 

 

图5  生成式 AI 为建筑行业带来的年度新增经济价值区间(麦肯锡测算) 

结论

Procore Analytics 的重建,表面看是一次产品升级,实质是一次数据分发范式的切换:从“逐客户 API 拉取”转向“基于开放协议的原地共享”。前者以牺牲刷新频率为代价换取实现简单,后者以统一治理为前提换取规模、时效与成本的可扩展性。

这轮切换给出了三个可复制的工程要点:以 Medallion 分层与多区域部署保证数据就近处理与统一出口;以自动化授权对账支撑按用户、按项目的细粒度管控;以有限、可预告的变更节奏(每年 4 次破坏性、12 次非破坏性变更)维系对数千下游环境的兼容承诺。

对建筑科技行业而言,当数据出口从私有接口走向开放协议,业主、总包与分包之间的数据协作边界将更多由治理策略而非接口开发来定义;对更广泛的企业软件行业而言,本案例再次验证了一个朴素的判断——AI 时代的竞争,始于把数据干净、可治理地流动起来。

责编: 爱集微
来源:爱集微 #Procore# #数据共享# #建筑科技#
THE END

*此内容为集微网原创,著作权归集微网所有,爱集微,爱原创

关闭
加载

PDF 加载中...