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

大家好，我是一名 Salesforce 架构师。在我的职业生涯中，我见过许多企业因数据量失控而陷入困境——系统性能下降、存储成本飙升、用户体验受损。一个健全的数据归档策略不仅仅是技术选择，更是保障 Salesforce 平台长期健康、可扩展和合规的关键。今天，我将从架构师的视角，深入探讨 Salesforce 数据归档的各种策略、权衡以及最佳实践。

背景与应用场景

为什么我们需要数据归档 (Data Archiving)？Salesforce 作为一个强大的 CRM 平台，其核心价值在于实时、可操作的数据。然而，随着业务的增长，数据会以惊人的速度累积。这些历史数据，如几年前关闭的案例 (Cases)、已完成的任务 (Tasks) 或过期的商机 (Opportunities)，虽然对于日常运营不再至关重要，但往往由于合规性或历史分析的需要而不能被简单删除。

这种数据量的激增会直接导致几个核心问题：

存储成本高昂：Salesforce 的在线数据存储是有限且昂贵的。超出配额将导致额外的成本，并可能影响新业务数据的创建。
性能下降：当对象中的记录数达到数百万甚至数千万时，即我们所说的大数据量 (Large Data Volumes, LDV)，报表、列表视图、搜索查询以及 SOQL (Salesforce Object Query Language) 的性能会显著下降，影响用户的工作效率。
合规与治理风险：诸如 GDPR、CCPA 等数据保护法规对数据保留期限有严格规定。没有明确的归档策略，企业可能面临违规风险。
系统敏捷性降低：在 LDV 环境中，部署、数据迁移和沙盒刷新等管理任务会变得更加耗时和复杂。

因此，数据归档的目标就是将不再频繁访问的“冷”数据从核心业务对象中移出，迁移到一个成本更低、对性能影响更小的存储位置，同时确保在需要时仍能以可接受的方式访问这些数据。

原理说明

从架构层面看，Salesforce 数据归档策略主要可以分为三大类。每种策略都有其独特的优势、劣势和适用场景，作为架构师，我们需要根据企业的具体需求、技术栈和预算进行权衡。

策略一：原生平台方案 - Big Objects

Big Objects 是 Salesforce 平台提供的原生大数据存储解决方案，专为存储和管理海量数据而设计。它可以看作是平台上的一个轻量级、可扩展的数据库。

核心原理：

我们将历史数据从标准或自定义对象（如 Case）中提取出来，然后插入到一个自定义的 Big Object（如 Archived_Case__b）中。这个 Big Object 的字段结构通常会模仿原始对象的关键字段。

关键特性：

可扩展性：能够存储数十亿甚至更多的记录，性能稳定。
查询方式：主要通过异步 SOQL (Async SOQL)进行查询。这是一种为处理海量数据而设计的非实时查询机制，它会在后台运行并在完成后通知用户。标准 SOQL 只能基于索引字段进行有限的查询。
用户界面：Big Objects 中的数据无法在标准的报表、仪表盘或列表视图中直接查看。通常需要通过自定义的 Lightning Web Components (LWC) 调用 Apex 来查询并展示数据。
成本效益：相比于标准的数据存储，Big Objects 的成本相对较低。

架构师视角：这是一个“平台内闭环”的解决方案。优点是数据从未离开 Salesforce 的信任边界，安全性有保障。缺点是数据访问的灵活性受限，不适合需要对归档数据进行复杂、实时分析的场景。

策略二：外部平台存储 (Off-Platform Storage)

这是最常见也是最灵活的企业级归档策略。其核心思想是将 Salesforce 中的历史数据迁移到一个外部系统中，如云数据仓库或数据湖。

核心原理：

通过 ETL (Extract, Transform, Load) 工具，定期将满足归档条件的 Salesforce 数据抽取出来，加载到外部存储中，如 Amazon S3、Google BigQuery、Snowflake 或企业自建的数据库。同时，在 Salesforce 内部，可以保留一个“存根”记录或通过 Salesforce Connect 使用外部对象 (External Objects) 来提供对归档数据的访问入口。

典型架构组件：

ETL 工具：MuleSoft、Salesforce Data Pipelines (原 Tableau CRM) 或自定义的批处理 Apex 结合 Bulk API。
外部数据存储：Heroku Postgres、AWS RDS、Snowflake 等。
数据访问层：通过 Salesforce Connect 将外部数据表虚拟化为 Salesforce 内的外部对象，或者开发自定义 LWC，通过 API 调用外部系统来展示数据。

架构师视角：这是一个高度可定制和可扩展的方案。优点是存储成本极低，并且可以利用外部平台强大的数据处理和分析能力。缺点是架构复杂性高，需要考虑集成、数据同步、安全性以及跨系统的身份验证等问题。数据一旦离开 Salesforce，就需要额外的治理措施来确保其安全合规。

策略三：AppExchange 第三方解决方案

Salesforce AppExchange 上有许多成熟的第三方数据归档和备份解决方案，如 OwnBackup Archiver、Odaseva、Grax 等。

核心原理：

这些解决方案通常提供一个完整的、开箱即用的归档平台。用户只需通过配置界面定义归档策略（例如，归档所有超过两年的已关闭案例），应用就会自动处理数据的抽取、迁移和存储（通常存储在供应商管理的云存储或客户自己的云存储中）。同时，它们通常提供无缝的数据查看和恢复机制。

架构师视角：这是典型的“购买优于构建 (Buy vs. Build)”决策。优点是实施速度快、风险低，并且通常内置了复杂的合规和治理功能。缺点是会产生持续的软件许可费用，并且可能在处理高度定制化的业务逻辑时缺乏灵活性。

示例代码

对于原生 Big Objects 方案，一个关键的实现步骤是将数据从标准对象插入到 Big Object 中。以下代码示例展示了如何使用 Apex 将 `Case` 记录归档到名为 `Archived_Case__b` 的 Big Object 中。此示例严格遵循 Salesforce 官方文档。

假设我们已经创建了一个名为 `Archived_Case__b` 的 Big Object，它包含 `Case_ID__c` (Text), `Subject__c` (Text), 和 `Closed_Date__c` (Date/Time) 等字段。

// 这是一个批处理 Apex 类的 execute 方法，用于处理归档逻辑
// This is the execute method of a Batch Apex class for handling the archiving logic

global class ArchiveCasesBatch implements Database.Batchable<sObject> {

    global Database.QueryLocator start(Database.BatchableContext bc) {
        // 查询所有创建于 365 天前且已关闭的案例
        // Query for all cases that were created more than 365 days ago and are closed
        String query = 'SELECT Id, CaseNumber, Subject, Status, ClosedDate FROM Case WHERE IsClosed = true AND CreatedDate < LAST_N_DAYS:365';
        return Database.getQueryLocator(query);
    }

    global void execute(Database.BatchableContext bc, List<Case> scope) {
        List<Archived_Case__b> casesToArchive = new List<Archived_Case__b>();

        for (Case c : scope) {
            // 为每个案例创建一个对应的 Big Object 记录
            // Create a corresponding Big Object record for each Case
            Archived_Case__b archive = new Archived_Case__b();
            archive.Case_ID__c = c.Id; // 存储原始记录 ID，用于追溯
            archive.Case_Number__c = c.CaseNumber;
            archive.Subject__c = c.Subject;
            archive.Status__c = c.Status;
            archive.Closed_Date__c = c.ClosedDate;
            
            casesToArchive.add(archive);
        }

        if (!casesToArchive.isEmpty()) {
            // 使用 Database.insertImmediate 方法将数据插入 Big Object
            // Big Objects 不支持传统的 DML 操作，必须使用此方法
            // Use the Database.insertImmediate method to insert data into the Big Object.
            // Big Objects do not support traditional DML operations; this method must be used.
            List<Database.SaveResult> results = Database.insertImmediate(casesToArchive);

            List<Id> successfullyArchivedCaseIds = new List<Id>();
            for (Integer i = 0; i < results.size(); i++) {
                if (results[i].isSuccess()) {
                    // 仅当数据成功插入 Big Object 后，才记录其 ID 以便后续删除
                    // Only record the ID for subsequent deletion if the data was successfully inserted into the Big Object.
                    successfullyArchivedCaseIds.add((Id)casesToArchive[i].get('Case_ID__c'));
                } else {
                    // 详细的错误处理逻辑应在这里实现
                    // Detailed error handling logic should be implemented here
                    System.debug('Failed to archive case. Errors: ' + results[i].getErrors());
                }
            }

            // 确认归档成功后，从原始 Case 对象中删除记录
            // After confirming successful archival, delete the records from the original Case object.
            if (!successfullyArchivedCaseIds.isEmpty()) {
                // 在实际生产中，删除操作应格外小心，并可能需要额外的验证步骤
                // In a real production environment, deletion should be handled with extreme care and may require additional validation steps.
                // List<Case> casesToDelete = [SELECT Id FROM Case WHERE Id IN :successfullyArchivedCaseIds];
                // delete casesToDelete;
            }
        }
    }

    global void finish(Database.BatchableContext bc) {
        // 可以在此处发送完成通知
        // Completion notifications can be sent here
        System.debug('Case archiving batch process finished.');
    }
}

注意：上述代码中的删除部分被注释掉了。在生产环境中，删除操作是不可逆的，必须设计一个万无一失的验证流程，确保数据已成功归档并可访问，然后再执行删除。

注意事项

在设计和实施归档策略时，架构师必须仔细考虑以下几点：

数据关系完整性：在归档父记录（如 Account）或子记录（如 Case）时，如何处理它们之间的关系？如果只归档 Case，那么 Account 上的关联列表将不再显示这些 Case。如果归档 Account，所有关联的 Contacts、Opportunities 和 Cases 何去何从？必须定义清晰的规则来维护引用完整性或接受数据关系的断开。
数据检索机制与 SLA：用户如何访问归档数据？访问是实时的还是可接受延迟的？例如，财务审计团队可能需要快速查询七年前的合同数据，而销售团队可能只需要一个链接指向外部系统的报告。服务水平协议 (Service Level Agreement, SLA) 决定了你的技术选型。
权限与安全：归档数据必须遵循与原始数据相同的安全和共享模型。如果数据存储在外部，必须确保外部系统的访问控制与 Salesforce 的权限模型保持一致或更加严格，这通常是一个巨大的挑战。
API 限制：大规模的数据抽取和加载过程会消耗大量的 API 调用。架构上应优先使用 Bulk API 2.0，并合理安排作业执行时间，避免与正常的业务高峰期冲突，以防止达到 Salesforce 的 API 治理限制 (Governor Limits)。
测试策略：归档是一个高风险操作。必须在 Full Copy Sandbox 中进行端到端的完整测试，包括数据抽取、加载、验证、删除以及最终用户访问归档数据的全过程。验证数据的一致性和准确性是测试的重中之重。

总结与最佳实践

数据归档不是一次性的项目，而是一个持续的、动态的治理过程。作为 Salesforce 架构师，我们的目标是构建一个既能满足当前业务需求，又能适应未来增长的弹性架构。

决策框架与最佳实践：

始于策略，而非工具：在评估任何技术方案之前，首先要与业务和法务部门共同制定一个清晰的数据生命周期管理 (Data Lifecycle Management, DLM) 政策。明确哪些数据需要归档、保留多久、谁可以访问。
按需选择方案：
- 对于追求平台内、中等规模、对实时性要求不高的归档场景，Big Objects 是一个值得考虑的原生方案。
- 对于大型企业、存在数据湖/数据仓库、需要对归档数据进行复杂分析的场景，外部平台存储是更具战略性的选择。
- 对于希望快速部署、降低开发和维护成本、且需求能被标准化产品满足的场景，AppExchange 解决方案是最高效的路径。
设计可恢复性：在最终删除 Salesforce 中的数据之前，确保归档的数据是完整、可验证和可恢复的。这不仅仅是技术问题，更是业务连续性的保障。
用户体验至上：无论选择哪种策略，都必须为最终用户提供一种简单、直观的方式来访问归档数据。一个复杂的访问流程会严重影响方案的采纳率。
持续监控与优化：定期审查数据增长率、系统性能和存储使用情况。归档策略应根据业务的变化进行调整和优化。

总之，一个成功的 Salesforce 数据归档策略是技术、业务和治理的完美结合。通过深思熟虑的架构设计，我们可以将数据增长从一个“问题”转变为企业可以利用的宝贵“资产”。

Salesforce中文网