Salesforce Big Objects 深度解析：面向架构师的大规模数据管理与归档策略

背景与应用场景

作为一名 Salesforce 架构师，我在设计可扩展、高性能的 Salesforce 解决方案时，最常遇到的挑战之一就是大规模数据量 (Large Data Volume, LDV)。当一个组织的核心对象（如 Case, Task, 或自定义对象）的记录数达到数千万甚至数亿级别时，标准的 Salesforce 存储和查询机制会开始面临性能瓶颈。报表和列表视图加载缓慢、SOQL 查询超时、存储成本飙升等问题接踵而至，严重影响用户体验和系统稳定性。

为了应对这一挑战，Salesforce 提供了原生的大数据解决方案——Big Objects（大对象）。Big Objects 旨在为 Salesforce 平台提供海量数据的存储和查询能力，它构建在可横向扩展的大数据技术（如 Apache HBase）之上，能够可靠地存储数十亿条记录，同时保持可预测的性能。

从架构师的角度看，Big Objects 并非标准对象的替代品，而是一个特定场景下的战略工具。其核心应用场景包括：

1. 数据归档 (Data Archiving)

这是 Big Objects 最经典的应用场景。将生产环境中已关闭或非活跃的历史记录（例如，三年前的 Case 记录、已完成的 Task、历史订单）迁移到 Big Objects 中。这样做的好处是双重的：首先，可以显著减少主对象的数据量，从而提升其查询、报表和整体操作性能；其次，这些历史数据并未被删除，仍然保留在 Salesforce 平台内，可以通过特定的方式（如 Async SOQL）进行查询，满足合规审计或历史分析的需求。

2. 客户 360 度视图数据沉淀

为了构建完整的客户视图，企业需要捕获并存储大量的客户交互数据，例如网站点击流、移动应用使用日志、物联网 (IoT) 设备事件、社交媒体互动等。这类数据通常具有高并发、高容量的特点，使用标准对象存储既不经济也不高效。Big Objects 提供了一个理想的“数据湖”，用于存储这些海量的、非事务性的交互数据。这些数据随后可以被聚合分析，为销售、服务和营销团队提供深刻的洞察。

3. 审计与合规性记录

在金融、医疗等受严格监管的行业，企业需要长期保留详细的操作日志、交易记录或系统审计跟踪。这些记录一旦生成便很少修改，但需要被安全、廉价地存储多年，并且在需要时能够被快速检索。Big Objects 的不可变性和高效的索引查询能力使其成为存储此类合规性数据的绝佳选择。

---

原理说明

要正确地设计和使用 Big Objects，理解其底层原理至关重要。它与标准/自定义对象在数据模型、查询机制和平台功能支持上存在根本性的区别。

数据模型与索引

Big Objects 的核心是其索引驱动 (Index-driven) 的数据模型。在定义一个 Big Object 时，你必须定义一个复合主键 (Composite Primary Key)，它由 1 到 5 个自定义字段组成。这个复合主键就是该 Big Object 的索引 (Index)。

这是最关键的一点：对 Big Object 的数据检索完全依赖于这个索引。查询条件必须包含索引中定义的字段，并且字段的顺序至关重要。例如，如果你的索引定义为 `AccountId__c` (first field) + `Event_Timestamp__c` (second field)，那么你所有的查询都必须至少过滤 `AccountId__c`。如果你只尝试用 `Event_Timestamp__c` 来查询，查询效率会极低甚至失败。这种设计确保了即使在数十亿条记录中，只要查询遵循索引规则，平台就能快速定位到所需的数据子集。

查询机制：Async SOQL

由于数据量巨大，同步查询（Standard SOQL）在 Big Objects 上受到严格限制，通常只能用于基于完整索引进行小范围的精确查找。对于大规模的数据提取和分析，必须使用 Async SOQL (异步 SOQL)。Async SOQL 是一种为处理海量数据而设计的查询方式。你提交一个查询作业，Salesforce 会在后台异步处理它。作业完成后，结果会存储在一个目标对象（标准对象、自定义对象或另一个 Big Object）中，供你进一步处理或导出。

平台功能限制

Big Objects 是一个纯粹的后端存储解决方案，因此它不具备标准对象所拥有的大部分平台功能。作为架构师，你必须清晰地认识到这些限制：

• 无标准 UI：你无法为 Big Objects 创建标准页面布局、列表视图或选项卡。数据的展示需要通过自定义开发（如 Lightning Web Components）实现。
• 无自动化逻辑：不支持 Triggers、Flows、Process Builder 或 Workflow Rules。所有的数据操作和逻辑处理都需要通过 Apex 或 API 来完成。
• 无关系字段：不支持标准的查询关系字段（Lookup, Master-Detail）。字段类型非常有限，主要是文本、数字、日期时间等基础类型。
• 无共享模型：Big Objects 不支持标准的共享规则。对 Big Object 数据的访问权限通常由用户的简档权限（如 "View All Data"）控制。

---

示例代码

以下示例将演示如何定义、插入和查询一个用于归档历史订单的 Big Object。所有代码均源自 Salesforce 官方文档。

1. 定义 Big Object 的元数据

Big Objects 通常通过 Metadata API 进行定义。以下是一个名为 `Order_History__b` 的大对象的 `.object` 文件定义。注意 `deploymentStatus`、`label` 以及 `fields` 和 `indexes` 的定义。

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <deploymentStatus>Deployed</deploymentStatus>
    <label>Order History</label>
    <pluralLabel>Order Histories</pluralLabel>
    <fields>
        <fullName>Account_Id__c</fullName>
        <label>Account Id</label>
        <length>18</length>
        <required>true</required>
        <type>Text</type>
        <unique>false</unique>
    </fields>
    <fields>
        <fullName>Order_Date__c</fullName>
        <label>Order Date</label>
        <required>true</required>
        <type>DateTime</type>
    </fields>
    <fields>
        <fullName>Order_Number__c</fullName>
        <label>Order Number</label>
        <length>30</length>
        <required>true</required>
        <type>Text</type>
        <unique>false</unique>
    </fields>
    <fields>
        <fullName>Order_Details__c</fullName>
        <label>Order Details</label>
        <length>131072</length>
        <type>LongTextArea</type>
        <visibleLines>3</visibleLines>
    </fields>
    <indexes>
        <label>OrderHistoryIndex</label>
        <fields>
            <name>Account_Id__c</name>
            <sortDirection>ASC</sortDirection>
        </fields>
        <fields>
            <name>Order_Date__c</name>
            <sortDirection>DESC</sortDirection>
        </fields>
        <fields>
            <name>Order_Number__c</name>
            <sortDirection>ASC</sortDirection>
        </fields>
    </indexes>
</CustomObject>

注释：此索引定义了三个字段作为复合主键：`Account_Id__c`, `Order_Date__c`, 和 `Order_Number__c`。这意味着查询时必须首先提供 `Account_Id__c`，然后可以进一步通过 `Order_Date__c` 和 `Order_Number__c` 进行筛选。

2. 使用 Apex 插入数据

向 Big Objects 插入数据可以使用 `Database.insertImmediate()` 方法。这与标准 DML 操作不同，因为它会立即提交记录，而不参与事务。

// 创建一个 Big Object 记录列表
List<Order_History__b> newOrders = new List<Order_History__b>();

// 填充记录数据
Order_History__b order1 = new Order_History__b();
order1.Account_Id__c = '001xx000003DHP0AAO';
order1.Order_Date__c = Datetime.newInstance(2023, 1, 15, 10, 30, 0);
order1.Order_Number__c = 'ORD-000123';
order1.Order_Details__c = '{"product":"Laptop","quantity":1}';
newOrders.add(order1);

Order_History__b order2 = new Order_History__b();
order2.Account_Id__c = '001xx000003DHP0AAO';
order2.Order_Date__c = Datetime.newInstance(2023, 2, 20, 14, 0, 0);
order2.Order_Number__c = 'ORD-000456';
order2.Order_Details__c = '{"product":"Mouse","quantity":2}';
newOrders.add(order2);

// 使用 insertImmediate 插入记录
Database.SaveResult[] results = Database.insertImmediate(newOrders);

// 遍历结果并检查是否成功
for (Database.SaveResult sr : results) {
    if (sr.isSuccess()) {
        System.debug('Successfully inserted Order History record. ID: ' + sr.getId());
    } else {
        for (Database.Error err : sr.getErrors()) {
            System.debug('Error inserting record: ' + err.getStatusCode() + ': ' + err.getMessage());
        }
    }
}

注释：`insertImmediate` 方法非常适合小批量或实时的 Big Object 数据写入。对于大规模数据迁移，建议使用 Bulk API 2.0。

3. 使用 Async SOQL 查询数据

以下示例演示了如何通过 Apex 提交一个 Async SOQL 作业，以聚合特定客户的历史订单总数，并将结果存储在一个名为 `Monthly_Order_Summary__c` 的自定义对象中。

// 引入 Async SOQL 相关的命名空间
using namespace System.Data;

// 定义目标对象，用于存储查询结果
String targetObject = 'Monthly_Order_Summary__c';

// 定义映射关系，将查询结果字段映射到目标对象字段
String fieldMapping = 'total:Total_Amount__c, month:Month__c';

// 构建 Async SOQL 查询语句
String query = 'SELECT COUNT(Id) total, CALENDAR_MONTH(Order_Date__c) month ' +
               'FROM Order_History__b ' +
               'WHERE Account_Id__c = \'001xx000003DHP0AAO\' ' +
               'GROUP BY CALENDAR_MONTH(Order_Date__c)';

// 创建并配置 Async SOQL 作业
AsyncSoqlOptions options = new AsyncSoqlOptions();
options.targetObject = targetObject;
options.fieldMapping = fieldMapping;

// 提交作业
AsyncSoqlJob job = System.Data.submitAsyncSoqlJob('OrderSummaryJob', query, options);

// 输出作业 ID，用于后续状态跟踪
System.debug('Async SOQL Job submitted with ID: ' + job.getJobId());

// 后续可以通过 [SELECT Status, ErrorMessage FROM AsyncSoqlJob WHERE Id = :job.getJobId()] 来轮询作业状态

注释：此代码段展示了 Async SOQL 的核心三要素：目标对象 (`targetObject`)、字段映射 (`fieldMapping`) 和查询语句 (`query`)。作业提交后是异步执行的，你需要通过查询 `AsyncSoqlJob` 对象来监控其进度和结果。

---

注意事项

在你的架构设计中引入 Big Objects 之前，必须仔细评估以下几点：

1. 索引设计是成败的关键：这是最重要的规则。索引一旦定义，就无法修改。必须在创建 Big Object 之前，与业务分析师和开发团队一起，仔细规划未来所有可能的查询模式，并据此设计索引的字段和顺序。错误的索引设计将导致数据几乎无法使用。
2. API 与限制：Async SOQL 有自己的每日作业限制（例如，每个组织每天最多 10,000 个作业）。Bulk API 2.0 的摄入也受制于组织的 API 调用限制。在设计数据加载和查询流程时，必须将这些限制纳入考量，并设计合理的重试和错误处理机制。
3. 权限与可见性：访问 Big Object 数据通常需要 "View All Data" 权限，或者通过自定义权限集授予特定字段的读写权限。它没有行级别的共享，因此不适用于需要复杂数据访问控制的场景。
4. 数据删除策略：删除 Big Object 记录需要使用 `Database.deleteImmediate()`。规划完整的数据生命周期管理 (DLM) 策略，包括如何识别和批量删除过期数据，是保持系统整洁和合规的关键。
5. 不支持 SOQL 关系查询：你无法在 SOQL 中通过 `__r` 来遍历关系。如果需要将 Big Object 数据与标准对象数据关联，通常需要在查询出 Big Object 数据后，在代码层面或在外部系统中进行二次处理和关联。

---

总结与最佳实践

Big Objects 是 Salesforce 平台上一把强大的“瑞士军刀”，专门用于解决 LDV 带来的性能和成本问题。然而，它并非万能药。作为架构师，我们的职责是确保在正确的场景下使用正确的工具。

最佳实践：

• 优先规划索引：在编写任何代码或创建对象之前，将 80% 的精力投入到索引设计上。模拟业务场景，确认索引能满足所有已知的查询需求。
• 分层数据架构：将 Big Objects 视为数据架构中的“冷存储”或“归档层”。热数据（频繁访问和修改）应保留在标准/自定义对象中，而冷数据则迁移到 Big Objects。
- 结合 CRM Analytics：Big Objects 与 CRM Analytics (原 Tableau CRM) 集成良好。你可以使用 CRM Analytics 连接器直接从 Big Objects 中提取海量数据进行复杂的可视化分析和仪表板制作，这是展示 Big Object 数据价值的常用模式。
• 异步处理思维：所有涉及 Big Objects 的大规模操作都应该是异步的。无论是通过 Apex Batch 加载数据，还是通过 Async SOQL 查询数据，都需要在架构中考虑其异步特性，并为用户提供友好的状态反馈机制。
• 在沙箱中进行规模测试：在将 Big Objects 方案部署到生产环境之前，务必在全尺寸沙箱 (Full Sandbox) 中用接近生产级别的数据量进行严格的加载和查询性能测试，以验证你的索引设计和查询逻辑是否高效。

通过遵循这些原则和实践，你可以有效地利用 Salesforce Big Objects 构建一个既能处理海量数据、又保持高性能和成本效益的企业级解决方案，真正发挥 Salesforce 平台的可扩展性优势。