DIY“物联网物联网”——自己动手处理传感器数据自己动手处理传感器数据
摘要:传感器已经在航空、电力等行业得到大量的部署应用,而物联网的构建需要基于传感器的大量部署和应用,日
前,本文作者DIY了一个办公室“物联网”,模拟了现实生产中传感器应用,我们不妨学习一下。
【编者按】传感器已经大量部署于实际生产中,涉及航空、电力、医疗、教育各个行业的传感器形成大规模的工业物
联网,各式各样的传感器产生了大量的数据,如何去分析这些数据,作者用Raspberry Pi和四个Tinkerforge传感器DIY
了一个办公室“物联网”,模拟了现实生产中传感器应用,为我们带来了一些有益的借鉴,下面是作者的精彩分析。
以下为译文:
当前的一个客户项目和一般工业大数据项目的有趣性质(数据产生于传感器)给了我启发,我决定自己动手处理传感
器数据,我想通过这个小实验,了解具体如何处理、存储和分析这些数据,以及在这一过程中会遇到哪些挑战?
为了获取传感器数据,我们决定把传感器安装到我们的办公室里,生成我们自己的传感器数据,我们发现Tinkerforge
的bricks和bricklets系统非常友好,易于上手,于是我们选择采用Tinkerforge系统。
我们得到了以下四个传感器bricklet:
1.声音强度传感器(实际上是个小麦克风)
2.温度传感器
3.多点触摸bricklet(12个自制的可连接铝箔垫)
4.运动探测器
四个bricklet都连接到主bricklet上,然后将主bricklet连接到Raspberry Pi。
我们把温度传感器放在办公室的中央,将运动探测器安装在厨房和浴室之间的走廊里,把声音强度传感器放在厨房门
边,而触摸传感器则放在咖啡机、冰箱门和厕所的门把上。
虽然这样的设备很难跟实际生产中的情形相比(而且为了获取足够多的数据,你需要等很长时间),在这次小小的实
验中,我们还是很快遇到了那些现实传感器应用过程中的一些关键问题。
我们选择了MongoDB作为存储解决方案,主要是因为我们的那个客户项目也使用了MongoDB。
四个传感器产生的数据可以分为两类:温度和声音强度传感器输出连续的数据流,运动探测器和多点触摸传感器往往
是由非固定频率的事件触发。
这就形成了MongoDB中两种不同的文档模式。对于第一类(流),我们使用MongoDB推荐的模式,实际上也是这种
情况下的最佳实践,即“时间序列模式”(见 http://blog.mongodb.org/post/65517193370/schema-design-for-time-
series-data-in-mongodb),由一个内部的嵌套文档集合组成。嵌套的层数和每个级别子文档的数量取决于数据的时间
粒度。在我们的实验中,Tinkerforge传感器的最高时间分辨率为100ms,产生了下面的文档结构:
1.每小时一篇文档
2.字段:小时时间戳、传感器类型、值
4.值:嵌套的子文档(subdocument)集,每分钟60个子文档(subdocument),每一秒60个子文档(subdoc),每
1/10秒10个子文档(subdoc)