2021 年，活跃的物联网设备超过 100 亿台。

预计到 2030 年，活跃的物联网设备数量将超过 254 亿台。

到 2025 年，每分钟将有 152,200 台物联网设备连接到互联网。

到 2025 年，物联网解决方案有可能产生 4-11 万亿美元的经济价值。

83% 的组织通过引入物联网技术提高了效率。

据估计，在 2019 年至 2025 年的六年期间，全球物联网支出将达到 15 万亿美元。

到 2026 年，消费物联网市场预计将达到 1420 亿美元，复合年增长率为 17%。

94% 的零售商同意实施物联网的好处大于风险。

到 2025 年，物联网设备生成的数据量预计将达到 73.1ZB（zettabytes）。

原文作者：Bojan Jovanovic

1 引文

物联网大数据统计数据显示，随着采用率的提高，设备将在接下来的几年中在全球范围内产生成倍增长的数据。到 2025 年，这些数字将达到 73.1ZB，相当于 2019 年产出的 422%，当时产生了 17.3ZB 的数据。

这样海量的数据，价值挖掘的潜力可以说是无穷的。越来越多的物联网厂商选择设备上云，想挖掘物联网设备数据背后的价值是其中很重要一个因素。本文从阿里云物联网数据分析功能的演进，探讨物联网数据分析的技术解决方案。

2 数据标准化

物联网数据协议多种多样，碎片化严重，所以物联网平台从开始就提出了用物模型来统一设备数据上云的标准，后来也成为了事实上的行业标准做法。但是以 MQTT 协议为例的物联网数据传输协议，是没有对设备数据传输格式做要求的，实际上物联网厂商可以用完全自定义的二进制数据上云，然后流转到自己的存储。这样就导致物联网平台被通道化，平台不感知用户上报的数据内容，无法为用户创造更多的价值。

因此平台提供了通过脚本的形式解析用户的自定义协议，通过脚本解析后的数据，已经是通用的 alink json 协议，能够被平台感知。

3 即席查询（Ad Hoc）版本

即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

百度百科词条：即席查询

阿里云的物联网数据分析，第一个版本是基于即席查询架构的版本，这个版本在一段时间内，解决了用户设备数据上云后的分析问题，在刚开始的业务体量阶段，有其架构的实用性，也为平台积累的一些原始能力和第一批用户。

3.1 数据分析功能的提出

解析后的标准 alink 设备数据，首选的存储是时序存储，而不是传统 IT 系统最常见的关系型存储。这是由物联网的设备特征和业务属性决定的。这些时序类的设备数据上云后，大部分的用户选择通过规则引擎流转到自建的平台。如下图左一所示：

为了不让物联网平台被通道化，同时给上云的物联网平台用户提供更多的价值，创造更多的平台附加值，我们上线了物联网数据分析功能（上图右一），上云的设备数据进行存储后，可以被设备分析模块进行使用。在数据分析模块里，用户可以用时序透视，可视化分析，SQL 工具等功能对设备数据进行分析。

3.2 数据存储

经过解析后的设备 alink 协议数据，是存储在时序存储中的。但是时序存储中的数据不能直接使用，不是分析工具无法分析时序存储中的数据，而是有稳定性和成本两方面的考虑：

第一，设备数据上报链路对数据入仓的实时性能有很高的要求，一旦分析类的读请求大量消耗时序存储的系统资源，势必会影响时序存储系统的稳定性。

第二，时序存储和离线存储的成本差距巨大，为了减少存储成本，时序存储底座里只有一个月的数据存储，而要做到长时间的数据持久化存储，需要更低成本的存储底座，这里我们选择的是阿里云的 OSS 存储。

因此平台会通过实时入仓的任务，将设备上云数据同步到 OSS 存储底座上，这里采用的是 ORC 格式，方便大数据分析技术栈的各个生态产品进行分析使用。如下图所示：

3.3 基于即席查询（Ad Hoc）的数据分析架构

转储过的设备数据，只包含了设备上报的事实数据，但是实际在用户的业务过程中，纯粹的设备事实数据是没法给用户带来更大的业务价值的。举个例子，在室内节能解决方案中，我们要通过上报的设备数据找出最耗电的室内电器，针对性的进行管理，以此降低电力费用支出。我们可以通过设备上报的事实数据，找到耗费了最多电量的电器，但是这个设备为什么耗费这么多电量，需要很多额外的维度信息补充。比如电器的型号，电器的运行环境数据，电器的安装位置，电器的运行时长等。抛开这些维度数据，单纯的分析设备的事实数据意义不大。

用户的维度数据，一般都以关系型存储的方式，存储在用户的业务系统中，比如用户的 IT、ERP、CRM 等系统。因此我们需要用技术上的方案，来方便的进行统一、融合分析。

这里我们提供了 SQL 编辑工作台，将设备的事实数据和用户的维度的数据，都展示在 SQL 工作台，供用户定义自己需要的分析 SQL 语句，采用即席查询（Ad Hoc）的方式，查询自己需要的数据。定义好的 SQL，可以发布固化，成为数据服务 API， 用户调用 API 的过程实际上就是执行了自定义的分析 SQL。形如下图

不同类型数据存储底座的打通，我们采用的是基于数据湖的技术方案，形如下图：

3.4 架构的问题

由于用户调用的数据查询 API 是通过 SQL 工作台编辑的即席查询（Ad Hoc）SQL 语句发布，调用的 API 背后实际上执行的是一条用户的自定义分析 SQL 语句，所以要保证数据服务 API 的性能和并发（其实也就是分析 SQL 的执行性能）是很难的。

这个难度的本质原因是用户的分析需求 SQL 语句，与数据服务 API 查询语句之间，存在场景的矛盾。用户的分析 SQL 场景可以是很复杂的，分析数据的时间维度可以横跨一年，扫描数据量巨大。亦或者用户本身的 SQL 水平有限，难以用高效的方法实现 SQL 分析查询。但是数据服务 API 常用在系统集成场景中，需要的是低延迟，高并发。

基于这两种场景差异，在数据分析的场景，用户对 SQL 分析的结果返回，其实没有很严格的时间要求，几秒的执行时间都是可以接受的。在用户的心智中，分析 SQL 返回的快慢是和背后执行的 SQL 复杂程度以及分析数据量大小正相关的。

但是一旦分析型的 SQL 生成了数据服务 API，在用户感知中，这个正相关的心智就会淡化。无论复杂 SQL 生成的 API 还是简单的 SQL 生成的 API，在用户看来并没有什么区别，所以用户也不会像即席查询分析场景一样，对不同复杂程度 SQL 生成的 API 性能有不同的容忍。这个也很好理解，同样的数据服务 API，为什么有的 API 性能好，有的性能差。

另一种情况，哪怕对于同一个 SQL，在分析场景和数据服务 API，同样 5 秒返回结果的查询，在 SQL 分析中，用户可能觉得可以忍受，但是在系统集成场景，数据服务 API 以 5S 返回用户系统可能已经触发了系统报警。

3.5 架构问题的缓解方案

由于基于即席查询（Ad Hoc）架构的数据分析平台存在上述的一些问题，我们做了很多系统底层的优化，来缓解这种同一个分析 SQL 同时应用在分析场景和 API 调用场景的性能差异。

第一，平台建设了一套对线上运行的 SQL 进行自动评分的系统，根据 SQL 的历史运行时间和扫描数据等指标，对 SQL 进行打分。这样就给了系统定义了一把尺子，哪些数据服务端 API 背后的 SQL 是质量差的 SQL，需要额外优化，哪些 SQL 质量好，能提供更高的 QPS 和更低的调用延迟；

第二，基于 API 背后的 SQL 评分体系，平台实现了一套多实例动态路由机制，机制的目的对不同打分的 SQL 进行动态路由，类似于高速公路的快慢车道分离，执行慢的 SQL 在慢车道执行，执行快的 SQL 在快车道，互不影响，防止慢 SQL 影响整个实例的资源水位，拖慢快 SQL 的执行效率；为了实现快慢车道隔离，我们同步了几份完全相同的存储底座，带来了成本一定程度上的上升，这个也为后来的基于调度的分析架构带来了改进的动力。

第三，为了提高平台中 SQL 的整体执行效率，平台实现了通用的系统字段谓词下推，例如租户分区的下推，时间分区的下推，产品 key 的分区条件下推，尽量在 SQL 最内层扫描数据时，就将数据量减少到最小。

4 结语

其他还有很多对 SQL 执行性能和稳定性的优化，这里不一一例举，总之在一段时间内，这个基于即席查询（Ad Hoc）的架构，支持了阿里云物联网数据分析的业务发展。后来当物联网数据分析业务体量提高到一定程度后，这个架构存在的一些无法调和的弊端越来越制约平台的发展，因此发展出了基于调度和预计算的架构，我们会在下一篇为大家进行分享。