从2025年6月20日起，亚马逊Timestream版 LiveAnalytics 将不再向新客户开放。如果您想使用亚马逊 Timestream LiveAnalytics，请在该日期之前注册。现有客户可以继续照常使用该服务。有关更多信息，请参阅 Amazon Timestream 以了解 LiveAnalytics 可用性变更。
本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
架构
用于实时分析的 Amazon Timestream 是从头开始设计的，旨在大规模收集、存储和处理时间序列数据。其无服务器架构支持完全分离的数据摄取、存储和查询处理系统，这些系统可以独立扩展。这种设计简化了每个子系统，可以更轻松地实现坚定不移的可靠性，消除扩展瓶颈，并减少相关系统故障的机会。随着系统的扩展，这些因素中的每一个都变得越来越重要。
写架构
在写入时间序列数据时，Amazon Timestream for Live Analytics 会将表、分区的写入路由到处理高吞吐量数据写入的容错内存存储实例。反过来，内存存储在独立的存储系统中实现了持久性，该存储系统将数据复制到三个可用区（AZs）。复制基于法定人数，因此节点或整个可用区的丢失不会中断写入可用性。其他内存存储节点近乎实时地同步到数据以提供查询。读取器副本节点 AZs 也跨越多个节点，以确保高读取可用性。
Timestream for Live Analytics 支持将数据直接写入磁存储，适用于生成吞吐量较低的延迟数据的应用程序。迟到的数据是指时间戳早于当前时间的数据。与内存存储中的高吞吐量写入类似，写入磁存储的数据将跨三次复制， AZs 并且复制基于法定人数。
无论数据是写入内存还是磁性存储，Timestream for Live Analytics 都会在将数据写入存储之前自动对其进行索引和分区。一个 Timestream for Live Analytics 表可能有数百、数千甚至数百万个分区。各个分区不直接相互通信，也不共享任何数据（无共享架构）。相反，表的分区是通过高度可用的分区跟踪和索引服务来跟踪的。这提供了另一种关注点分离，专为最大限度地减少系统故障的影响并大大降低相关故障的可能性而设计。
存储架构
当数据存储在 Timestream for Live Analytics 中时，将根据随数据一起写入的上下文属性按时间顺序和跨时间组织数据。拥有除时间之外还能分割 “空间” 的分区方案对于大规模扩展时间序列系统非常重要。这是因为大多数时间序列数据是在当前时间或大约当前时间写入的。因此，仅按时间进行分区并不能很好地分配写入流量或允许在查询时对数据进行有效修剪。这对于极大规模的时间序列处理非常重要，它使Timestream for Live Analytics能够以无服务器方式比当今其他领先系统高出几个数量级。生成的分区之所以被称为 “切片”，是因为它们代表二维空间的分区（设计为大小相似）。Live Analytics 表的时间流从单个分区（切片）开始，然后根据吞吐量的需要在空间维度中进行拆分。当切片达到一定大小时，它们会在时间维度上进行拆分，以便随着数据大小的增长实现更好的读取并行性。
Timestream for Live Analytics 旨在自动管理时间序列数据的生命周期。Timestream for Live Analytics 提供两个数据存储——一个内存存储和一个经济实惠的磁性存储。它还支持配置表级策略以自动跨商店传输数据。传入的高吞吐量数据写入存储器中，在内存存储中，数据会针对写入进行优化，也可以在当前时间左右执行读取，以便为仪表板供电和提醒类型查询。当写入、警报和仪表板制作需求的主要时间范围过去时，允许数据自动从内存存储流向磁性存储以优化成本。Timestream for Live Analytics 允许为此目的在内存存储上设置数据保留政策。为迟到的数据写入的数据会直接写入磁存储。
一旦数据在磁存储中可用（由于内存存储保留期到期或由于直接写入磁存储），就会将其重组为一种针对大容量数据读取进行了高度优化的格式。磁性存储器还具有数据保留策略，如果存在时间阈值使数据超过其用处，则可以配置该策略。当数据超过为磁性存储保留策略定义的时间范围时，会自动将其删除。因此，使用 Timestream for Live Analytics，除了某些配置外，数据生命周期管理可以在幕后无缝进行。
查询架构
Live Analytics 查询的时间流以 SQL 语法表示，该语法具有针对特定时间序列的支持（特定于时间序列的数据类型和函数）的扩展，因此对于已经熟悉 SQL 的开发人员来说，学习曲线很容易。然后，查询由自适应分布式查询引擎处理，该引擎使用来自切片跟踪和索引服务的元数据，在发出查询时无缝访问和合并跨数据存储的数据。这将带来一种能引起客户共鸣的体验，因为它将 Rube Goldberg 的许多复杂性整合为一个简单而熟悉的数据库抽象。
查询由专门的工作人员队伍运行，其中参与运行给定查询的工作人员数量由查询的复杂性和数据大小决定。对大型数据集进行复杂查询的性能是通过在查询运行时队列和系统的存储队列上的大规模并行性实现的。快速高效地分析海量数据的能力是Timestream for Live Analytics的最大优势之一。运行超过 TB 甚至 PB 数据的单个查询可能会让成千上万台计算机同时处理所有数据。
蜂窝架构
为了确保 Timestream for Live Analytics 可以为您的应用程序提供几乎无限的扩展，同时确保 99.99% 的可用性，该系统还使用蜂窝架构进行设计。Timestream for Live Analytics 没有将整个系统扩展为多个较小的副本，称为单元格。这允许对细胞进行全面测试，并防止一个细胞中的系统问题影响给定区域中任何其他细胞的活性。虽然 Timestream for Live Analytics 旨在支持每个区域的多个单元格，但请考虑以下虚构场景，即一个区域中有 2 个单元。
在上面描述的场景中，数据摄取和查询请求首先分别由发现端点处理，分别用于数据摄取和查询。然后，发现端点识别包含客户数据的单元，并将请求定向到该单元的相应摄取或查询端点。使用时 SDKs，这些端点管理任务将以透明方式为您处理。