PM2.5云监测平台方案

1、. . . . PM2.5云监测平台方案目录目录2PM2.5 云监测平台方案41.概述41.1背景41.2平台设计原则41.3平台系统意义62.PM2.5云监测平台总体设计72.1系统主要功能72.2技术优势82.3技术方案92.3.1 平台架构92.3.2 技术路线103 可超大规模部署的PM2.5云监测节点设计123.1 PM2.5云监测节点系统架构123.2 PM2.5云监测节点传感器133.2.1 PM2.5采集方法133.2.2 PM2.5传感器143.3 PM2.5云监测节点主控板173.3.1 主控板173.3.2 计算部分183.3.3 通信部分203.4 PM2.5云监测节点

2、的供电213.4.1太阳能供电213.4.2 市电供电223.5 PM2.5云监测节点的结构和安装部署223.5.1 PM2.5云监测节点的结构223.5.2 PM2.5云监测节点的安装部署233.5.2.1 立柱安装方式243.5.2.2 墙壁安装方式264 PM2.5云监测云平台设计284.1 PM2.5云监测云平台总体架构284.2 PM2.5云监测云平台优势和特点294.3 PM2.5云监测云平台组成架构304.3.1PM2.5监测平台304.3.2PM2.5预警平台314.4.3 PM2.5污染传播过程实时演化与污染源追踪314.4.4 PM2.5云监测云平台云存储324.4.4 P

3、M2.5云监测云平台Jobkeeper系统364.4.5 PM2.5云监测云平台分布式数据立方系统384.4.3 PM2.5云监测平台数据个性化服务485 PM2.5云监测平台优势特点505.1超大规模部署505.2 在线监测实时性强505.3 基于云平台的超强扩容性505.4 PM2.5数据的高准确性505.5 云计算海量数据处理515.6平台科学管理515.7实时数据推送516 PM2.5云监测平台的意义516.1 历史数据的实时查询526.2 PM2.5污染源溯源526.3 PM2.5污染预报526.4 污染预警527 成功案例537.1 537.2 537.3 联想531.概述1.1背

4、景目前许多城市的空气质量监测站较少，目前空气污染已经严重危害人民生活健康。城市雾霾天气正是空气污染的典型表现，造成雾霾的主要原因是PM2.5的严重污染。云创存储的PM2.5云监测平台通过超大规模部署PM2.5监测节点对环境进行实时监测，通过云计算（数据立方）分析处理大规模的PM2.5监测的数据，利用PM2.5监测和预警系统可以做到与时的污染预警，并且通过，APP等数据推送方式进行空气污染自动报警，与时做好污染防护，最大程度降低破坏空气环境的损害。通过海量历史数据智能分析，能够演化到PM2.5的污染过程，并且追溯污染源头，进而解决PM2.5污染源头，有效抑制污染源，保护空气环境。1.2平台设计原

5、则针对实际情况,充分考虑空气环境监测云计算平台系统的建设发展需求，以实现系统统一管理、高效应用、平滑扩展为目标，以“先进、安全、成熟、开放、经济”为总体设计原则。1、先进性原则在系统总体方案设计时采用业界先进的云计算方案和技术，以确保一定时间不落后。选择实用性强产品，模块化结构设计，既可满足当前需要又可实现今后系统发展平滑扩展。2、安全性原则数据是业务系统核心应用的最终保障，不但要保证整套系统能够7*24h正常运行，在进行系统设计时，充分考虑数据高可靠存储，采用高度可靠的软硬件容错设计，进行有效的安全访问控制，实现故障屏蔽、自动冗余重建等智能化安全可靠措施，提供统一的系统管理和监控平台，进行有

6、效的故障定位、预警。3、成熟性原则为确保整个系统能够稳定工作，软件平台将使用先进、完善、易于管理和稳定可靠的云存储计算资源管理系统，对于与其他应用的集成接口，提供统一的通用稳定访问接口。4、开放性原则系统建设具有开放性的标准体系，提供开放的应用API编程接口，提供人性化的应用和管理界面，以满足用户需求。遵循规的通用接口标准，使全系统中的硬件、通信、软件、操作平台之间的互联共享。在系统不停止工作的情况下，可以更换单元备件。系统的维护和升级操作由系统管理员即可完成。5、经济性原则现有业务系统存储数据量较大，且数据的增长速度较快。因此在建设系统存储架构时，应从长远的角度考虑，建设一个长期的云存储架构

7、，除了可以应对存储硬件设备的升级速度外，还必须考虑到对前期存储设备的投资保护，在保证不断提供功能和性能提高的同时，存储架构在较长的时间能够保持相对稳定。结合先进的云平台技术架构优势，根据本次项目建设的实际容量需求设计，同时充分考虑应用发展需求，实现系统可弹性在线平滑升级。通过软件实现在较廉价普通服务器上实现高度容错，同时能够在较低冗余度的情况下实现高度可靠容错，大大节约和降低系统建设的硬件成本。1.3平台系统意义基于云计算架构的PM2.5云监测平台，超大规模部署廉价的PM2.5云监测节点，配合城市现有的环境监测站点，准确、与时、全面地反映环境质量现状与发展趋势，为环境管理、污染源控制、环境规划

8、等提供科学依据，并结合天气状况、城市交通、人口密度、工业产值等元素，进行系统的研究，为保护环境，改善城市的大气环境质量改善起到技术支撑作用。具体可归纳为: (1) 超大规模部署PM2.5云监测节点，改变传统的空气环境监测模式，使环境监测覆盖更密集。(2) PM2.5污染传播过程实时演化与污染源追踪。根据海量监测数据进行PM2.5污染传播过程实时演化，追踪寻找污染源，为实现监督管理、控制污染提供依据。 (3) 构建云计算海量数据处理平台，存储本区域海量数据，积累长期监测资料，为研究环境容量、实施总量控制、目标管理、预测预报环境质量提供数据。 (4) 基于云平台的PM2.5污染预警系统，反映小区域

9、的PM2.5的情况，可以快速反映污染，与时做好防护。(5) 为保护人类健康、保护环境、合理使用自然资源、制订环境法规、标准、规划等服务。2.PM2.5云监测平台总体设计2.1系统主要功能PM2.5云监测平台需要提供的主要功能描述如下。（1） 超大规模的PM2.5云监测节点的部署超大规模的PM2.5监测节点的部署，保证了PM2.5监测的大量的数据，能精确的获取PM2.5的详细信息。（2）实时数据入库系统实时数据入库系统主要负责全市所有PM2.5云监测节点产生数据实时存到PM2.5云监测平台数据存储中心。 （3）数据存储系统原始PM2.5数据，将全部存储在PM2.5云监测平台分布式文件系统，用于存

10、储海量的非结构化数据。为了满足和适应数据量、数据特征和查询处理的不同需求，部分存存储于关系型数据库中。（4）实时预警系统对PM2.5标准指标设置对应的域阀值，超过该值超过一分钟等就第一时通过，App推送，或者短信等形式通知行政执法人员，给管理部门迅速出动，与时阻止破坏环境保护的行为。（5）数据查询分析应用系统PM2.5数据查询分析应用提供包括实时监控空气PM2.5，查看历史记录和分析数据等功能。PM2.5历史查询处理时，由于PM2.5的超大规模的部署，造成数据量巨大，需要调度使用云计算技术管理多台服务器节点进行并行处理。（6）数据下载系统在实际使用中，可能用户会对某一时间段或者类型的数据特别关

11、心，就可以通过数据管理系统查询并导出这部分数据以供使用。（7）数据库系统设计在云计算平台中充分利用云计算系统与传统数据库结合方式建设，针对数据量比较小的用户信息等基础数据信息存放在传统数据库中，针对超大规模PM2.5云监测节点的实时量大，存放时间长，历史数据量大的PM2.5监控数据放在云架构数据库数据立方中，基础数据库做为云计算数据库的补充以与数据转换的接口，前期历史沉淀量大，服务器压力大的PM2.5监控数据可以按照规则迁移到云计算数据库中。2.2技术优势云计算架构的PM2.5云监测平台技术优势：1.支持数以万计PM2.5云监测节点同时上报数据能够接受每天千亿记录级的海量数据。2.原始数据实时

12、入库、生成索引能够对流量超过10000条/秒的全量原始监控数据流进行实时处理。3.数据管理规模达到十万亿记录级别云计算架构能够存储管理和处理十万亿记录级别的数据量，完成各种复杂业务应用计算和分析。4.秒级数据查询响应能力高效索引算法，智能化调度任务系统，满足秒级查询速度。5.实时业务处理与预警能力高效实时数据通道，对于系统中实时监控、告警等实时业务，提供秒级响应时间。2.3技术方案2.3.1 平台架构通过超大规模部署PM2.5云监测节点，针对PM2.5监测建立PM2.5云监测平台。PM2.5云监测节点检测到PM2.5的相关信息，通过GPRS进行无线数据传输，传输到云平台，在数据接受服务器上进行

13、数据接收、解析和预处理，将数据存入数据立方进行云存储和云计算，并且通过WEB服务器进行数据的最后处理和公布，通过web页面和移动终端可以实时的查看所有PM2.5云监测节点的PM2.5的实时情况和历史数据，以与PM2.5污染的演化过程。具体的系统总体架构详见下图1。图1 PM2.5云监测平台总体架构2.3.2 技术路线详细的技术线路图详见图2。图2 PM2.5云监测平台技术线路图3 可超大规模部署的PM2.5云监测节点设计3.1 PM2.5云监测节点系统架构PM2.5 云监测节点是由设备箱、传感器、主控板、电源和无线通信平台组成。传感器将采集到的电信号，通过线材传输给主控板，主控板进行信号解析、

14、算法分析和数据量化后，把数据通过无线通信方式(GPRS)传输到云平台。PM2.5云监测节点可以大规模部署，每个节点均可以将采集到的数据传输到云平台进行处理。具体的架构详见图3。图3 PM2.5云监控平台架构PM2.5云监测节点从功能上来说，是由电源模块、采集模块和通信模块组成，PM2.5云监测节点部架构具体详见图4。实际的PM2.5监测节点详见图5。图4PM2.5云监测节点的架构图5PM2.5云监测节点实物图3.2 PM2.5云监测节点传感器3.2.1 PM2.5采集方法虽然肉眼看不见空气中的颗粒物，但是颗粒物却能降低空气的能见度，使消失，天空变成灰蒙蒙的一片，这种天气就是灰霾天。根据2013

15、年灰霾试点监测报告，在灰霾天，PM2.5的浓度明显比平时高，PM2.5的浓度越高，能见度就越低。虽然空气中不同大小的颗粒物均能降低能见度，不过相比于粗颗粒物，更为细小的PM2.5降低能见度的能力更强。能见度的降低其本质上是可见光的传播受到阻碍。当颗粒物的直径和可见光的波长接近的时候，颗粒对光的散射消光能力最强。可见光的波长在0.4-0.7微米之间，而粒径在这个尺寸附近的颗粒物正是PM2.5的主要组成部分。理论计算的数据也清楚地表明这一点：粗颗粒的消光系数约为0.6平方米/克，而PM2.5的消光系数则要大得多，在1.25-10平方米/克之间，其中PM2.5的主要成分硫酸铵、硝酸铵和有机颗粒物的消

16、光系数都在3左右，是粗颗粒的5倍。所以，PM2.5是灰霾天能见度降低的主要原因。目前国外环保部门监测PM2.5普遍采用射线吸收和微量振荡天平等方法。除了以上两种自动测试方法外，还有利用光散射的原理测定颗粒物浓度的方法。该测定方法的原理是：空气中的颗粒物浓度越高，对光的散射就越强。测定光的散射后，就可以算出颗粒物浓度。该测试方式测定速度快，自动化程度高，操作简单。本次设备使用的是红外光散射法来进行测试相关的数据。通过相关的探头来进行采集相关的数据。通过采集的通道利用红外光散射来进行获取颗粒浓度。采集空气的通道有固定的加热源，通过加热源来进行空间的动态的采集。将相关的颗粒浓度转换成相关的数据通过无

17、线通信进行数据传输。3.2.2 PM2.5传感器PM2.5传感器实物图详见图6。图6 PM2.5传感器1、传感器规格 尺寸：（长）59mm×（宽）45mm×（高）22mm； 重量：24g； 正常工作电压：DC 5V±10% （CN1:Pin1=GND Pin3=±5V） 脉冲电压 30mV以下； 正常工作电流：90mA； 检测粒子直径：1m以上； 检测围：30立方米； 输出方式：脉冲电压 周期30秒 最高值4.5V 最低值0.7V； 启动时间：电源接通后 约1分钟（电阻温度稳定时间）；2、传感器的特点PWM脉宽调制输出；采用粒子计数原理；可灵敏检测直径1

18、微米以上的粒子；置加热器可实现自动吸入空气；小尺寸重量轻；易安装使用。3、 传感器的原理传感器的原理结构图详见图7.图7 传感器的原理结构图模块置一个加热器，热引起上升气流使外部空气流进模块部。空气通过检测通道，利用光的原理、通过光和透镜以与处理模块来进行检测。具体的检测方法和通道如图8所示。图8 传感器的检测另外，传感器的透镜需要视环境状况隔一段时间进行清洁，约 6 个月一次。清洁时用棉签一头醮清水轻擦，然后用另一头擦干。不可以用酒精等有机溶剂擦拭透镜。3.3 PM2.5云监测节点主控板3.3.1 主控板图9 PM2.5云监测节点主控板PM2.5云监测节点主控板主要是用来采集PM2.5传感器

19、的信号，进行信号解析、算法分析和数据量化，将PM2.5的数据发送到云平台上。PM2.5云监测主控板详见图9。1、利用PWM波进行对PM2.5采样，计算；2、通过GPRS无线发送数据到云平台；3、输入电源是12V直流电源；4、使用温度围：-2570；3.3.2 计算部分通过传感器的检测颗粒，输出相关的PWM波，低电平的波形width是10ms-90ms，利用这个PWM波形来进行获取相关的参数，详见图10。通过获取低电平的占空比，从而通过图11获取到对应的数值。图10传感器的采样图11 传感器采样的曲线图通过如下的计算，可以得到其中一个通道的采样值。通道的LOW Pluse的占空比设定为L，测试的

20、采样值为P。则：如果获取到的L < 0.08，则：P=0.1*L*100*10(ug/m3);如果获取到的0.08=< L <0.15，则：P=( (L*1008)/6.5 + 0.8)*10( ug/m3);通过相关的采样，可以采样得到传感器的两个通道的值，一个通道是1um以上的粒子的值P1，另外一个通道是可以进行设置的，这里设置为可以检测2.5以上的粒子的值P2。PM2.5是指大气中直径小于或等于2.5微米的颗粒物，也称为可入肺颗粒物（暂无标准中文名）。所以在这里要计算最终的采样值PL，需要进行如下的计算：PL = P1 - P2;这里就可以计算出大气中直径小于或等于2.

21、5微米的颗粒物。3.3.3 通信部分PM2.5云监测节点的通信主要是通过GPRS进行数据的无线传输。具体的数据传输的网络示意图详见图12。图12 GPRS数据传输PM2.5云监测节点将才采集的数据通过TCP/IP协议的封包，利用GPRS通过移动基站进行无线传输，数据进入Internet网络后，在云平台上把数据在服务器上提取出来，解析后将数据入库，进行数据的处理，最后通过WEB服务器或者APP等方式将数据展现出来。注意:每个PM2.5云监测节点必须有运营商的SIM卡进行数据通信，该SIM卡需要有GPRS业务，同时使用的地点必须有运营商的信号。例如使用中国移动的SIM卡，该卡需要有GPRS的业务，

22、同时放置PM2.5云监测节点的地点需要有中国移动的信号才可以正常的通信。3.4 PM2.5云监测节点的供电供电方式有两种，一种是太阳能供电方式，一种是市电供电方式。示意图详见图13。图13 PM2.5云监测节点供电方式3.4.1太阳能供电太阳能供电方式是基于太阳能进行可持续性的充电，从而避免了提供充电或者接入市电的情况。太阳能供电是利用太阳能储能电池和太阳能电池通过太阳能控制器进行有效的电源输出方式进行供电。太阳能储能电池有蓄电、供电的功能，太阳能电池主要是用来吸收光源进行产生电并且储存在太阳能储能电池。通过太阳能控制器，可以保护太阳能储能电池。利用两块40W的太阳能电池和一个封装在地埋箱的8

23、0Ah的太阳能储能电池，可以在一定的环境中，可以满足设备的供电要求。太阳能储能电池的规格是12V电压，80Ah的规格，在完全没有太阳能的情况下，可以支持10*24h的无间断供电。具体的实物详见图14。图14 太阳能供电方式3.4.2 市电供电在PM2.5部署的主要的区域，可以利用市电直接接入PM2.5云监测节点，通过220V交流电输入供电。3.5 PM2.5云监测节点的结构和安装部署3.5.1 PM2.5云监测节点的结构PM2.5云监测节点的设备箱体大小为300*400*150。具体详见图15。图15 PM2.5云监测节点箱体结构3.5.2 PM2.5云监测节点的安装部署在城市的不同区域部署P

24、M2.5云监测节点，并且有效使用PM2.5云监测平台，能够比较全面地掌握城市不同区域，在不同时间段、不同气候特点（包括气温、风向、季节）下的 PM2.5 的实时监测数据。目前环境监测站的监测设备一般部署在离地面高度20m-25m之间，而云创存储的PM2.5环境监测系统环境监测设备根据实际的情况来进行部署。设备小巧，部署方式灵活，可以部署在立杆上或者是墙壁上等公共设施上。详细见图16。图16 PM2.5云监测节点部署方式3.5.2.1 立柱安装方式PM2.5云监测节点立柱安装方式图详见图17和图18。图17 PM2.5立柱安装方式正面图太阳能电池板PM2.5设备箱蓄电池地埋箱图18 PM2.5立

25、柱安装方式背面图M10固定螺栓太阳能板支架半圆型抱箍注：抱箍大小需根据安装立柱的直径调整。3.5.2.2 墙壁安装方式PM2.5云监测节点墙壁安装方式图详见图19和图20。图19 PM2.5墙壁安装方式正面图太阳能电池板挂壁板PM2.5设备箱蓄电池地埋箱图20 PM2.5立柱安装方式侧面图太阳能板支架M10膨胀螺栓4 PM2.5云监测云平台设计4.1 PM2.5云监测云平台总体架构PM2.5云监测云平台总体架构详见图30。 图30系统总体物理架构图通过超大规模部署PM2.5云监测节点，针对PM2.5监测建立PM2.5云监测平台。PM2.5云监测节点检测到PM2.5的相关信息，通过GPRS进行无

26、线数据传输，传输到云平台，在数据接受服务器上进行数据接收、解析和预处理，将数据存入数据立方进行云存储和云计算，并且通过WEB服务器进行数据的最后处理和公布，通过web页面和移动终端可以实时的查看所有PM2.5云监测节点的PM2.5的实时情况和历史数据，以与PM2.5污染的演化过程，为客户科学分析环境污染趋势，为决策制和行政执法人员最好环境保护的信息化技术支持工作。4.2 PM2.5云监测云平台优势和特点1、优异性能云存储采用控制流与数据流分离的技术，数据的存储或读取实际上是与各个存储节点上并行读写，这样随着存储节点数目的增多，整个系统的吞吐量和IO性能将呈线性增长。同时，云存储采用负载均衡技术

27、，自动均衡各服务器负载，使得各存储节点的性能调节到最高，实现资源优化配置。2、无限容量可以出来海量的环境监测数据，可支撑的容量接近无限，经推算，理论容量为1024×1024×1024 PB (1G个PB容量)。3、在线伸缩云存储资源管理系统扩容非常方便，支持不停止服务的情况下，动态加入新的存储节点，无需任何操作，即实现扩容；同时，无需人为干预，也可以摘下任意节点，系统自动缩小规模而不丢失数据，存储在此节点上的数据将会重新备份到其他节点上。4、通用易用云存储系统提供专用的API接口，供开发人员调用。5、智能管理提供基于WEB的管理控制平台，所有的管理工作均由数据立方一体机管理

28、模块自动完成，使用人员无需任何专业知识便可以轻松管理整个系统。通过管理平台，可以对数据立方中的所有节点实行实时监控，用户通过监控界面可以清楚地了解到每一个节点的负载、存储和运行情况。4.3 PM2.5云监测云平台组成架构本系统主要有PM2.5监测平台，PM2.5预警系统，云存储系统，PM2.5污染传播过程实时演化和污染源追踪，面向 Jobkeeper分布式调度，分布式数据立方系统和PM2.5数据个性化服务等组成。在本次云建设中，分布式文件系统属于基础平台支撑层，以用于数据集中存储和共享，实现对数据的统一管理和高效应用；分布式数据立方属于分布式数据库层，用于结构化和非结构化数据的高性能访问；分布

29、式计算和Hive则基于云存储进行大规模的高性能的并发计算和数据的挖掘。下面具体说明各系统的基本组成和主要功能。4.3.1PM2.5监测平台PM2.5监测与预警系统软件平台完全基于B/S结构设计，为管理人员提供完善的操作平台，同时，为其他普通人员定制基于B/S结构的浏览模块。系统通过权限访问，提高系统运行的安全性。系统可实时、准确、高效地监测PM2.5状况，并对数据整编入库、分析处理，形成结果，供决策人员使用。超大规模的部署PM2.5云监测节点，通过GPRS等方式传输到云平台后到达PM2.5监测平台，数据直接通过云计算技术的监测技术直接入库，作为PM2.5数据直接存放起来，为以后环境质量数据，以

30、与后期环境质量的趋势分析做详实准确的数据基础。主要包括PM2.5数据入库模块，PM2.5数据分析模块，海量数据分析模块，同时结合地理信息针对环境污染位置明确责任，建立绩效考核机制最大围提高环境执法人员的工作能动性。4.3.2PM2.5预警平台作为PM2.5监测平台的有效补充，PM2.5预警平台承担着更多实时执法提供更多与时的有效的信息化支持。预警系统的运行是根据PM2.5监测数据与数据处理平台形成的结果，当数据达到设定报警值时，预警系统会自动启动，决定预警级别与围。并根据系统设定，启动报警通过，APP推送或者是短信等方式直接发送给相关人员。PM2.5预警平台WEB页面详见图31。该图只能静态展

31、示相关的页面，动态的效果需要实时演示。图31 PM2.5预警平台静态图4.4.3 PM2.5污染传播过程实时演化与污染源追踪基于数据立方的云平台，可以完全进行海量历史数据分析，从而可以根据实时的海量数据推演PM2.5污染传播过程，进行PM2.5污染过程演化。超大规模部署PM2.5云监测节点，可以完全从大面积围和局部区域定位PM2.5污染源的扩散点，进行定位PM2.5污染源，从监测污染、定位污染到找到污染原因并且治理污染。形成一整套的PM2.5监测和治理方案。PM2.5污染传播过程实时演化详见图32。图32 PM2.5污染传播过程实时演化4.4.4 PM2.5云监测云平台云存储分布式文件系统被设

32、计为将海量文件存储在一个大集群的多台计算机上。分布式文件系统将每一个文件以分块序列的形式进行存储，一个文件的所有分块除去最后一个分块外都是等大小的。为了实现容错将文件分块进行自动复制。文件分块的块大小和复制比例都是可以按照单个文件进行配置的。分布式文件系统中的所有文件都是“只写一次”并且严格限定在任何时候只有一个写文件操作者。 分布式文件系统是云计算框架的分布式并行文件系统，是分布式计算的存储基石。负责数据分布式存储与数据的管理，并能提供高吞吐量的数据访问。分布式文件系统的基本特征如下：(l)对于整个集群有单一的命名空间。(2)文件会被分割成多个文件块，每个文件块被分配存储到数据节点上，而且根

33、据配置会有复制的文件块来保证数据安全性。(3)数据一致性。适合一次写入多次读取的模型，客户端在成功创建文件之后，才能看到文件的存在。(4)云计算，包括分布式文件系统，非常适合在廉价机器上的分布式存储和分布式处理。它是容错的、可伸缩的、非常易于扩展。并且，以简单性和适用性著称的分布式计算是云计算不可缺少的重要组成部分。(5)分布式文件系统的默认配置适合于大多数安装的应用。通常情况下，只有在一个非常大规模的集群上才需要修改默认配置。(6)支持shell命令行风格的分布式文件系统目录交互。(7)分布式文件系统是用java编写的，可广泛运行在多种软硬件平台上。(8)分布式文件系统经常性地实现新的特性和

34、改进。(9)Namenode和DataNode都建了Web服务器，可以方便地查看集群的状态。 分布式文件系统的体系框架是Master/Slave结构，一个典型的分布式文件系统通常由单个Namenode和多个DataNode组成。Namenode是一个中心服务器，负责文件系统的名字空间的操作，比如打开、关闭、重命名文件或目录，它负责维护文件路径到数据块的映射，数据块到DataNode的映射，以与监控DataNode的心跳和维护数据块副本的个数。集群中的DataNode一般是一个节点一个，负责管理它所在节点上的存储。分布式文件系统暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从部看

35、，一个文件其实被分成一个或多个数据块，这些块存储在一组DataNode上。DataNode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。 所有对目录树的更新和文件名和数据块关系的修改，都必须能够持久化，文件在分布式文件系统中存储图如图33。图33 分布式文件系统结构图分布式文件系统涉与到Namenode、DataNode和客户端们之间的交互。本质上，客户端与Namenode通讯是通过获取或者修改文件的元数据，与 DataNode进行实际的I/O操作。如图13所示，在分布式文件系统中有三个重要的角色：Namenode、DataNode和Client

36、，其中Client就是需要获取分布式文件系统文件的应用程序。这里通过三个操作来说明他们之间的交互关系：(l)文件写入。首先Client向Namenode发起文件写入的请求，Namenode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。(2)文件读取。Client向Namenode发起文件读取的请求，Namenode返回文件存储的DataNode的信息。Client根据返回的信息读取DataNode上的文件信息。(3)文件Block复制。Namen

37、ode发现部分文件的Block不符合最小复制数或者部分DataNode失效，通知DataNode相互复制Block。DataNode收到通知后开始直接相互复制。图34 Namenode、DataNode和client之间的交互4.4.4 PM2.5云监测云平台Jobkeeper系统Jobkeeper的系统架构如下图35所示。图35 Jobkeeper的系统架构虚拟化资源层：将机器进行虚拟化，形成更大围的服务集群。存储层：存储数据的处理结果集或其他中间结果集的单元。数据处理层：独立的数据处理程序，是对不同需求数据的统一处理方案，由JobKeeper调度平台进行统一的配置管理。业务层：对于应用层的

38、相关功能的业务化，数字化处理，用于将应用层的需求任务进行规则化划分，形成统一的处理化模式。应用层：一组用于管理和结果反馈的显示组件。是整个系统面向用户和开发人员的基础承载。JobKeeper的任务分发流程如下图36所示。图36 JobKeeper任务分发流程图当用户在应用层下发任务给管理节点，管理节点调度机器采集机器节点的信息，根据具体的算法选取最优节点并分发任务，接下来具体的处理节点接收到任务并处理同时将结果返回给管理节点，管理节点整理汇总处理结果，而后返回给应用层。服务器节点组：负责对处理节点的系统信息以与任务处理信息进行实时的跟踪和保存，对应的信息镜像存储在基于cStor或者NFS服务的

39、存储系统上。处理节点组：通过RPC的远程调用获取各自节点的任务处理目标，并实时的和处理节点上的任务处理目标进行对比，控制程序的执行和结束。处理节点组会在一个设定的心跳间隔主动的和管理节点组联系一次，报告节点存活状态。4.4.5 PM2.5云监测云平台分布式数据立方系统分布式数据立方，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用分布式数据立方技术可在廉价PC Server上搭建起大规模结构化存储集群。其目的是处理庞大的表，可以用普通的计算机处理10亿行数据，并且有数百万列元素组成的数据表这表的索引是行关键字。分布式数据立方可以直接使用本地的文件系统和云计算作为数据存储方式，不过为

40、了提高数据的可靠性和系统的健壮性，发挥分布式数据立方处理大数据量等功能，需要使用云计算作为文件系统。1、数据模式 分布式数据立方类似Bigtable的分布式数据库，是一个稀疏的，长期存储的，多维的，排序的映射表.这表的索引是行关键字，列关键字和时间戳。每个值是一个不解释的字符数组，数据都是字符串，没类型。用户在表格中存储数据，每一行都是一个可排序的主键和任意多的列。由于是稀疏存储的，所以同一表里面的每一行数据都可以有截然不同的列。列名字的格式是"<family>:<lable>",都是由字符串组成，每一表有一个family集合，这个集合是固定不变的，

41、相当于表的结构，只能通过改变表的结构来改变。但是lable值相对于每一行来说都是可以改变的。分布式数据立方把同一个family里面的数据存储在同一个目录底下，而分布式数据立方的写操作时锁行的，每一个都是一个原子元素都可以加锁。所有数据库的更新都是一个时间戳标记，每个更新都是一个新的版本，而分布式数据立方会保留一定数量的版本，这个值是可以设定的。客户端可以获取距离某个时间最近的版本，或者一次获取所有版本。2、 概念视图RowKeycolumn-family1column-family2column-family3column1column2column1column2column3column1

42、key1t1:abct4:dfadst2:gdxdft3:hellot2:worldkey2t3:abct4:dfadst2:dfdsfat1:gdxdft3:hellot3:dfdfkey3t2:dfadfasdt2:dfxxdfasd t1:dfdasddsft1:taobao. 分布式数据立方以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family).1)Row Key与nosql数据库们一样,row key是用来检索记录的主键。访问分布式数据立方 table中的行，只有三种方式：A)通过单个row key访问；B)通过row key的range；C)全表扫描Row

43、key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在分布式数据立方部，row key保存为字节数组。2)列族分布式数据立方表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history，courses:math 都属于courses 这个列族。3)时间戳分布式数据立方过row和columns确定的为一个存贮单元称为cell。每个 cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由分布式数据

44、立方(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。4)Cell由row key, column(=<family> + <label>), version 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。3、 物理存储1)Table中的所有行都按照row key的字典序排列。详见图372)Table 在行的方向上分割为多Hregion。详见图37图37 Table的

45、示意图3)region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。详见图38。图38 多个Table示意图4)Hregion是分布式数据立方中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。图39 Hregion5)HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。事实上，HRegio

46、n由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。如图40StoreFile以HFile格式保存在分布式文件系统上。图40 StoreFile以HFile格式保存在分布式文件系统上HFile的格式详见图41。图41 HFile的格式Trailer部分的格式详见图42。图42 Trailer部分的格式HFile分为六个部分：Data Block 段保存表中的数据，这部分可以被压缩Meta Block 段 (可选的)保存用户自定义的kv对，可以被压缩。File Info 段Hfile的元信息

47、，不被压缩，用户也可以在这一部分添加自己的元信息。Data Block Index 段Data Block的索引。每条索引的key是被索引的block的第一条记录的key。Meta Block Index段 (可选的)Meta Block的索引。Trailer这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从存中找到key所在的block，通过一次磁盘io将整

48、个block读取到存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。目标Hfile的压缩支持两种方式：Gzip，Lzo。HLog(WAL log)WAL 意为Write ahead log，类似mysql中的binlog,用来做灾难恢复只用，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。每个Region Server维护一个Hlog,而不是每个Region一个。这样不同region

49、(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。HLog文件就是一个普通的云计算 Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，

50、timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。HLog Sequece File的Value是分布式数据立方的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。图43 分布式数据图44 分布式存储Client1)包含访问分布式数据立方的接口，client维护着一些cache来加快对分布式数据立方的访问，比如regione的位置信息。ZookeeperA)保证任何时候，集群中只有一个masterB)存贮所有Region的寻址入口C)实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Maste