通过这种方式访问数据比通过数据共享要复杂得多。从我们所有的研究和与客户的讨论来看，似乎实际上有两种方式可以访问 Salesforce Data Cloud 中的仓库数据：
将其复制到 Salesforce Data Cloud： Salesforce 将此副本称为“加速数据对象”，并巧妙地将此操作称为“缓存”。实际上，这意味着您查询仓库并将整个数据集复制到 Data Cloud 内的外部数据湖对象 (DLO)。根据我们的经验，Salesforce 通常会推荐此选项，因为它将使他们的受众查询性能更高，并且 Salesforce 还可以通过向客户收取额外的缓存存储费用而受益。从字面上看，它不是零拷贝解决方案：您必须将数据复制到 Salesforce Data Cloud。
运行混合查询：第二种选择最 全球数据中的海外华人 接近零拷贝的本质，似乎允许受众查询直接混合数据云中本地存储的数据和仓库中的数据。我们从客户那里听说，这种解决方案的扩展性不佳，并且完全不适用于超过几百万行的表。另外值得一提的是，虽然底层数据保留在仓库中，但任何受众的实际结果都会发布并存储在数据云中。
总结：只有当您使用“数据共享”访问仓库中的 Salesforce 数据时，Salesforce 的零拷贝架构才是真正的零拷贝。但是，在 Salesforce Data Cloud 中直接使用仓库数据 (BYOL) 需要额外的工作和持续的维护，不必要地昂贵，并且实际上会将您的数据复制到 Salesforce 的基础设施中。此设置还有其他几个技术缺陷：
为了让 Salesforce Data Cloud 查询和聚合您的数据，数据仓库中的所有对象都必须直接映射到 Salesforce 的标准 Customer 360 数据模型；否则，该数据将无法用于数据联合。您无法按原样提供数据，必须通过将数据明确映射到 Salesforce 的数据模型来限制自己。这很难做到，而且还需要您将这些重构的数据装入 Iceberg 表中 — 这又是您需要管理的另一个复杂问题。
存在限制、延迟，并且无法支持大容量数据集：许多 Salesforce Data Cloud 功能仅当您的数据本地存储在 Salesforce 中时才可用。只有有限数量的受众可以使用 BYOL 数据集，而且这些数据集只能每 12 小时计算一次（根据他们的文档）。根据数据集的大小，查询限制也很明显。举个例子：我们目前正在与一家大型零售商合作，该零售商无法通过 BYOL 从其仓库中查询超过数百万条记录的任何数据集。
创建数据的多个副本：如上所述，BYOL 数据联合将数据复制到 Salesforce Data Cloud。然后，如果您想在 Salesforce 生态系统中的其他工具（如其 CRM 或 Salesforce Marketing Cloud）中使用该数据，则需要为每个工具制作另一个副本 - 它们无法从原始数据存储中执行操作。