DIY“物聯(lián)網(wǎng)”――自己動(dòng)手處理傳感器數(shù)據(jù)

【編者按】傳感器已經(jīng)大量部署于實(shí)際生產(chǎn)中，涉及航空、電力、醫(yī)療、教育各個(gè)行業(yè)的傳感器形成大規(guī)模的工業(yè)物聯(lián)網(wǎng)，各式各樣的傳感器產(chǎn)生了大量的數(shù)據(jù)，如何去分析這些數(shù)據(jù)，作者用Raspberry Pi和四個(gè)Tinkerforge傳感器DIY了一個(gè)辦公室“物聯(lián)網(wǎng)”，模擬了現(xiàn)實(shí)生產(chǎn)中傳感器應(yīng)用，為我們帶來(lái)了一些有益的借鑒，下面是作者的精彩分析。

以下為譯文：

當(dāng)前的一個(gè)客戶項(xiàng)目和一般工業(yè)大數(shù)據(jù)項(xiàng)目的有趣性質(zhì)（數(shù)據(jù)產(chǎn)生于傳感器）給了我啟發(fā)，我決定自己動(dòng)手處理傳感器數(shù)據(jù)，我想通過(guò)這個(gè)小實(shí)驗(yàn)，了解具體如何處理、存儲(chǔ)和分析這些數(shù)據(jù)，以及在這一過(guò)程中會(huì)遇到哪些挑戰(zhàn)？

為了獲取傳感器數(shù)據(jù)，我們決定把傳感器安裝到我們的辦公室里，生成我們自己的傳感器數(shù)據(jù)，我們發(fā)現(xiàn)Tinkerforge的bricks和bricklets系統(tǒng)非常友好，易于上手，于是我們選擇采用Tinkerforge系統(tǒng)。

我們得到了以下四個(gè)傳感器bricklet：

• 聲音強(qiáng)度傳感器（實(shí)際上是個(gè)小麥克風(fēng)）
• 溫度傳感器
• 多點(diǎn)觸摸bricklet（12個(gè)自制的可連接鋁箔墊）
• 運(yùn)動(dòng)探測(cè)器

四個(gè)bricklet都連接到主bricklet上，然后將主bricklet連接到Raspberry Pi。

我們把溫度傳感器放在辦公室的中央，將運(yùn)動(dòng)探測(cè)器安裝在廚房和浴室之間的走廊里，把聲音強(qiáng)度傳感器放在廚房門(mén)邊，而觸摸傳感器則放在咖啡機(jī)、冰箱門(mén)和廁所的門(mén)把上。

雖然這樣的設(shè)備很難跟實(shí)際生產(chǎn)中的情形相比（而且為了獲取足夠多的數(shù)據(jù)，你需要等很長(zhǎng)時(shí)間），在這次小小的實(shí)驗(yàn)中，我們還是很快遇到了那些現(xiàn)實(shí)傳感器應(yīng)用過(guò)程中的一些關(guān)鍵問(wèn)題。

我們選擇了MongoDB作為存儲(chǔ)解決方案，主要是因?yàn)槲覀兊哪莻€(gè)客戶項(xiàng)目也使用了MongoDB。

四個(gè)傳感器產(chǎn)生的數(shù)據(jù)可以分為兩類：溫度和聲音強(qiáng)度傳感器輸出連續(xù)的數(shù)據(jù)流，運(yùn)動(dòng)探測(cè)器和多點(diǎn)觸摸傳感器往往是由非固定頻率的事件觸發(fā)。

這就形成了MongoDB中兩種不同的文檔模式。對(duì)于第一類（流），我們使用MongoDB推薦的模式，實(shí)際上也是這種情況下的最佳實(shí)踐，即“時(shí)間序列模式”（見(jiàn) http://blog.mongodb.org/post/65517193370/schema-design-for-time-series-data-in-mongodb），由一個(gè)內(nèi)部的嵌套文檔集合組成。嵌套的層數(shù)和每個(gè)級(jí)別子文檔的數(shù)量取決于數(shù)據(jù)的時(shí)間粒度。在我們的實(shí)驗(yàn)中，Tinkerforge傳感器的最高時(shí)間分辨率為100ms，產(chǎn)生了下面的文檔結(jié)構(gòu)：

• 每小時(shí)一篇文檔
• 字段：小時(shí)時(shí)間戳、傳感器類型、值
• 值：嵌套的子文檔（subdocument）集，每分鐘60個(gè)子文檔（subdocument），每一秒60個(gè)子文檔（subdoc），每1/10秒10個(gè)子文檔（subdoc）

MongoDB中文檔是預(yù)先分配的，預(yù)先對(duì)所有的字段進(jìn)行初始化，保證初始值大于傳感器的數(shù)據(jù)范圍，這樣做是為了避免由于MongoDB數(shù)據(jù)庫(kù)中文檔持續(xù)增多造成的麻煩。

第二個(gè)類型的數(shù)據(jù)（事件驅(qū)動(dòng)/觸發(fā)）以類“bucket”文檔模式存儲(chǔ)。針對(duì)每個(gè)傳感器的類型，需要預(yù)先為值分配固定數(shù)量的條目（一bucket分配100個(gè)）。當(dāng)事件發(fā)生時(shí)，將其寫(xiě)入這些文件中，每個(gè)事件對(duì)應(yīng)100個(gè)條目組的一個(gè)子文檔，子文檔貫穿著事件的始終。當(dāng)記錄/事件第一次被寫(xiě)入到文檔中時(shí)，全部文件獲取與開(kāi)始日期對(duì)應(yīng)的時(shí)間戳。每次寫(xiě)入到數(shù)據(jù)庫(kù)時(shí)，應(yīng)用程序都會(huì)檢查當(dāng)前記錄是否已經(jīng)寫(xiě)入到當(dāng)前文檔，如果寫(xiě)入已經(jīng)完成，它會(huì)設(shè)置文檔的結(jié)束日期/時(shí)間并啟動(dòng)引導(dǎo)到下一文檔的寫(xiě)入。

這兩個(gè)文檔模式表示權(quán)衡的邊界情況，在傳感器數(shù)據(jù)中比較常見(jiàn)。

MongoDB推薦的“時(shí)間序列”模式很適合高效寫(xiě)入，而且兼具良好、一致性架構(gòu)的優(yōu)勢(shì)：每個(gè)文檔都對(duì)應(yīng)著一個(gè)時(shí)間單位（在我們的實(shí)驗(yàn)中，時(shí)間單位為一個(gè)小時(shí)），這使得管理和檢索數(shù)據(jù)非常方便。此外，還可以很容易從當(dāng)前的時(shí)間推斷出要寫(xiě)入的“當(dāng)前”文檔，所以應(yīng)用程序不需要一直對(duì)文檔進(jìn)行追蹤。

嵌套結(jié)構(gòu)實(shí)現(xiàn)了對(duì)不同粒度級(jí)數(shù)據(jù)的整合――雖然應(yīng)用中這些整合不得不手動(dòng)執(zhí)行。由于這樣一個(gè)事實(shí)，在該文檔模式中，“分鐘”、“秒”和“毫秒”不再有單一的鍵，相反，每一分鐘、 每一秒、每一毫秒都有各自的鍵。

一旦數(shù)據(jù)變得稀疏、不連續(xù)，這個(gè)模式就會(huì)出現(xiàn)問(wèn)題。實(shí)驗(yàn)中，這些數(shù)據(jù)顯然是由運(yùn)動(dòng)探測(cè)器和多點(diǎn)觸摸傳感器產(chǎn)生：由于事件是隨機(jī)發(fā)生的，所以數(shù)據(jù)也沒(méi)有固定的頻率。對(duì)于時(shí)間序列文檔模式，這就意味著文檔的某些字段永遠(yuǎn)用不到，這顯然是對(duì)磁盤(pán)空間的一種浪費(fèi)。

如果傳感器數(shù)據(jù)開(kāi)始時(shí)不是通過(guò)事件驅(qū)動(dòng)的話，也會(huì)產(chǎn)生稀疏數(shù)據(jù)。換句話說(shuō)，許多傳感器，雖然它們以一個(gè)固定的頻率測(cè)量數(shù)據(jù)，但是只會(huì)自動(dòng)輸出相對(duì)于上一次測(cè)量改變的值，這個(gè)問(wèn)題已經(jīng)被解決了，如果你想要堅(jiān)持時(shí)間序列文檔模式，就需要經(jīng)常檢查是否有值被傳感器省去，以傳感器發(fā)出的最新值更新數(shù)據(jù)庫(kù)。當(dāng)然，這有可能會(huì)在數(shù)據(jù)庫(kù)中引入大量的冗余。

Bucket模式中用實(shí)際已記錄的數(shù)據(jù)填充文檔，避免了這一問(wèn)題，但它也有自身的缺點(diǎn)：

• 應(yīng)用程序需要處理有可能出現(xiàn)的全部數(shù)據(jù)重建問(wèn)題（包括尚未保存的冗余數(shù)據(jù)）
• “bucket”文件沒(méi)有一致的開(kāi)始和結(jié)束時(shí)間――如果你對(duì)特定時(shí)間范圍感興趣，你就必須查找該范圍內(nèi)的所有文件
• “bucket”的管理（跟蹤當(dāng)前的bucket，檢查bucket是否為滿）需要應(yīng)用程序解決

Tinkerforge傳感器帶有多語(yǔ)言版本的API，我們決定使用Python，在連接傳感器的Raspberry Pi上運(yùn)行腳本，數(shù)據(jù)則寫(xiě)入到MongoSoup托管的MongoDB實(shí)例中，MongoSoup是我們的MongoDB即服務(wù)解決方案。通過(guò)API注冊(cè)例如聲音強(qiáng)度和溫度bricklet，你需要執(zhí)行下列操作： 

Tinkerforge API支持通過(guò)回調(diào)函數(shù)從傳感器中自動(dòng)地讀取數(shù)據(jù)。若要使用此功能，你需要注冊(cè)你想要通過(guò)bricklet觸發(fā)的功能：

它將以每100ms的速度自動(dòng)查詢傳感器的新數(shù)據(jù)并分別調(diào)用stream_handler.cb_intensity_SI和stream_handler.cb_temperature函數(shù)。

為了節(jié)省網(wǎng)絡(luò)帶寬，只在上一次傳感器的測(cè)量值發(fā)生改變時(shí)，你提供的功能才會(huì)被觸發(fā)――也產(chǎn)生了上文討論的稀疏數(shù)據(jù)。

可以通過(guò)直接自定義代碼的方式，以一個(gè)固定的頻率查詢傳感器來(lái)避免這種現(xiàn)象。但是，就如上文所說(shuō)的那樣，這會(huì)導(dǎo)致數(shù)據(jù)庫(kù)中充滿了冗余數(shù)據(jù)。此外，它增加了從傳感器到應(yīng)用程序的網(wǎng)絡(luò)開(kāi)銷。

最后，其中一個(gè)將必須決定哪種模式更適合用例。關(guān)于數(shù)據(jù)模式，MongoDB提供了大量元數(shù)據(jù)模式，你的選擇應(yīng)完全由用例（比如你最有可能遇到的讀/寫(xiě)模式）來(lái)決定。

一個(gè)好方法是在決定一個(gè)文檔模型之前，問(wèn)以下幾個(gè)問(wèn)題：

• 從整體的角度考慮（考慮到帳戶數(shù)據(jù)庫(kù)和應(yīng)用程序性能），是數(shù)據(jù)庫(kù)中的稀疏/冗余代價(jià)高？還是之后重建應(yīng)用程序中的冗余數(shù)據(jù)代價(jià)高？
• 數(shù)據(jù)實(shí)際上有多大變化？如果周期性的持續(xù)測(cè)量比較少，那最好留有一定量的冗余。
• 從一個(gè)更大的時(shí)間尺度看，有恒定的頻率嗎？例如，你的數(shù)據(jù)主要是以幾秒鐘為周期的分段常數(shù)，而這些周期的長(zhǎng)度相同，那你可能需要考慮粗粒化時(shí)間尺度，丟掉小尺度內(nèi)的冗余信息。
• 假如出現(xiàn)另一種情況，常數(shù)的長(zhǎng)度變化太快，事件隨機(jī)發(fā)生，那你最好還是選擇用bucket模式。

在我們的實(shí)驗(yàn)中，最初的假設(shè)是溫度數(shù)據(jù)和聲音強(qiáng)度數(shù)據(jù)會(huì)有很大變化，我們需要將它們存儲(chǔ)在“時(shí)間序列”數(shù)據(jù)模式中，而運(yùn)動(dòng)探測(cè)器和觸摸傳感器數(shù)據(jù)適合用bucket模式，實(shí)際上我們也是這么做的。

在完成安裝并執(zhí)行處理傳感器數(shù)據(jù)的Python腳本后，我們開(kāi)始收集數(shù)據(jù)。

我們使用matplotlib和Flask web服務(wù)器框架，搭建起一個(gè)小型的web服務(wù)，直觀顯示最近收集的數(shù)據(jù)以用于檢查，并將該web服務(wù)部署到Heroku。

我們生成三個(gè)plot，第一個(gè)隨著時(shí)間變化分別顯示觸摸傳感器和運(yùn)動(dòng)探測(cè)器的事件，其他兩個(gè)顯示隨著時(shí)間的推移聲音強(qiáng)度和溫度水平，plot中的每個(gè)數(shù)據(jù)點(diǎn)平均一秒鐘計(jì)算一次。

一眼就能看出辦公室中人員活動(dòng)產(chǎn)生的不同傳感器數(shù)據(jù)之間存在明顯相關(guān)性。

你可以確定選擇使用bucket模型是正確的，因?yàn)榻?jīng)常會(huì)有在長(zhǎng)達(dá)20 分鐘的時(shí)間里，傳感器沒(méi)有記錄下任何東西。

看一下溫度數(shù)據(jù)，雖然它會(huì)有波動(dòng)，但很明顯這種波動(dòng)保持在1攝氏度的范圍內(nèi)。如果用例是監(jiān)測(cè)全球白天溫度的變化，那很可能需要在時(shí)間上采用粗粒度數(shù)據(jù)寫(xiě)入或者切換到bucket模式。

聲音強(qiáng)度數(shù)據(jù)表現(xiàn)為：長(zhǎng)時(shí)間的安靜（測(cè)量值很?。┲蟠舐暿录蝗?、短時(shí)間爆發(fā)。這樣短時(shí)間的數(shù)據(jù)肯定不容許被遺漏，所以上述的粗粒度辦法行不通，不過(guò)可以考慮切換到bucket模型，僅向數(shù)據(jù)庫(kù)中寫(xiě)入變化的數(shù)據(jù)測(cè)量值。

原文鏈接：Processing and analysing sensor data

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)