Databricks 提出 OpenSharing：用就地读取替代客户数据复制管道

做数据工程的人大概都经历过这样的场景：客户每周通过 SFTP 丢一个文件到指定目录，你的作业脚本去拉取、解析、入库。第一个客户没问题，第五个开始有格式偏差，第二十个的时候你的管道已经变成了二十个独立的小系统，每个都有自己的怪癖、自己的失败模式和自己的回填逻辑。

Databricks 工程团队 Jordan、Soldo、Nikhil 和 Tallam 在博客中把这个问题拆解为三层隐性成本：管道维护（每个客户都有独特故障点）、增量跟踪（你必须自己记住上次处理到哪里，一旦簿记漂移就会重复或遗漏）、回填依赖（出了 bug 需要重处理几个月数据时，你得求客户重新导出）。

他们提出的替代方案是 OpenSharing，一个基于 Delta Lake 和 Iceberg 开放表格式的协议。核心思路用一句话概括：不要复制，就地读。

具体机制是这样的：客户已经维护着一张表，你通过 OpenSharing 协议直接读取这张表，而不是让客户导出文件给你。当你的管道运行时，它读取表的变更数据流（Change Data Feed），从中获知哪些记录被创建、删除或更新。这意味着你不再需要自己维护一张记录处理进度的表——管道会自动管理这个检查点。

传统模式里，客户为了喂给你数据，必须搭建并维护一个导出管道——有自己的调度、格式和失败模式。OpenSharing 把这件事简化为一个授权操作：在客户已有的表上授予你读取权限。

对系统性能的影响，作者的解释是：你读取的是云存储上的表文件，用的是自己的计算资源，而不是查询客户的数据库，因此不会拖慢客户的系统。

作者还强调协议的开放性：因为建立在开放表格式上，读取方不需要使用 Databricks 平台。

需要指出的是，这是 Databricks 对自身产品的设计说明，没有附带客户迁移数据、性能基准或与现有方案的量化对比。所声称的收益——消除管道维护、回填变查询、双方节省存储——是架构设计的预期结果，而非已验证的生产指标。

对于正在维护多个客户数据管道的团队，这篇文章的价值在于提供了一个清晰的架构对比：传统模式的成本结构（线性增长的维护负担）与就地读取模式的成本结构（固定协议 + 表自带版本历史）。是否值得迁移，取决于你对自己管道复杂度的诚实评估。