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

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

[[216508]]

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

構建網(wǎng)關

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

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

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

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

怎樣才能實現(xiàn)TICK(譯者注：Telegraf、InfluxDB、Chronograf和Kapacitor的縮寫，分別代表數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)可視化和監(jiān)控告警)，并運行在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 

現(xiàn)在我們已經(jīng)準備進入下一步了!

負載測試設備

我的原始想法只是想看看，在這么小的設備上添加了負載后，它的處理情況是怎樣的。因此我從GitHub網(wǎng)站上(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產(chǎn)生了嚴重的壓力!

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

本地分析

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

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

降低物聯(lián)網(wǎng)數(shù)據(jù)的采樣率

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

首先，讓我們搭建一臺自己的網(wǎng)關設備，使之能夠向上轉發(fā)數(shù)據(jù)到InfluxDB的另一個實例中。雖然有好幾種方法可以做到這一點，但是鑒于我們將通過Kapacitor來降低數(shù)據(jù)采樣率，因此我們在此直接使用kapacitor.conf文件來實現(xiàn)。在該kapacitor.conf文件中，已經(jīng)有一個部分帶有“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"] 

這只是解決了一部分的問題。而我們現(xiàn)在需要真正采樣數(shù)據(jù)，并進行發(fā)送。在上文中我使用了Chronograf v1.3.10，它有一個內(nèi)置的TICKscript編輯器，因此我在Chronograf中點擊“警報(Alerting)”選項卡，并創(chuàng)建一個新的TICK腳本，然后選擇telegraf.autoget數(shù)據(jù)庫作為我的數(shù)據(jù)源：

由于我實際上并沒有從該設備上收集到傳感器的數(shù)據(jù)，所以我在此使用CPU的使用率作為數(shù)據(jù)，并利用自己的TICKScript來降低采樣率。下面我編寫了一個非?；A的TICKScript來降低CPU數(shù)據(jù)的采樣率，并且予以向上轉發(fā)：

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實例之中。在這個網(wǎng)關設備上，CPU的數(shù)據(jù)如下所示：

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

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

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

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

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

結論

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

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

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