关于时序数据库:基于物联网平台-Tablestore-打造设备元数据管理平台

近些年来物联网技术高速倒退，广泛应用到了诸如智慧出行、智慧工业、智能家居等场景中，无论是何种场景的利用，都离不开对数据的“采集 - 解决 - 存储 - 剖析”这套流程。然而不同的利用，其本身的数据个性和业务需要大不相同，那么对于实现上述流程所需的产品组件也会有所区别。总体来说，咱们能够依照利用和数据特点分为三类场景：时序数据、音讯数据、元数据。

如上图展现了物联网场景的三大类数据。以智能汽车场景为例，车辆定时会更新以后的最新状态信息，例如发动机以后转速、以后车速等，这些形容车辆最新状态信息的数据咱们称之为元数据。而在智能汽车行驶过程中，车辆的状态数据会随着工夫的变动而变动，例如车辆一段时间内的车速、胎压等，这些形容车辆历史状态信息的数据咱们称之为时序数据。还有一种数据场景是对车辆行为进行管制的指令音讯，例如调节车辆空调温度指令下发以及车辆执行命令后的后果反馈，这些控制指令的上下行咱们称之为音讯数据。不同类型的数据利用的场景各不相同，所以对存储系统的需要也有所不同。本文章次要剖析设施元数据场景有哪些业务需要，以及如何抉择适合的存储组件和实现计划。

场景需要

首先以工业设施元数据场景为例，来剖析有哪些具体的业务需要。
在工业生产过程中，通常设施会以某个固定的周期（或由某个事件触发）上报最新运行状态信息，这也就是上文提到的设施元数据，例如设施 ID，以后运行温度、湿度、压力值等。业务上依据设施元数据来治理设施，例如查问某台设施的以后运行状态，多条件在线检索设施，“圈选”出符合条件的设施汇合。通过剖析设施元数据来实时监控设施的运行状态，出现异常及时响应，防止故障产生等。上面对业务需要做一个小结：

1. 设施状态数据定时上报，通过数据网关上云存储。
2. 存储侧须要可能反对大规模设施元数据实时更新。
3. 存储侧须要反对依据任意个设施指标作为条件查找设施。如果查问设施量较少，咱们称之为“设施检索”；如果一次查找的设施数量十分大，咱们称之为“设施圈选”。
4. 设施状态更新后，存储侧须要反对对异样状态实时监测。

技术难点

依据下面的场景需要，咱们能够总结为对存储侧的几个性能需要：

1. 存储规模：反对海量设施元数据存储，可能达到千万级甚至亿级。
2. 实时更新：反对高并发、低提早的数据更新。
3. 任意字段组合检索：反对依据一个或多个字段值组合条件来检索设施元数据。
4. 反对并发检索：对应设施圈选的场景，在设施圈选的后果集较大的场景下，须要反对并发检索以晋升圈选性能。
5. 数据更新实时计算：可能探测数据更新，并可能对更新后数据进行实时计算。

存储选型

元数据存储场景对数据库的规模、性能、查问能力等各个方面都有较高的要求。通常来说，关系型数据库 MySQL 都是作为存储选型的第一选项，这是因为 MySQL 是最为通用，大家也最为相熟的数据库产品。然而 MySQL 个别只在小规模的数据存储（千万级）和低并发的数据更新（一万内 QPS）场景下体现优异，当规模变大时，MySQL 的性能会急剧下降，这显然不满足元数据存储的要求。到这里，大家可能会想到应用开源数据库 HBase，因为 HBase 的分布式架构可能反对大规模数据存储和写入，在这一点上是能够满足元数据存储需要的。然而 HBase 只反对了基于主键（RowKey）查问，无奈在属性列上建索引查问，所以在设施检索、圈选时的效率极低，极其状况下可能会以全表扫描加数据过滤的这种形式来查问数据，这一点上无奈满足上述的需要。最初咱们来看下表格存储 Tablestore，Tablestore 是一款云原生 Serverless 的结构化数据存储，原生具备大规模的数据存储和低提早数据更新，同时提供了多元索引性能，可能反对任意字段组合检索，是物联网平台底层依赖的外围数据存储系统，撑持了亿级设施的元数据管理。上面对上述几个存储产品在实现元数据存储场景中的能力做一个总结：

Tablestore 技术介绍

表格存储 Tablestore 是一款云上的结构化数据存储产品，具备极为丰盛的产品性能和生态，提供了物联网存储 Iotstore、宽表引擎、多元索引等能力来满足时序数据、音讯数据、元数据场景的需要。针对于时序与音讯数据场景的解决方案不在本文章中开展解说。上面咱们来看一下 Tablestore 提供了哪些能力来满足元数据存储的场景需要。

Tablestore 采纳了多引擎的存储架构，不同的场景需要实现的原理不同，先来看一张图：

其中宽表引擎是一个分布式的数据表，负责设施元数据的存储与更新。宽表引擎采纳了多分区（shard）的分布式构造，每一个分区对应了一台 worker。在元数据写入的过程中，路由节点依据主键的范畴将写入申请路由到不同的分区进行解决，当某个分区的负载达到瓶颈时，服务端会主动决裂成多个分区，使得宽表引擎的整体吞吐能力可能线性进步。如下图所示：

相比于宽表引擎，索引引擎底层采纳了倒排索引、空间索引等存储构造，可能反对任意数据组合检索、聚合。索引引擎别离提供了两种查问接口：search 和 parallelScan。

• search 接口。search 接口反对多条件组合查问、含糊查问等能力，能够满足设施检索的场景需要。
• parallelScan 接口。parallelScan 接口反对以多并发的形式进行数据检索，可能大幅提高数据返回速度，实用用于设施元数据圈选场景。

Tablestore 提供了与 Flink 实时计算对接的能力，可作为 Flink 的数据源表，将实时变动的设施元数据推送到 Flink 中进行计算，从而实现元数据检测的业务场景。与此同时，反对将计算的后果再写入 Tablestore 的数据表中，来实现记录异样数据后果。

分享完元数据存储场景的需要和 Tablestore 的技术原理后，咱们来看看如何搭建一个设施元数据场景的物联网架构。物联网数据上报网关后，依据不同的利用类型个别有三种数据流向，应用服务器订阅生产，长久化存储，转发到音讯队列。设施元数据的次要需要是存储和计算，所以咱们能够列出一个简略的数据流转过程：网关 -> 存储 -> 流计算。上面将介绍通过物联网平台 + Tablestore + Flink 来搭建元数据管理平台。

物联网平台 + Tablestore + Flink 实现元数据管理计划

基于云上搭建的元数据管理平台架构如下图所示：

上述的架构图中蕴含了三个组成模块：物联网平台，表格存储 Tablestore、实时计算 Flink。各个模块在架构中承当的角色和性能如下：

• 物联网平台：负责设施元数据接入、设施治理和数据转发。
• 表格存储 Tablestore：数据表负责设施元数据的存储、更新、查问。多元索引负责设施检索和圈选。通道服务提供与实时计算 Flink 对接的能力。
• 实时计算 Flink：负责对设施元数据变动进行流计算作业，可将计算结果回写到 Tablestore 中存储，或对接 Kafka 等音讯队列订阅生产。

计划实现

假如某工业生产厂商现有一百万台智能设施，每台设施定时更新本身的温度、湿度、压力数据等状态数据，筹备应用上述计划架构来搭建元数据管理平台。
数据规模：一亿行
数据结构：如上面的 SQL 语句所示
CREATE TABLE device_meta_data (

 device_name varchar(100), -- 设施名
 humidity decimal(5,2), -- 设施以后湿度
 pressure decimal(5,2), -- 设施以后压力值
 temperature decimal(5,2), -- 设施以后温度
 location varchar(20), -- 设施地位坐标
 timestamp long -- 数据上报工夫戳

);

开明服务

筹备一个阿里云账号，别离开明如下服务。开明步骤请参考产品官网。

• 物联网平台
• 表格存储 Tablestore
• 实时计算 Flink

创立实例和表

首先须要在 Tablestore 中创立实例 metadata-db（数据库），并创立存储元数据和异样后果数据的两张数据表，表名别离为 device_meta_data 和 device_errorResult_data，操作步骤如下图所示。
（1）创立实例。

（2）创立元数据表和异样数据表。

创立产品、模型和设施

在物联网平台控制台中创立产品（product_metadata），物模型（默认模块）、设施（test_deviceName）。一个产品相当于同类型设施的形象，而物模型则是对设施上报数据结构的定义。
（1）创立产品。

（2）创立物模型。

（3）创立设施。

创立解析器

在物联网平台中创立解析器，解析器负责将设施元数据更新的 topic 进行自定义脚本解决后，写入到 Tablestore 中长久化存储。如下图所示：

创立解析器须要别离配置数据源、解析脚本和数据目标。通过物模型上报的设施元数据会汇聚到名为 / 产品名 / 设施名 /thing/event/property/post 的 topic 中作为数据源，也能够自定义一个 topic。数据目标则是配置设施元数据须要写入的 Tablestore 实例名和表名等信息。解析脚本是能够自定义的，例如本案例中将设施的经纬度信息组合成一个坐标字符串写入 Tablestore，如下图所示：

设施上报数据

通常设施上报数据是基于设施端 SDK 开发程序来上报数据到物联网平台中，但为了疾速实现计划，本文中应用物联网平台提供的设施模拟器来进行数据上报操作。如下图的一个模仿设施上报了一条数据:

设施元数据通过解析器解决后存储到 Tablestore 中，到此咱们曾经实现了设施元数据采集与存储的所有操作。
因为设施模拟器只能模仿单台设施元数据产生的过程，为了更贴近实在的业务场景，咱们间接在 Tablestore 中生成了一亿条设施元数据以供后续步骤的实现。通过上文咱们能够得悉，设施检索与圈选须要依赖 Tablestore 的多元索引性能，所以首先咱们须要创立一个多元索引 device_meta_data_index：

上面将通过 Tablestore 来实现设施元数据查问、检索、圈选等业务需要。

设施查问

Tablestore 提供了 SQL、控制台或 SDK 等多种数据拜访形式。以 SQL 为例，首先通过 SQL 确认设施元数据已正确导入。

select count(*) from `device_meta_data`; 

查问 device_name = “test_deviceName” 的设施元数据。

select * from `device_meta_data` where device_name = 'test_deviceName'

设施检索和圈选

设施检索和圈选依赖 Tablestore 的多元索引能力，别离采纳 search 和 parallelScan 接口来实现。

• 设施检索
  先来说设施检索，设施检索通常不会返回比拟大的数据后果集，即便合乎查问条件的数据量很大，也会采取分页的策略返回。针对于此场景，Tablestore 的多元索引性能采纳了倒排索引、空间索引等数据结构来减速数据检索速度，例如上面一个例子：

检索设施温度低于 20 摄氏度，压力值在 0.5 kpa 至 1.0 kpa 之间，并且设施名以“e3”结尾的设施。

select * from device_meta_data where temperature < 20 and pressure between 0.5 and 1.0 and device_name like 'e3%';

• 设施圈选
  设施圈选通常返回的数据量比拟大，如果应用 SQL 只能单并发查问和返回，这样性能显然是不高的。针对这个场景，Tablestore 推出了 parallelScan 接口来实现，parallelScan 接口的优化如下图所示：

在执行设施元数据圈选之前，首先会调用 ComputeSplit 接口依据多元索引中的数据量级来计算最大可执行的查问并发度。而后会依照多并发的形式别离查问多个数据分区，每一并发只负责一部分数据的查问和返回，通过这种形式能够极大地提高数据圈选的速度。如上面一个例子：

须要圈选设施名以“a”结尾并且设施温度低于 10 摄氏度的所有设施。

*int splitsSize = client.computeSplits(computeSplitsRequest).getSplitsSize();// 获取并发数
*// 多线程执行
run(){ParallelScanRequest parallelScanRequest = ParallelScanRequest.newBuilder().tableName(tableName).indexName(indexName)
                    .scanQuery(ScanQuery.newBuilder()
                        .query(QueryBuilders.bool()
                            .must(QueryBuilders.wildcard("device_name","a*"))// 查问条件
                            .must(QueryBuilders.range("temperature").lessThan(10)))
                        .maxParallel(splitsSize)
                                                 .currentParallelId(currentParallelId)// 以后并发 ID
                                                .build())
    RowIterator iterator = client.createParallelScanIterator(parallelScanRequest);// 返回以后并发命中的后果集
}
// 多线程执行 **

从下面代码的运行后果能够看出，查问的数据后果将以多并发的形式返回，每个并发都蕴含了一部分查问命中的数据。parallelScan 接口在大规模数据圈选、数据导出场景下，均匀单个并发能够达到 1W/s 以上的查问返回速度，并且查问数据量越大可切的并发数越高，这种可程度扩大的查问形式极大地提高了数据圈选导出速度。

设施实时监控

设施实时监控依赖于 Tablestore 的通道服务能力，通道服务能够间接对接实时计算 Flink 来实现元数据流计算，如下图所示：

在实时计算中创立了源表、后果表和流计算作业。其中源表依赖 Tablestore 中设施元数据中创立增量通道服务，通道服务将设施元数据的实时变动数据推送到 Flink 计算引擎中进行流计算作业。而本案例中流计算作业将异样的设施状态数据保留到了 Tablestore 的异样后果数据表中，后续可通过异样数据后果表中查问某台设施的异样记录信息。针对于异样数据的解决还有一种业务场景是推送到 Kafka 等音讯队列中进行解决，如告警机制接入、短信告诉等。
为了更直观地看到流计算作业成果，咱们能够在设施元数据表中更新一条设施元数据：

update `device_meta_data` set `pressure` = 2.0 where `device_name` = "test_deviceName"

通过流计算引擎解决后，会断定该条数据为异样数据，并主动写入到异样后果数据表中。

select * from `device_errorResult_data` where `device_name` = "test_deviceName"

总结

本文分享了设施元数据的场景特点和架构实际。设施元数据场景中业务需要对存储组件的存储规模、查问形式以及计算性能有很高的要求，从存储、查问、计算几个维度比照 MySQL、HBase、Tablestore 三款产品，最终抉择了采纳表格存储 Tablestore 作为元数据场景外围存储库，并使用 Tablestore 上下游生态，打造出 物联网平台 + Tablestore + 实时计算 Flink 组合作为实现设施元数据存储的云端架构。