Salesforce 数据归档策略：性能与合规性的最佳实践
背景与应用场景
随着企业业务的快速发展，Salesforce 组织中的数据量会呈指数级增长。当数据量达到一定规模时，一系列问题便会接踵而至：系统性能下降、报表和列表视图加载缓慢、存储成本攀升，甚至可能触及 Salesforce 的 Governor Limits (管控限制)。此外，诸如 GDPR（通用数据保护条例）和 CCPA（加州消费者隐私法案）等数据合规性法规，也对数据的生命周期管理和保留策略提出了严格要求。
因此，制定一套行之有效的数据归档 (Data Archiving) 策略，对于维护 Salesforce 组织的健康、确保系统性能和满足合规性要求至关重要。数据归档的核心思想是将不再频繁访问的、历史性的数据从核心业务对象中移出，迁移到成本更低、更适合长期存储的地方，同时确保在需要时仍然可以访问这些数据。
典型的应用场景包括：
- 归档已关闭超过数年的个案 (Cases)。
- 归档已丢失或关闭多年的业务机会 (Opportunities)。
- 归档过往的市场活动 (Campaigns) 数据。
- 存储和归档由物联网 (IoT) 设备产生的大量时间序列数据。
- 备份和归档字段历史数据 (Field History) 或系统日志。
一个设计良好的归档策略不仅能解决存储和性能问题，还能简化数据管理，降低合规风险，并为长期数据分析提供支持。
原理说明
Salesforce 数据归档并非只有一种方法，技术架构师需要根据业务需求、数据量、预算和技术能力，选择最合适的策略或策略组合。以下是几种主流的归档策略：
1. 平台外归档 (Off-platform Archiving)
这是最传统的归档方法。其核心原理是使用 ETL (Extract, Transform, Load) 工具，如 MuleSoft、Informatica，或通过 Salesforce 的 Bulk API 和 Data Loader (数据加载器)，将 Salesforce 中的历史数据导出，并存储在外部系统中。这个外部系统可以是一个数据仓库（如 Snowflake, Google BigQuery, Amazon Redshift）、一个关系型数据库，甚至是低成本的云存储（如 Amazon S3）。
- 优点: 最大程度地释放了 Salesforce 的存储空间，对于海量数据的长期存储极具成本效益。外部数据仓库通常具备更强大的分析和处理能力。
- 缺点: 数据不在 Salesforce 平台内，用户无法通过标准界面直接访问。需要额外的集成开发工作来确保数据同步和一致性。如果需要查看归档数据，通常需要构建自定义的 Lightning Web Component (LWC) 来调用外部系统的 API，实现数据回显。
2. 平台内归档 - 使用 Big Objects
Salesforce 提供了 Big Objects (大对象)，这是一种专为在 Salesforce 平台上存储和管理海量数据而设计的技术。Big Objects 可以存储数十亿甚至更多的记录，非常适合作为平台内的归档解决方案。
- 优点: 数据保留在 Salesforce 平台内，继承了 Salesforce 的安全模型和部分功能。可以通过 Async SOQL (异步 SOQL) 进行大规模数据的查询和分析。可以构建自定义 UI 来展示归档数据，提供无缝的用户体验。
- 缺点: Big Objects 不支持标准报表和仪表盘，不支持触发器 (Triggers)、流程 (Flows) 等标准自动化工具。查询功能受限于索引字段，且必须使用 Async SOQL。DML 操作与标准对象不同。
3. 自定义归档对象方法
这是一种相对简单的平台内归档方法。其原理是创建一个与源对象（如 `Case`）结构类似的自定义对象（如 `Archived_Case__c`）。然后，通过批处理 Apex (Batch Apex) 定期将符合归档条件的记录从源对象移动到这个自定义的归档对象中。
- 优点: 实现简单，开发成本较低。数据仍然在 Salesforce 平台内，可以通过标准报表等方式进行有限的访问。
- 缺点: 这种方法并没有真正解决数据存储问题，因为数据只是从一个对象转移到另一个对象，仍然占用 Salesforce 的数据存储空间。对于大规模数据，它对性能的改善效果不如前两种方法显著。
4. AppExchange 解决方案
Salesforce AppExchange (应用市场) 上有许多成熟的第三方数据归档和备份解决方案，例如 OwnBackup, Odaseva 等。这些工具通常提供了一套完整的数据生命周期管理功能。
- 优点: 开箱即用，提供用户友好的配置界面、自动化的归档策略、数据恢复功能以及详细的合规报告。
- 缺点: 需要额外的软件采购成本。
在本文中，我们将重点探讨技术实现上最具代表性的 Big Objects 归档策略。
示例代码
我们将以归档“个案 (Case)”为例，展示如何使用 Big Objects。整个过程包括：定义 Big Object、插入数据和查询数据。
1. 定义 Big Object
Big Object 的定义通过元数据 API 完成。你需要创建一个 `.object` 文件。文件名必须以 `__b` 结尾。核心在于定义一个或多个字段作为索引 (index)，这是高效查询的关键。
下面是一个名为 `Archived_Case__b.object` 的示例定义。我们将 `Case_Number__c`、`Account_Id__c` 和 `Closed_Date__c` 定义为索引字段。索引的顺序非常重要，因为它决定了你将来如何使用 Async SOQL 进行查询。
<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<deploymentStatus>Deployed</deploymentStatus>
<fields>
<fullName>Account_Id__c</fullName>
<label>Account Id</label>
<length>18</length>
<type>Text</type>
<unique>false</unique>
</fields>
<fields>
<fullName>Case_Number__c</fullName>
<label>Case Number</label>
<length>80</length>
<type>Text</type>
<unique>false</unique>
</fields>
<fields>
<fullName>Closed_Date__c</fullName>
<label>Closed Date</label>
<type>DateTime</type>
</fields>
<fields>
<fullName>Details__c</fullName>
<label>Details</label>
<length>32768</length>
<type>LongTextArea</type>
<visibleLines>3</visibleLines>
</fields>
<indexes>
<fullName>ArchivedCaseIndex</fullName>
<label>Archived Case Index</label>
<fields>
<name>Case_Number__c</name>
<sortDirection>ASC</sortDirection>
</fields>
<fields>
<name>Account_Id__c</name>
<sortDirection>ASC</sortDirection>
</fields>
<fields>
<name>Closed_Date__c</name>
<sortDirection>DESC</sortDirection>
</fields>
</indexes>
<label>Archived Case</label>
<pluralLabel>Archived Cases</pluralLabel>
</CustomObject>
2. 使用 Apex 插入数据到 Big Object
将数据从标准 `Case` 对象移动到 `Archived_Case__b` 通常在 Batch Apex 中完成。插入 Big Object 记录时，应使用 `Database.insertImmediate()` 方法，而不是标准的 `insert` DML 语句。
// 此代码片段展示了如何将数据插入到 Big Object 中
// 在实际项目中，这部分逻辑应放在 Batch Apex 的 execute 方法中
// 1. 从标准 Case 对象查询需要归档的数据
List<Case> casesToArchive = [
SELECT Id, CaseNumber, AccountId, ClosedDate, Description
FROM Case
WHERE Status = 'Closed' AND ClosedDate < LAST_N_YEARS:5
LIMIT 10000
];
List<Archived_Case__b> archivedCases = new List<Archived_Case__b>();
// 2. 将 Case 记录转换为 Big Object 记录
for (Case c : casesToArchive) {
archivedCases.add(new Archived_Case__b(
Case_Number__c = c.CaseNumber,
Account_Id__c = c.AccountId,
Closed_Date__c = c.ClosedDate,
Details__c = c.Description
));
}
// 3. 使用 Database.insertImmediate() 插入 Big Object 记录
if (!archivedCases.isEmpty()) {
Database.SaveResult[] results = Database.insertImmediate(archivedCases);
// 4. 错误处理：检查插入结果
for (Database.SaveResult sr : results) {
if (!sr.isSuccess()) {
// 记录错误日志
for(Database.Error err : sr.getErrors()) {
System.debug('Error inserting Big Object record: ' + err.getMessage());
}
}
}
}
// 5. 插入成功后，删除原始的 Case 记录 (务必谨慎操作)
// delete casesToArchive;
3. 使用 Async SOQL 查询 Big Object
对 Big Object 的查询必须使用 Async SOQL，它专为处理海量数据而设计，以异步方式运行。在 Apex 中，可以通过调用 REST API 端点来启动一个 Async SOQL 作业。
// 此代码片段展示了如何从 Apex 启动一个 Async SOQL 查询作业
// 官方文档主要通过 REST API 展示 Async SOQL，以下为 Apex 调用示例
// 1. 构建查询语句，查询必须基于索引字段进行过滤
String query = 'SELECT Case_Number__c, Closed_Date__c, Details__c FROM Archived_Case__b WHERE Account_Id__c = \'001xx000003DHPPAA4\'';
// 2. 准备 HTTP 请求
HttpRequest req = new HttpRequest();
// 使用Async SOQL的REST API端点
req.setEndpoint(URL.getOrgDomainUrl().toExternalForm() + '/services/data/v58.0/async-queries');
req.setMethod('POST');
// 设置授权头，使用当前用户的 Session ID
req.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
req.setHeader('Content-Type', 'application/json');
// 3. 构建请求体
Map<String, String> bodyMap = new Map<String, String>{'query' => query};
req.setBody(JSON.serialize(bodyMap));
// 4. 发送请求
Http http = new Http();
HttpResponse res = http.send(req);
String jobId = '';
// 5. 解析响应，获取作业 ID
if (res.getStatusCode() == 201) { // 201 Created 表示作业已成功提交
Map<String, Object> responseMap = (Map<String, Object>)JSON.deserializeUntyped(res.getBody());
jobId = (String)responseMap.get('id');
System.debug('Async SOQL Job started with ID: ' + jobId);
// 后续步骤 (未在代码中展示):
// a. 轮询作业状态：定期向 /services/data/vXX.X/async-queries/{jobId} 发送 GET 请求
// b. 当作业状态为 "JobComplete" 时，获取结果文件的 locator
// c. 使用 locator 从 /services/data/vXX.X/async-queries/{jobId}/results/{locator} 获取 CSV 格式的结果
} else {
System.debug('Failed to start Async SOQL job. Status: ' + res.getStatus() + ' Body: ' + res.getBody());
}
注意事项
- 权限与可见性: Big Objects 有自己的权限集。你需要为需要访问归档数据的用户分配对 Big Object 的读取权限。
- API 限制: 数据迁移过程会消耗大量的 API 调用，特别是使用 Bulk API 时。Async SOQL 也有其自身的限制，例如每天可以创建的作业数量有限。请在设计方案时充分考虑这些限制。
- 索引设计: Big Object 的查询性能完全依赖于索引。索引一旦创建便无法修改。必须在设计阶段就仔细规划好查询模式，并据此定义索引字段和顺序。
- 错误处理与事务: 归档是一个多步骤过程（查询 -> 插入归档表 -> 删除源数据）。这个过程不是原子性的。必须设计强大的错误处理和重试机制，例如，在成功插入 Big Object 并确认后，再删除原始记录，以防数据丢失。
- 数据检索策略: 在归档前，必须明确用户如何访问这些数据。是仅供后台审计，还是需要在 UI 上展示？如果是后者，你需要开发 LWC 等自定义组件，通过 Apex 调用 Async SOQL 并解析结果，这是一个相对复杂的过程。
- Governor Limits: 如果使用 Batch Apex 进行归档，依然要遵守标准的 Apex Governor Limits，如 SOQL 查询行数、CPU 时间等。合理设计批处理的大小 (batch size)至关重要。
总结与最佳实践
Salesforce 数据归档是一个复杂的系统工程，但对于保障平台长期稳定、高效运行至关重要。没有一种策略是万能的，最佳方案往往是多种策略的结合。
以下是几点最佳实践建议：
- 制定数据生命周期管理 (DLM) 策略: 在编写任何代码之前，首先要和业务方一起定义清晰的数据策略。明确哪些数据需要归档、归档的触发条件（例如，关闭超过3年的个案）、数据的保留期限以及最终的销毁策略。
- 从评估开始: 使用 Salesforce 的存储使用情况工具分析数据构成，识别出占用空间最大、增长最快的对象，这些是归档的首要目标。
- 选择合适的策略:
- 对于需要保留在平台内、数据量巨大且查询模式固定的场景，Big Objects 是理想选择。
- 如果首要目标是降低 Salesforce 存储成本，且数据可以与外部数据湖/仓库集成，平台外归档 是更优解。
- 对于数据量不大、预算有限且希望快速实现的简单场景，可以考虑自定义归档对象方法。
- 如果需要一个功能全面、包含恢复和合规管理的企业级解决方案，评估 AppExchange 产品是明智之举。
- 优先考虑数据完整性: 在归档过程中，要特别注意处理好对象之间的关系。使用外部 ID (External ID) 来维护归档数据与 Salesforce 中活动数据之间的关联。
- 在沙箱中充分测试: 归档操作是破坏性的（会删除源数据）。必须在 Full Sandbox (完整副本沙箱) 中对整个归档流程进行反复、彻底的测试，验证其性能、数据准确性和错误处理逻辑。
总之，成功的数据归档策略需要技术架构师深入理解业务需求、精通平台特性，并进行周密规划和严谨执行，最终实现 Salesforce 组织性能、成本和合规性三者之间的最佳平衡。
评论
发表评论