Salesforce 数据归档策略：架构师综合指南

背景与应用场景

作为一名 Salesforce 架构师，我经常遇到的核心挑战之一便是如何有效管理日益增长的数据。随着企业业务的扩展，Salesforce 组织内的记录数量会呈指数级增长，从客户个案 (Cases)、任务 (Tasks) 到各种自定义对象日志，数据不断累积。如果不加以管理，这种增长会直接导致一系列问题：

1. 存储成本增加：Salesforce 的数据和文件存储空间是有限且昂贵的。超出限制后，企业需要购买额外的存储空间，这是一笔不小的开销。

2. 性能下降：当对象中的数据量达到数百万甚至数千万条时，列表视图 (List Views)、报告 (Reports) 和仪表盘 (Dashboards) 的加载速度会显著变慢。SOQL 查询会变得低效，甚至可能因为超时而失败，严重影响用户体验和业务流程的自动化效率。

3. 治理与合规风险：许多行业（如金融、医疗）都有严格的数据保留政策。例如，GDPR (通用数据保护条例) 要求企业不能无限期地保留个人数据。一个清晰的数据归档策略是满足这些合规性要求的基础。

4. 系统维护困难：庞大的数据集使得数据迁移、备份和沙箱刷新 (Sandbox Refresh) 等常规维护任务变得更加耗时和复杂。

因此，制定一个主动、可扩展且安全的数据归档 (Archiving) 策略，对于维护 Salesforce 平台的健康、性能和成本效益至关重要。归档的本质是将不再频繁访问的、历史性的数据从主要的、活跃的业务对象中移出，迁移到一个成本更低、为长期存储而优化的位置，同时在需要时仍然能够查询到这些数据。

---

原理说明

一个成功的归档策略设计需要回答三个核心问题：归档什么 (What)、何时归档 (When) 和 归档到哪里 (Where)。作为架构师，我们需要从全局视角评估各种方案的优劣，并为企业选择最合适的路径。

归档什么 (What) & 何时归档 (When)

首先，需要与业务利益相关者合作，识别适合归档的对象和数据。通常，候选对象具备以下特征：

• 事务性数据：例如已完成的任务 (Tasks)、已关闭的个案 (Cases)、已发送的邮件日志 (Email Messages)。
• 事件驱动数据：例如系统日志、API 调用记录、字段历史追踪 (Field History Tracking)。
• 时间敏感数据：例如超过3年未更新的业务机会 (Opportunities) 或联系人 (Contacts)。

确定归档对象后，必须定义明确的归档规则。例如：“将所有状态为‘已关闭’且最后修改日期在 24 个月前的 Case 记录进行归档。” 这个规则必须是具体、可量化且无歧义的。

归档到哪里 (Where)

这是架构设计的核心。归档目标位置的选择直接影响到成本、可访问性、安全性和实现复杂度。以下是几种主流的架构方案：

方案一：利用 Salesforce Big Objects (大对象)

Big Objects 是 Salesforce 平台原生提供的一种可扩展对象，专为存储和管理海量数据（十亿级别）而设计。它们可以被视为一种简化的数据库表，非常适合作为归档目标。

• 优点：
  • 原生平台：数据保留在 Salesforce 生态系统内，共享相同的安全模型（如字段级安全 FLS），并且更容易管理。
  • 高可扩展性：专为大数据量设计，性能稳定。
  • API 访问：可以通过标准的 Apex、SOAP API 和 REST API 进行异步 SOQL (Async SOQL) 查询。
• 缺点：
  • 功能限制：不支持标准 UI、触发器 (Triggers)、流程 (Flows) 或验证规则 (Validation Rules)。数据访问通常需要自定义开发，例如构建 Lightning Web Components (LWC) 来展示。
  • 查询限制：标准的 SOQL 查询功能有限，必须基于索引字段进行过滤。复杂查询需要使用 Async SOQL。

方案二：利用外部数据存储 (Off-Platform)

将数据归档到 Salesforce 平台之外的云存储或数据库中，是另一种常见且灵活的选择。例如 Amazon S3、Azure Blob Storage、Google Cloud Storage，或者 Heroku Postgres、Amazon RDS 等数据库服务。

• 优点：
  • 成本效益：外部云存储的单位成本通常远低于 Salesforce 存储。
  • 灵活性：企业可以利用外部平台的强大数据处理和分析工具（如 AWS Athena, Google BigQuery）对归档数据进行深度分析。
  • 无限扩展：几乎不受存储容量的限制。
• 缺点：
  • 集成复杂性：需要构建和维护一个集成解决方案（例如，使用 MuleSoft、Informatica 或自定义 API 集成）来移动数据。这带来了额外的开发和运维成本。
  • 数据安全与合规：数据离开 Salesforce 平台后，企业需要自行负责其安全性、加密和合规性，增加了治理的复杂性。
  • 访问割裂：用户可能无法在 Salesforce UI 中无缝地访问归档数据。虽然可以使用 Salesforce Connect (Salesforce 连接) 将外部数据以外部对象 (External Objects) 的形式虚拟化地展示在 Salesforce 中，但这会增加配置复杂度和潜在的性能开销。

方案三：利用 AppExchange 应用程序

AppExchange 市场上有许多成熟的第三方数据归档解决方案。这些应用通常提供了开箱即用的归档策略配置、自动化作业调度和归档数据访问界面。

• 优点：
  • 快速实施：无需大量自定义开发，可以快速部署和配置。
  • 功能完善：通常包含数据关系维护、归档数据查看器、恢复机制等成熟功能。
  • 降低维护成本：由服务商负责应用的更新和维护。
• 缺点：
  • 许可费用：需要支付持续的订阅费用。
  • 厂商锁定：企业的归档策略会与特定厂商的技术深度绑定。
  • 灵活性受限：可能无法满足一些高度定制化的归档需求。

---

示例代码

从架构师的角度，虽然不直接编写生产代码，但理解其实现原理至关重要。以下示例展示了如何使用 Apex 将数据插入到 Big Object 中。假设我们有一个名为 `Archived_Case__b` 的 Big Object，用于归档 Case 数据。

首先，定义 `Archived_Case__b`，它有几个关键字段：`Legacy_Case_Id__c` (用于存储原始 Case 的 Salesforce ID), `Subject__c`, `Closed_Date__c` 等。其中，`Legacy_Case_Id__c` 和 `Closed_Date__c` 应该被定义为索引的一部分。

在归档过程中，通常会使用批处理 Apex (Batch Apex) 来查询需要归档的 Case 记录，然后将它们转换为 Big Object 记录并插入。`Database.insertImmediate()` 方法用于同步插入 Big Object 记录。

// 这是一个在 Batch Apex 的 execute 方法中可能出现的代码片段
// 假设 'casesToArchive' 是从 start 方法传递过来的 Case 记录列表

// 1. 准备一个用于存储 Big Object 记录的列表
List<Archived_Case__b> casesToInsertToBO = new List<Archived_Case__b>();

// 2. 遍历需要归档的 Case 记录
for (Case c : casesToArchive) {
    // 3. 创建一个新的 Big Object 记录实例
    Archived_Case__b archivedCase = new Archived_Case__b();

    // 4. 映射字段：将标准 Case 对象的字段值赋给 Big Object 的相应字段
    // 存储原始记录的 ID 是至关重要的，便于未来追溯
    archivedCase.Legacy_Case_Id__c = c.Id;
    archivedCase.Case_Number__c = c.CaseNumber;
    archivedCase.Subject__c = c.Subject;
    archivedCase.Description__c = c.Description;
    archivedCase.Status__c = c.Status;
    archivedCase.Priority__c = c.Priority;
    archivedCase.Closed_Date__c = c.ClosedDate;
    // ... 映射其他需要的字段 ...

    // 5. 将准备好的 Big Object 记录添加到列表中
    casesToInsertToBO.add(archivedCase);
}

// 6. 检查列表是否为空，避免不必要的操作
if (!casesToInsertToBO.isEmpty()) {
    // 7. 使用 Database.insertImmediate() 批量插入 Big Object 记录
    // 这个方法是同步执行的，专门用于 Big Object 操作。
    // 返回一个 SaveResult 列表，可以用于检查每条记录的插入是否成功。
    List<Database.SaveResult> saveResults = Database.insertImmediate(casesToInsertToBO);

    // 8. (可选但推荐) 遍历结果，进行错误处理
    for (Integer i = 0; i < saveResults.size(); i++) {
        if (!saveResults[i].isSuccess()) {
            // 如果插入失败，记录错误日志
            Database.Error err = saveResults[i].getErrors()[0];
            System.debug('Error inserting Archived Case. Record Index: ' + i +
                         '. Legacy Case ID: ' + casesToInsertToBO[i].Legacy_Case_Id__c +
                         '. Error: ' + err.getStatusCode() + ': ' + err.getMessage());
            // 在实际项目中，应将错误信息记录到自定义日志对象或平台事件中
        }
    }

    // 9. 在 Big Object 插入成功后，执行原始 Case 记录的删除操作
    // 强烈建议这是一个独立且可监控的步骤，确保数据已安全归档再删除。
    // delete casesToArchive;
}

注意：上述代码是一个核心片段。一个完整的归档作业应该包含查询逻辑 (Batch Apex 的 `start` 方法)、删除逻辑，以及完善的错误处理和通知机制。

---

注意事项

在设计和实施归档策略时，必须仔细考虑以下几点，以避免潜在的风险和问题。

1. 数据完整性与关系 (Data Integrity and Relationships):

当您归档一个父记录（例如 Account）时，其关联的子记录（例如 Contacts, Cases）如何处理？反之，归档子记录时，父记录的查找关系会断开。必须设计一种策略来维护这些关系。一个常见的做法是在归档记录中创建一个文本字段（如 `Legacy_Parent_Id__c`），用于存储原始父记录的 Salesforce ID。这虽然失去了声明式的关系，但为数据重建和追溯提供了线索。

2. 权限与可见性 (Permissions and Visibility):

归档数据的访问权限需要被严格控制。如果使用 Big Objects，可以利用字段级安全 (FLS) 控制字段的可见性。但 Big Objects 不支持记录级的共享规则。如果归档到外部系统，则访问控制完全依赖于外部系统的身份和权限管理机制，必须确保它能与 Salesforce 的用户体系（或企业统一身份认证体系）对齐。

3. API 限制与治理 (API Limits and Governance):

大规模的数据归档作业会消耗大量的 API 调用和计算资源。必须遵循 Salesforce 的 Governor Limits (执行限制)。推荐使用 Bulk API 2.0 来高效地查询和删除大量数据，使用 Batch Apex 来处理复杂的转换逻辑。作业的设计应考虑分批次、小批量执行，并安排在系统负载较低的时段运行，避免影响正常的业务操作。

4. 错误处理与重试机制 (Error Handling and Retry Mechanisms):

归档过程可能因为各种原因（如 API 限制、网络问题、数据校验失败）而中断。一个健壮的架构必须包含详细的日志记录、失败重试机制和管理员通知功能。例如，可以设计一个自定义的日志对象来记录每一批次作业的成功与失败，并提供一个仪表盘来监控归档作业的整体健康状况。关键原则是：先验证归档成功，再删除原始数据，绝不能颠倒顺序。

5. 合规性与数据驻留 (Compliance and Data Residency):

如果选择将数据归档到外部系统，必须确保该系统的物理位置和安全标准符合企业所在行业和国家/地区的数据法规要求（如 GDPR, CCPA, HIPAA）。数据驻留问题是全球化企业在选择云服务商时必须优先考虑的因素。

---

总结与最佳实践

数据归档不是一次性的项目，而是一个持续的数据生命周期管理 (Data Lifecycle Management) 过程。作为 Salesforce 架构师，我们的目标是设计一个与企业共同成长的、可持续的归档策略。

最佳实践：

• 主动规划，而非被动应对：不要等到性能问题和存储警告出现时才开始考虑归档。在系统设计的早期就应该将数据增长和归档策略纳入蓝图。
• 业务驱动，技术实现：归档规则和策略必须源于业务需求。与业务部门紧密合作，了解他们对历史数据的访问频率和需求，这决定了技术方案的选择。
• 选择合适的工具：
  • 对于极大规模、访问频率低、查询模式简单的数据，Big Objects 是一个优秀的、成本可控的原生解决方案。
  • 对于需要与外部数据湖/数据仓库集成、进行复杂分析的场景，外部存储方案更具灵活性。
  • 对于寻求快速实现、标准功能满足需求的企业，AppExchange 应用可以显著缩短价值实现的时间。
• 关注用户体验：无论数据归档在哪里，都要为需要访问这些数据的用户提供一个尽可能无缝的体验。这可能意味着需要开发一个自定义的 LWC 组件来查询和展示 Big Object 或外部对象的数据。
• 测试、测试、再测试：在部署到生产环境之前，务必在全量沙箱 (Full Sandbox) 中对整个归档流程进行彻底的测试，包括性能测试、数据完整性校验和回滚预案的演练。

通过深思熟虑的架构设计，我们可以将数据归档从一个令人头痛的难题，转变为提升 Salesforce 平台性能、保障合规性并优化成本的战略性举措。