摘要：權衡性價比之后，決定采取最后一種方案。它們分別用于處理流入結點之前的數據，和結點之后的數據。這時對數據庫進行簡單的操作檢查數據是否如自己預期地被寫入了指定數據庫。

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

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

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

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

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

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

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. ? 
注解：
對于code： 可以使用grafana預先定義的code， 也可以自定義一些code并用json/jsonp方式導入;   
對于geohash: 主要是為了支持elasticsearch， 但是對于influxdb， 可以人工添加geohash的tag，并將數據看作是表格讀取geohash tag中的內容；

“以country code和geohash為區分，詳述在不同數據庫下針對這兩種數據源的配置方法”---如果用這樣的方法組織文檔，一目了然，結構清晰；讀者按圖索驥，效率大大提高，至少好過現在的文檔。而全文檔如此重要的一句話，竟然放在一個毫不起眼的角落。恕我實在無法理解撰寫者的意圖。

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

2. 在Telegraf中添加能夠對經緯度數據對做處理并產生geohash的plug-in；
可惜我并沒有找到這樣可以直接使用的plug-in。轉念想到可以自己開發plug-in,但是對我而言時間，學習成本太。高。（Golang小白,geohash算法不了解）。兩個字：排除！ ?
P.S:有興趣的朋友可以看看telegraf的文檔，他們是歡迎各種形式的plugin PR的。暗中觀察，這樣的plug-in應該要歸在processor plug-in一類中。而目前官方只在這類中給了個printer。基本等于沒什么卵用，就是在cmd里打印下數據流。亟待小伙伴填坑！
ref:https://github.com/influxdata...

3. 使用Kapacitor對流出數據庫的數據分析處理，后而送至可視化終端；
Kapacitor是influxdata四個開源核心產品之一（TICK stack, K--Kapacitor)，可以對數據進行相應的分析處理，比如使用機器學習模型處理分析數據。具體其他功能不是特別清楚沒做仔細調研，有興趣的同學移架這里。
至于排除的原因和2類似，沒有可用的腳本，開發成本太高。

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

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

而吸引我使用Red-Node很重要的一個原因是:Node-RED中有一個名為node-red-node-geohash的結點模塊，在Node-RED項目中使用npm簡單安裝后，即可將數據中的經緯度數據對直接編碼成geohash碼，反之亦然。這樣就避免了我投入大量時間成本和開發成本在geohash到經緯度的轉碼上；

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

注：整個方案詳細步驟參考了該博客內容（https://primalcortex.wordpres...）

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

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

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

安裝Node-RED： ?

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

安裝至關重要的geohash node：

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

運行Node-RED：

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

cmd提示成功信息

用瀏覽器打開途中高亮地址，進入node-red的用戶界面---新世界大門打開，噔噔！

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

從我機器上的MQTT broker上訂閱從我的模擬器中發出的特定話題的數據后，利用geohash結點模塊處理經緯度數據，生成geohash，然后再一次利用MQTT broker發布一個新的話題，用于傳遞經過處理的數據， 這時只要數據庫訂閱這個新話題，就能利用telegraf順利地將數據存入數據庫中。
在這個流向中除了必備的mqtt和geohash節點，我還利用了兩個function節點來自定義代碼。它們分別用于處理流入geohash結點之前的數據，和geohash結點之后的數據。
根據官方文檔中的描述，geohash節點將會直接讀取msg.payload中的lat和lon屬性，如果規定了精確度即msg.payload.precision存在，那么會一并處理生成唯一的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.

在第一章中，我提到過，我的地理數據是被包裹在location屬性中的，即msg.payload.location。因此geohash無法直接得到經緯度信息。這時就借助了location-preprocessor的功能節點將location中的信息提取出來。注意在引用的文檔敘述中的最后一句， 如果msg中包含了location屬性，會直接處理location屬性中的lat,lon屬性，忽略payload中的信息。 借助這一點，我們則可以將msg.payload.location中的信息直接放入msg.location讓其計算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;

當得到有效的geohash碼后，此時，只需將msg.location.geohash的值復制進入msg.payload中，此時數據中就擁有了geohash碼了。接著只需新建一個mqtt話題，將處理的數據通過mqtt broker發布出去，則Node-RED的配置到這里就結束了。
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接受數據之前，要將geohash一項設置為tag才能被Worldpanel識別和使用。同時如果使用了mqtt的新話題，要記得在配置文件中修改相關項
到這里，運行telegraf和influxdb，數據應該安然無恙地被telegraf簡單處理后存入數據庫。這時對數據庫進行簡單的操作檢查數據是否如自己預期地被寫入了指定數據庫。 ?

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

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只認兩個兄弟，一個叫做metric，還有一個就是geohash！location name的這個人可以考慮，但是可有可無。其他的都滾一邊去！
geohash就是個打手，Worldmap Panel說讓它去哪兒它就得去哪兒，該在那個地理位置就給定在哪里；
metric是個師爺，在geohash的定位基礎上，每個點要顯示的值都靠metric去提供。但是師爺這種人聰明絕頂，行走江湖容易遭人暗算，所以metric是個化名，真正名字叫什么，主要看數據庫給什么值了。總之在Worldmap上他就叫metric。
這樣一來我們就可以設置數據集按照geohash來定位，而在每個geohash的點上需要顯示的值則由metric確定。比如從我的需求出發，需要顯示我的每臺設備在地圖上的定位并能讓用戶看到每臺機器的當前運行的溫度情況，那么我就應該這樣來設置我的query。

同時，在worldmap一欄對map data options進行設置：

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

到這里應該可以看到美膩的demo了！Worldmap panel到這里終于可用了！

臉上笑嘻嘻，心里真是mmp啊！朋友們填坑不易，且填且珍惜哦！
也不知道自己還能堅持填坑多久，前路漫漫啊前路漫漫！
最后是不是要祝盆友們元旦快樂呢？雖然我知道看到最后的基本都是真愛，而真愛的概率和在這個現實世界一樣基本為0。