关于热力图数据上报清洗，我们做了一个有意思的尝试

前言

最近几年，我们在一些商场、图书馆、机场或港口环境里，经常可以看到一些机器人在转来转去，它们被大家熟知的作用是对客户进行指引服务。不仅于此，事实上，一些企业也会利用机器人来收集这些人流密集地的特征数据，通过上报这些特征数据，进行快速的清洗加工处理，从而提供有意义的应对疏导措施，或者指引信息（广告）投放决策等商业上的转化。

其中有一个主要场景是统计区域的热力图，并开放给特定的系统（也在考虑开发给终端用户）进行查询加工处理。

这些机器人会在不同的时段进行按需投放，且会在采集数据有较大变化或某固定周期内进行上报。数据采集变化大的时候，上报会趋于频繁，后面的数据清洗处理任务需求也会同步增加。

我们将在本篇文章里探讨下如何在技术选型上更适合地对这类场景进行数据上报清洗与处理。

场景特点与要求

1． 数据通道的连接能力：数据通道随着业务的扩展，机器人的投放也会同步增加，对于数据通道有足够的扩展灵活性，可以按需进行扩展，同时连接的级别能够支持 10W+ 级别的扩展。

2． 简洁数据清洗能力：对于数据的处理，本质上就是对数据的归纳统计，逻辑实现上并不复杂。对于数据本身的峰谷变化，能有最简单有效的匹配扩缩处理能力即可，在清洗上不希望为此引入复杂的传统大数据级别的笨重方案。

3．弹性数据访问能力：这里提到的的热力图信息，以后会考虑开放给终端用户访问，访问量都是动态变化的，随着不同的时间、节日、突发事件等都会有不可预知的幅度变化，所以在此业务中要求有弹性的访问能力。业务方不希望通过限流方式来实现，因为会对业务量本身造成影响。

4． 性能优越的存储能力：此场景下，数据写入与读取并发量都高，客户希望使用 NoSQL 的方式进行存储。NoSQL 类型能最好支持排序的功能，本文介绍的方案中使用 Redis，不再做更多的分析介绍。

备选的技术方案分析

数据通道的连接能力

1、自建 Kafka

优点：

• Kafka 作为通用的数据收集信息通道，使用面广泛，接入方式多样化。社区完善，学习成本低。

• Kafka 本身搭建容易，与下游的大数据处理产品协调方案成熟。

缺点：

• 动态处理 Kafka 的扩容复杂。

• 需要搭建额外处理集群的稳定性配套方案。

• 外网网络流量管理需要配合额外的方案。

• 主流方案是作为连接应用的收集能力，对于终端的连接能力没有规模级别的案例验证。

2、消息队列 MQTT 方案

优点：

• 支持百万级别的连接，完成可以覆盖业务发展的诉求，为业务留足了扩展空间。

• MQTT 的协议非常简洁，在端与服务间的传输中有优势。支持各种消息触达的 QoS 质量。

• 支持各种客户端接入实现语言。

• 可实时观测客户端的连接情况，方便发现异常情况。

缺点：

• 处理大数据的实践没有 Kafka 成熟，下游产品选型受一定的限制。

 弹性数据清洗的能力

1、大数据方案（Storm、Spark、Flink 等）

优点：

• 开源的通用方案，资料众多，方案成熟。

缺点：

• 搭建运维复杂，需要提供额外的监控与恢复手段。

• 需要学习接受各种组件方式（下图是以 Storm 为例）。

• 提前评估资源使用情况，无法按照实时数据量进行相应的扩缩使用。

2、函数计算方案

优点：

• 按需进行扩缩，毫秒级的伸缩能力，适合数据量的脉冲峰谷变化。

• 不需要进行清洗环境的管理。

• 概念简单，学习成本低。

• 其它优点参考下图：

缺点：

• 函数计算是各个云厂商的产品，要求一定需要在云上运行。

 弹性数据访问的能力

1、传统应用的方案

优点：

• 作为业务的一部分嵌在某个应用实现中，技术成熟，学习成本低。

缺点：

• 需要自实现根据业务请求量来进行弹缩处理，或者很多时候采用评估的方式进行资源冗余处理。

2、API Gateway+ 函数计算方案

优点：

• 根据客户的请求量实时进行弹缩处理。按需使用，不为高峰时段烦恼，不会闲置付费。

• 自动附带专业的访问监控大盘。

缺点：

• 需要少量的学习成本。

综述

在这个热力图信息收集清洗与访问业务中，可以参考使用下图的解决方案完美实现。

重点接入步骤

MQTT 到函数计算的介绍

请参考函数计算的微消息队列 MQTT 服务集成方案。

(https://help.aliyun.com/document_detail/194654.html

API 网关通过函数计算提取数据的介绍

详情请参考 API 网关函数触发实例。

(https://help.aliyun.com/document_detail/74794.html)。

以 Node.js 为例：

module.exports.handler = function(event, context, callback) {    var event = JSON.parse(event);   var content = {     path: event.path,     method: event.method,     headers: event.headers,     queryParameters: event.queryParameters,     pathParameters: event.pathParameters,     body: event.body   // 您可以在这里编写您自己的逻辑。   // 从Redis提取数据的逻辑     }   var response = {        isBase64Encoded: false,        statusCode: '200',        headers: {          'x-custom-header': 'header value'        },        body: content      };    callback(null, response)};

后注

在当前 DT 时代，各种脉冲数据上报的仪器非常多，例如新能源汽车的传感器，公交位置上报，智能物管的开锁，智慧停车场的车位管理，无人店铺的销售等等。在各类场景中，关于上报数据的处理无处不在，而以上提到的场景都可以通过本方案的 MQTT+FC+API Gateway 的方式参考优化来实现。

原文链接：关于热力图数据上报清洗，我们做了一个有意思的尝试