亚马逊 QuickSight SPICE 与直接查询模式最佳实践

主要要点

在本文中，我们概述了使用 QuickSight 的 SPICE 和直接查询模式的优势以及考虑因素。SPICE 提供高性能、低成本的数据处理解决方案，而直接查询模式则适用于实时数据需求。针对不同的场景，我们提供了如何有效选择查询模式的建议。

亚马逊 QuickSight 是一款可扩展的无服务器业务智能BI服务，具有机器学习ML支持。这项服务可以连接来自亚马逊网络服务AWS、其他云服务商以及本地的数据源。常见的数据源包括亚马逊简单存储服务 (Amazon S3)、亚马逊 Athena、亚马逊关系数据库服务 (Amazon RDS) 和亚马逊 Redshift。有关更多支持的数据源，请查看支持的数据源。连接到数据源后，用户可以在此基础上创建数据集。每个数据集可以使用 SPICE超级快速并行内存计算引擎或直接查询模式。用户可以使用这些数据集创建交互式仪表板、分页报告，以及支持自然语言查询的数据主题。

在 QuickSight 中，当可视化加载于分析、仪表板、报告、导出中，或在对 Amazon Q 提出自然语言问题时，数据会从数据集中进行查询。每次请求发送时，都会将直接查询发送到基础数据源。通过 SPICE，数据的可刷新的快照在 QuickSight 中被缓存，所有查询都使用 SPICE 中的最新快照，无需重新连接到基础数据源。

Amazon QuickSight SPICE和直接查询模式的最佳实践商业智能博客

以下示意图展示了 QuickSight 查询模式之间的区别。例如，当连接到 Redshift 数据源时，QuickSight 可以选择将数据从 Redshift 录入到 SPICE 中，或直接从 Redshift 查询数据。

使用 SPICE 的好处

SPICE 是一个内存计算引擎，旨在加速 QuickSight 中仪表板的性能。用户可以通过配置的调度、按需使用 UI 或通过刷新 API 来将数据从数据源导入 SPICE。SPICE 结合了列存储、最新硬件创新所支持的内存技术以及机器代码生成，以便在大型数据集上执行交互查询并快速返回响应。当 SPICE 数据集正在刷新时，依赖的仪表板会显示先前快照中的数据，以便用户可以不间断地与仪表板进行交互。

除了性能提升外，SPICE 还通过仅在需要数据导入时查询数据源，从而减轻数据源的负担。SPICE 的使用费用仅基于为存储数据而购买的容量以 GB 计。这些数据集在任何数量的仪表板和用户中消费均不产生额外费用。每个 Author、Author Pro、Admin 和 Admin Pro 许可证包含 10 GB 的 SPICE 容量，并可以在账户级别购买额外容量。当 SPICE 数据集被大量用户并发访问时，SPICE 会自动扩展并管理整个工作负载，以便为整个用户群体提供一致的快速响应时间。通过将工作负载从数据源转移到 SPICE，用户可以获得成本效益和改进的仪表板性能。

在安全性方面，存储在 SPICE 中的数据在静止时是加密的。默认情况下，SPICE 加密密钥由 AWS 管理。或者，SPICE 允许使用存储在 AWS 密钥管理服务 (AWS KMS) 中的客户管理密钥对静态数据进行加密。这为用户提供了审计数据访问和满足监管安全要求的工具。用户可以通过撤销对 AWS KMS 密钥的访问，立即锁定对数据的访问。数据从数据源转移到 SPICE 以及从 SPICE 转移到用户界面时，均使用传输层安全性TLS进行加密。

使用 SPICE 时的考虑因素

存储在 SPICE 数据集中的数据是数据的一个快照。要从源获取最新数据并刷新 SPICE 数据集，用户可以配置调度或使用事件驱动的方法。

SPICE 支持通过数据摄取操作 API 进行编程调用。一个常见的用例是在提取、转换、加载ETL流程完成后使用这些 API 触发 SPICE 数据刷新，并将数据存储在数据湖或数据仓库中。每个数据集可以在 24 小时内进行最多 32 次全量刷新。此按需刷新过程需要通过 QuickSight UI 或使用 QuickSight API 调用 CreateIngestion 来启动。每个数据集在 24 小时内可以进行最多 100 次按需增量刷新。需要注意的是，在达到限制后，无法启动按需全量刷新或增量刷新。然而，这不会影响已配置的计划，它们将继续按计划运行。有关全量和增量刷新的更多细节，请参见保持数据新鲜的增量 SPICE 刷新。

SPICE 每个数据集允许最多 10 亿行或 1 TB 数据以先到者为准。每个字段可以存储最多 2047 个 Unicode 字符，每个列名最多可支持 127 个 Unicode 字符。如需获取有关 SPICE 数据源配额的更多详细信息，请查看数据源配额。随着数据量的增加，用户需要主动管理增长，以确保在数据导入过程中不会超过 SPICE 限制，防止数据导入失败。有关 SPICE 大小估算，请参见估算 SPICE 数据集大小。

轻舟加速器下载

另一个重要的考虑因素是总 SPICE 容量，此容量在账户级别分配。在以下屏幕截图中，剩余可用容量仅限于 162 GB。如果此可用容量被单个或多个数据集耗尽，将导致数据导入失败。为防止此类失败，用户可以根据需要从 QuickSight UI 手动购买额外的 SPICE 容量。此外，用户还可以启用自动购买容量选项，以便 SPICE 自动获取所需的容量，从而避免数据导入失败。

使用直接查询模式的好处

直接查询模式允许对数据源进行近实时查询。当用户打开或刷新仪表板时，QuickSight 会直接向数据源发送查询。数据源负责运行查询并返回结果，这些结果会立即在仪表板中可视化。如果数据源的响应时间较快，使用直接查询模式可以获得最新数据和高性能仪表板的双重好处。

直接查询模式对数据集的行数或大小没有限制。这使得直接查询模式适合用于数据量超过 SPICE 行数或大小限制的用例。

对于响应较慢的查询，用户可以使用数据集参数来过滤数据，从而减少数据量，进而加快查询性能。当用户与仪表板交互时，他们在控件、过滤器和可视化中所做的选择和操作可以通过实时的自定义参数化 SQL 查询传播到数据源。有关更多详细信息，请参见使用数据集参数优化 Amazon QuickSight 中的查询。

使用直接查询模式时的考虑因素

由于直接查询模式会在用户访问仪表板时实时发送查询到数据源，因此性能将依赖于数据源的运行时。如果查询运行较长时间，仪表板用户将经历较长的等待时间，以便可视化呈现。一般来说，使用直接查询模式时的等待时间会比使用 SPICE 数据集时更长。为确保良好的用户体验，建议在使用直接查询模式时选择响应时间较快的数据源。

需要注意的是，QuickSight 对生成仪表板可视化设置了 2 分钟的超时。此超时适用于直接查询模式和 SPICE。然而，并非所有数据库驱动程序都会响应 2 分钟的超时并取消查询，因此可能需要手动或通过编程在数据源中取消查询。直接查询模式对每个列名支持最多 127 个 Unicode 字符，对每个数据集支持 2000 列。特定于数据源的超时也会适用，并且会因每种数据源类型而异。

最后，随着数据量的增长，查询响应时间可能会减慢，这要求用户提升源的能力，这可能会产生额外成本。特别是在处理大量频繁使用仪表板的用户时，因为直通查询模式的高并发量会超出数据源处理负载的能力，因此更需关注此问题。

不同场景下的推荐查询模式

本节讨论具有不同延迟要求的仪表板的常见场景，并描述如何使用 SPICE 和直接查询模式来满足它们的需求。其他需考虑的关键因素包括数据量、数据更新频率和数据源性能。

仪表板数据每日更新

仪表板数据通常需要每日更新，以反映前一天的信息。在这些情况下，数据通常通过批量 ETL 流程从源系统提取、转换并加载到数据湖或数据仓库中，通常在业务外时间运行。如果数据量在 SPICE 配额之内，则根据源系统中数据更新的方式，推荐方法有所不同。对于源系统中的个别记录更新场景，SPICE 与每日全量刷新是合适的选择。然而，如果数据主要是追加的，则 SPICE 与每日增量刷新会更好地处理新添加的数据。如果 ETL 过程在一天中的某个时间完成，则可以安排 SPICE 中的每日数据刷新，以与 ETL 过程对齐。另一方面，如果 ETL 处理时间不可预测，则可以使用更灵活的方法。在这种情况下，可以在 ETL 过程完成后，使用 QuickSight API 以编程方式调用 SPICE 刷新。有关更多信息，请参见亚马逊 QuickSight 中的事件驱动 SPICE 数据集刷新。