如何通过降低数据采样率构建通用智能物联网网关设备适合一个企业的不一定适合另一家企业。虽然根据IoT项目的规模和复杂性，有许多组件可供选择，但它们往往会形成类似的架构，即：收集器或IoT网关设备，部署来自多个传感器节点的单个传感器在那里收集数据并转发到企业上游数据采集。这些网关或采集器设备通常使用ZWave（译者注：智能家居领域的无线网络规范）设备连接互联网进行数据上传，或者将各种蓝牙设备桥接到WiFi，使用其他网络连接。然而，大多数这些网关或收集器设备往往是“哑”网关类型。他们除了转发给上游收集器外什么都不做。那么我们能否将物联网网关变成智能设备呢？它使您能够在发送数据之前在采集器设备上执行本地分析和数据处理。如果能够实现，那一定非常好用！搭建网关在我决定搭建（另一个）物联网智能网关设备之前，我已经（有点）搭建了一个正在运行的InfluxDB（译者注：InfluxDB是一个当前流行的时序数据库，它是用Go语言编写的）ARTIK-520设备。不过这个ARTIK-520并不是独一无二的，我们在打造物联网设备的时候，往往奉行越便宜越好的原则。虽然情况并非总是如此，但当您构建越来越多的网关时，您需要考虑成本因素。翻出了几年前买的Pine-64），开始了自己的尝试。您一定会问：为什么是Pine-64而不是RaspberryPi？因为Pine-64的成本只有一半，15美元，而不是RaspberryPi的35美元，就这么简单。而我的Pine-64同样配置为ARMA53四核1.2GHz处理器和2GB内存。与RaspberryPi的1GBRAM相比，我得到了更强大的GPU用于各种用途。此外，它带有内置WiFi，但没有加密狗。我选择了ZWave板，这样我就可以与sub-GHz物联网设备进行通信。使用此类设备作为IoT网关的一个好处是您仅受所用microSD卡大小的限制。比如我只用了16GB的SD卡，但是Pine-64最大可以支持256GB的内存卡。如何在Pine-64上实现TICK（译者注：Telegraf、InfluxDB、Chronograf和Kapacitor的缩写，分别代表数据采集、数据存储、数据可视化和监控报警）并运行起来？我建议您使用Xenial的映像来启动并运行Pine-64。因为它是Pine-64的“官方”Ubuntu版本，所以它与InfluxDB配合得很好。不要忘记运行命令：apt-getupgrade一旦启动并运行，您需要确保一切都是最新的。接下来需要将Influx的各个repository加载到apt-get中：.com/${DISTRIB_ID,,}${DISTRIB_CODENAME}stable"|tee-a/etc/apt/sources.list你可能需要使用sudo来运行它们，这里我巧妙地使用"sudobash"来启动它起来，确保一切准备就绪。接下来，您需要添加一个“必需”包以访问InfluxData的存储库：apt-getinstallapt-transport-https后跟：apt-getinstallinfluxdbchronograftelegrafkapacitor现在我们准备好继续下一步了！负载测试设备我最初的想法只是想看看它如何处理如此小的设备上的附加负载。所以我从GitHub网站(https://github.com/influxdata/influx-stress)下载了“influx-stress”并在设备上运行它。Usingbatchsizeof10000line(s)Spreadingwritesacross100000seriesThrottlingoutputto~200000points/secUsing20concurrentwriter(s)Runninguntil~18446744073709551615pointssentoruntil~2562047h47m16.854775807shaselapsed哇，它达到了每秒200,000个点!事实证明它的确给Pine-64产生了严重的压力!正如您所看到的，很快就逼近2GB内存，CPU占用率也是100%。当然，在现实生活中，作为网关设备，几乎不可能遇到这样的负载。它通常只收集几十到几百个传感器的数据。本地分析正如您从上面的仪表板中看到的，我能够轻松地在本地分析Pine-64。同时板载HDMI接口和全GPU，本地访问仪表盘和实时监控变得相当简单。正如我上面提到的，如果一个设备可以处理更多的工作，它就会更有用。理想情况下，您可能需要将所有数据收集在一个网关设备上，并在本地实现各种分析、告警等功能。但在现实世界中，这不是一个网关/采集器应该有的，我们应该把各种处理工作“搬”出去，也就是将数据向上游转发。如果您仅使用网关设备向上游转发所有数据，那么对IoT数据进行下采样将非常容易。但如果你需要处理网络连接问题，或者想节省成本和带宽，你会希望在转发数据之前降低数据采样率（数据下采样）。幸运的是，一般比较实用的物联网设备都具备在向上游转发前进行各种本地分析、本地告警处理和数据采样的能力。而且实现起来也不难！首先，让我们构建一个我们自己的网关设备，可以将数据转发到另一个InfluxDB实例。有几种方法可以做到这一点，但由于我们将通过Kapacitor对数据进行下采样，我们将直接在此处使用kapacitor.conf文件进行操作。在kapacitor.conf文件中，已经有一个带有“localhost”的[[influxdb]]条目，因此我们只需要添加一个新的[[influxdb]]部分来为上游实例提供服务。如下：[[influxdb]]enabled=truename="mycluster"default=falseurls=["http://192.168.1.121:8086"]username=""password=""ssl-ca=""ssl-cert=“”ssl-key=""insecure-skip-verify=falsetimeout="0s"disable-subscriptions=falsesubscription-protocol="http"subscription-mode="cluster"kapacitor-hostname=""http-port=0udp-bind=""udp-buffer=1000udp-read-buffer=0startup-timeout="5m0s"subscriptions-sync-interval="1m0s"[influxdb.excluded-subscriptions]_kapacitor=["autogen"]这只是解决方案的一部分问题。现在我们需要对数据进行实际采样并发送。在上面我使用了Chronografv1.3.10，它有一个内置的TICKscript编辑器，所以我点击Chronograf中的“警报”选项卡并创建一个新的TICK脚本，然后选择telegraf.autoget数据库作为我的数据源：由于我实际上并没有从设备收集传感器数据，我在这里使用CPU使用率作为数据并使用我自己的TICKScript进行下采样。下面我写了一个非常基本的TICKScript来对CPU数据进行下采样并将其向上转发：stream|from().database('telegraf').measurement('cpu').groupBy(*)|where(lambda:isPresent("usage_system"))|window().period(1m).every(1m).align()|mean('usage_system').as('mean_usage_system')|influxDBOut().cluster('mycluster').create().database('downsample').retentionPolicy('autogen').measurement('mean_cpu_idle').precision('s')该脚本简单地从“usage_system”字段值中收集每分钟CPU测量值，并在计算平均值后写入该值取决于我的上游InfluxDB实例。在这个网关设备上，CPU数据如下：在upstream实例中，降采样后的数据如下：可以看出数据大致相同，只是粒度略低。***，我在网关设备上将数据保留策略设置为1天。这样，我仍然在本地保留了一些历史数据，而没有“填满”设备：现在我的物联网网关设备不仅可以从本地传感器收集数据，还可以向本地用户呈现各种分析，还可以发送本地警报（只要我打开Kapacitor的报警功能），它还降低了本地数据的采样率，可以将其发送到我的企业级InfluxDB实例进行进一步的分析和处理。在这个网关设备上，我有细粒度的毫秒级数据。同时，我的上游设备接收到的粒度稍低的分钟级数据足以让我深入了解各个本地传感器的情况，而无需支付各种数据上传的带宽成本。使用这种方法，我还可以连接到区域InfluxDB实例并将每分钟的数据存储在其中。而且我能够将更多的下采样数据转发到这个聚合整个企业传感器数据的InfluxDB实例。虽然我可以把所有的数据沿着整个“链路”向上传送到最终的企业数据汇聚处，但是如果我真的这样汇聚成千上万个传感器的数据，相应的存储和带宽成本势必会被大量消耗掉无用的细粒度数据。最后，我想再次强调：及时、准确、可操作的物联网数据，才是真正有用的。因此，您的数据越旧，可操作性就越低；它的可操作性越低，您需要的粒度就越小。通过降低数据采样率并设置随时间逐渐增加的数据保留策略，您可以确保即时数据具有高度可操作性和准确性，同时保持长期数据趋势和分析。原标题：ArchitectingIoTGatewayDevicesforDataDownsampling，作者：DavidG.Simmons
