亚马逊时间流-时间序列是新的黑色

后拇指

从我职业生涯的最初几天起,数据以及我们从这些数据中得出的见解一直在我心中占据着特殊的位置。在像亚马逊这样的公司,在苛刻的时间框架内向客户交付数以百万计的商品,并运行大规模的全球数据中心来托管我们基于云的服务产品,都取决于我们理解、处理和分析大量数据的能力。

当然,这在几乎所有行业都是正确的——利用数据的能力可能是企业兴衰成败的关键。作为一名技术领导者,我对此感到担忧的是,许多公司没有投资于能够让他们在这里取得成功的正确技术。以数据库为例,许多数据库仍然在使用传统的关系数据库,这仅仅是因为它们不知道其他方法。关系数据库当然有它的位置,但它经常被用作锤子——一种用于直截了当地解决许多问题的通用工具——而事实上,有许多专门的数据库技术更适合于一项任务。就像外科医生会有各种各样的手术刀或木匠会有几十个钻头一样,开发人员需要能够以最有效的方式准确满足其业务目标的数据管理选项。必威体育精装版app官网

我们所看到的一个真正起飞的领域是需要跟踪和测量一段时间内的数据-时间序列数据。作为个人,我们在日常生活中一直使用它;如果你想改善你的健康,你可以跟踪你每天走多少步,并随着时间的推移将其与你的体重或体型联系起来,以了解你做得有多好。这显然是一个小规模的例子,但在光谱的另一端,大规模时间序列用例在我们当前的技术景观中比比皆是。无论是跟踪每毫秒发生变化的股票或加密货币的价格、视频流应用程序的性能和健康指标、读取温度、压力和湿度的传感器,还是数百万物联网设备生成的信息。现代数字应用要求AWS客户以极端规模收集、存储和分析时间序列数据,其性能是关系数据库无法提供的。

今天,我想深入介绍客户如何在AWS上构建自己的时间序列解决方案,以及我们如何构建Amazon Timestream,为客户提供更具可扩展性、一流性能的选择。

再也没有鲁布·戈德伯格的机器了

当我们建立新的服务时,我们的目标是解决棘手的客户问题。在时间序列数据的情况下,我们发现客户正在使用几个AWS服务构建复杂的定制体系结构。在Timestream之前,在AWS上构建时间序列解决方案的一种常见方法是拼凑如下内容:

这里的想法是在数据进入时对其进行排队,然后将其放入一个高度可扩展且耐用的存储中,如Amazon DynamoDB。从那里,将数据导出到Amazon EMR,以便将数据塑造成能够满足每个用例的格式,使用Redshift或Athena将数据公开给分析和特定于应用程序的功能,等等。

对于较小规模的实现来说,这是一个合理的体系结构,但随着吞吐量需求的增加,扩展这一体系结构成为一个重大挑战。为了完成这项工作,客户最终会反复登陆、转换和移动数据,而不仅仅是几个AWS服务,而是几十个AWS服务通过管道连接在一起。查看这些解决方案真的感觉就像查看鲁布·戈德堡机械. 为了满足这些工作负载的需求,体系结构变得多么复杂,这令人震惊。

最重要的是,所有这些都需要由我们的客户构建、管理和维护,但仍然无法满足他们的规模和性能需求。我们看到的许多时间序列应用程序正在生成大量数据。这里一个常见的例子是视频流。交付高质量视频内容是一个非常复杂的过程。了解负载延迟、视频帧丢失和用户活动是需要大规模实时进行的事情。仅此过程就可以每秒生成数GB的数据,同时每小时轻松运行数十万次(有时超过一百万次)查询。在这里,关系数据库当然不是正确的选择,前面提到的体系结构管理起来很复杂,仍然难以满足这样的应用程序的需求。

这正是我们构建Timestream的原因。

Timestream是如何构建的?

我们从头开始构建Amazon Timestream,以实现大规模应用。Timestream最初是通过解耦数据摄取、存储和查询来实现的,这样每个数据都可以独立扩展。该设计使每个子系统保持简单,使其更容易实现坚定不移的可靠性,同时还消除了扩展瓶颈,并减少了相关系统故障的机会,随着系统的发展,这一点变得更加重要。

同时,为了管理总体增长,系统是基于单元的——而不是将系统作为一个整体进行扩展,我们将系统分割为多个较小的自身副本(称为“单元”),以便可以对这些单元进行全面测试,并且一个单元中的系统问题不会影响任何其他单元中的活动。基于单元的体系结构是我们对亚马逊极光采取了同样的方法,这是一项近年来为我们提供了良好服务的战略,以保持业界领先的服务可用性。作为旁白,几年前Peter Vosshall就最小化爆炸半径和基于单元架构的应用做了一次非常棒的演讲。我极力推荐看他的演讲.

获取数据

其他时间序列实现的主要挑战之一是如何在不影响查询性能的情况下将高吞吐量的事件引入系统。其他时间序列系统难以做到这一点,这就是为什么它们经常分阶段对其性能进行基准测试——它们在不运行查询的情况下加载测量吞吐量和延迟的数据,然后在不同时加载任何数据的情况下对查询性能进行基准测试。虽然这对于原始比较可能有一些价值,但对于实际工作负载来说是不现实的。一个系统在满负荷下的性能并不等于其子系统性能的总和。事实上,通常情况下,针对同一系统的大规模并发活动的最佳性能实际上是通过不孤立地优化子系统的设计来实现的。认识到这一点,Timestream同时优化了扩展数据摄取和查询负载,并始终在整个工作负载运行时测试系统。

在摄取端,Timestream将表(或者更确切地说,表的分区)的写入路由到只进行写入的容错内存存储实例。内存存储反过来在一个单独的存储系统中实现持久性,该存储系统跨三个可用性区域(AZ)复制数据。复制是基于仲裁的,因此节点丢失或整个AZ不会中断写入可用性。在接近实时的情况下,其他内存中存储节点与数据同步,以便为查询服务。读卡器副本节点也跨越AZ,以确保高读可用性。

实现大规模的关键在于分区方案——一个时间流真正闪耀的领域。单个timestream表可能有数百个、数千个甚至数百万个分区。各个分区之间不直接通信,也不共享任何关于彼此的数据(无共享架构)。相反,表的分区是通过一个高度可用的分区跟踪和索引服务来实现的。这实现了另一种关注点分离,专门设计用于最小化系统中故障的影响,并降低相关故障的可能性。

当数据存储在Timestream中时,它不仅按时间顺序进行组织,而且还根据用数据编写的上下文属性跨时间组织数据。我们发现,在时间之外划分“空间”的分区方案对于大规模扩展时间序列系统非常重要。这是因为大多数时间序列数据是在当前时间或大约当前时间写入的。因此,仅按时间划分并不能很好地分配写通信量,也不能在查询时有效地修剪数据。这对于极端规模的时间序列处理来说是一件大事,它允许Timestream以无服务器的方式扩展到比当今其他领先系统更高的数量级。我们将产生的分区称为“瓷砖”,因为它们代表了二维空间的分区,这些分区的设计尺寸相似,很像厨房地板的瓷砖。

时间流表从单个分区(分片)开始,然后根据吞吐量要求在空间维度上拆分。当分片达到一定大小时,它们会在时间维度上进行拆分,以便随着数据大小的增长实现更好的读取并行性。

数据生命周期

Timestream旨在自动管理时间序列数据的生命周期。它提供两个数据存储—内存存储和经济高效的磁性存储,并支持配置表级策略以跨存储自动传输数据。传入的写操作位于内存存储区中,在内存存储区中,数据针对写操作进行了优化,并在当前时间执行读取操作,以启动仪表板和警报类型查询。当写入、警报和仪表板需求的主要时间段过去后,允许数据自动从内存存储流向磁性存储将优化成本。

Timestream允许为此目的在内存存储上设置数据保留策略。

一旦数据移动到磁性存储器,它将被重新组织为一种格式,该格式针对大容量数据读取进行了高度优化。磁性存储器还具有数据保留策略,如果存在数据超出其用途的时间阈值,则可以配置该策略。当数据超过为磁存储保留策略定义的时间范围时,它将自动删除。我曾看到客户煞费苦心地将这些生命周期机制构建到他们的Rube Goldberg机器中,他们发现这些东西非常难以正确使用。使用Timestream,而不是某些配置,数据生命周期管理在幕后无缝进行。事实证明,这是我们的“Rube Goldberg”解决方案客户认为非常有价值的功能之一,因为以前他们必须自己转换和移动数据,这在一次性解决方案中非常复杂且容易出错。

查询

时间流查询以SQL语法它扩展了特定于时间序列的支持(特定于时间序列的数据类型和函数),因此对于已经使用SQL的开发人员来说,学习曲线很容易。然后,查询由自适应分布式查询引擎进行处理,该引擎使用磁贴跟踪和索引服务中的元数据在发出查询时跨数据存储无缝访问和组合数据。这使得体验与客户产生了良好的共鸣必威体育精装版app官网,因为它将许多Rube-Goldberg的复杂性分解为一个简单而熟悉的数据库抽象。

查询由专门的工作组运行,其中登记运行给定查询的工作组数量由查询复杂性和数据大小决定。大型数据集上复杂查询的性能是通过在系统的查询执行组和存储组上的大规模并行实现的。能够快速高效地分析大量数据是Timestream最大的优势之一。一个执行数TB甚至数PB数据的查询可能会有数千台机器同时处理这些数据。

专为当今(和未来)数据驱动的世界而设计

当今世界,时间序列数据的数量和使用正在迅速增加,其驱动因素是对地球上和地球以外的一切进行检测/监测,以极高的带宽进行连接(5G等),并利用ML/AI驱动的分析来利用数据。现在,当客户需要处理、管理和分析大量时间序列数据时,他们不再需要构建和维护Rube Goldberg机器——借助Timestream,AWS承担了所有的复杂性,客户只需关注他们想从数据中得到什么。