Implement a backup strategy for Amazon Quick Sight BI assets

为 Amazon Quick Sight BI 资产实施备份策略 | 人工智能

为 Amazon Quick Sight BI 资产实施备份策略

Amazon Quick Sight 是 Amazon Quick 的核心功能——这是一个智能代理驱动的 AI 数字工作空间，旨在最大化终端用户生产力，它通过自然语言查询、交互式仪表板和来自可信企业数据源的嵌入式分析，提供 AI 驱动的 BI 能力。

Amazon Quick Sight 的资产（如仪表板、分析、数据集和数据源）可以使用本文介绍的 AssetsAsBundle API 进行备份。备份策略有助于防范意外删除、无意修改和区域性中断。对于依赖 Quick Sight 支持关键业务决策的团队，建议制定完善的备份计划。

本文是两部分系列文章的第一部分，涵盖 Amazon Quick Sight BI 资产的备份和恢复：

• 第 1 部分（本文）：介绍如何设计和实施备份策略，包括资产选择、可用的导出 API 以及现成的自动化工具示例。

• 第 2 部分：介绍恢复过程。您可以使用第 1 部分创建的备份，在发生意外删除、无意更改或作为更广泛的灾难恢复计划的一部分时恢复资产。

对于金融、医疗和能源等受严格监管的行业组织来说，有效的备份策略尤为重要，原因如下：

• 数据丢失防护可防范人为错误、意外删除和勒索软件等事件。

• 满足恢复目标有助于组织实现恢复点目标（RPO）和恢复时间目标（RTO），减少事件期间的数据丢失。

• 审计和报告支持对资产生命周期（创建、更新和删除）进行跟踪和报告。

• 提高工作负载弹性可快速将系统恢复到先前状态，减少停机时间并提高可靠性。这与 AWS Well-Architected Framework 的可靠性支柱一致。

• 灾难恢复（DR）准备为实施 DR 流程奠定基础，该流程可预见技术相关灾难，并有助于组织的业务连续性计划（BCP）。

有关 Quick 的灾难恢复功能及其如何根据组织需求进行评估的更多信息，请参阅《Amazon Quick 灾难恢复和弹性指南》。

在本文中，我们将介绍在 Quick Sight 中为 BI 资产实施有效备份策略的最佳实践。我们首先介绍选择包含在备份中的资产的选项，然后解释可用的高级 API，最后提供示例代码以帮助您快速入门。

业务智能的备份实践

由于 BI 系统在支持决策过程和关键利益相关者方面的作用，它们在业务连续性方面面临独特的挑战。您必须通过实施有效的备份计划来保护它们免受服务中断的影响。在制定此计划之前，了解架构和需要考虑的维度非常重要，这些是您 DR 计划的一部分。

上图显示 Quick Sight 依赖于 AWS 跨多个 AWS 区域的全球基础设施，以提供 Quick Sight 资产（包括数据源、数据集、分析和仪表板）的高可用性。

超快速、并行、内存计算引擎（SPICE）通过在Quick Sight区域内的多个可用区（AZs）中跨冗余副本实现高可用性（HA），从而存储和加密导入的数据。

通过这种区域设计，您可以在多个区域中维护资源，并在主BI资源所在的区域发生意外停机时使用次级区域。

对于用户和身份管理，Quick Sight使用您在初始账户订阅过程中定义的单一区域。图示显示，该区域托管用户和组身份信息，必须对用户访问Quick Sight保持可用。

例如，如果用户想要访问位于eu-west-1区域的仪表板，但Quick Sight主区域是us-east-1，则这两个区域都必须可用才能完成用户访问流程。Quick Sight使用包含可用区（AZs）的区域架构以实现冗余。然而，如果您需要防范区域停机的罕见情况，必须相应地设计灾难恢复（DR）策略。

提示：如果您不确定Quick Sight主区域，可以通过运行以下命令获取此信息：

aws quicksight describe-account-settings --aws-account-id XXXXXXXXXXXX --region us-east-1

注意：此aws quicksight describe-account-settings命令将us-east-1指定为端点区域。如果收到200状态，您的身份区域是us-east-1。否则，您将收到如下错误信息，提示您指向当前的身份区域（例如，eu-west-1）：

调用DescribeAccountSettings操作时发生错误（AccessDeniedException）：操作从端点us-east-1调用，但您的身份区域是us-east-1。请使用eu-west-1端点。

定义需包含在备份计划中的Quick Sight资产

在更清晰地了解Quick Sight架构后，下一步是选择要包含在备份计划中的资产，为此您可以采用两种策略：

备份特定资产：

当您定义一个以保护业务运营关键资产为重点的备份或灾难恢复策略，并且可以在灾难或意外删除后方便地恢复这些资产时，此选项适用。这包括关键利益相关者用于做出业务决策的特定仪表板（及其依赖资产），或运营团队（财务、物流、采购等）用于支持持续业务运营的资产。

当您需要一个简单的备份计划，并且对业务连续性至关重要的BI资产只是Quick Sight实例中所有可用资产的一个子集时，建议使用此选项。

备份所有资产：

当您希望定义一个涵盖版本管理和潜在灾难恢复的备份策略时，建议使用此策略。通过备份所有资产，如果人为错误导致意外修改或删除，您可以将任何资产回滚到之前的状态。此外，由于您拥有账户中所有资产的备份，您可以在灾难恢复计划中选择特定资产进行恢复。

这种方法提供最大覆盖范围，但也需要更复杂的编排和自动化。本文重点介绍此策略，并提供可调整的示例代码，以最大限度减少生产环境的部署时间。

选择策略后，请选择要导出的 BI 资产类型。Quick Sight 提供以下资产类型：

• 仪表板：面向读者用户的只读资产，从分析中发布。您也可以将仪表板保存为分析以进行编辑。

• 分析和仪表板：分析是仪表板的可编辑版本。只有您选择的作者才能访问它。

• 数据源：数据源实现了与您数据的连接，这些数据可以来自分析源（如数据库或数据仓库）、AWS 服务（如 Amazon Simple Storage Service（Amazon S3））或第三方软件即服务（SaaS）数据提供商（如 Jira 和 ServiceNow）。

• 数据集：一种使用数据源访问外部数据的资产类型，您可以利用这些数据准备和构建分析和仪表板所需的数据。

• VPC 连接：一种可用于与位于该 VPC 或可通过该 VPC 访问（如对等 VPC 或通过 VPN 或 AWS Direct Connect 连接的网络）的数据库和数据仓库等 VPC 资源集成的功能。

• 主题：一组样式和外观设置，您可以将其应用于多个分析和仪表板，以匹配符合产品或企业品牌需求的审美标准。

所有这些资产之间都存在依赖关系，分析和仪表板位于此依赖链的顶端，如下图所示。

在选择要备份的资产类型时，请注意这些依赖关系，以便能够从备份中完全恢复资产。例如，当您备份仪表板时，还需要备份其依赖项，这些依赖项可能包括数据集、数据源、VPC 连接和一个主题。下一节将解释 Quick Sight 导出 API 如何处理这些依赖关系。

备份流程概述

本文介绍的机制使用了 Quick Sight 中的 AssetsAsBundle API。AssetsAsBundle API（也称为 AAB API）是一组高级 API，旨在支持 Quick Sight 资源的程序化导出和导入。它们涵盖多种使用场景，如发布管理、备份和恢复、跨账户迁移以及持续集成和持续交付（CI/CD）工作流程。

这组 API 包括以下操作：

• StartAssetBundleExportJob：创建一个包含操作中导出资产的包（bundle）。该包是一个包含文本文件的 zip 文件。格式可以是 JSON 或 AWS CloudFormation，具体取决于 ExportFormat 参数中指定的值。根据格式，您可以直接使用 AAB API 导入这些资产，或使用 CloudFormation 基础设施即代码（IaC）进行配置。异步操作完成后，系统会将包上传到临时的 S3 位置以供下载。

• StartAssetBundleImportJob：将之前导出的包还原为其中打包的资产。您可以使用导入操作为一组广泛的参数（如资产名称和数据源连接参数（主机、端口、工作组等））定义覆盖设置。

• DescribeAssetBundleImportJob 和 DescribeAssetBundleExportJob：AssetBundle 操作均为异步操作。您可以使用这些 API 了解操作状态、轮询进度，并在操作完成后执行后续操作。执行导出任务时，可通过 DescribeAssetBundleExportJob 获取捆绑包的 DownloadUrl，该链接有效期为 5 分钟。您可通过再次调用 DescribeAssetBundleExportJob 延长链接有效期。

AssetsAsBundle API 支持的资产类型及当前限制

AssetsAsBundle API 支持 Quick Sight 的一系列资产，包括分析、仪表板、数据源、数据集、共享文件夹、受限文件夹、刷新计划、主题和 VPC 连接。但部分资产类型存在限制。

不支持的数据源：Adobe Analytics、文件、GitHub、Jira、Salesforce、ServiceNow、Amazon S3（含本地上传的清单文件）和 Twitter。

不支持的数据集：包含通过连接的 SageMaker 机器学习模型推断生成的机器学习（ML）列的数据集。

在执行 StartAssetBundleExportJob 操作时，若未将这些资产排除在备份计划之外，可能会导致 InvalidParameterValueException 错误。为解决此问题，可按照以下步骤替换不支持的数据源和数据集。

针对包含本地清单文件的 Amazon S3 数据源：

• 创建新的 Amazon S3 数据源。
• 将清单文件上传至 Amazon S3。
• 从数据源中引用该清单文件。
• 使用 UpdateDataSet API 将数据源替换为依赖数据集中的新数据源。

针对其他不支持的数据源和数据集：

按照以下步骤将不兼容的数据集转换为兼容格式：

• 创建连接到备份所需数据源的分析。
• 创建一个表格可视化以显示所有数据集列。
• 将数据导出为 CSV 文件。
• 使用上传至 Amazon S3 的清单创建 Amazon S3 数据集。
• 使用替换数据集功能，将分析和仪表板更新为新数据集。

备份计划中需考虑的其他资产

尽管 Quick Sight 资源是关键备份对象，但为应对潜在的恢复或灾难恢复场景，还需在备份计划中包含一些额外资源和配置。

您可以将 Quick Sight 资产及其权限（包括访问它们的用户和组）一并导出。通过将 IncludePermissions 标志设置为 true 可控制此功能。

由于每个 Quick Sight 资产均由用户拥有，因此需要备份用户和组以实现完整可恢复的备份。

AssetsAsBundle API 不涵盖用户和组，但可通过 DescribeUser、DescribeGroup 和 DescribeGroupMembership API 获取相关信息并包含在备份中。

除用户和组外，还需考虑备份账户设置，例如账户自定义（DescribeAccountCustomization API）、自定义品牌（DescribeBrand API）以及文件夹（ListFolders、DescribeFolder 和 DescribeFolderPermissions API）。

自动化工具支持三种操作模式：仅用户备份、仅资产备份和两者兼备。这为执行备份计划提供了最大的灵活性。下图展示了工具根据所选操作模式遵循的流程。

用户和组备份

用户和组备份服务使用 Quick Sight 用户和组 API 读取您账户的当前状态，并将获取的用户和组数据存储在 Amazon DynamoDB 中。该服务使用基于日期的后缀为 DynamoDB 表命名，以保留历史备份数据并防止覆盖。这使得可以实现时间点恢复和备份历史跟踪。这种设计还简化了恢复操作，因为在查询特定备份中的数据时，无需按日期后缀进行筛选。

2025-10-19 备份运行示例：

• 用户：quicksight-users-backup-2025-10-19
• 组：quicksight-groups-backup-2025-10-19
• 用户-组成员关系：quicksight-users-groups-backup-2025-10-19

用户表结构：

{
  "user_name": "string (partition key)",
  "arn": "string",
  "email": "string",
  "role": "string",
  "identity_type": "string",
  "active": "boolean",
  "principal_id": "string",
  "backup_timestamp": "string (ISO 8601)",
  "custom_permissions_name": "string"
}

组表结构：

{
  "group_name": "string (partition key)",
  "arn": "string",
  "description": "string",
  "principal_id": "string",
  "members": ["list of user names"],
  "backup_timestamp": "string (ISO 8601)"
}

用户-组成员关系表结构：

{
  "membership_id": "string (partition key, format: username#groupname)",
  "user_name": "string",
  "group_name": "string",
  "user_arn": "string",
  "group_arn": "string",
  "backup_timestamp": "string (ISO 8601)"
}

注意：用户和组备份服务实现了双区域支持。用户和组操作使用 identity_region 配置参数，而备份资产操作使用标准 aws_region。这种设计解决了企业场景中 Quick Sight 身份管理配置在不同区域而资产存储在另一区域的情况。

资产备份

资产捆绑备份服务协调区域内资产的导出，并将生成的捆绑包上传到 Amazon S3 位置以供后续使用。自动化备份包括以下资产：数据源、数据集、分析、仪表板和主题。默认情况下，备份包含所有依赖项。如有需要，可以禁用此设置。

总体而言，该服务执行以下任务：

• 使用 ListDataSources API 列出所有数据源，过滤掉基于 Amazon S3 清单的数据源以及 VPC 连接名称无效的数据源。名称必须仅包含由连字符分隔的字母数字字符。
• 使用 ListDataSets API 列出所有数据集，通过检查 ImportMode 字段过滤掉 FILE 类型的数据集。
• 使用 ListAnalyses API 列出所有分析。
• 使用 ListDashboards API 列出所有仪表板。
• 按类型对资产进行分组以进行单独的导出作业。可以配置每个捆绑包中包含的资产数量，最大为 100（API 限制）。
• 使用 DescribeAssetBundleExportJob API 检查导出作业状态，并实现指数退避以避免限流。
• 使用以下前缀结构将完成的资产捆绑包上传到 Amazon S3：

my-QuickSight-backups/
└── QuickSight-backups/                          # 自定义 S3 前缀
    ├── 2024/01/15/
    │   ├── datasources/
    │   │   ├── datasources-143022.zip            # 单个捆绑包（≤ max_assets_per_bundle）
    │   │   └── datasources_bundle_1-143045.zip   # 资产超出限制时的多个捆绑包
    │   ├── datasets/
    │   │   ├── datasets_bundle_1-143045.zip      # 资产超出限制时的多个捆绑包
    │   │   └── datasets_bundle_2-143045.zip      # 多个捆绑包的连续编号
    │   ├── analyses/
    │   │   └── analyses-143108.zip               # 单个捆绑包
    │   └── dashboards/
    │       ├── dashboards_bundle_1-143131.zip    # 多个仪表板捆绑包的第一个
    │       └── dashboards_bundle_2-143131.zip    # 第二个仪表板捆绑包
    └── 2024/01/16/
        ├── datasources/
        │   └── datasources-090015.zip
        ├── datasets/
        │   └── datasets-090030.zip
        └── ...

注意：仅当需要备份的资产数量超过 max_assets_per_bundle 配置值时，才会在捆绑包编号字符串中体现。

端到端备份工具

QuickSight-backup 工具提供了一种简单的方法，可将您的 QuickSight 资产及其依赖项导出到 Amazon S3 等耐用且低成本的存储中。该工具为生成的捆绑包创建新的前缀，因此不会覆盖之前的备份。该工具还使用相同原则导出用户和组：DynamoDB 存储这些数据，表名包含备份生成的日期。通过这种方法，您可以将备份作为恢复策略的数据源，并跟踪 QuickSight 资产及其关联用户的变更历史。

代码使用 Boto3 Python SDK，并通过 setuptools 提供打包支持以便安装和使用。

工具使用和配置

在使用工具之前，请确保满足以下前提条件：

• Python 3.8 或更高版本。

• 具有企业版或更高版本的 QuickSight 账户。

• 使用适当凭证配置的 AWS 命令行界面 (AWS CLI)。

• 必要的 AWS 权限。请参阅代码中的权限部分。

从源代码克隆

git clone https://github.com/aws-samples/sample-quicksight-backup-tool.git
cd quicksight-backup-tool

创建 Python 虚拟环境（推荐）

python3 -m venv ./.venv
source .venv/bin/activate

安装包

pip install -e .

创建配置文件

要开始使用，请参考仓库中的 config-basic.yaml 文件或从头创建一个配置文件。该配置文件定义了工具的关键参数，包括以下内容：

• AWS 账户。

• 区域。

• 备份位置（DynamoDB 表和 Amazon S3 存储桶前缀）。

使用工具

安装完成后，可以按以下方式运行工具：

quicksight-backup --config config.yaml --mode full

您只需提供 --config 参数。其余参数可以省略。--mode 参数控制备份类型（full、users-only 或 assets-only），其中 full 是默认模式。以下列表描述了工具支持的参数。

可选参数

• --mode , -m : 备份模式（full、users-only、assets-only）；默认为 full。

• --output-dir , -o : 报告和清单的输出目录。

• --verbose , -v : 启用详细（DEBUG）日志记录。

• --log-file : 日志文件路径。

• --dry-run : 验证配置而不执行备份。

• --no-progress : 禁用进度指示器。

• --generate-manifest : 生成备份清单文件。

• --generate-report : 生成可读的备份报告。

• --version : 显示版本信息。

如需更多信息，请参阅工具的 README 文件。

工具代码

你可以在 aws-samples 仓库中找到该工具的代码。此工具可帮助你快速入门。将其作为基础参考，根据你的具体备份需求进行优化和调整。

在生产环境中实施备份解决方案之前，请确认以下事项：

• 审查并调整代码，使其符合你的具体基础设施要求、安全策略和合规标准。

• 在非生产环境中进行全面测试，以验证功能和性能。

• 实施适当的安全部控制措施，包括加密、访问管理和审计日志，这些是你的组织所要求的。

• 验证恢复流程，确认你的备份策略满足定义的恢复时间目标（RTO）和恢复点目标（RPO）。

• 考虑成本优化策略和监控措施，以确保解决方案在运营预算范围内。

• 避免并发执行工具：此工具依赖于 AssetsAsBundle API，这些 API 的限流阈值较低。示例工具未设计为在同一 AWS 账户内并行运行多个实例。如果多个团队需要使用该工具，请考虑实施并发控制机制（例如 DynamoDB 中的锁表或数据库级别的锁），以防止可能触发 API 限流的并发运行。

定时执行

上一节描述的示例工具旨在按需执行，非常适合入门或运行临时备份。对于生产级备份策略，你可能希望自动化备份运行，按照定期计划执行，从而在无需人工干预的情况下持续保护 Quick Sight 资产。

本节概述了定时、全自动备份解决方案的高层架构。该架构的详细实现和代码超出了本文范围。

架构概述

定时执行架构基于三个 AWS 管理服务构建，这些服务协同工作，提供可靠、无服务器且成本效益高的自动化流程：

• Amazon EventBridge 是调度器。它按照定义的周期（例如每天午夜）触发备份工作流。EventBridge 规则允许你定义灵活的基于 cron 或速率的计划，而无需管理任何底层基础设施。

• AWS Step Functions 是编排层。它按正确顺序协调各个备份步骤的执行。Step Functions 提供内置的错误处理、重试逻辑和执行历史记录，这使其非常适合处理跨多个 API 调用和异步操作的长时间运行的工作流。

• AWS Lambda 将每个单独的备份步骤实现为独立的无状态函数。将备份逻辑拆分为多个 Lambda 函数可以解决备份过程中固有的时间限制。每个导出任务都是异步的，完成时间可能因导出资产的数量和大小而异，可能需要几分钟。

由于端到端备份过程可能需要较长时间，自动化流程被分解为独立步骤，每个步骤由专用的 Lambda 函数实现。AWS Step Functions 按顺序协调这些函数，在它们之间传递状态，并处理临时故障的重试。工作流包含以下步骤：

• 用户和组备份：使用 Quick Sight 身份 API 获取所有 Quick Sight 用户、组及组成员关系，并按照技术实现章节中描述的方式，通过基于日期的表后缀将数据持久化存储到 DynamoDB。此操作可以与资产备份操作并行运行，因为它没有依赖项。

• 资产备份发现：列出目标区域（数据源、数据集、分析和仪表板）中的所有 Quick Sight 资产，应用必要过滤器排除不支持的资产类型，并将资产分组为最多包含 100 项的列表。此步骤的输出将作为后续步骤的输入传递。

• 生成捆绑包：为输入参数指定列表中的所有资产启动导出任务，轮询任务完成状态，并将生成的 ZIP 捆绑包上传到指定的 Amazon S3 前缀。

• 状态检查：定期轮询活动捆绑包执行状态，并在导出完成时通知 AWS Step Functions 状态机。

下图展示了计划执行架构的高层流程。

关键设计考量

• 异步轮询：check-status Lambda 函数使用 DescribeAssetBundleExportJob API 轮询由 generate-bundle Lambda 函数启动的任务，直到任务达到终端状态（SUCCESSFUL 或 FAILED）。check-status Lambda 函数以等待条件（例如 30 秒）循环运行。

• 并行性：配置适当的并行级别以控制工作流中各步骤执行的 API 调用量，特别是在调用 DescribeAssetBundleExportJob 和 StartAssetBundleExportJob API 的 generate-bundle 步骤，这些 API 具有较低的并发速率限制。可以使用内联 map 状态的 MaxConcurrency 字段限制 generate-bundle 步骤的并发运行次数。

• 错误处理：Step Functions 允许在每个阶段定义 catch 块和重试策略。某一步骤的失败（例如不支持的资产类型）不会中止整个备份运行。

• 成本：启用计划功能后，成本会随着备份频率和保留期的增加而增加。关于存储成本估算的指导，请参阅成本估算章节。

成本估算

以下章节估算在 Amazon S3（用于资产捆绑包）和 DynamoDB（用于用户和组元数据）上运行备份工具的成本。

Amazon S3：资产捆绑包存储

资产捆绑包是每次导出任务后上传到 Amazon S3 的压缩 ZIP 文件。根据解决方案设计，每个最多包含 100 个资产的捆绑包压缩后平均约为 500 KB。

关键结论：资产捆绑包的 Amazon S3 存储成本非常低。即使对于拥有数千个资产的大型 Quick Sight 部署，压缩后的捆绑包大小仍保持在兆字节级别，每月存储成本远低于 0.01 美元。

Amazon DynamoDB：用户和组元数据存储

用户和组信息存储在带有日期后缀的DynamoDB表中以保留备份历史。DynamoDB存储成本约为每GB每月0.25美元（标准表类，按需模式）。

DynamoDB中存储的每个项目代表一个用户或组定义（包括所有相关属性，如ARN、电子邮件、角色、组成员资格和备份时间戳）。根据本文所述的模式，平均项目大小约为256 KB。

您可以使用以下公式估算DynamoDB表的大小：

表大小估算 = 项目数量 × 平均项目大小（256 KB）

关键结论：对于中小型组织，DynamoDB存储成本保持在较低水平（每个备份快照每月不到0.10美元）。对于拥有数万名用户的大型组织，每个快照的成本仍处于个位数美元的低端范围。

总结

对于单次未计划的备份运行，总AWS成本实际上接近于零，最多仅包含几美分的Amazon S3和DynamoDB存储成本。如果您实施计划备份（见计划执行部分），成本将随着备份频率和保留期线性增长。即使每天备份并保留90天，大多数部署的总存储成本仍保持在个位数美元的低端范围。随着备份历史增长，建议使用Amazon S3生命周期策略和DynamoDB标准-IA存储类来优化成本。

结论

在本文中，我们介绍了如何设计和实施针对Amazon Quick Sight资产的全面备份策略，以确保业务连续性、满足监管要求并防止数据丢失。

我们介绍了如何使用AssetsAsBundle API以编程方式导出和保留关键BI资产（包括仪表板、分析、数据集和数据源及其依赖项和权限）。为了帮助您入门，本文包含了一个示例自动化工具，您可以测试并根据组织需求进行调整。该代码协调这些API，将资产包存储在Amazon S3中，并在DynamoDB中保留用户和组信息以实现时间点恢复。

准备好保护您的Quick Sight BI资产了吗？今天就从AWS Samples存储库克隆示例备份工具，并在非生产环境中进行测试。从简单的配置开始，备份最重要的仪表板，然后在验证流程后扩展到生产就绪的备份策略。要了解更多关于Amazon Quick Sight的信息，请参阅《Amazon Quick Sight用户指南》。

作者简介

'"`