此文本使用 Salesforce 的自动翻译系统翻译。参加我们的调查,提供有关此内容的反馈,并告诉我们您接下来想要查看的内容。
Note
概览
企业通常会将数据同时存储在 Salesforce 和其他外部数据湖中,例如 Snowflake、Google BigQuery、数据块、Redshift 或 Amazon S3 等云存储。对于希望充分利用数据能力的公司来说,这种在不同源系统中的数据孤立构成了挑战。
致力于跨多个数据湖汇集数据的架构师面临着关于如何最好地集成这些数据的关键架构决策。Data 360 为数据集成提供了多个选项,其中每个选项都有不同的利弊。
本指南提供了一个框架来评估在集成数据时哪种模式最适合您对延迟、成本、可扩展性、治理和复杂性的要求,帮助您选择何时使用数据接收、零复制数据联合或混合方法。该指南还将帮助您在不同数据摄取和数据联合方法之间进行选择,每种方法都满足不同的需求。
将外部数据湖库与 Data 360 集成需要仔细考虑数据新鲜度、治理和漏斗效率之间的权衡。例如,使用 Zero Copy 数据联合实时查询可以最大限度地提高数据的新鲜度,但随着您通过网络移动更多数据,可能会降低漏斗效率。因此,对于大多数真实世界的实施,多云湖滨生态系统中的摄取和联合是最佳路径。这种混合方法确保了可扩展的、受管的、可互操作的架构,它无缝支持实时个性化和欺诈检测等低延迟操作工作负载,以及监管报告和历史趋势分析等分析工作负载。本决策指南将帮助您了解如何浏览这些权衡,并选择正确的策略。
外卖
- **数据接收:**将数据复制到 Salesforce Data 360,创建受管的规范数据模型。当您需要:
- **建立一个全面的 Customer 360:**将不同的源统一并转换为一个受信任的简档。
- **满足严格的监管合规性:**创建可审计的集中副本,其中数据访问和谱系可以严格控制。
- **零复制联盟:**无重复地实时查询外部源,实现实时个性化、实时仪表板和快速源入门。您必须权衡两个主要选项:
- **实时和缓存(加速查询):**最适合对 Snowflake、Google BigQuery、Redshift 或数据块等外部数据平台中的数据进行交互式分析和实时仪表板。通过将处理推送到源系统,避免缓慢、昂贵的数据重复。
- **文件联合:**最适合云数据湖中数据的大规模批处理和 AI 模型训练 (S3、ADLS)。通过直接查询开放表格式的文件,解锁 ETL 和数据科学工作负载的海量数据集,避免代价高昂和接收缓慢。
- **混合模型:**将统一简档的接收与联合进行融合以获得新鲜感,支持全方位参与、Agentforce 驱动的操作和 AI/ML 培训。
重要注意事项
-
**混合架构:**通常需要混合数据摄取和数据联合。
- 将关键数据的数据摄取用于规范数据模型和核心治理。
- 通过 Zero Copy 聚合所有其他数据,以最大限度地减少构建和维护接收数据漏斗的操作开销。
-
**数据摄取频率很重要:**根据业务价值、延迟需求和操作复杂性选择频率。
- 将实时用于对时间敏感的工作流(个性化、实时仪表板、Agentforce 操作)。
- 对于中等紧急流程(市场活动、运营报表),近乎实时。
- 历史或低速数据集的批次。
-
**将联盟模式与延迟和性能匹配:**选择最适合您的访问模式以及对新鲜度、性能和成本的要求。
- 将实时查询用于低延迟至关重要的操作仪表板和实时个性化。
- 当查询频繁但稍微过时的结果可以接受时,使用缓存(加速查询),以平衡性能和成本。
- 将文件联合用于大规模、吞吐量繁重的分析或批处理工作负载,非常适合历史数据集或时间不太敏感的数据集。
-
将治理与数据驻留要求保持一致:
- 在集中治理至关重要的地方使用接收。
- 在可接受的分散治理时使用联合,同时在外部源强制执行严格的治理。Zero Copy 遵守源级策略,例如行级安全性 (RLS) 和数据屏蔽。
-
**优先考虑高价值工作流的接收:**有选择地将摄取应用于关键流程,例如身份解析、监管报告和操作激活。
-
**成本和复杂性推动决策:**实时摄取可能既昂贵又复杂。架构师应权衡加入、存储和转换数据的成本与直接通过 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 中并完全受管,这与数据保留在源位置的 Zero Copy 不同。在 Data 360 中计算转换,这允许集中治理和审计。
数据摄取用例
使用数据接收在 Salesforce Data 360 中存储规范的受管数据集,以实现合规性和运营控制。在需要完全控制、审计和可追溯性时使用摄取。非常适合集中式计算和治理至关重要的受监管或高价值工作流。
摄取最适合为身份解析、监管报告、任务关键型 AI 驱动的工作流和客户参与构建可信基础。
数据摄取方法
数据接收方法因您使用的连接器接收数据而异。一些连接器提供多种接收方法,而其他连接器仅以批处理或流模式运行。请参阅数据 360:Data 360 连接器及其可用方法的完整列表的集成和连接器。
- 实时
- 使用流漏斗或变更数据捕获 (CDC) 进行亚秒级接收。
- 最适合对时间敏感的工作流(欺诈检测、个性化、操作仪表板)。
- 在 Data 360 中推送转换和聚合,以减少下游 I/O 并优化计算使用。使用增量 CDC,以最大限度地减少数据重组。
- 流
- 每 1-3 分钟以较小的增量摄取一次。
- 平衡新鲜度和成本,适合市场活动编排、近乎实时的参与和运营报告。
- 使用微型批处理来控制 I/O 峰值。如果可能,在源位置聚合数据,以减少传输量并优化存储。
- 批次(计划加载)
- 定期接收大型数据集(每小时、每天、每周)。
- 对于历史数据集、监管报告和合规用例,经济高效且可靠。
- 确保计算位置与源存储位于同一区域,以实现性能和成本优化。
架构师行动手册
- 数据接收的用例
- **生成 Customer 360 统一简档:**为客户身份和属性构建单一的真实来源。
- **维护监管合规数据集:**为敏感数据强制执行治理、谱系和可审计性。
- **集中市场活动编排:**确保市场营销、销售和服务全部从一致、可信的数据集运行。
- 设计实践
- 支持批量接收,以满足历史或低延迟容忍的需求,例如归档报告或定期快照。
- 使用 CDC 或流 API 保持操作和个性化工作流的新鲜度,确保近乎实时的更新。
- 通过应用增量加载而不是重新加载整个数据集来控制存储和计算增长,以优化成本和效率。
- 将接收漏斗与计算位置和增量处理保持一致,以���少网络 I/O。在 Data 360 中应用转换,以避免不必要地移动原始数据。
- 成本注意事项
- **实时摄取:**最高的计算和漏斗成本;适合高价值、时效性高的工作流,例如个性化、操作仪表板或 Agentforce 驱动的操作。
- **流接收:**适中计算和存储成本;适用于容忍轻微延迟的频繁更新,例如市场活动编排或运营报告。
- **批量摄取:**更低的计算成本、可预测的存储;最适合历史数据集或低频更新。使用特定连接器从 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 中临时存储聚合数据的缓存副本。
- 通过可配置的持续时间(几分钟到几天),降低频繁访问数据集的重复查询成本和延迟。
- 数据不会永久复制或完全管理;新鲜度通过源的定期刷新进行管理。
- 文件联合
- 提供对对象存储中大规模数据集的直接、只读访问(例如,S3、带 Iceberg 的 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 中的用户和实体映射到与外部系统中的身份相对应的唯一的集中企业标识符。
- **调整安全策略:**确保根据映射的身份应用联合系统中的行级安全性和屏蔽策略。这保留了查询外部数据时的合规性。
- **标准化身份模式:**在所有数据源中保持一致的身份属性(电子邮件、用户 ID、客户 ID 等),以避免不匹配和访问违规。
- 实时查询
- 成本注意事项
- **实时���询:**按查询付费模式 - 外部 Lakehouse 计算会产生成本,并可能因高 QPS 而激增。最适合价值大于成本变化率的新鲜度关键用例。
- **加速查询(缓存):**通过减少对源系统的点击,降低了与实时查询相比的查询成本,但增加了填充和刷新缓存的批处理数据接收成本。最适合频繁访问的数据集。
- **文件联合:**对象存储中最便宜的存储选项作为数据,但查询成本取决于文件大小、分区和修剪。最适合 PB 级别的历史数据或批量数据。
零复制方法决策条件
| 决策点 | 实时查询 | 缓存(加速查询) | 文件联合 |
|---|---|---|---|
| 数据源位置 | 外部数据湖库(Snowflake、Google BigQuery、Redshift、数据块)。 | 外部数据湖库(Snowflake、Google BigQuery、Redshift、数据块) | 对象存储或云数据湖(S3、ADLS、GCS),通常使用 Open Table 格式,例如 Iceberg。 |
| 目的/用例 | 非常适合交互式分析和实时仪表板。最适合实时个性化和动态工作流。 | 最适合查询频繁但结果稍显过时的情况。适用于 BI 仪表板和细分。 | 最适合大规模批处理和 AI/ML 模型训练。非常适合历史分析和 PB 级报表。 |
| 新鲜度/延迟 | 最大新鲜度;查询直接实时运行。支持亚秒决策。 | 稍微过时的结果可以接受。新鲜度取决于缓存间隔,可从 15 分钟到 7 天进行配置。 | 针对批量繁重、吞吐量密集型作业进行优化。不适合实时仪表板。 |
| 访问模式 | 最适合不频繁或临时查询。用于新鲜度至关重要的高 QPS(每秒查询)、低延迟查询。 | 最适合高频读取场景。提高频繁访问模式的性能。 | 只读访问权限。适用于没有摄取的 PB 级数据集。 |
| 性能驱动因素 | 高度依赖于外部源系统的性能。在谓词和聚合可以推送到源时优化。 | 与重复的实时查询相比,减少延迟。性能取决于缓存管理和间隔。 | 性能在很大程度上取决于对象格式、分区和外部系统吞吐量。使用分区域列格式 (Parquet/ORC)。 |
| 所涉费用 | 按查询付费模式。外部 Lakehouse 计算会产生成本。对于不频繁的查询来说很经济高效,但是费用可能会因为每秒查询量 (QPS) 高而激增。 | 成本低于重复的��时查询。减少重复查询外部源的需要。添加缓存存储和刷新开销。 | 最便宜的存储选项。查询成本取决于文件大小和分区。 |
| 关键注意事项 | 避免不必要地扫描大量数据的未筛选查询。 | 需要缓存管理。不适合亚秒决策。 | 查询性能在很大程度上取决于通过分区和谓词下推进行优化。 |
混合方法
混合架构使架构师能够在 Data 360 中锚定关键数据集以实现集中治理,同时利用联合查询来实现新鲜度、减少重复以及对大型外部数据集的可扩展访问。这种方法平衡了 I/O、计算位置、成本和合规性要求。
混合用例
通过将数据接收和零复制结合起来,使用混合方法实现平衡的治理、新鲜度和运营效率,以提供实时、可操作的见解。将摄取用于需要可追溯性、RLS 和屏蔽的高价值受监管数据集,并将联合用于新鲜度和性能至关重要的短暂或高用量数据集。
架构师行动手册
- 用例
- **全方位参与:**将历史客户数据与实时行为相结合,以提供一致的上下文感知体验。
- **AI/ML 漏斗:**在策划的规范数据集上训练模型,同时使用来自外部源的原始或实时信号来丰富它们。
- **合规性和灵活性混合需求:**对敏感数据应用严格的治理,但应结合使用,以确保操作灵活性。
- 行业场景
- **零售:**将接收用于身份解析和简档统一;将接收用于实时优惠和个性化。
- **医疗保健:**通过摄取维护黄金级患者记录,同时为即时上下文提供 IoT 设备流和传感器数据。
- **金融服务:**将受监管的数据引入合规监管的湖泊,同时整合外部查询,以进行欺诈检测和风险监控。
- 设计实践
- **带摄取的锚治理:**将高价值或受监管的数据引入规范模型,以确保 Trust 和合规性。
- **使用新鲜度联盟:**允许外部湖库提供实时或大规模数据访问,而不会重复。
- **平衡成本与性能:**简档工作负载,以决定接收的内容与联合的内容,从而最大限度地减少不必要的存储或查询成本。
- **应用分层治理:**对接收的数据实施集中治理,同时利用联合系统自身的安全控制(例如,RLS、屏蔽)。
- 在设计混合漏斗时,请确保增量接收历史数据集,并将聚合或筛选器推送到聚合源,以优化 I/O 和计算使用。
- 成本注意事项
- 在需要新鲜度时,通过将合规或关键数据的摄取与联合相结合,优化总成本和性能。
- 在混合摄取和联合时,考虑 I/O 和计算分配。要降低重复查询源系统的计算成本,请对高读取、频繁访问的联合数据集使用缓存 (加速查询)。
用例决策指南
以下是说明如何应用此逻辑的常见原型。
- "单一真理源"原型:集中和治理
- **场景:**您需要为整个全球企业构建合规、统一的 Customer 360 简档。数据来自十几个不同的系统,必须遵守严格的 GDPR 和 CCPA 法规,并将作为所有营销和服务交互的可信来源。
- **推荐模式:****数据摄取。**优先级是治理、Trust 和控制。将数据引入 Data 360 是创建与源系统隔离的完全可审计的规范简档的唯一方法。
- “实时见解”原型:分析而不移动
- **场景:**数据科学团队需要对 Snowflake 中不断更新的大规模事务表运行探索性查询。同时,您的执行团队需要由相同数据支持的实时 BI 仪表板。每天移动 PB 级数据太慢,成本太高。
- **推荐模式:****零复制联盟。**首要任务是大规模的速度、灵活性和成本效益。Zero Copy 允许您利用现有数据仓库的巨大功能进行实时查询,而没有数据重复的开销和延迟。
- "混合智能"原型:管理核心,聚合边缘
- **场景:**您想要使用来自数据湖的实时行为信号(例如网站点击)来丰富您的受管、接收的客户简档。您需要核心简档的稳定性,但实时数据的即时性支持即时个性化。
- **推荐模式:****混合方法。**使用数据摄取来创建客户数据的稳定和受管核心。然后,使用 Zero Copy 将易失性的实时“边缘”数据联合在一起,并在查询时将其联接在一起,以获得完整的最新视图。
前进之路
企业数据策略不再是选择单一的集成模式,而是在可交互的数据生态系统中构建可控的灵活性。根据业务需求为每个源数据系统选择正确的数据集成方法通常会导致一种混合方法,这种方法结合了数据接收和数据联合的优点。
- 将关键任务受管数据集引入 Salesforce Data 360,以实现合规性、身份解析和运营工作流。
- 通过 Zero Copy 聚合数据,以实现实时、探索性和 AI 驱动的分析,而不会复制存储。
Hyperforce 上的 Salesforce Data 360 提供多区域弹性和可扩展性。 带有冰山表格的开放式 Lakehouse 支持计算分离,并与 Snowflake、Databricks 和 S3 Iceberg 等平台交互,从而构成了真正可交互的多云数据生态系统的主干。
随着数据生态系统的发展,不断平衡新鲜度、成本、性能和合规性,以保持架构灵活性。通过将接收的受管数据与联合访问统一起来,让您的平台面向未来。这支持跨云、地区和业务域的实时智能、AI 激活和企业级个性化。
一刀切的解决方案不适合大多数企业。最佳策略将正确的模式映射到正确的业务驱动因素。
关于作者
Yugandhar Bora 是 Salesforce 的软件工程架构师,专门从事数据和智能应用平台中的数据架构。他领导企业架构审查委员会 (EARB) 专注于数据治理和统一数据模型的举措,同时为自动化平台配置解决方案做出贡献。
Jan Fernando 是 Salesforce 首席架构师办公室的首席架构师。他于 2012 年加入 Salesforce,在创业生态系统中积累了丰富的经验。在加入首席架构师办公室之前,他曾在 Platform 组织中工作了十多年,领导了多项关键技术变革。
2 minute read
