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

post-thumb

从我职业生涯的早期开始,数据,以及我们从这些数据中得出的见解,一直在我心中占据着特殊的位置。在亚马逊这样的公司,要按照要求的时间框架将数百万件商品交付给客户,以及运行大型全球数据中心来托管我们基于云计算的服务,都取决于我们理解、处理和分析大量数据的能力。

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

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

今天,我将深入介绍客户如何在AWS上构建自己的时间序列解决方案,以及我们如何构建Amazon时间流,为客户提供更可伸缩、性能最好的选项。

再也没有鲁布·戈德堡机器了

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

这里的想法是在传入数据时对其进行排队,然后将其放入高度可伸缩且持久的存储中,如Amazon DynamoDB。然后,将数据导出到Amazon EMR,以便将数据转换为一种格式,以满足您的每个用例,使用Redshift或Athena将数据公开给分析和应用程序特定的功能,等等。

对于较小规模的实现来说,这是一种可行的架构,但随着吞吐量需求的增加,伸缩性就成为了一个主要挑战。为了完成这项工作,客户最终会反复地着陆、转换和移动数据,并将数十个AWS服务流水线连接在一起。看着这些解决方案真的像是看着小题大作的机器.为了满足这些工作负载的需要,体系结构变得多么复杂,这令人震惊。

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

所以我们创建了时间流。

时间流是如何建立的?

我们从零开始,建立了亚马逊时间流的大规模。时间流从解耦数据摄取、存储和查询开始,这样每个数据都可以独立伸缩。该设计保持了每个子系统的简单性,使其更容易实现不可动摇的可靠性,同时也消除了扩展瓶颈,并降低了相关系统故障的机会,而随着系统的增长,相关系统故障的机会变得更加重要。

同时,为了管理整体增长,该系统是基于细胞——而不是规模系统作为一个整体,我们系统划分为多个小的副本本身(称为“细胞”),这些细胞可以在全面测试,和一个细胞的一个系统问题不能影响其他细胞的活动。基于单元的体系结构是与我们在亚马逊极光上采用的方法相同近年来,这一策略为我们保持行业领先的服务可用性提供了良好的帮助。顺便提一下,Peter Vosshall在几年前做了一个关于最小化爆炸半径和我们基于细胞架构的应用的很棒的演讲。我强烈推荐看他的谈话

获取数据中

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

在摄取方面,Timestream将表(或者更确切地说,是表的一个分区)的写路由到只接受写操作的容错内存存储实例。内存存储在一个独立的存储系统中实现持久性,该存储系统跨三个可用分区(az)复制数据。复制是基于仲裁的,因此节点或整个AZ的丢失不会破坏写可用性。在接近实时的情况下,其他内存存储节点同步数据以服务查询。reader副本节点也可以跨az,以确保高读可用性。

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

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

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

数据生命周期

时间流旨在自动管理时间序列数据的生命周期。它提供了两种数据存储—内存存储和经济有效的磁性存储,并且它支持配置表级策略来自动跨存储传输数据。传入的写位于内存存储区,数据在这里进行了写优化,以及在当前时间执行的读操作,以驱动仪表板和警告类型查询。当写、警报和仪表板需求的主要时间框架已经过去时,允许数据自动从内存存储流到磁性存储,从而优化成本。

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

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

查询

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

查询由专门的工作人员团队运行,其中指定运行给定查询的工作人员数量由查询复杂性和数据大小决定。大型数据集上的复杂查询的性能是通过大量并行实现的,无论是在查询执行队列还是系统的存储队列上。快速有效地分析大量数据的能力是时间流的最大优势之一。在tb甚至pb级的数据上执行的一个查询可能会有数千台机器同时在处理它。

设计在今天(和明天)数据驱动的世界中执行

当今世界在时间序列数据的数量和使用上正在迅速增长,这是由仪器/监控地球上和其他地方的一切,连接在非常高的带宽(5G等),并利用ML/ ai驱动的分析来利用数据。现在,当客户需要处理、管理和分析大量的时间序列数据,他们不再需要建立和维护一个小题大作的机器——Timestream AWS承担所有的复杂性,和客户可以专注于他们想要的数据。

评论的Disqus