--- schema_version: "1" id: bf3b883f45b6d8ba7831318c033bda6ae06d44ed855a878a2d349831267269e9 title: Data 360 互操作性 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/decision-guides/guides/data-360-interoperability.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/decision-guides/guide/data-360-interoperability.html source_site: architect.salesforce.com content_type: documentation content_hash: e2094695ae0441563e3f24eb85a03a7d7f5be74c8d3cda26983b6903e09925fb products: - 决策指南 - Architect Site Content Repo updated_at: 2026-07-01T00:00:00Z --- # Data 360 互操作性 企业通常会将数据存储在 Salesforce 和其他外部数据湖中（例如，_Snowflake_、_Google BigQuery_、_数据块_、_Redshift_ 或 _Amazon S3_ 等对象存储）。对于希望充分利用数据价值来支持 AI 驱动的体验的公司来说，在多个系统中竖井式数据给他们带来了挑战。Salesforce _Data 360_ 是基础情报层，每个 Agentforce AI 客服人员都用它来在正确的时间访问正确的上下文。 致力于跨多个数据湖将数据集中在一起的架构师面临着关于如何最好地集成这些数据的关键架构决策。_Data 360_ 为数据集成提供了多个选项，每个选项都有各种利弊。 ## 指南概览 本指南提供了一个框架来评估在集成数据时哪种模式最适合您对延迟、成本、可扩展性、治理和复杂性的要求，帮助您选择何时使用数据接收、零复制数据联合或混合方法。该指南还将帮助您在不同数据摄取和数据联合方法之间进行选择，每种方法都满足不同的需求。 将外部数据湖库与 _Data 360_ 集成需要仔细考虑数据新鲜度、治理和漏斗效率之间的权衡。例如，使用 Zero Copy 数据联合实时查询可以最大限度地提高数据的新鲜度，但随着更多数据通过网络移动，可能会降低漏斗效率。对于大多数真实世界的实施，在多云湖滨别墅生态系统中结合引入和聚合是最佳路径。这种混合方法确保了可扩展的、受管的、可互操作的架构，该架构支持低延迟操作工作负载（例如，实时个性化和欺诈检测）和分析工作负载（例如，监管报告和历史趋势分析）。本指南帮助您确定如何使用适当的策略导航这些权衡。 ## 重要外卖 - **数据接收**将数据复制到 Salesforce _Data 360_ 中，并创建受管的规范数据模型。这是您需要时的理想选择： - **建立一个全面的 Customer 360。**这允许您将不同的源统一并转换为一个受信任的简档。 - **满足严格的监管合规要求。**这允许您创建可审计的集中副本，以便可以紧密控制数据访问和谱系。 - **Zero Copy Federation** 实时查询外部源，没有重复，实现了实时个性化、实时仪表板和快速源入门。这种方法提供了两个主要选项，但有一些权衡需要平衡： - **实时查询：**将其用于交互式分析和在外部数据平台(例如 _Snowflake_、_BigQuery_、_Redshift_ 或_数据块_)中实时显示的数据仪表板。通过将查询处理推送到源系统并仅返回必要的结果，这有助于避免缓慢且代价高昂的数据重复。这种方法针对新鲜度至关重要的不频繁或临时查询进行了优化。它适用于低_查询/秒 (QPS)_ 工作负载(查询成本在高 QPS 时可能会大幅飙升)。 - **缓存（加速查询）：**将其用于不经常更改的频繁数据查询。加速查询会保持本地缓存，缓存会以可配置的时间间隔（15 分钟到 7 天）更新，这会减少源的重复命中。这种方法平衡了仪表板性能和成本、细分和 BI 工作负载，其中的结果稍微过时是可以接受的。这不适用于亚秒决策。 - **文件联合:**将其用于云数据湖中数据的大规模批处理和 AI 模型训练（例如 _S3_ 或 _ADLS_）。这种方法通过直接查询开放表格式的文件来避免缓慢、昂贵的接收，从而释放了庞大的 ETL 数据集和数据科学工作负载。 - **混合模型**将_统一简档_的摄取与新鲜感的融合在一起,后者支持全方位参与、Agentforce 驱动的操作和 AI/ML 培训。 ### 重要注意事项 - **采用混合架构。**通常，需要混合数据摄取和联合。 - 对规范数据模型和核心治理的关键数据使用_数据摄取_。 - 对所有其他数据联合使用 _Zero Copy_，以保持新鲜度，并最大限度地减少构建和维护数据接收漏斗的操作开销。 - **数据摄取频率很重要。**根据业务价值、延迟需求和操作复杂性选择频率。 - 对时间敏感的工作流(例如个性化、实时仪表板和 Agentforce 操作)使用_实时_。 - 对于中等紧急流程（例如，市场活动和运营报表），使用 _Near Real_。 - 对历史或低速数据集使用批处理。 - **将联盟模式与延迟和性能匹配。**选择最适合您的访问模式和新鲜度、性能和成本要求的选项。 - 在低延迟至关重要的领域，将_实时查询_用于操作仪表板和实时个性化。 - 当查询频繁且稍微过时的结果可以接受时，使用_缓存 (加速查询)_，这有助于平衡性能和成本。 - 将_文件联合_用于大规模、吞吐量大的分析或批处理工作量,这是历史数据集或时间不太敏感的数据集的理想选择。 - **将治理与数据驻留要求保持一致。** - 在集中治理至关重要时使用_摄取_。 - 当分散的治理可以接受时，使用_联盟_，同时在外部实施严格的治理。 - 对源级策略（例如，_行级安全性 (RLS)_ 和数据屏蔽）使用 _Zero Copy_。 - **优先考虑高价值工作流的接收。**有选择地将摄取应用于关键流程（例如，身份解析、监管报告和操作激活）。 - **成本和复杂性推动决策。**实时摄取可能既昂贵又复杂。这就是为什么架构师必须权衡加入、存储和转换数据的成本与直接通过 _Zero Copy_ 查询数据的成本。 选择正确的集成模式 — _数据接收_、_零复制_或_混合_方法 — 直接影响多云平台的延迟、治理、运营效率和成本。此决策决定了如何可靠、大规模地提供实时见解、AI 驱动的激活和个性化参与。 ## 产品比较 此表比较了 Salesforce _Data 360_ 中的_数据接收_和_零复制_模式，重点关注功能、权衡和好处以及企业用例和结果。将此用作参考，以设计平衡性能、成本和合规性的混合、多云数据平台。
模式类型 模式/工具 优点 注意事项 结果
数据摄取 实时：
  • 通过 CDC 支持的摄取 API 进行亚秒延迟摄取。
  • 连续流漏斗。
  • 提供即时见解
  • 支持低延迟操作和个性化用例
  • 支持事件驱动的工作流
  • 高成本
  • 复杂架构
  • 低延迟源系统要求
  • 高用量源可能会导致过多的流，从而导致漏斗饱和
  • I/O 密集型
  • 选择性字段和筛选有助于减少开销
 Agentforce：
  • 实时欺诈警报、零售个性化和运营警报
Analytics：
  • 亚秒级仪表板和 KPI 监控
合规性：
  • 持续更新受管工作流的客户记录
流：
  • 通过本机连接器每 1-3 分钟进行一次微批处理接收
  • 平衡成本和新鲜度
  • 具有比实时更简单的架构
  • 支持增量更新
  • 略微延迟
  • 可能不适合重要的次秒决策
  • 批处理大小影响内存/计算
  • 管理 I/O
  • 适用于可预测的重复更新模式
  • 窗口聚合有助于减少处理负载
 Agentforce：
  • 及时的市场活动触发器和近乎实时的参与
Analytics：
  • 推荐引擎和接近实时的仪表板
合规性：
  • 具有可审计性的频繁更新
批次：
  • 通过连接器或 API 提供计划的大容量加载。
  • 支持对象存储和 ETL/ELT 漏斗。
  • 支持大规模数据集的成本效益
  • 易于实施
  • 为历史分析提供可靠性
  • 数据延迟
  • 不适用于时间敏感的操作
  • 加载时段内的 I/O 密集型
  • 网络吞吐量可能成为大文件的瓶颈
  • 适用于历史聚合或受监管的报表工作流
 Agentforce：
  • IT 支持票证 (Jira/ServiceNow) 和聚合工作流
Analytics：
  • 历史分析和趋势评估
合规性：
  • 监管报告和患者/索赔数据聚合
零复制 实时查询：
  • 提供对外部系统的直接查询和读取时模式，没有数据重复
  • 提供最大新鲜度
  • 具有最小的存储开销
  • 支持实时运营见解
  • 取决于源性能
  • 高查询量可能会影响延迟
  • 适用于具有谓词下推和聚合的查询，以最小化 I/O
  • 避免在大规模数据集上使用未筛选的查询
 Agentforce：
  • 适应实时活动的动态工作流
Analytics：
  • 操作仪表板和实时报表
合规性：
  • 在源位置遵守行级安全性和屏蔽
加速查询（缓存）：
  • 为聚合查询提供缓存的本地副本，这些查询可在 15 分钟到 7 天内配置。
  • 提供优化的查询执行
  • 减少延迟
  • 具有比重复实时查询更低的成本
  • 提高频繁访问模式的性能
  • 需要缓存管理
  • 过时取决于缓存间隔
  • 适用于高频查询
  • 不适合亚秒决策
  • 增量刷新仅支持更新插入；已删除的记录不会从缓存中删除。
  • 定期需要手动完全刷新，以保持缓存与源同步
 Agentforce：
  • 用于快速决策的预聚合参与度量
Analytics：
  • BI 仪表板、细分和分析报告
合规性：
  • 带有审计日志的一致监管的仪表板
文件联合:
  • 提供对对象商店或湖泊中大型历史数据集的直接访问(例如 S3、Iceberg、Google BigQuery 和 Redshift)。
  • 处理大规模数据集
  • 在 Data 360 中需要最少存储空间
  • 支持 AI/ML 工作负载
  • 只读
  • 查询性能取决于外部系统吞吐量
  • 适用于批量繁重、吞吐量密集型作业
  • 不适用于实时仪表板
 Agentforce：
  • 非典型（批处理繁重）
Analytics：
  • ML/AI 培训、历史分析和 PB 级报告
合规性：
  • 管理对外部数据集的访问，而不会重复
## Data 360 集成模式 Data 360 有三种主要集成模式 - 数据接收、零复制数据联合和混合方法。 ### 数据摄取 通过_数据接收_，数据被物理复制到 _Data 360_ 中并完全受管理，这与数据保留在源位置的 _Zero Copy_ 不同。换句话说,转换的计算发生在 _Data 360_ 中,它提供了集中的治理和审计。 #### 数据摄取用例 使用_数据接收_在 Salesforce _Data 360_ 中存储规范的受管数据集，以实现合规性和运营控制。在需要完全控制、审计和可追溯性时使用摄取。数据摄取是受监管或高价值工作流的理想选择，在这些工作流中，集中计算和治理至关重要。 摄取适用于为身份解析、监管报告、任务关键型 AI 驱动的工作流和客户参与构建可信基础。 数据摄取概览 #### 数据摄取方法 _数据接收_方法可能会有所不同，这取决于您使用哪个连接器来接收数据。一些连接器提供多种接收方法，而其他连接器仅以批处理或流模式运行。有关 _Data 360_ 连接器和可用方法的完整列表，请查看 [Data 360：集成和连接器](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5)。 - **实时：** - 使用_变更数据捕获_提供亚秒级摄取 - 适用于对时间敏感的工作流（例如，欺诈检测、个性化和操作仪表板） - 该功能在 _Data 360_ 中推送转换和聚合，这有助于减少下游 I/O 并优化计算使用 - 支持使用增量 CDC，以最大限度地减少数据重组 - **流：** - 每 1-3 分钟提供少量摄取 - 平衡新鲜度和成本 - 适用于市场活动编排、近乎实时的参与和运营报告 - 支持使用微批处理控制 I/O 峰值 - 在源位置聚合数据（如果可能），以减少传输量并优化存储 - **批次（计划加载）：** - 提供大型数据集的定期摄取（例如，每小时、每天和每周） - 为历史数据集、监管报告和合规用例提供成本效率和可靠性 - 确保计算位置与源存储位于同一区域，以提高性能并优化成本 #### 架构师行动手册 - **数据引入用例：** - **生成 Customer 360 统一简档。**为客户身份和属性构建单一的真实来源。 - **维护监管合规数据集。**对敏感数据强制执行治理、谱系和可审计性。 - **集中市场活动编排。**确保市场营销、销售和服务都从一致、可信的数据集运行。 - **设计实践：** - 适应历史或低延迟容忍需求的批量接收（例如，归档报告或定期快照）。 - 使用 CDC 或流 API 保持操作和个性化工作流的新鲜度，以确保近乎实时的更新。 - 通过应用增量负载来优化成本和效率（而不是重新加载整个数据集），从而控制存储和计算增长。 - 将接收漏斗与计算位置和增量处理保持一致，以减少网络 I/O。 - 在 _Data 360_ 中应用转换，避免不必要地移动原始数据。 - **成本注意事项：** - **实时摄取**的计算和漏斗成本最高,这可能是高价值、时效性强的工作流(例如个性化、操作仪表板或 Agentforce 驱动的操作)的理由。 - **流摄取**的计算和存储成本适中,可能适合容忍轻微延迟的频繁更新(例如,市场活动编排或运营报告)。 - **批量接收**具有较低的计算成本和可预测的存储，适用于历史数据集或低频更新。使用特定连接器从 Salesforce 组织免费接收批处理数据。 - **刷新模式**允许您选择_增量刷新_模式，这降低了总摄取和计算成本。在 Salesforce 中，我们建议尽可能使用_增量刷新_来优化所有摄取类型的效率。 - 从源到 _Data 360_ 的 I/O 量也会影响**成本**。优化批次大小、分区和区域对齐降低了转移成本，并提高了性能。 - **行业场景：** - **财务：**对于_了解客户 (KYC)_、_反洗钱 (AML)_ 和欺诈检测（其中可审计性和合规性是不容置疑的），需要使用摄取数据集。 - **医疗保健：**将摄取用于患者身份解析和符合 HIPAA 的记录，这可实现安全、统一的视图。 - **零售：**将_销售点 (POS)_、电子商务和忠诚计划数据整合到统一简档中，以实现细分和个性化。 - **电信：**使用规范、受管订阅者数据，支持流失预防和使用情况分析。 #### 数据摄取方法决策条件 | 功能 | 实时摄取 | 流摄取 | 批量摄取 | | :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **延迟和新鲜度** | 具有通过具有_变更数据捕获(CDC)_支持的摄取API进行亚秒延迟摄取的功能。提供连续的流漏斗。适用于低延迟操作用例。 | 具有每 1-3 分钟通过本机连接器进行微批量接收的功能。支持增量更新。预计会略有延迟。 | 预计数据延迟。允许计划的大批量加载。具有定期摄取功能（每小时、每天和每周）。不适用于时间敏感的操作。 | | **主要用例** | 非常适合低延迟操作和个性化用例。用于对时间敏感的工作流。支持事件驱动的工作流。用于实时欺诈警报和操作警报。 | 适用于中等紧急流程。用于市场活动编排、近乎实时的参与和运营报告。用于及时的市场活动触发器。 | 经济高效地处理大规模数据集。适用于历史分析。用于历史聚合或受监管的报表工作流。适用于历史或低速数据集。 | | **架构复杂性和 I/O** | 包括高成本和复杂的架构。需要低延迟源系统。I/O 密集型。高用量源会导致漏斗饱和。 | 具有比实时更简单的架构。I/O 中等。适用于可预测的重复更新模式。批次大小会影响内存和计算。 | 易于实施。在加载窗口期间 I/O 密集型。网络吞吐量可能成为大批量的瓶颈。 | | **成本注意事项** | 包括最高的计算和漏斗成本。仅适用于高价值、对时间敏感的工作流。 | 包括适度的计算和存储成本。提供平衡的成本与新鲜度方法。适用于容忍轻微延迟的频繁更新。 | 具有更低的计算成本和可预测的存储。建议用于历史数据集或低频更新。通过 Salesforce 内部漏斗接收是免费的。 | | **设计实践** | 使用增量 CDC，以最大限度地减少数据重组。筛选并使用选择性字段以减少开销。 | 使用微型批处理来控制 I/O 峰值。考虑窗口聚合，以减少处理负载。 | 用于归档报告或定期快照。确保计算位置与源存储位于同一区域，以实现成本优化。 | ### 零复制数据联合 #### 零复制用例 使用 _Zero Copy_ 对外部系统进行实时查询，无需数据重复，以实现对大型或临时数据集的灵活性、新鲜性和可扩展访问。它适用于实时仪表板、探索性分析、AI/ML 模型训练和直接通过 Salesforce _Data 360_ 进行实时客户参与。 零复制数据联盟概览 #### 零复制方法 当使用 _Zero Copy_ 时，架构师必须在三种可用的数据联合方法之间进行选择，其中每种方法都在新鲜度、性能和成本之间进行权衡。 - **实时查询** - 直接针对外部系统（例如 _Snowflake_、_Google BigQuery_、_Redshift_、_数据块_等）运行查询，没有数据重复。 - 最大限度地减少通过网络的数据移动，并减少 Salesforce _Data 360_ 计算的 I/O，这在可以推送谓词和聚合时是最佳的。 - 适用于实时见解和低延迟操作仪表板。 - 取决于外部系统性能。 - **缓存（加速查询）** - 在 Salesforce _Data 360_ 中临时存储聚合数据的缓存副本。 - 通过可配置的持续时间（几分钟到几天），减少频繁访问的数据集的重复查询成本和延迟。 - 数据不会永久复制或完全管理，因此新鲜度通过源的定期刷新进行管理。 - _增量刷新_仅支持更新插入。已删除的记录不会从缓存中删除。 - 定期执行完全刷新，以确保缓存与源保持同步。 - **注意：**_Snowflake_ 连接器支持_卸载_功能，该功能通过使用 Snowflake 发起的暂存存储桶来提高加速率。默认情况下启用，但可以通过编辑连接禁用。 - **文件联合** - 提供对对象存储中大规模数据集的直接只读访问（例如，带 _Iceberg_ 的 _S3_ 和 _GCS_）。 - 适用于 AI/ML 工作负载、历史分析和 PB 级报表，无需移动数据。 - 查询性能在很大程度上取决于对象格式、分区和网络 I/O。如果不进行优化，大型扫描可能会产生大量 I/O。 #### 架构师行动手册 - **用例** - 随着客户行为的变化，**实时个性化和**自适应工作流会提供动态优惠、推荐和 Next Best Action。 - **实时仪表板和运营分析**直接从外部仓库为关键业务仪表板和 KPI 提供支持。 - 具有大型外部数据集的**AI/ML模型**训练利用了来自数据湖和仓库的PB级数据，而无需通过文件联合移动。 - **行业场景** - **零售/媒体：**通过整合点击流或内容交互数据，启用个性化推荐和实时客户参与。 - **财务：**通过查询外部仓库，在不复制敏感数据的情况下，近乎实时地运行欺诈检测和风险评分。 - **技术/企业：**当数据集驻留在多个系统中时，支持跨云报表、IT 服务仪表板和运营分析。 - **设计实践** - **实时查询** - 当新鲜度至关重要时，用于高 QPS、低延迟查询。 - 将谓词和聚合推送到外部系统，以减少通过网络进行的数据重组。 - 避免不必要地扫描大量数据的查询。 - 请考虑分区修剪和筛选。 - **文件联合** - 在不摄取的情况下访问对象存储中的 PB 级数据集。 - 通过将对象存储与 Salesforce 计算保持在同一云区域中，最大限度地减少延迟和出口成本。 - 使用分区域列格式 (Parquet/ORC) 和下拉筛选器，以减少 I/O 和网络传输。 - 利用查询和谓词推送在源位置筛选和聚合数据，从而减少数据移动。 - 避免跨区域数据访问（除非绝对必要），因为这会增加 I/O、延迟和成本。 - **缓存（加速查询）** - 缓存频繁访问的数据集，以平衡成本和性能。 - 配置刷新间隔，以平衡新鲜度和查询成本。 - **合规性：**通过直接在联盟系统中利用_行级安全 (RLS)_ 和屏蔽策略，在源头强制执行治理。 - 以下是一些跨平台统一 RLS 和屏蔽的最佳实践： - **使用集中企业 ID。**将 Salesforce _Data 360_ 中的用户和实体映射到与外部系统中的身份相对应的唯一的集中企业标识符。 - **调整安全策略。**确保联盟系统中的 RLS 和屏蔽策略基于映射的身份应用。这保留了查询外部数据时的合规性。 - **标准化身份模式。**在所有数据源中保持一致的身份属性（电子邮件、用户 ID、客户 ID 等），以避免不匹配和访问违规。 - **成本注意事项** - **实时查询：**在按查询付费模型中，外部湖滨别墅计算会产生成本，这可能会导致高 QPS 峰值。这适用于值大于成本可变性的新颖性关键用例。 - **加速查询（缓存）：**此方法通过减少对源系统的点击率来降低查询成本(与_实时查询相比 )_ ; 但是,它增加了填充和刷新缓存的批处理数据接收成本。这适用于频繁访问的数据集。 - **文件联合:**这是对象存储中最便宜的存储选项；但是，查询成本取决于文件大小、分区和修剪。这适用于 PB 级别的历史数据或批量数据。 #### 零复制方法决策条件 | 决策点 | 实时查询 | 缓存（加速查询） | 文件联合 | | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **数据源位置** | 外部数据湖别墅（例如，_Snowflake_、_Google BigQuery_、_Redshift_ 和_数据块_） | 外部数据湖别墅（例如，_Snowflake_、_Google BigQuery_、_Redshift_ 和_数据块_） | 对象存储或云数据湖（例如 _S3_、_ADLS_ 和 _GCS_），它们通常使用 _Iceberg_ 等开放表格式。 | | **目的/用例** | 适用于交互式分析和实时仪表板。适用于实时个性化和动态工作流。 | 适用于查询频繁，但结果稍显过时的情况。适用于 BI 仪表板和细分。 | 适用于大规模批处理和 AI/ML 模型训练。适用于历史分析和 PB 级报表。 | | **新鲜度/延迟** | 提供最大新鲜度 直接实时运行查询。当源系统针对具有有效谓词下推的低延迟查询进行优化时，支持亚秒决策。 | 当稍微过时的结果可以接受时使用。新鲜度取决于缓存间隔，缓存间隔可从 15 分钟到 7 天进行配置。 | 适用于批量繁重、吞吐量密集型作业。不适合实时仪表板。 | | **访问模式** | 适用于新鲜度至关重要且查询量较低的不频繁或临时查询。在高 QPS 时，成本会显著飙升，因此在查询频率高时评估缓存（加速查询）非常重要。 | 适用于高频读取场景。提高频繁访问模式的性能。 | 提供*只读*访问权限。适用于没有摄取的 PB 级数据集。 | | **性能驱动因素** | 高度依赖于外部源系统性能。适用于谓词和聚合可以推送到源时。 | 与重复的实时查询相比，减少延迟。性能取决于缓存管理和间隔。 | 性能在很大程度上取决于对象格式、分区和外部系统吞吐量。使用分区域列格式 (Parquet/ORC)。 | | **所涉费用** | 这是按查询付费的模式，因此外部湖滨别墅计算会产生成本。对于不频繁的查询，这非常经济高效，但支出可能会随着 QPS 数量的增加而激增。 | 成本低于重复的实时查询。它减少了重复查询外部源的需要，但增加了缓存存储和刷新开销。 | 这是最便宜的存储选项。对于同一地区、同一云的 AWS 设置(例如,US-East-1 中的 _S3_,其 _Data Cloud_ 租户也在 US-East-1),访问的行不会消耗信用。跨区域或跨云配置(例如,_Azure_、_GCS_ 或不同 _AWS_ 区域)会对访问的行产生信用消耗。查询成本也取决于文件大小、分区和谓词下拉优化。 | | **关键注意事项** | 避免不必要地扫描大量数据的未筛选查询。 | 此方法需要缓存管理。不适合亚秒决策。 | 查询性能在很大程度上取决于通过分区和谓词下推进行优化。 | ### 混合方法 混合架构使架构师能够在 _Data 360_ 中锚定关键数据集以实现集中治理，同时利用联合查询实现新鲜度、减少重复以及对大型外部数据集的可扩展访问。这种方法平衡了 I/O、计算位置、成本和合规性要求。 #### 混合用例 通过将数据接收和零复制结合起来，使用混合方法实现平衡的治理、新鲜度和运营效率，以提供实时、可操作的见解。将摄取用于需要可追溯性、RLS 和屏蔽的高价值受监管数据集，并将联合用于新鲜度和性能至关重要的短暂或高用量数据集。 混合方法概览 #### 架构师行动手册 - **用例** - **全方位参与：**将历史客户数据与实时行为相结合，以提供一致的上下文感知体验。 - **AI/ML 漏斗：**在策划的规范数据集上训练模型，同时使用来自外部源的原始或实时信号来丰富它们。 - **合规性和灵活性混合需求：**对敏感数据应用严格的治理，并对操作灵活性进行联合。 - **行业场景** - **零售：**将_摄取_用于身份解析和简档统一，并将_联合_用于实时优惠和个性化。 - **医疗保健：**通过_摄取_维护黄金级患者记录，同时使用 IoT 设备流和传感器数据_的联盟_来获取即时上下文。 - **金融服务：**在使用_联盟_进行外部欺诈检测和风险监控查询时，将受监管的数据引入合规监管的湖中。 - **设计实践** - **带摄取的锚治理：**将高价值或受监管的数据引入规范模型，以确保 Trust 和合规性。 - **使用新鲜度联盟：**允许外部湖泊别墅提供实时或大规模数据访问，而不会重复。 - **平衡成本与性能：**简档工作量，以确定何时使用_摄取_与_联合_，这将最大限度地减少不必要的存储和查询成本。 - **应用分层治理：**在利用联合系统安全控制（例如，RLS 和屏蔽）的同时，对接收的数据实施集中治理。 - **注意：**在设计混合漏斗时，重要的是要确保增量接收历史数据集，并将聚合或筛选器推送到聚合源，以优化 I/O 和计算使用。 - **成本注意事项** - 在需要新鲜度时，将合规性或关键数据的_摄取_与_联盟_结合起来，权衡总成本和性能。 - 在混合_摄取_和_联合_时，考虑 I/O 和计算分配。要降低对源系统的重复查询的计算成本，请对高读取、频繁访问的联合数据集使用缓存 (加速查询)。 - 使用此规则来指导接收与联合决策：当数据被频繁访问但不经常更改时，_加速查询_通常更具成本效益。但是，当数据频繁更改时（相对于访问频率），_实时查询_或_摄取_更合适。以下是一些成本示例： - **加速成功：**从 1 万个记录构建并每天更新 10 万个更改的仪表板每天查看 20 次。对于_实时查询_，_加速_成本大约相当于每月 ~600 个信用额，而实际成本大约相当于每月 4,200 个信用额。 - **实时查询成功：**使用每 30 分钟更改一次的数据每天发布 20 次的细分。在此刷新频率下，_实时查询_的_加速_成本约为每月 4200 个信用，而实际成本约为每月 28800 个信用。 ## 用例决策指南 让我们仔细看看一些常见的原型，它们说明了如何应用这个逻辑。 - **"单一真理源"原型:集中和治理** - **场景：**您需要为整个全球企业建立合规、统一的 _Customer 360_ 简档。数据来自十几个不同的系统,必须遵守严格的 _GDPR_ 和 _CCPA_ 法规,并且将成为所有营销和服务互动的真实来源。 - **推荐模式：****数据摄取。**此处的优先级是治理、Trust和控制。将数据引入 _Data 360_ 是创建与源系统绝缘的完全可审计的规范简档的唯一方法。 - **“实时见解”原型：分析而不移动** - **场景：**数据科学团队需要对 _Snowflake_ 中不断更新的大规模事务表运行探索性查询。同时，您的执行团队需要由相同数据支持的实时 _BI_ 仪表板。每天移动 PB 级数据既缓慢又昂贵。 - **推荐模式：****零复制联盟。**这里的优先级是大规模的速度、灵活性和成本效益。_Zero Copy_ 允许您利用现有数据仓库的功能进行实时查询，而不会造成数据重复的开销和延迟。 - **"混合智能"原型：管理核心，聚合边缘** - **场景：**您想要使用来自数据湖的实时行为信号（例如，网站点击）来丰富您的受管、接收的客户简档。您需要核心简档的稳定性，但实时数据的即时性支持即时个性化。 - **推荐模式：****混合方法。**使用_数据接收_为客户数据创建稳定的受管核心。使用 _Zero Copy_ 将易失性的实时“边缘”数据联合在一起，然后在查询时将它们连接在一起，以获得完整的最新视图。 ## 前进之路 企业数据策略不再专注于选择单一的集成模式，而是在可交互的数据生态系统中构建可控的灵活性。正确的方法将每个源系统映射到最适合其新鲜度、治理、成本和访问要求的模式： - 将关键任务、受监管的数据集引入 Salesforce _Data Cloud_，以实现合规性、身份解析和运营工作流。 - 通过 _Zero Copy_ 聚合数据，进行实时、探索性和 AI 驱动的分析，而不会重复存储。 - 应用_缓存(加速查询)_，以减少查询频率高和数据更改频率低时的源系统负载和信用消耗 _Hyperforce_上的Salesforce _Data 360_提供多区域弹性和可扩展性。它开放的湖滨别墅与 _Iceberg_ 表实现了计算分离以及与 _Snowflake_、_Databricks_ 和 _S3 Iceberg_ 等平台的互操作性。 随着数据生态系统的发展，我们必须不断平衡新鲜度、成本、性能和合规性，以保持架构灵活性。这就是为什么通过联合访问统一接收的受管数据来适应未来非常重要。这支持跨云、地区和业务域的实时智能、AI 激活和企业级个性化。 请记住，一刀切的解决方案不适合大多数企业。最佳策略将正确的模式映射到正确的业务驱动因素。 ## 关于作者 **Yugandhar Bora** 是 Salesforce 的软件工程架构师,专门从事数据和智能应用程序平台中的数据架构。他领导_企业架构审核委员会 (EARB)_ 计划，重点关注数据治理和统一数据模型，同时也致力于自动化平台配置解决方案。 **Jan Fernando** 是 Salesforce 首席架构师办公_室 (OCA)_ 的首席架构师,于 2012 年加入 Salesforce。在加入 OCA 之前,他曾在 _Platform_ 组织中工作了十多年,领导了多项关键技术变革。