乐趣区

关于分析:Amazon-Timestream-在车联网场景的典型应用和性能测试

jiezi

在工业物联网以及互联网等场景中，经常会产生大量的带工夫标签的数据，被称为 工夫序列数据。这些数据的典型特点为：产生频率快（每一个监测点一秒钟内可产生多条数据）、重大依赖于采集工夫（每一条数据均要求对应惟一的工夫）、测点多信息量大（实时监测零碎有成千上万的监测点，监测点每秒钟都产生数据，每天轻松产生几十 GB 甚至更多的数据量）。例如，生产制作、电力、化工等行业，须要实时监测，查看并剖析海量设施所采集和产生的数据；车联网以及电动汽车也会产生海量数据用于行车安全监控，车辆设施状态监控；互联网利用运行状况的监控、实时点击流数据的收集以及剖析等等。

工夫序列数据的这些特点，使得传统的关系型数据库无奈提供高效存储、疾速扩大以及疾速解决的能力。工夫序列数据库因而应运而生，它采纳非凡的存储形式，专门针对工夫序列化数据做了优化，极大进步了工夫相干数据的解决能力，绝对于关系型数据库，它的存储空间减半，查问速度失去显著进步。

Amazon Timestream 是一种疾速、可扩大的全托管、无服务器工夫序列数据库服务，借助 Amazon Timestream，您能够每天轻松存储和剖析数万亿个事件。其次要劣势为：

  • 高性能、低成本：相比传统关系型数据库，其速度晋升了 1000 倍，而老本仅为十分之一。
  • 无服务器：主动缩放以调整容量和性能，使得您只须要专一于应用程序的构建，而无需治理底层基础设施。
  • 生命周期治理：依据您事后设置好的生命周期策略，Amazon Timestream 能够主动实现将近期数据保留在内存层，而将历史数据挪动到老本优化的磁性存储层，帮忙您节俭治理时序数据库的工夫以及老本。
  • 简略高效查问：无需在查问中显式指定数据是保留在内存中还是老本优化层中，Amazon Timestream 的查问引擎可用于对立的拜访和剖析近期数据和历史数据。

此文将利用一个车联网行车监控上报时序数据的模型，探讨 Amazon Timestream 如何通过流式办法注入行车数据以及在不同数据量下的的扩展性以及查问性能体现。构造上分为数据模型、Amazon Timestream 端到端测试、性能体现三个局部，如果心愿间接看性能评测后果，能够间接跳到性能体现当中查看论断。

数据模型

场景介绍

咱们选取一个车联网行车监控的典型场景，汽车实时监测数据会以时序数据的模式，流式的上传并存储到 Amazon Timestream 中，由不同的数据使用者、不同的应用程序做不同类型的 SQL 查问。

应用 Amazon Timestream，能够无效解决车联网利用的若干痛点。

  1. 数据无奈牢靠地收集或传输，并且数据之间存在间隙或者乱序。
  2. 须要对多个数据系列执行不同的剖析，这些数据系列无奈以雷同的速率（频率）生成数据或以雷同的速率生成数据但不同步。
  3. 数据的工夫心跳粒度可能从秒级到分钟，小时不等。
  4. 须要计算并思考数据在不同时间段内的统计值，例如平均值，标准偏差，百分位数和排名。
  5. 须要以可变的粒度级别检索数据，例如特定剖析时间轴中的缩放：降采样和随机采样的要求。

每辆车的每次上报，都蕴含工夫戳，设施根本属性（ID 等信息），以及不同维度的属性值（温度，速度等）。数据 Schema 如下表所示。

data = {"vin": vin,  # 车架号，VIN = 'vin-' + str(rand_n(14))  
 "event_time": str(datetime.datetime.now()),   # 工夫戳 timestamp
 "trip_id": trip_id,    # 行程标识 
 "PressureLevel": random.choice(['LOW', 'NORMAL', 'HIGH']),  # 压力值程度
 "Systolic": random.randint(50, 80),  # 某参数值
 "Diastolic": random.randint(30, 50),   # 某参数值
 "temp": random.randint(0, 1000),   # 温度
 "powertrainState": DOUBLE,  # 能源总成状态
 "ignition_state": DOUBLE,   # 点火状态
 "bms_soc2":DOUBLE,  # 排放值
 "odo":DOUBLE,   # 里程数
 "speed":DOUBLE, # 速度数
 "gear":DOUBLE,  # 变速器
 "engine_rpm":DOUBLE  # 发动机转速
}

Amazon Timestream 建模

在建模之前，咱们先理解一下 Amazon Timestream 中的一些基本概念。

  • Time series 工夫序列：在一段时间范畴内，记录的一个或者多个数据点（也就是 records）序列。比方一个短时间的股价，一个短时间的 CPU 或内存利用率，以及一段时间 Iot 传感器的温度压力值等。

Record 记录：在工夫序列当中的一个数据点。

  • Dimension：工夫序列当中的一个 mete-data 属性值。蕴含 dimension 的 key 值以及理论值。比方对于 Iot 传感器，常见的 dimension name 为设施 ID，dimension value 为 12345。
  • Measure：record 当中理论被测量的值。比方一个设施的理论温度或者湿度。Measure 蕴含 measure names（相当于为 key 值）以及 measure values。
  • Timestamp 工夫戳：表明测量值是在哪个工夫点被测量的。
  • Table：存储工夫序列的表
  • Database：数据库

依据定义，咱们对上述 schema 当中的 key 做一个分类，将反馈设施根本状况类的信息归类到 DIMENSION 里，将理论须要上报的值归类为 MEASURE 类，建模如下：

Amazon Timestream 测试

测试目标

为了验证 Amazon Timestream 数据库能够反对车联网实时数据监控和查问，咱们设计了针对 Amazon Timestream 的测试场景，其中波及端到端集成和性能测试。测试冀望验证下列场景。

  1. 数据能够通过流式注入的形式写入 Amazon Timestream 数据库。
  2. 数据注入速率不小于每秒 1000 条数据，每条数据 Playload 大抵在 8KB 左右。
  3. 数据依照百万级、千万级和亿级分阶段测试，数据保留工夫为 1 周。超过此时间段的数据将移至数据湖中保留，数据湖数据处理不在本文探讨拜访。
  4. 为了良好的老本效率，测试不同存储分层下的 Amazon Timestream 的性能体现，保证数据能够平滑的在不同层级的存储中转换。
  5. 测试在不同存储分层下工夫窗口内查问，聚合，跨表查问等性能。

架构阐明

在此次压测中，咱们用 python 程序模仿物联网设施产生数据的过程，数据将实时写入到流式存储介质 Amazon Kinesis Data Stream 当中，通过由 Flink 构建的 Amazon Timestream data connector，实时读取 kinesis 里的数据，并写入到 Amazon Timestream 中。

  • Amazon Kinesis Data Stream：
    https://aws.amazon.com/cn/kin…
  • Amazon Timestream data connector：
    https://docs.aws.amazon.com/z…

压测步骤

  1. 在 此处 下载此次压缩所须要的代码，并依照 README 的步骤进行必要软件的下载、装置以及运行。

此处：
https://github.com/nwcd-sampl…

  1. 启动 Amazon Timestream Flink Connector (在README 当中也蕴含此步骤）。
  • Amazon Timestream Flink Connector：
    https://github.com/nwcd-sampl…
cd /home/ec2-user/timestream/amazon-timestream-tools/integrations/flink_connector
mvn clean compile
mvn exec:java -Dexec.mainClass="com.amazonaws.services.kinesisanalytics.StreamingJob" -Dexec.args="--InputStreamName TimestreamTestStream --Region us-east-1 --TimestreamDbName kdaflink --TimestreamTableName kinesis-6yi"
mvn exec:java -Dexec.mainClass="com.amazonaws.services.kinesisanalytics.StreamingJob" -Dexec.args="--InputStreamName TimestreamTestStream --Region us-east-1 --TimestreamDbName kdaflink --TimestreamTableName kinesis-6yi --TimestreamIngestBatchSize 75"

请左右滑动理解更多细节

  1. 在另一个 terminal 或者另一台服务器启动执行生产数据的 python 程序（在  README  当中也蕴含此步骤）。

    # cd /home/ec2-user/timestream/amazon-timestream-tools/tools/kinesis_ingestor
python3 timestream_kinesis_data_gen_blog.py --stream TimestreamTestStream --region us-east-1

    请左右滑动理解更多细节

  2. 此时，如无谬误，Amazon Timestream  将继续被写入数据。能够在 kinesis 的监控，Amazon Timestream  监控中，察看写入提早等指标。也能够在 Amazon Timestream  中，通过 count 的形式查问写入条数。当观测达到目标数量级时，进行写入。
  3. 如果心愿进步并行写入速度，能够通过增大 producer 脚本（timestream_kinesis_data_gen_blog.py）的并行来解决，但此时应留神 kinesis 的写入速度是否达到瓶颈。kinesis 单个 shard 有 1MB/s 或者 1000 条 /s 的写入限度，如达到瓶颈，请增大 kinesis 的 shard 数量。
  4. 在写入实现后，在确保测试服务器曾经配置了 Amazon CLI 后，运行 query_test.py 脚本，依据本人的须要，更改替换 profile_name (默认为 default),DATABASE_NAME，TABLE_NAME，RIGHT_TABLE_NAME（做 join 操作），QUERY_REPEAT(运行 query 的次数) 等参数。此脚本将记录在不同的 SQL 查问下，每次以及均匀的提早数据。
  • Amazon CLI：
    https://docs.aws.amazon.com/c…
  • query_test.py：
    https://github.com/nwcd-sampl…

性能体现

在此次测试中，咱们别离通过上述办法向 Amazon Timestream 不同 table 里写入了百万，千万，和亿级别的数据，次要监控指标有 Amazon Timestream 的写入提早，Query 查问速度。

写入提早

在写入 TPS 在 6000 条 / 秒 下：

  • 在写入 TPS 在 6000 条 / 秒下：

  • 6 亿条数据 Kinesis 写入的时延在 60ms – 75ms

Query 查问速度

咱们别离针对百万级，千万级，和亿级的数据量做了不同 SQL 语句下的测试；并且在每个数量级下，咱们做了比照测试，以比照 Amazon Timestream 内存介质和磁性介质在不同查问语句下的体现。

对应 SQL 语句可在 query_test.py 中查看并做批改。

  • 百万级 records：9547102 rows（950 万条）

  • 千万级 records：71602075 rows（7000 万条）

  • 亿级 records：609769360 rows（约 6 亿条）

论断

通过测试数据，咱们能够失去以下论断：

Amazon Timestream 能够良好的反对大规模数据输出，提供了平滑的注入性能。

Amazon Timestream 能够良好的反对大规模数据存储，并且通过不同分层，优化老本。

Amazon Timestream 能够良好的反对典型时序查问，提供了丰盛的时序查询方法，并且能够在海量数据状况下提供良好的查问性能。

晋升查问性能方面，咱们有如下倡议:

  • Amazon Timestream 所扫描的 data size 越大，返回速度越慢。这一点能够在每个表格中的 data size 与 response data 中失去证实。
  • 咱们倡议查问时仅蕴含对查问必不可少的度量和维名称。
  • 在可能的状况下，在查问的 WHERE 子句中蕴含一个工夫范畴。
  • 在可能的状况下，在查问的 WHERE 子句中比拟维度和度量时，请应用相等运算符。
  • 应用 CASE 表达式执行简单的聚合，而不是屡次从同一张表中进行抉择。
  • 仅在查问的 GROUP BY 子句中应用必要的列。
  • 如果应用 ORDER BY 子句查看前 N 个值或后 N 个值，请应用 LIMIT 子句以晋升查问性能

咱们倡议遵循其余最佳实际指南的倡议，以优化工作负载的规模和性能。

对于一些查问性的 SQL 语句，如 between and,  在内存当中的查问速度会更快；但对于一些剖析类的服务，如 group by，在磁性存储介质下会有更好的成果。 这是因为：内存存储专为疾速的工夫点查问进行了优化，而磁性存储官网文档：则为疾速的剖析查问进行了优化。此论断在 Amazon Timestream官网文档 当中能够失去实践反对。

  • 最佳实际指南：
    https://docs.aws.amazon.com/t…
  • 官网文档：
    https://docs.aws.amazon.com/z…

参考文档

  • Amazon Timestream 官网文档：
    https://docs.aws.amazon.com/z…
  • Amazon Timestream Blog：
    https://aws.amazon.com/cn/blo…

本篇作者


李天哥
亚马逊云科技解决方案架构师
负责基于亚马逊云科技的云计算计划架构征询和设计，善于开发，Serverless 等畛域，具备丰盛的解决客户理论问题的教训。


梁睿
亚马逊云科技解决方案架构师
次要负责企业级客户的上云工作，服务客户涵盖从汽车，传统生产制作，金融，酒店，航空，游览等，善于 DevOps 畛域。11 年 IT 业余服务教训，历任程序开发，软件架构师、解决方案架构师。

退出移动版