摘要：權(quán)衡性價(jià)比之后，決定采取最后一種方案。它們分別用于處理流入結(jié)點(diǎn)之前的數(shù)據(jù)，和結(jié)點(diǎn)之后的數(shù)據(jù)。這時(shí)對(duì)數(shù)據(jù)庫(kù)進(jìn)行簡(jiǎn)單的操作檢查數(shù)據(jù)是否如自己預(yù)期地被寫入了指定數(shù)據(jù)庫(kù)。

繼上次搭建完框架得到了個(gè)粗糙的demo以后，基本的圖形組件試了個(gè)遍沒(méi)什么阻力。我天真地以為我離真理的距離簡(jiǎn)直就只有一步之遙了。 ?
想著我還有些模擬的地理數(shù)據(jù)沒(méi)有做可視化，數(shù)據(jù)信息的內(nèi)容放在名為location的屬性之下，具體格式如：

{
  "location": {
   "lat":12.345,
   "lon":56.789
  },
  "temperature": 49.966,
  "more-props": "value"
 }

一個(gè)很自然而然想法萌生了---用地圖來(lái)展示相關(guān)信息。但！萬(wàn)萬(wàn)那沒(méi)想到，一進(jìn)地圖的坑，卡了10天都沒(méi)出坑。（部分原因是圣誕節(jié)讓我懶惰[寫不出來(lái)就讓圣誕節(jié)背鍋哈哈哈哈]，沒(méi)有做功課)。
關(guān)于基于地圖的信息可視化，Power BI上的Map工具給我留下了用戶友好簡(jiǎn)單易用的好印象。只要使用直接的經(jīng)緯度數(shù)據(jù)對(duì)就能在地圖上對(duì)位置定位并展示。邏輯慣性讓我想當(dāng)然了，天真地以為所有的地圖插件都一樣”單純”。
首先，在Grafana的標(biāo)準(zhǔn)可視化工具中是不包括地圖相關(guān)的工具的， 但在插件庫(kù)中官方發(fā)布了一款名為Worldmap Panel基于地圖可視化的工具，符合我的需求看起來(lái)效果也不錯(cuò)。

在簡(jiǎn)單地下載安裝了這個(gè)插件后，我發(fā)現(xiàn)事情并沒(méi)有想象簡(jiǎn)單。該工具和我的可視化框架最大的沖突是:
Worldmap Panel并不支持通過(guò)經(jīng)緯度數(shù)據(jù)對(duì) e.g. (latitude, longtitude)在地圖上定位與可視化， 其支持的數(shù)據(jù)格式有且僅有兩種：Country/State Code或geohash。?

以下從官方文檔中摘出的這句話很好地的解釋了這兩種數(shù)據(jù)類型。 ?

There are currently two ways to connect data with points on a map. Either by matching a tag or series name to a country code/state code (e.g. SE for Sweden, TX for Texas) or by using geohashes to map against geographic coordinates。 ?

Grafana和InfluxDB的文檔大概是我有生以來(lái)看到過(guò)寫的最邏輯混亂的文檔之一了，吐槽請(qǐng)見(jiàn)上篇博客。
在這新年之際，我要邀請(qǐng)大家繼續(xù)欣賞出自Grafana官方WorldMap Panel的documentation。 說(shuō)實(shí)話我一口氣看了三遍后竟然比看第一遍時(shí)還要混亂。文檔以table data, time series data和json為data source的介紹相關(guān)配置實(shí)在是非常地不明智之舉。以我的構(gòu)架為例：首先，使用influxdb得到的數(shù)據(jù)照理說(shuō)應(yīng)該是time series data吧？畢竟人家influxdb號(hào)稱time-series數(shù)據(jù)庫(kù)，以寫入數(shù)據(jù)庫(kù)時(shí)的時(shí)間戳作為表格的唯一索引。 然而最后使用的配置方法竟然歸檔在table data下(influxdb: 我不要面子的哦)； ?
其次"time-series data"這個(gè)稱謂也許還能夠直觀地理解是以時(shí)間戳為索引的數(shù)據(jù)（更有甚者我這樣的理解其實(shí)是錯(cuò)誤的），那么“table data”該如何去理解呢？"time-series data"難道不是以表格的形式組織排列儲(chǔ)存的嗎？至于“json”就更為模糊了，是以json為格式的數(shù)據(jù)？還是通過(guò)json的形式傳遞的數(shù)據(jù)？ 那么json這種格式的數(shù)據(jù)就不能同時(shí)是"time-series data"或"table data"嗎？這三種類型的數(shù)據(jù)不具備互斥性，由此可見(jiàn)這種分類方法是不科學(xué)的。
我個(gè)人主觀認(rèn)為正確的分類方法正如文檔開(kāi)頭所說(shuō)，我在本文的第一章節(jié)也引用了這句話:

There are currently two ways to connect data with points on a map. Either by matching a tag or series name to a country code/state code (e.g. SE for Sweden, TX for Texas) or by using geohashes to map against geographic coordinates. ? 
注解：
對(duì)于code： 可以使用grafana預(yù)先定義的code， 也可以自定義一些code并用json/jsonp方式導(dǎo)入;   
對(duì)于geohash: 主要是為了支持elasticsearch， 但是對(duì)于influxdb， 可以人工添加geohash的tag，并將數(shù)據(jù)看作是表格讀取geohash tag中的內(nèi)容；

“以country code和geohash為區(qū)分，詳述在不同數(shù)據(jù)庫(kù)下針對(duì)這兩種數(shù)據(jù)源的配置方法”---如果用這樣的方法組織文檔，一目了然，結(jié)構(gòu)清晰；讀者按圖索驥，效率大大提高，至少好過(guò)現(xiàn)在的文檔。而全文檔如此重要的一句話，竟然放在一個(gè)毫不起眼的角落。恕我實(shí)在無(wú)法理解撰寫者的意圖。

為了解決這個(gè)如鯁在喉的數(shù)據(jù)匹配問(wèn)題，幾種可能的解決方法一番折騰后初現(xiàn)原形：
1. 在原始數(shù)據(jù)中人工硬是添加個(gè)country code field或geohash field；
最容易想到的方法。簡(jiǎn)單粗暴快捷！但是考慮到這樣的方法并不能適配所有的IoT設(shè)備，且大部分的GPS產(chǎn)生的數(shù)據(jù)還是經(jīng)緯度。排除排除!

2. 在Telegraf中添加能夠?qū)?jīng)緯度數(shù)據(jù)對(duì)做處理并產(chǎn)生geohash的plug-in；
可惜我并沒(méi)有找到這樣可以直接使用的plug-in。轉(zhuǎn)念想到可以自己開(kāi)發(fā)plug-in,但是對(duì)我而言時(shí)間，學(xué)習(xí)成本太。高。（Golang小白,geohash算法不了解）。兩個(gè)字：排除！ ?
P.S:有興趣的朋友可以看看telegraf的文檔，他們是歡迎各種形式的plugin PR的。暗中觀察，這樣的plug-in應(yīng)該要?dú)w在processor plug-in一類中。而目前官方只在這類中給了個(gè)printer?；镜扔跊](méi)什么卵用，就是在cmd里打印下數(shù)據(jù)流。亟待小伙伴填坑！
ref:https://github.com/influxdata...

3. 使用Kapacitor對(duì)流出數(shù)據(jù)庫(kù)的數(shù)據(jù)分析處理，后而送至可視化終端；
Kapacitor是influxdata四個(gè)開(kāi)源核心產(chǎn)品之一（TICK stack, K--Kapacitor)，可以對(duì)數(shù)據(jù)進(jìn)行相應(yīng)的分析處理，比如使用機(jī)器學(xué)習(xí)模型處理分析數(shù)據(jù)。具體其他功能不是特別清楚沒(méi)做仔細(xì)調(diào)研，有興趣的同學(xué)移架這里。
至于排除的原因和2類似，沒(méi)有可用的腳本，開(kāi)發(fā)成本太高。

4. 使用node-influx和node-geohash等開(kāi)源插件, 后端語(yǔ)言（如node.js)處理,向數(shù)據(jù)庫(kù)直接添加geohash tag并寫入值；
看起來(lái)似乎是個(gè)物美價(jià)廉的正經(jīng)解決方法。不過(guò)由于本文討論的是實(shí)時(shí)IoT數(shù)據(jù)的可視化，可能每分鐘就會(huì)向數(shù)據(jù)庫(kù)內(nèi)寫入大量的數(shù)據(jù)，如果在數(shù)據(jù)存儲(chǔ)后再對(duì)數(shù)據(jù)進(jìn)行操作，則要頻繁地調(diào)用數(shù)據(jù)庫(kù)I/O進(jìn)行讀寫操作,將已經(jīng)存入的數(shù)據(jù)記錄逐條處理并寫回，增加了數(shù)據(jù)庫(kù)負(fù)擔(dān)。因此排除。
ref: https://community.influxdata....

5. 使用Node-Red對(duì)數(shù)據(jù)流向管理，在數(shù)據(jù)存入數(shù)據(jù)庫(kù)之前利用已有的集成塊調(diào)用接口計(jì)算geohash以減輕對(duì)數(shù)據(jù)庫(kù)的負(fù)擔(dān)。
Node-RED為一個(gè)開(kāi)源的IoT設(shè)備數(shù)據(jù)流編輯器，主要用于可視化IoT數(shù)據(jù)的流向并且對(duì)數(shù)據(jù)流向進(jìn)行管理和連接。 它依賴于活躍的node.js社區(qū)，擁有大量可用資源和強(qiáng)大的社區(qū)支持。 既能有效地將數(shù)據(jù)從源頭歷經(jīng)的各個(gè)技術(shù)棧以流程圖的形式表達(dá)出來(lái)，又能對(duì)數(shù)據(jù)流進(jìn)行簡(jiǎn)單管理，支持javascript對(duì)數(shù)據(jù)流的處理，因此對(duì)前端工程師十分友好。

而吸引我使用Red-Node很重要的一個(gè)原因是:Node-RED中有一個(gè)名為node-red-node-geohash的結(jié)點(diǎn)模塊，在Node-RED項(xiàng)目中使用npm簡(jiǎn)單安裝后，即可將數(shù)據(jù)中的經(jīng)緯度數(shù)據(jù)對(duì)直接編碼成geohash碼，反之亦然。這樣就避免了我投入大量時(shí)間成本和開(kāi)發(fā)成本在geohash到經(jīng)緯度的轉(zhuǎn)碼上；

其次，Node-RED對(duì)數(shù)據(jù)流向進(jìn)行管理和編輯處理的強(qiáng)大功能，允許在流向中插入自定義的javascript功能代碼；這讓數(shù)據(jù)流向設(shè)計(jì)的靈活度大大提高了，因此也能充分利用這種靈活度將我的數(shù)據(jù)在存入數(shù)據(jù)庫(kù)之前將關(guān)于經(jīng)緯度的數(shù)據(jù)轉(zhuǎn)譯成geohash，這樣一來(lái)就避免了方法4中對(duì)數(shù)據(jù)庫(kù)資源的浪費(fèi)和復(fù)寫；
最后，Node-RED的可視化編輯界面能有效將數(shù)據(jù)流向以一種簡(jiǎn)單直接的方式表達(dá)出來(lái)，是選擇使用該工具的加分點(diǎn)。權(quán)衡性價(jià)比之后，決定采取最后一種方案。 ?

注：整個(gè)方案詳細(xì)步驟參考了該博客內(nèi)容（https://primalcortex.wordpres...）

tips: 使用Node-RED的前提條件是保證node.js已安裝;

已安裝過(guò)node.js的盆友們可以跳過(guò)這一趴！

如果是和我一樣使用windows系統(tǒng)的小伙伴們， 推薦一個(gè)插件叫做chocolately, 從此Windows也擁有了軟件包管理工具，命令行安裝package不是夢(mèng)！
打開(kāi) windows cmd使用chocolately安裝node.js： choco install nodejs-lts

安裝Node-RED： ?

C:WINDOWSsystem32>npm install -g --unsafe-perm node-red

安裝至關(guān)重要的geohash node：

用戶app路徑 pm ode_modules ode-red>npm install node-red-node-geohash

運(yùn)行Node-RED：

用戶app路徑 pm ode_modules ode-red>node-red

cmd提示成功信息

用瀏覽器打開(kāi)途中高亮地址，進(jìn)入node-red的用戶界面---新世界大門打開(kāi)，噔噔！

Node-RED的數(shù)據(jù)流向編輯器采用模塊拖拽的形式，用戶很容易理解和使用，因此上手不難，學(xué)習(xí)曲線平緩。 ?
根據(jù)我的案例情況，在Node-RED上搭建的數(shù)據(jù)流向如下

從我機(jī)器上的MQTT broker上訂閱從我的模擬器中發(fā)出的特定話題的數(shù)據(jù)后，利用geohash結(jié)點(diǎn)模塊處理經(jīng)緯度數(shù)據(jù)，生成geohash，然后再一次利用MQTT broker發(fā)布一個(gè)新的話題，用于傳遞經(jīng)過(guò)處理的數(shù)據(jù)， 這時(shí)只要數(shù)據(jù)庫(kù)訂閱這個(gè)新話題，就能利用telegraf順利地將數(shù)據(jù)存入數(shù)據(jù)庫(kù)中。
在這個(gè)流向中除了必備的mqtt和geohash節(jié)點(diǎn)，我還利用了兩個(gè)function節(jié)點(diǎn)來(lái)自定義代碼。它們分別用于處理流入geohash結(jié)點(diǎn)之前的數(shù)據(jù)，和geohash結(jié)點(diǎn)之后的數(shù)據(jù)。
根據(jù)官方文檔中的描述，geohash節(jié)點(diǎn)將會(huì)直接讀取msg.payload中的lat和lon屬性，如果規(guī)定了精確度即msg.payload.precision存在，那么會(huì)一并處理生成唯一的geohash碼。具體描述如下：

A function that encodes lat,lon to and from a geohash.
If the msg.payload is an object with properties lat or latitude and lon or longitude - it will add a geohash property to the payload.
The precision can be set by msg.payload.precision from 1 to 9.
Note: If the msg contains a .location property it will operate on that in preference to the .payload.

在第一章中，我提到過(guò)，我的地理數(shù)據(jù)是被包裹在location屬性中的，即msg.payload.location。因此geohash無(wú)法直接得到經(jīng)緯度信息。這時(shí)就借助了location-preprocessor的功能節(jié)點(diǎn)將location中的信息提取出來(lái)。注意在引用的文檔敘述中的最后一句， 如果msg中包含了location屬性，會(huì)直接處理location屬性中的lat,lon屬性，忽略payload中的信息。 借助這一點(diǎn)，我們則可以將msg.payload.location中的信息直接放入msg.location讓其計(jì)算geohash。
location-preprocessor的代碼: ? ?

//The main purpose of this snippet is to extract the location info from msg.payload and then put it to msg.location to get the calculated geohash. 
var message=JSON.parse(msg.payload);
if(message[0].location!==null)
{
  msg.location={
      "lat":message[0].location.lat.toString(), 
      "lon":message[0].location.lon.toString(),
      "precision":"8"
  };
//msg.location=message;
}
return msg;

當(dāng)?shù)玫接行У膅eohash碼后，此時(shí)，只需將msg.location.geohash的值復(fù)制進(jìn)入msg.payload中，此時(shí)數(shù)據(jù)中就擁有了geohash碼了。接著只需新建一個(gè)mqtt話題，將處理的數(shù)據(jù)通過(guò)mqtt broker發(fā)布出去，則Node-RED的配置到這里就結(jié)束了。
location-afterprocessor的代碼: ?

//The main purpose for this snippet is to put the geohash property into msg.payload which is then transferred by mqtt-broker via certain topic
if(msg.location.geohash!==null)
{
   var message=JSON.parse(msg.payload);
   message[0].geohash=msg.location.geohash;
   msg.payload=JSON.stringify(message);
   msg.topic="sensors/wrap_geohash";
}
return msg;

[注意]在使用telegraf接受數(shù)據(jù)之前，要將geohash一項(xiàng)設(shè)置為tag才能被Worldpanel識(shí)別和使用。同時(shí)如果使用了mqtt的新話題，要記得在配置文件中修改相關(guān)項(xiàng)
到這里，運(yùn)行telegraf和influxdb，數(shù)據(jù)應(yīng)該安然無(wú)恙地被telegraf簡(jiǎn)單處理后存入數(shù)據(jù)庫(kù)。這時(shí)對(duì)數(shù)據(jù)庫(kù)進(jìn)行簡(jiǎn)單的操作檢查數(shù)據(jù)是否如自己預(yù)期地被寫入了指定數(shù)據(jù)庫(kù)。 ?

既然到這里已經(jīng)保證數(shù)據(jù)庫(kù)里有了可用的數(shù)據(jù)，那么接下來(lái)開(kāi)始設(shè)置Worldmap Panel工具吧！
欣喜伴隨著絕望。又要開(kāi)始研究文檔T.T。 ?
瞅來(lái)瞅去，文章里關(guān)于配置最重要的一段話就是這里了：

An example of Table Data would using InfluxDB and then formatting the data returned from the metric query as Table.
Similar to the Elasticsearch query above, 3 fields are expected (2 of them are mandatory)

field named metric
geohash tag named geohash
an optional location name (shown in the mouse over). This location name has to be specified in the Worldmap settings tab too.

我給大家用直白的話翻譯一下這段話的意思： 老子Worldmap Panel只認(rèn)兩個(gè)兄弟，一個(gè)叫做metric，還有一個(gè)就是geohash！location name的這個(gè)人可以考慮，但是可有可無(wú)。其他的都滾一邊去！
geohash就是個(gè)打手，Worldmap Panel說(shuō)讓它去哪兒它就得去哪兒，該在那個(gè)地理位置就給定在哪里；
metric是個(gè)師爺，在geohash的定位基礎(chǔ)上，每個(gè)點(diǎn)要顯示的值都靠metric去提供。但是師爺這種人聰明絕頂，行走江湖容易遭人暗算，所以metric是個(gè)化名，真正名字叫什么，主要看數(shù)據(jù)庫(kù)給什么值了?？傊赪orldmap上他就叫metric。
這樣一來(lái)我們就可以設(shè)置數(shù)據(jù)集按照geohash來(lái)定位，而在每個(gè)geohash的點(diǎn)上需要顯示的值則由metric確定。比如從我的需求出發(fā)，需要顯示我的每臺(tái)設(shè)備在地圖上的定位并能讓用戶看到每臺(tái)機(jī)器的當(dāng)前運(yùn)行的溫度情況，那么我就應(yīng)該這樣來(lái)設(shè)置我的query。

同時(shí)，在worldmap一欄對(duì)map data options進(jìn)行設(shè)置：

location data一定要選擇table,且一般table field name設(shè)置為geohash；

到這里應(yīng)該可以看到美膩的demo了！Worldmap panel到這里終于可用了！

臉上笑嘻嘻，心里真是mmp啊！朋友們填坑不易，且填且珍惜哦！
也不知道自己還能堅(jiān)持填坑多久，前路漫漫啊前路漫漫！
最后是不是要祝盆友們?cè)┛鞓?lè)呢？雖然我知道看到最后的基本都是真愛(ài)，而真愛(ài)的概率和在這個(gè)現(xiàn)實(shí)世界一樣基本為0。