读取而非复制：用 OpenSharing 替代文件馈送——第二部分（如何实现）
内容提要
本文介绍 Databricks 通过 OpenSharing 共享表后接收方的用法。共享表保留历史，接收方可用 Structured Streaming 增量读取，Spark 通过检查点只处理新增数据，无需复制数据。示例中零售商共享订单表，接收方增量写入本地 Delta 表，第二次运行仅写入 200 行而非 1200 行。若需处理增删改，应读取变更数据馈送；非 Spark 接收方则按版本范围拉取变更。
延伸解读
增量读取的关键：历史与检查点
共享表必须发布时带上历史（WITH HISTORY），接收方才能将其作为 Structured Streaming 源。Spark 通过检查点记录已读到的版本，每次运行只处理新增数据。示例中第二次运行仅写入 200 行而非全量 1200 行，验证了增量机制。若共享时不带历史，接收方只能获得静态快照，无法实现增量读取。
何时需要变更数据馈送（CDF）
主增量读取使用 ignoreChanges，适合仅追加的落地模式，但可能重复发出行且不会传播删除。若下游需要处理插入、更新和删除，应改为读取共享表的 Change Data Feed。启用 CDF 是可选的，仅在需要 upsert 和删除路径时开启；Databricks Runtime 19 及以上可依赖自动 CDF，无需手动设置属性。
非 Spark 接收方的限制与替代方案
上述检查点流式读取和 CDF 依赖接收方在 Databricks 上运行 Spark。其他接收方（如 pandas、BI 工具、Snowflake）通过凭据文件连接 OpenSharing；若使用 OSS Spark，可用相同的 spark.readStream 代码通过 delta-sharing 连接器读取。没有 Spark 则无法持续流式读取，只能按版本范围拉取变更。
实施前的最小验证路径
建议从一个常规 Delta 表和一个接收方开始，先明确关键问题，再验证最小端到端流程：创建共享、读取初始快照、写入新行、更新一行、删除一行，并确认接收方看到预期结果。这样可避免一开始就试图解决所有共享场景，同时验证治理与访问控制是否按预期工作。
Q&A
OpenSharing 共享表如何实现增量读取而不复制数据？
提供方共享表时保留历史（WITH HISTORY），接收方将共享表作为 Structured Streaming 源。Spark 通过检查点记录已读取位置，每次运行只处理新增数据，数据始终留在提供方存储中，接收方实时读取。
接收方在 Databricks 上使用共享表需要做哪些配置？
接收方需有启用 Unity Catalog 的 Databricks 工作区，通过共享目录访问共享表。提供方创建源表并启用 Change Data Feed（可选），以 WITH HISTORY 发布到共享，注册接收方并授权。接收方将共享挂载为目录后即可像普通表一样读取。
如何验证共享表的读取确实是增量的？
先对初始数据运行一次流，然后在提供方添加新行后再次运行。目标表的提交历史会显示两次流写入：第一次写入 1000 行，第二次仅写入 200 行（而非 1200 行），证明检查点只拉取了新增数据。
如果下游需要处理插入、更新和删除，应该怎么做？
应读取共享表的 Change Data Feed（CDF），而不是使用 ignoreChanges 的增量落地模式。ignoreChanges 可能重复发出行且不传播删除，而 CDF 能捕获所有变更类型。
非 Spark 接收方（如 pandas、BI 工具）如何消费共享表？
它们通过 OpenSharing 使用凭据文件连接，而非元数据共享 ID。如果没有 Spark，就没有连续流，需按版本范围拉取变更。若运行 OSS Spark，可通过 delta-sharing 连接器使用相同的 spark.readStream 代码。
实施 OpenSharing 共享前需要明确哪些问题？
建议从一张常规 Delta 表和一個接收方开始，先回答：数据更新频率、接收方需要哪些变更类型、下游消费模式等。然后验证最小端到端流程：创建共享、读取初始快照、写入新行、更新行、删除行，并确认接收方看到预期结果。
