Procore 如何借助 OpenSharing 驱动建筑数据分析
内容提要
Procore Analytics 2.0 基于 Databricks 与 OpenSharing 重构数据架构，取代旧版每日限次刷新的 API 抽取模式。新架构采用青铜、白银、黄金三层数据管道，跨区域处理，并通过 OpenSharing 向客户分发数百张治理良好的数据表，支持 Power BI、Tableau 及 Databricks 原生共享，并按用户和项目自动执行权限控制。可提取数据目录规模翻倍，构建时间减半，刷新频率不再受限，新功能数据几乎即时可用。
延伸解读
从API抽取到共享：架构转变的核心价值
Procore Analytics 1.0依赖公共API递归抽取数据，不仅刷新频率被限制在每日一次（付费最多三次），还面临超时、成本高和脆弱性问题。2.0改用OpenSharing直接共享治理好的数据表，消除了API调用的瓶颈。这一转变的关键在于将数据分发从“拉取”变为“推送”，使刷新频率不再受技术限制，客户可按业务节奏安排同步，尤其适合条件每小时都在变化的建筑项目。
权限控制与数据隔离的实际意义
新架构通过Unity Catalog集中治理，并按用户和项目自动执行权限。文章举例：总承包商可以向业主共享项目进度，同时保持自身财务数据私密；也可仅向特定贸易伙伴共享其范围数据。这种细粒度控制由定时任务自动协调，无需手动配置。对于多参与方、数据敏感的建筑工程，这意味着客户能在不暴露商业机密的前提下实现协作，降低了数据共享的信任门槛。
数据目录翻倍与发布节奏的平衡
Procore Analytics 2.0在不到一半的时间内将可提取数据表扩展到数百张，目录规模翻倍。这得益于青铜、白银、黄金三层管道和统一的语义层，使新功能数据几乎即时可提取。但向数千个下游环境分发数据也带来破坏性变更的风险，因此Procore设定了每年四次破坏性变更（提前六周通知）和十二次非破坏性变更（提前三周通知）的节奏，在快速迭代与客户管道稳定性之间取得平衡。
对客户工作方式的直接影响
刷新频率限制解除后，客户不再受每日一次的限制，许多客户每天多次拉取数据。文章描述了一个具体场景：项目经理在重要客户会议前收到高管的临时更新，可及时反映在实时仪表板中，而旧模型下这些细节只能在会议中口头解释。此外，统一的黄金层确保Procore界面中的数值与客户提取中的数值名称和值一致，减少了跨工具核对数据的工作量。
Q&A
Procore Analytics 2.0 相比旧版在数据刷新频率上有什么改进？
旧版 Procore Analytics 1.0 每天只能刷新一次，即使付费额外刷新也最多每天三次。2.0 版本通过 OpenSharing 取消了这一限制，客户可以根据业务节奏安排刷新，许多客户每天多次刷新。
OpenSharing 如何帮助 Procore 扩大可提取的数据目录规模？
OpenSharing 允许 Procore 向每个客户共享数百张经过治理的数据表，并支持按客户分区访问，从而管理数十万个数据共享。这使得 Procore Analytics 2.0 在不到一半的时间内将可提取的数据目录扩大到数百张表，规模翻倍。
Procore 如何确保不同客户和项目之间的数据权限隔离？
Procore 通过 Unity Catalog 集中治理每张表，并自动执行权限控制。一个定时任务会监视新的共享和权限变更，从 Procore 应用中读取每个用户的权限，并相应调整 OpenSharing 的授权，实现按用户和按项目的权限执行，无需手动配置。
Procore Analytics 2.0 的数据架构分为哪几层？各自的作用是什么？
采用青铜、白银、黄金三层架构：青铜层原样接收来自应用数据库和集成事件的原始数据；白银层进行清洗、验证和质量检查，生成确认数据集；黄金层对数据聚合、优化和建模，供分析使用。黄金层数据从各区域汇总到主分析区域，再通过 OpenSharing 分发给客户。
客户如何通过 OpenSharing 接收 Procore 的数据？
有两种路径：没有 Databricks 的客户在 Procore 应用内生成 OpenSharing 令牌，使用开放协议连接；已有 Databricks 的客户添加工作区标识符，通过 Databricks 到 Databricks 的原生共享接收数据。BI 工具如 Power BI 和 Tableau 可直接使用，其他平台可通过 OpenSharing 客户端库消费。
Procore 对数据架构的破坏性变更采取了怎样的发布策略？
Procore 每年进行四次破坏性变更发布，提前六周通知；每年进行十二次非破坏性发布，提前三周通知。破坏性变更包括重命名字段、更改列数据类型或重构表等可能中断客户下游管道的操作。
