边缘计算框架_轻量级边缘流式计算框架Creek实战

产品与开发的日常

和RD的第一次交流：

RD：有没有边缘流式计算的需求？就是在边缘侧跑流式计算。

PM：有啊有啊。之前提过，但是技术难度大。边缘本来就资源受限，跑流式计算会导致硬件成本上升，客户爸爸不答应啊。我好南啊。

RD：如果有需求，我们就去攻克流式计算使用资源的问题。

PM：好啊好啊，如果这个技术难题解决了，我就把流式计算集成到边缘计算产品当中。边缘流式计算的场景是...(此处省略800字)

How Time Flys，几个月转瞬即逝，RD开发了 基于Apache Flink的边缘流式计算框架Creek。

和RD的第二次对话：

RD：技术问题已解决，可以做产品了。

PM：在你们攻克技术难题的时候，PRD就已经同步开始准备了。今天我们一起过PRD评审，下周过技术评审，争取这个Q上线。

边缘流式计算的典型场景

数据分析师的取数场景

在数据分析场景下，数据分析师经常使用「10分钟平均值」或「15分钟平均值」作为样本数据进行分析，而不会直接使用原始采集数据。如果云平台当中只有原始采集数据，数据分析师通常使用以下几种方式获取「10分钟平均值」：

1. 导出原始数据，通过数据预处理工具获取10分钟平均值

2. 云平台增加流式计算任务，计算10分钟平均值并实时保存在数据库

3. 通过大数据平台对历史数据执行离线任务，计算历史数据的10分钟平均值并保存在数据库

上述的几种方案能够让数据分析师拿到10分钟平均值，但是成本都很高，也不方便。

通过边缘流式计算可以很好的解决上述问题，边缘节点在边缘侧通过流式计算得到10分钟平均值，然后上报至云端iothub，经由规则引擎将10min数据转存到数据库，可以大大降低数据分析师的取数难度。

运维人员的实时监控场景

在物联网场景下，设备测量数据因为各种因素(网络因素、设备自身精度因素)经常会出现抖动情况，如果对设备的实时采集值配置阈值告警，经常会出现误告警，导致用户需要处理大量无用告警，逐渐用户对告警的准确性失去信心，阈值告警形同虚设。

针对这种场景，用户可以借助流式计算的能力来降低数据抖动带来的偏差，常见的方案有：

1. 按平均值告警：通过流式计算获取10分钟平均值、10分钟最大值、10分钟最小值、10分钟计算样本数，然后设定阈值规则，比如“10分钟平均值>阈值 且 10分钟计算样本数>100”

2. 按持续时间告警：通过流式计算找出实时采集值一直大于指定阈值且持续时间很长的设备，比如"设备温度>100℃ 且 持续时长>5分钟"

在网络不稳定的场景下，上述两种方案如果通过云端流式计算来实现，最终得到的计算值准确度不高，比如当设备出现5分钟无连接的时候，云端再去计算10分钟平均值，计算的结果并不准确。而边缘侧是内网环境，网络异常的概率大大降低。在边缘侧将统计值计算好后再上报云端，可以大大提升流式计算统计结果的准确性。

边缘流式计算价值

• 降低成本，包括流量成本、存储成本、云端流式计算资源成本。

• 在弱网络环境下，提升流式计算结果的准确性。

边缘流式计算实践

模拟场景

为了验证边缘流式计算，我们可以搭建一个这样的典型场景：

1. 使用模拟器每秒1条数据的频率，不间断往边缘hub发送模拟数据

2. 模拟数据的格式为：{"humidity":6.3426914,"temperature":11.457714,"timestamp":1576207523}

3. 云端配置边缘流式计算任务，计算temperature的统计值，包括：

• 10分钟平均值

• 10分钟最大值

• 10分钟最小值

• 10分钟计算样本数

下发边缘流式计算任务至边缘核心设备(使用树莓派即可)

在边缘侧验证流式计算结果

操作指南

点击阅读原文查看详细操作指南。

检查流式计算结果

启动MQTTBox，订阅 testtopic/update和 testtopic/streamdata这两个topic，查看数据模拟器产生的模拟数据，以及基于模拟数据进行流式计算得到的结果，如下图所示：

• testtopic/update：模拟数据，1秒1条记录

• testtopic/streamdata：流式计算结果，包含最大值、最小值、平均值、计算样本数，因为是1分钟统计结果，所以计算样本数刚好是60，与实际相符。

云端监控流式计算任务的资源使用情况，发现内存占用在12M左右，相比边缘流式计算带来的价值，这点资源使用率上升，完全值得。

最后，点击阅读原文查看详细操作指南。