昆山环保局空气质量检测平台云计算平台解决方案(49.docx

《昆山环保局空气质量检测平台云计算平台解决方案(49.docx》由会员分享，可在线阅读，更多相关《昆山环保局空气质量检测平台云计算平台解决方案(49.docx（47页珍藏版）》请在三一办公上搜索。

1、空气质量监测云计算平台解决方案修改记录日期版本修改要点修改者注释2013.05.061.0初始版本注：版本升级时，要注明原因，和主要的更改内容。目录目录3空气质量前端方案41概述41.1背景41.2意义42设计52.1 系统架构52.1.1总体架构52.1.2部署方式62.2 传感器72.3 计算92.4 采集部分102.5 通信部分112.6 电源部分122.6.1锂电池供电122.6.2太阳能供电133特点13空气质量检测平台方案1概述南京云创存储的空气质量监测方案，是基于云计算的大气质量监测平台，前端通过特征因子监测设备和空气质量两套监测设备可以监测大气污染中的空气质量,pm10, SO

2、2,NO2等大气中污染因子。通过海量数据的科学数据分析对比得到主要的反映局部区域的相关参考值，从而和宏观上反映城市的整体的空气质量的监测站点的监测方式形成互补。1.1背景目前许多城市的环境监测中心站点较少，分布分散，环境监测的数据仅从宏观上反映城市的整体的空气质量，但是不能从微观上反映局部区域、特定区域的空气质量的好坏，这就需要建设更多的环境监测站点，提供更多的实时的环境监测数据。国外一套空气质量环境监测仪器价格在10万美金，国产价格在10万人民币，价格昂贵。建设更多的环境监测站点需要巨大的资金投入，成本太高。而廉价的空气质量环境监测系统价格大约在1万人民币，能够解决资金投入问题，同时满足一定

3、的测量精度，和现有的空气环境自动监测系统形成互补，为环保部门服务。目前350米以下都有颗粒污染物，污染程度比较严重，加之信息化工作处于低端水平，以及公众对于空气质量的关注度不断提升，使得空气质量的监测重要性日益突出。廉价的空气质量环境监测系统与目前的传统监测站点的监测方式形成互补，满足公众环境需求，提升政府形象。1.2意义部署空气质量环境监测系统，配合城市现有的环境监测站点，准确、及时、全面地反映环境质量现状及发展趋势，为环境管理、污染源控制、环境规划等提供科学依据，并结合天气状况、城市交通、人口密度、工业产值等元素，进行系统的研究，为保护环境，改善城市的大气环境质量改善起到技术支撑作用。具体

4、可归纳为: (1) 根据环境质量标准，评价环境质量。(2) 根据污染分布情况，追踪寻找污染源，为实现监督管理、控制污染提供依据。(3) 构建云计算海量数据处理平台，存储本区域海量数据，积累长期监测资料，为研究环境容量、实施总量控制、目标管理、预测预报环境质量提供数据。(4) 为保护人类健康、保护环境、合理使用自然资源、制订环境法规、标准、规划等服务。1.3总体设计原则针对本次工程的实际情况,充分考虑环保局环境监测云平台系统建设的建设发展需求，以实现系统统一管理、高效应用、平滑扩展为目标，以“先进、安全、成熟、开放、经济”为总体设计原则。先进性原则在系统总体方案设计时采用业界先进的方案和技术，以

5、确保一定时间内不落后。选择实用性强产品，模块化结构设计，既可满足当前的需要又可实现今后系统发展平滑扩展。安全性原则数据是业务系统核心应用的最终保障，不但要保证整套系统能够7X24运行，而且存储系统必须有高可用性，以保证应用系统对数据的随时存取。同时配置安全的备份系统，对应用数据进行更加安全的数据保护，降低人为操作失误或病毒袭击给系统造成的数据丢失。在进行系统设计时，充分考虑数据高可靠存储，采用高度可靠的软硬件容错设计，进行有效的安全访问控制，实现故障屏蔽、自动冗余重建等智能化安全可靠措施，提供统一的系统管理和监控平台，进行有效的故障定位、预警。成熟性原则为确保整个系统能够稳定工作，软件平台将使

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

7、还必须考虑到对前期存储设备的投资保护，在保证不断提供功能和性能提高的同时，存储架构在较长的时间内能够保持相对稳定。结合先进的云平台技术架构优势，根据本次项目建设的实际容量需求设计，同时充分考虑应用发展需求，实现系统可弹性在线平滑升级。通过软件实现在较廉价普通服务器上实现高度容错，同时能够在较低冗余度的情况下实现高度可靠容错，大大节约和降低系统建设的硬件成本。1.4系统特点1、价格低廉，大规模部署空气质量环境监测设备只有国际通用的几分之一，即可满足空气质量监测、数据传输功能，无需国外昂贵的监测设备，和现有的环境监测点形成有利互补，对空气质量数据发布有参考意义。2、云计算海量数据处理技术架构云计算

8、海量数据处理平台，采用先进的云计算处理技术，对环境监测的数据入库和关联查询快速响应，支持自动容错和动态扩展，具有实时性、高可靠性、可伸缩性、高性价比等特点。3.扩容性空气质量监测前端设备可以根据需求进行增加设备，扩展整个系统的覆盖面积，但是不需要继续复杂的操作，可以动态的增加空气质量测试的节点，并能自动组网，具有很强的扩容性。4.实时性测定速度快，自动化程度高。测试方法决定了测试的实时性，采集时间实现秒级响应，且采集时间可以任意设定，采集的数据实时入库，可实时查询。5.采集数据的准确性采集的数据经过精确的校准，且灵敏度很高，和环保部分发布的空气质量数据及趋势接近，数据真实有效。2系统设计2.1

9、总体架构前端设备采集到相关的信息，通过GPRS进行无线数据传输，在有公网IP的服务器上进行数据接收和初步的处理，然后数据存入数据立方进行存储和计算，并且通过WEB服务器进行数据的最后处理和公布，通过web页面和移动终端可以实时的查看pm25实时和历史数据。具体的系统总体架构详见下图。图1空气质量云监控平台总体架构2.2系统主要功能空气质量监测云平台需要提供的主要功能描述如下。（1）实时数据入库系统实时数据入库系统主要负责全市所有空气质量监测点产生的各类空气因子数据实时存到空气质量监测平台数据存储中心。（2）空气质量监测平台数据存储系统原始空气质量数据，将全部存储在空气质量监测平台分布式文件系统

10、，用于存储海量的非结构化数据。为了满足和适应数据量、数据特征和查询处理的不同需求，部分存存储于关系型数据库中。（3）空气质量监测平台数据查询分析应用系统空气质量数据查询分析应用提供包括实时监控空气质量空气质量，查看历史记录和分析数据等功能。空气质量历史查询处理时，由于空气质量数据量巨大，需要调度使用多台服务器节点进行并行处理。（4）数据管理系统在实际使用中，可能用户会对某一时间段或者类型的数据特别关心，就可以通过数据管理系统查询并导出这部分数据以供使用。2.3技术优势1.无线传感网络节点问间可进行长距离的传输，国內最多50m,Corssbow 为150m. 而我们在节点间无阻挡时理论距离为30

11、000m, 有阻挡为5001000m, 具有极高的性价比. 2.能耗低，国外同类产品发射电流消耗为20mA, 我们可达仅为0.5mA;3.节点数多，囯外一般150个, 我们可以256个, 还可扩充至1000个以上.4.系统精度高，比同类产品高一个数量級；5.安全系数高，由于我们提供了数据完整性的检查和鉴权功能，加密算法采用了AES-128”,即具有高度的保密性。6.系统可靠性高，由于我们采用了碰撞避免机制，同时为需要固定带宽的通讯业务与留了专业时隙，避免了发射数据时的竞争和冲突，而且节点模块之间具有自动动态组网的功能，信息在整个网络中通过自由路由的方式进行传输，从而保证了信息的可靠性；7.系统

12、时延短，我们针对时延敏感的运用做了优化，通讯时延和从休眠状态激活的时延非常短。2.4技术方案1.监视和记录传感器的测试数据系统记录下所有不同传感器的测试数据并保留在系统的服务器的数据库中。服务器自带网站服务。可以以网页的形式提供监视结果。2.实时的数据传达和报警单个的传感器的数据可用来设成触发点来触发手机短信的发送，email的发送。3.随插随用的传感器和结点每一个在网络中的结点可以插入多个不同种类的传感器，只要传感器的接口是标准的ESB (Environmental Sensor Bus) ，无需任何改动，插入即可使用。4.网络的可扩张性只要加结点，网络就扩张。结点间的结网是自动的。结点间距

13、在2 公里内，就可以互相通讯。5.太阳能电池的应用和电源每个结点上都可以加上太阳能电池，配合内置的长寿可充电镍氢电池。在无太阳能充电的极端环境下，结点还能保持三个月以上的正常工作周期。在环境允许下，每个结点另可外接电源。6.系统软件的高可靠性和大规模高速处理能力海量的传感信号数据通过网络送到数据服务器的数据库。处理系统，存储分析系统及显示服务系统的软件做相应的工作以满足用户需求。3.前端采集设备3.1前端架构设计空气质量前端设备主要是由电源模块、采集模块和通信模块三大模块组成，前端采集设备内部架构具体详见图实际的空气质量监测设备详见图2。图2 前端设备的架构3.2主要模块和功能3.2.1传感器

14、我们将按其节点向所传输的距离，采用美国最新研制的微处理器及采用 Zigbee 等技术做无线传输，并将最新的系统集成技术，应用软件和网络传输，射频技术和底层软硬件控制技术相结和通过该特征因子传感器可以监测大气中的环境监测的特征因子：（1）硫化氢气体传感器检测范围0100ppm最大测量限150ppm灵敏度0.500.10uA/ppm使用温度范围20+50使用压力范围标准大气压10响应时间（T90）30S湿度范围1590RH无凝结零点漂移（20+40）0.2ppm（2）氨气NH3传感器标准工作条件 10ppm-100ppm NH3加热功耗小于900毫瓦使用温度-20-50储存温度-20-70RH 相

15、对湿度小于95% RH标准工作条件温度： 202 Vc:5V0.1 V相对湿度： 65%5% Vh: 5V0.1 V（3）有机溶剂气体传感器适宜于醇类、酮类、醛类、芳族化合物等有机溶剂的探测。加热功耗小于900毫瓦使用温度-20-50储存温度-20-70相对湿度小于95% RH探测范围：1ppm-100ppm 苯10ppm-100ppm甲苯5ppm-100ppm甲醇30ppm-300ppm酒精10ppm-300ppm丙酮1ppm-10ppm甲醛注：此传感器只测混和气体浓度。不分别给出各组份的含量。（4）可燃气体传感器用于液化气，天然气，煤气的监测。优良的抗乙醇，烟雾干扰能力。加热功耗900mW

16、使用温度-10-50储存温度-20-70相对湿度小于95%Rh探测范围：300-5000ppm 液化气，天然气，煤气。标准工作温度： 202 Vc:5.0V0.1V标准工作相对湿度： 65%5% Vh: 5.0V0.1V注：此传感器只测混和气体浓度。不分别给出各组份的含量。3.2.2前端数据转换通过传感器的检测颗粒，输出相关的PWM波，低电平的波形width是10ms-90ms，利用这个PWM波形来进行获取相关的参数，详见图8。通过获取低电平的占空比，从而通过图9获取到对应的数值。图8传感器的采样图9传感器采样的曲线图通过如下的计算，可以得到其中一个通道的采样值。通道的LOW Pluse的占空

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

18、颗粒物。3.2.3采集部分虽然肉眼看不见空气中的颗粒物，但是颗粒物却能降低空气的能见度，使蓝天消失，天空变成灰蒙蒙的一片，这种天气就是灰霾天。根据2010年灰霾试点监测报告，在灰霾天，空气质量的浓度明显比平时高，空气质量的浓度越高，能见度就越低。虽然空气中不同大小的颗粒物均能降低能见度，不过相比于粗颗粒物，更为细小的空气质量降低能见度的能力更强。能见度的降低其本质上是可见光的传播受到阻碍。当颗粒物的直径和可见光的波长接近的时候，颗粒对光的散射消光能力最强。可见光的波长在0.4-0.7微米之间，而粒径在这个尺寸附近的颗粒物正是空气质量的主要组成部分。理论计算的数据也清楚地表明这一点：粗颗粒的消光

19、系数约为0.6平方米/克，而空气质量的消光系数则要大得多，在1.25-10平方米/克之间，其中空气质量的主要成分硫酸铵、硝酸铵和有机颗粒物的消光系数都在3左右，是粗颗粒的5倍。所以，空气质量是灰霾天能见度降低的主要原因。目前国内外环保部门监测空气质量普遍采用滤膜称重、射线吸收和微量振荡天平等方法。除了以上三种测试方法外，还有利用光散射的原理测定颗粒物浓度的方法。该测定方法的原理是：空气中的颗粒物浓度越高，对光的散射就越强。测定光的散射后，就可以算出颗粒物浓度。该测试方式测定速度快，自动化程度高，操作简单。本次设备使用的是红外光散射法来进行测试相关的数据。通过相关的探头来进行采集相关的数据。通过

20、采集的通道利用红外光散射来进行获取颗粒浓度。采集空气的通道有固定的加热源，通过加热源来进行空间的动态的采集。将相关的颗粒浓度转换成相关的数据通过无线通信进行数据传输。3.2.4通信部分前端设备的通信主要是通过GPRS进行数据的无线传输。具体的数据传输的网络示意图详见图10。图10GPRS数据传输数据在前端设备基于TCP/IP协议，经过GPRS的数据传输，通过移动网络传输数据，利用公网的服务器接受数据，然后将数据入库后，进行数据的处理，最后通过WEB服务器将数据展现出来。注意:每个前端设备有一个供应商的SIM卡进行数据通信，该SIM卡需要有GPRS业务，同时使用的地点必须有供应商的信号。例如使用

21、中国移动的SIM卡，该卡需要有GPRS的业务，同时放置空气质量测试前端的地点需要有中国移动的信号才可以正常的通信。3.2.5电源部分供电方式有两种种，一种是锂电池和市电互补的供电方式，另一种是太阳能供电供电方式。3.2.5.2太阳能供电太阳能供电方式是基于太阳能进行可持续性的充电，从而避免了提供充电或者接入市电的情况。太阳能供电是利用蓄电池和太阳能互补的方式进行供电，通过太阳能控制器来进行互补。在太阳能供电不能满足供电需求的时候，利用蓄电池进行供电。利用20W的太阳能板，在一定的环境中，可以满足设备的供电要求。蓄电池的规格是12V电压，20Ah的规格，在完全没有太阳能的情况下，可以支持3*24

22、h的无间断供电。该供电方式同时提供电压监测功能。具体的实物详见图12。图12 太阳能供电方式的前端设备实物图3.2.5.1锂电池供电锂电池供电方式是基于市电可以提供的情况下进行的。如果部署的空气质量设备附近有市电，这样可以方便进行充电。或者是市电和锂电池进行互补方式进行供电。同时进行对电池进行电压监测，检测供电电压是否正常，电源供电是否正常。锂电池是12V电压，50Ah的规格，可以在没有充电或者没有市电互补的情况下持续10*24h的供电。具体的实物见图11。图11锂电池供电方式的前端设备实物图3.3部署安装方式在城市的不同区域布局并有效使用空气质量的监测系统，从而能够比较全面地掌握城市不同区域

23、，在不同时间段、不同气候特点（包括气温、风向、季节）下的空气质量的实时监测数据。空气质量环境监测系统环境数据采集设备采用先进的传感器、低功耗单片机技术和网络通讯技术相结合，可提供方便的数据查询方式，直接通过浏览器可以直接访问测试数据。目前环境监测站的监测设备一般部署在离地面高度20m-25m之间，而云创存储的空气质量环境监测系统环境监测设备根据实际的情况来进行部署。设备小巧，部署方式灵活，可以部署在电线杆等公共设施上。详细见图4。图4 部署在电线杆上前端设备4.后端云监测平台4.1项目需求针对本次环保局主要是监测大气中的环境数据，要做到实时性强，数据量大，还有总能做到海量历史数据挖掘的可扩展性

24、，监测数据主要存储结构化数据。建设适合存储容量数据平台，吞吐量需求为满足现在多个监测终端实时上传数据的需要和应用整体吞吐带宽和高并发需要，确保数据访问流畅，系统需提供多用户或应用高并发访问、高吞吐带宽设计，系统能够有效利用各机器的物理资源，性能可通过规模增加实现平滑增长。扩展性需求未来根据空气质量监测平台业务应用的变化和发展，需要快速实施系统资源的升级，可以在业务服务不间断的状态下平滑扩展，不会导致架构发生根本性变化，为不断产生和变化的业务需求提供持续的支持，支持业务系统的快速整合和部署对核心系统基础架构的特别要求。低成本需求要求系统能够以低硬件成本、低维护成本实现高可靠高性能应用要求，充分提

25、高资源利用率，简化管理，并能灵活、可持续扩展。可维护性需求要求系统具有自适应管理能力，安装、维护、升级简易方便，提供统一易用的WEB配置管理监控平台，实现智能化管理。接口需求要求能够提供通用的标准sql和编程接口，方便用户及应用系统访问，减少与应用集成或开发工作量，实现系统快速部署与集成。4.2系统总体设计系统平台总体架构图如下图所示通过前端采集设备采集的空气特征参数可以将4.3系统优势和特点优异性能云存储采用控制流与数据流分离的技术，数据的存储或读取实际上是与各个存储节点上并行读写，这样随着存储节点数目的增多，整个系统的吞吐量和IO性能将呈线性增长。同时，云存储采用负载均衡技术，自动均衡各服

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

27、个系统。通过管理平台，可以对数据立方中的所有节点实行实时监控，用户通过监控界面可以清楚地了解到每一个节点的负载、存储和运行情况。4.4系统组成架构在本次云建设中，分布式文件系统属于基础平台支撑层，以用于数据集中存储和共享，实现对数据的统一管理和高效应用；分布式数据立方属于分布式数据库层，用于结构化和非结构化数据的高性能访问；分布式计算和Hive则基于云存储进行大规模的高性能的并发计算和数据的挖掘。下面具体说明各系统的基本组成和主要功能。14.4.1存储层基本组成分布式文件系统分布式文件系统被设计为将海量文件存储在一个大集群的多台计算机上。分布式文件系统将每一个文件以分块序列的形式进行存储，一个

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

29、件之后，才能看到文件的存在。(4)云计算，包括分布式文件系统，非常适合在廉价机器上的分布式存储和分布式处理。它是容错的、可伸缩的、非常易于扩展。并且，以简单性和适用性著称的分布式计算是云计算不可缺少的重要组成部分。(5)分布式文件系统的默认配置适合于大多数安装的应用。通常情况下，只有在一个非常大规模的集群上才需要修改默认配置。(6)支持shell命令行风格的分布式文件系统目录交互。(7)分布式文件系统是用java编写的，可广泛运行在多种软硬件平台上。(8)分布式文件系统经常性地实现新的特性和改进。(9)Namenode和DataNode都内建了Web服务器，可以方便地查看集群的状态。分布式文件

30、系统的体系框架是Master/Slave结构，一个典型的分布式文件系统通常由单个Namenode和多个DataNode组成。Namenode是一个中心服务器，负责文件系统的名字空间的操作，比如打开、关闭、重命名文件或目录，它负责维护文件路径到数据块的映射，数据块到DataNode的映射，以及监控DataNode的心跳和维护数据块副本的个数。集群中的DataNode一般是一个节点一个，负责管理它所在节点上的存储。分布式文件系统暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组DataNode上。DataNode负责处理文件

31、系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。 所有对目录树的更新和文件名和数据块关系的修改，都必须能够持久化，文件在分布式文件系统中存储图如图：分布式文件系统结构分布式文件系统涉及到Namenode、DataNode和客户端们之间的交互。本质上，客户端与Namenode通讯是通过获取或者修改文件的元数据，与 DataNode进行实际的I/O操作。如图13所示，在分布式文件系统中有三个重要的角色：Namenode、DataNode和Client，其中Client就是需要获取分布式文件系统文件的应用程序。这里通过三个操作来说明他们之间的交互关系：(l)文件写入

32、。首先Client向Namenode发起文件写入的请求，Namenode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。(2)文件读取。Client向Namenode发起文件读取的请求，Namenode返回文件存储的DataNode的信息。Client根据返回的信息读取DataNode上的文件信息。(3)文件Block复制。Namenode发现部分文件的Block不符合最小复制数或者部分DataNode失效，通知DataNode相互复制Block。

33、DataNode收到通知后开始直接相互复制。分布式文件系统 Namenode、DataNode和客户端们之间的交互4.4.2Jobkeeper系统基本组成Jobkeeper的系统架构如下图所示：上图中对Jobkeeper进行了分层，对每层进行具体阐述 虚拟化资源层：将机器进行虚拟化，形成更大范围的服务集群。 存储层：存储数据的处理结果集或其他中间结果集的单元。 数据处理层：独立的数据处理程序，是对不同需求数据的统一处理方案，由JobKeeper调度平台进行统一的配置管理。 业务层：对于应用层的相关功能的业务化，数字化处理，用于将应用层的需求任务进行规则化划分，形成统一的处理化模式。 应用层：一

34、组用于管理和结果反馈的显示组件。是整个系统面向用户和开发人员的基础承载。JobKeeper的任务分发流程如下图所示：JobKeeper任务分发流程图当用户在应用层下发任务给管理节点，管理节点调度机器采集机器节点的信息，根据具体的算法选取最优节点并分发任务，接下来具体的处理节点接收到任务并处理同时将结果返回给管理节点，管理节点整理汇总处理结果，而后返回给应用层。服务器节点组：负责对处理节点的系统信息以及任务处理信息进行实时的跟踪和保存，对应的信息镜像存储在基于cStor或者NFS服务的存储系统上。处理节点组：通过RPC的远程调用获取各自节点的任务处理目标，并实时的和处理节点上的任务处理目标进行对

35、比，控制程序的执行和结束。处理节点组会在一个设定的心跳间隔内主动的和管理节点组联系一次，报告节点存活状态。4.4.3分布式数据立方系统基本组成分布式数据立方，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用分布式数据立方技术可在廉价PC Server上搭建起大规模结构化存储集群。其目的是处理庞大的表，可以用普通的计算机处理10亿行数据，并且有数百万列元素组成的数据表这张表的索引是行关键字。分布式数据立方可以直接使用本地的文件系统和云计算作为数据存储方式，不过为了提高数据的可靠性和系统的健壮性，发挥分布式数据立方处理大数据量等功能，需要使用云计算作为文件系统。1、数据模式 分布式数据

36、立方类似Bigtable的分布式数据库，是一个稀疏的，长期存储的，多维的，排序的映射表.这张表的索引是行关键字，列关键字和时间戳。每个值是一个不解释的字符数组，数据都是字符串，没类型。用户在表格中存储数据，每一行都是一个可排序的主键和任意多的列。由于是稀疏存储的，所以同一张表里面的每一行数据都可以有截然不同的列。列名字的格式是:,都是由字符串组成，每一张表有一个family集合，这个集合是固定不变的，相当于表的结构，只能通过改变表的结构来改变。但是lable值相对于每一行来说都是可以改变的。分布式数据立方把同一个family里面的数据存储在同一个目录底下，而分布式数据立方的写操作时锁行的，每一

37、个都是一个原子元素都可以加锁。所有数据库的更新都是一个时间戳标记，每个更新都是一个新的版本，而分布式数据立方会保留一定数量的版本，这个值是可以设定的。客户端可以获取距离某个时间最近的版本，或者一次获取所有版本。2、 概念视图分布式数据立方以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family)Row Keycolumn-family1column-family2column-family3column1column2column1column2column3column1key1t1:abct4:dfadst2:gdxdft3:hellot2:worldkey2t3:ab

38、ct4:dfadst2:dfdsfat1:gdxdft3:hellot3:dfdfkey3t2:dfadfasdt2:dfxxdfasd t1:dfdasddsft1: Row Key与nosql数据库们一样,row key是用来检索记录的主键。访问分布式数据立方 table中的行，只有三种方式：1 通过单个row key访问2 通过row key的range3 全表扫描Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在分布式数据立方内部，row key保存为字节数组。列族分布式数据立方表中的每个列，都归属与某个列族

39、。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history，courses:math 都属于courses 这个列族。时间戳分布式数据立方中通过row和columns确定的为一个存贮单元称为cell。每个 cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由分布式数据立方(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 cell中，不同版本的数据按照时间倒序排序，即最新

40、的数据排在最前面。Cell由row key, column(= + ), version 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。3、物理存储1 Table中的所有行都按照row key的字典序排列。2 Table 在行的方向上分割为多个Hregion。3 region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。4 Hregion是分布式数据立方中分布式存储和负载均衡的最小单元。最小单元就表

41、示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。5 HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。事实上，HRegion由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。如图：StoreFile以HFile格式保存在分布式文件系统上。HFile的格式为：Trailer部分的格式:HFile分为六个部分：Data Block 段保存表中的数据，这部分可以被压缩Meta Block 段 (可选的)保

42、存用户自定义的kv对，可以被压缩。File Info 段Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。Data Block Index 段Data Block的索引。每条索引的key是被索引的block的第一条记录的key。Meta Block Index段 (可选的)Meta Block的索引。Trailer这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描

43、整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。目标Hfile的压缩支持两种方式：Gzip，Lzo。HLog(WAL log)WAL 意为Write ahead log(http:/en.wikipedia.org/wiki/Write-ahead_logging)，类似mysql中的binlog,用来做

44、灾难恢复只用，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。每个Region Server维护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。HLog文件就是一个普通的云计算 Sequence File，Sequence Fi

45、le 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。HLog Sequece File的Value是分布式数据立方的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。Client1 包含访问分布式数据立方的接口，client维护着一些cache来加快对分布式数据立方的访问，比如regione的位置信息。Zoo

46、keeper1 保证任何时候，集群中只有一个master2 存贮所有Region的寻址入口3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master4 存储分布式数据立方的schema,包括有哪些table，每个table有哪些column familyMaster1 为Region server分配region2 负责region server的负载均衡3 发现失效的region server并重新分配其上的region4 GFS上的垃圾文件回收5 处理schema更新请求Region Server1 Region server维护Master分配给它的region，处理对这些region的IO请求2 Region server负责切分在运行过程中变得过大的region4.5关键技术4.5.1空气检测设备数据