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

　　以下為譯文：

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

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

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

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

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

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

　　這就形成了MongoDB中兩種不同的文檔模式。對于第一類（流），我們使用MongoDB推薦的模式，實(shí)際上也是這種情況下的最佳實(shí)踐，即“時(shí)間序列模式”，由一個(gè)內(nèi)部的嵌套文檔集合組成。嵌套的層數(shù)和每個(gè)級別子文檔的數(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ù)先對所有的字段進(jìn)行初始化，保證初始值大于傳感器的數(shù)據(jù)范圍，這樣做是為了避免由于MongoDB數(shù)據(jù)庫中文檔持續(xù)增多造成的麻煩。

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

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

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

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

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

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

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

　　·應(yīng)用程序需要處理有可能出現(xiàn)的全部數(shù)據(jù)重建問題（包括尚未保存的冗余數(shù)據(jù)）

　　·“bucket”文件沒有一致的開始和結(jié)束時(shí)間——如果你對特定時(shí)間范圍感興趣，你就必須查找該范圍內(nèi)的所有文件

　　·“bucket”的管理（跟蹤當(dāng)前的bucket，檢查bucket是否為滿）需要應(yīng)用程序解決

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

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

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

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

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

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

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

　　·從整體的角度考慮（考慮到帳戶數(shù)據(jù)庫和應(yīng)用程序性能），是數(shù)據(jù)庫中的稀疏/冗余代價(jià)高？還是之后重建應(yīng)用程序中的冗余數(shù)據(jù)代價(jià)高？

　　·數(shù)據(jù)實(shí)際上有多大變化？如果周期性的持續(xù)測量比較少，那最好留有一定量的冗余。

　　·從一個(gè)更大的時(shí)間尺度看，有恒定的頻率嗎？例如，你的數(shù)據(jù)主要是以幾秒鐘為周期的分段常數(shù)，而這些周期的長度相同，那你可能需要考慮粗粒化時(shí)間尺度，丟掉小尺度內(nèi)的冗余信息。

　　·假如出現(xiàn)另一種情況，常數(shù)的長度變化太快，事件隨機(jī)發(fā)生，那你最好還是選擇用bucket模式。

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

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

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

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

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

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

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

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