物联网数据分析（上篇）——业务系统架构类

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）的架构，支持了阿里云物联网数据分析的业务发展。后来当物联网数据分析业务体量提高到一定程度后，这个架构存在的一些无法调和的弊端越来越制约平台的发展，因此发展出了基于调度和预计算的架构，我们会在下一篇为大家进行分享。