【51CTO.com快譯】雖然當前有很多種方法可以為您構建出物聯網(IoT)的數據部署架構，但是往往適合于某一家企業的架構并不一定適合另一家。雖然根據物聯網項目的大小不同和復雜程度，有著許多種組件可供您選擇，但是它們往往會形成一種相似的架構，即：部署各個傳感器的收集器或IoT網關設備，從多個傳感器節點那里收集數據，然后轉發到企業的上游數據收集之中。

這些網關或收集器設備通常會使用ZWave(譯者注：智能家居領域的無線組網規格)設備來接入到互聯網進行數據上傳，或者橋接各種藍牙設備與WiFi，以及使用其他的網絡連接。

[[216508]]

不過，大多數這些網關或收集器設備往往是“啞”網關類型。它們除了向上游收集器做轉發之外，不做任何事情。那么我們是否能夠將IoT網關轉變成為一臺智能設備呢?使您在發送數據之前，能夠在收集器設備上進行本地分析和數據處理。如果能夠實現的話，勢必會非常有用!

構建網關

在我決定構建(另一個)物聯網智能網關設備之前，我已經(在某種程度上)建立了一個運行著InfluxDB(譯者注：InfluxDB是一個當下比較流行的時序數據庫，它使用Go語言來編寫)的ARTIK-520設備。但是，這個ARTIK-520并不是***的，而大家在建立物聯網設備的時候，經常會追求越便宜越好的原則。雖然實際情況并非總是如此，但是當您建立的網關越來越多的時候，就需要考慮到成本因素了。

我翻出了幾年前購買的Pine-64(譯者注：Pine-64是一款64位的軟硬件開源平臺，屬于卡片電腦，更多信息請瀏覽https://www.pine64.org/)，開始了自己的嘗試。您一定會問：為什么是Pine-64，而不是樹莓派(Raspberry Pi)呢?因為Pine-64只有一半的成本，它只要15美元而不是樹莓派的35美元，就這么簡單。

而且我的Pine-64有著同等配置的ARM A53四核1.2GHz的處理器和2GB的內存。相比于樹莓派的1GB內存來說，我在各種使用過程中會獲得更為強大的GPU。另外，它還自帶內置的WiFi，不過沒有加密狗。我選配了ZWave板卡，因此可以與sub-GHz(譯者注：頻率為1GHz以下，27MHz~960MHz)的物聯網設備進行通信。

運用此類的設備作為IoT網關的一個好處是：您只會受到所用microSD卡容量大小的限制。比如說我只使用了16GB的SD卡，而Pine-64卻能夠支持高達256GB的存儲卡。

怎樣才能實現TICK(譯者注：Telegraf、InfluxDB、Chronograf和Kapacitor的縮寫，分別代表數據采集、數據存儲、數據可視化和監控告警)，并運行在Pine-64上呢?我建議您使用Xenial的鏡像來啟動并運行Pine-64。因為它是Pine-64的“官方”Ubuntu版本，所以它非常適用于InfluxDB。請不要忘記運行如下命令：

apt-get upgrade 

一旦它啟動并運行起來，您要確保各個組件都已做好更新。

接下來，需要將Influx的各個存儲庫加載到apt-get：

curl -sL https://repos.influxdata.com/influxdb.key | apt-key add - 
source /etc/lsb-release 
echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | tee -a /etc/apt/sources.list 

您可能需要使用sudo來運行它們，而這里我巧妙地使用了“sudo bash”來使之啟動，并保證一切就緒。

接下來，您需要添加一個“必需”的包，來訪問InfluxData的存儲庫：

apt-get install apt-transport-https 

之后就是：

apt-get install influxdb chronograf telegraf kapacitor 

現在我們已經準備進入下一步了!

負載測試設備

我的原始想法只是想看看，在這么小的設備上添加了負載后，它的處理情況是怎樣的。因此我從GitHub網站上(https://github.com/influxdata/influx-stress)下載了“influx-stress”并將它運行在該設備上。

Using batch size of 10000 line(s) 
Spreading writes across 100000 series 
Throttling output to ~200000 points/sec 
Using 20 concurrent writer(s) 
Running until ~18446744073709551615 points sent or until ~2562047h47m16.854775807s has elapsed 

哇，它達到了每秒200,000個點!事實證明它的確給Pine-64產生了嚴重的壓力!

正如您所看到的，它很快接近用光了2GB的內存，并且CPU的使用率也是100%。當然在現實生活中，作為一臺網關設備，碰到這樣的負荷幾乎是不可能的，它一般只會從幾十到上百個傳感器那里收集數據。

本地分析

正如您從上述儀表盤所看的，我能夠輕松地在本地對Pine-64進行分析。同時，它擁有一個板載的HDMI接口和一個完整的GPU，這使得本地訪問儀表盤，以及實時監測就變得相當簡單了。正如我上面提到的，如果設備能夠處理更多的工作，就會顯得更有用。

理想狀態下，您可能需要收集所有的數據到一臺網關設備上，并實現各種本地分析、報警等功能。但是在現實世界中，這并不是網關/收集器所應該具有的，我們應該將各種處理作業“移”出去，即向上游轉發數據。

降低物聯網數據的采樣率

如果只是簡單地使用一臺網關設備向上游轉發所有的數據，那將非常的容易。但是如果您需要處理網絡連接問題，或者是想節約花銷與帶寬的話，您就會希望在轉發數據之前降低數據的采樣率(data downsampling)。幸運的是一般比較實用的IoT設備都有能力進行各種本地分析、本地警報處理，以及在上游轉發之前進行數據采樣。而且實現起來并不困難!

首先，讓我們搭建一臺自己的網關設備，使之能夠向上轉發數據到InfluxDB的另一個實例中。雖然有好幾種方法可以做到這一點，但是鑒于我們將通過Kapacitor來降低數據采樣率，因此我們在此直接使用kapacitor.conf文件來實現。在該kapacitor.conf文件中，已經有一個部分帶有“localhost”的[[influxdb]]條目，所以我們只需要添加一個新的[[influxdb]]部分服務于上游實例便可。如下所示：

[[influxdb]] 
 enabled = true 
 name = "mycluster" 
 default = false 
 urls = ["http://192.168.1.121:8086"] 
 username = "" 
 password = "" 
 ssl-ca = "" 
 ssl-cert = "" 
 ssl-key = "" 
 insecure-skip-verify = false 
 timeout = "0s" 
 disable-subscriptions = false 
 subscription-protocol = "http" 
 subscription-mode = "cluster" 
 kapacitor-hostname = "" 
 http-port = 0 
 udp-bind = "" 
 udp-buffer = 1000 
 udp-read-buffer = 0 
 startup-timeout = "5m0s" 
 subscriptions-sync-interval = "1m0s" 
 [influxdb.excluded-subscriptions] 
 _kapacitor = ["autogen"] 

這只是解決了一部分的問題。而我們現在需要真正采樣數據，并進行發送。在上文中我使用了Chronograf v1.3.10，它有一個內置的TICKscript編輯器，因此我在Chronograf中點擊“警報(Alerting)”選項卡，并創建一個新的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的數據如下所示：

而在上游實例中，其降低采樣率后的數據如下所示：

可見數據大體相同，只是粒度略低一些而已。***，我在網關設備上將數據的保留策略設為1天。這樣我在不“填滿”該設備的情況下，仍然在本地保留著一些歷史數據：

現在我的這臺IoT網關設備既可以收集本地傳感器的數據，又能向本地用戶呈現各種分析，還能發出本地報警(只要我開啟Kapacitor的警報功能)，另外它還降低了本地數據的采樣率，并能向上發送到我的企業級InfluxDB實例之中，以用于進一步的分析和處理。在這臺網關設備上，我擁有細粒度的毫秒級數據。與此同時，我的上游設備所收到的略低粒度的分鐘級數據，足以讓我洞悉到各臺本地傳感器的情況，而不必支付那些花費在各種數據上傳中的帶寬成本。

利用這個方法，我還可以與一個區域性InfluxDB實例里的分鐘級數據進行連接和存儲。而且我能夠轉發更多降低采樣率后的數據，到這個用于聚合全企業傳感器數據的InfluxDB實例之上。

雖然我完全可以將所有的數據沿著整條“鏈路”向上發送到最終的企業數據聚合處，但是如果我真的這樣聚集來自成千上萬臺傳感器里的數據，其對應的存儲和帶寬成本勢必會被大量無用的細粒度數據所消耗殆盡。

結論

在此，我想再次強調：唯有及時、準確、可操作的物聯網數據才能真正有用。所以您的數據越陳舊，就越不具有可操作性;而越不具有可操作性，您就越不需要精細。通過降低數據采樣率，以及設置隨著時間推移逐步延長的數據保留策略，您可以確保即時數據具有高度的可操作的和高精確度的特性，同時也能保障長期的數據趨勢與分析。

原文標題：Architecting IoT Gateway Devices for Data Downsampling，作者: David G. Simmons

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】