英特尔hadoop发行版案例

IntelHadoop发行版案例案例分享一浙江省多个地级市智能交通系统大数据2动机车辆统计和增长率•233M机动车(年增长率.3.67%)•114M轿车(年增长率.7.66%)•103M摩托车挑战•交通拥堵已成常态•道路建设不能赶上机动车增长速度•每年增长5%•现行管理方案取得效果，但不足够3SOURCE:机动车数量(单位:百万)224.74105.89233114050100150200250MotorVehiclesCarsDec-11Jun-1201234565.023.763.072.482.292.232.212.092.051.99MillionsMotorVehiclesbyCities(06/2012)7.66%智能交通系统目标4交通管理–强制交通规则(例如,限速)–运输计划支持–按需交通控制–交通情况研究旅客信息系统–实时路况–畅通&堵塞–历史照/摄相影像&统计–出行时间信息–不同出行方式–前瞻性的出行计划商用车辆信息•商用车辆管理，跟踪，调度公共安全三个主要的途径交通摄像–通常安装在高速和街道–2百万像素网络摄像头–已部署–5百万像素网络摄像头–新安装–每个摄像头1或2个线路–每城市中200~1000摄像头监控摄像–在街道上安装,在建筑物周围安装,etcGPS终端–在商用车辆上安装–新兴的带有摄像头，GPS和3G网络的平板电脑上5智能交通的一个数据中心实时路况影像车辆跟踪实时拥堵状态基于交通流量的信号灯控制6智能交通的软件架构7HBaseMapReduceHive即时查询(例如：路况信息)应用程序视频流处理(例如：实时路况)数据挖掘(例如：车辆跟踪)当前智能交通的功能8交通管理向控制中心和监控系统实时报告路况在定长路段通过平均车速计算超速车辆检测伪造车牌车辆通过分析出发地-目的地数据为道路建设提供参考公共安全实时跟踪车辆秒级超速违章检测和模糊查找黑名单警告和报警,或改变交通模式.检测某些地点相同车辆反常的高发事件旅客指引为驾驶员获取最新的实时路况影像和交通流量状态在城市中为每一路段进行时间估计案例分享二广东移动省公司请账单系统新详单系统建设的必要性原清帐单系统建立在小型机及其高端存储设备上。为了实现海量数据存储及快速导入，原系统把明细清单压缩存放到文件系统中，数据库只保留索引信息以满足查询性能的要求。随着时间推移，数据量增长，需找新的解决方案越来越迫切：•通过文件存储定长记录的方式，程序难以修改。原有清单中心基于266字节的定长格式，但新融合计费项目上线，清单格式增长至1024字节。•文件系统缺乏常规查询语言，如SQL，HIVE等，旧已经不能满足越多越多统计需求。•系统需要不断增加新字段，文件系统无法扩展。•文件系统不支持数据库常规的更新功能，详单冲销、修正、补信息等功能难以实现。•随着新详单格式改变，存储空间及性能相应需要增加5倍。扩容费用高昂。新清帐单系统关键需求一、必须能够高效处理海量数据单月清单数据量约1000亿条×1k/条=100TB，6个月总量高达600TB(6+1)~700T从600TB清单数据中检索某用户某个月的清单记录，响应时间应小于1秒支持高峰期每秒2000个并发访问查询满足现在清帐单业务的查询统计需求(23类)实时入库，清单文件无积压。（清单文件最大2万条，最小1条记录。实时生产，平均每秒2个20MB的清单文件，高峰期到每秒10个20MB文件）对联机分析必须提供标准编程接口，支持SQL/JDBC/ODBC等二、高可扩展和高可用用户程序查询数据不需要知道底层细节，比如数据分布细节可以水平扩展允许多台机器故障的场景下，业务不中断新清账单系统基于Hbase的测试结果以下数据是实验情况下对Intel的Hbase基于一个月详单数据的测试结果，随着集群规模扩大，性能还能线性的提高负载情况并发线程（并发用户）性能指标1:查询个数(用户数)/秒性能指标2:清单条数/秒平均查询延时高负载7500600个查询/秒400000条清单/秒0.9秒中等负载2500450个查询/秒300000条清单/秒0.5秒低负载1000200个查询/秒130000条清单/秒0.3秒在实现同样需求的情况下，相比小型机和高端存储方案，新清账单中心全部选用了pcserver等设备，我们预计，成本约降为原来的1/4，性能提升大于3倍。总体性能及成本综合评估:Hbase在5台查询清单PC的基础上，就达到了最大查询速度476个查询/秒，数据量达到285000条清单/秒，入库速度2.83万条/秒，平均每条记录1KB新详单系统实现架构——逻辑架构平衡各种优缺点后，及对进行大量的性能、功能及稳定性测试后我们最终选择基于HadoopHbase作为新详单系统实施方案。下图为新详单系统项目的逻辑架构：分布式文件系统(HDFS)协调服务(Zookeeper)分布式计算框架(Map/Reduce)分布式数据库(HBase)监控(Ganglia)批量数据导入工具(Sqoop)清帐单中心分布式Hadoop架构清单数据导入账单数据导入计费引擎账务数据层计算层分析层接口层计费网站内部网关CRM网上营业厅自助终端WAP营业厅自助渠道外部网关客户客服人员等新详单系统项目逻辑架构图新详单项目实施情况本项目底层通过PC服务器组构建出一个基于集群，采用INTEL提供的Hadoop产品（分布式文件系统+分布式数据库），上层由合作伙伴开发业务程序，对入库和查询进行业务处理。这种架构有效的屏蔽了底层的功能，对上层来说，只需要调研相关接口即可。数据的分发、复制、任务调度、容错都是由系统软件来控制。大规模的PC具备强大的处理能力和网络带宽，同时具备线性的横向扩展能力。3份冗余的数据保证对硬件的容错和读处理的支持。存储使用72台PC机身硬盘作分布式存储DataNode，每台PC配置6TB磁盘容量，按每份数据存放3份计算，有效容量144TB，保存6+1个月数据，压缩比1:5。已经完成的新详单系统，实现功能如下：实现个人账详单数据存储和实时查询展示实现集团清单数据存储和批量导出实现补卡预处理实时查询实现网站/彩信账单文件、邮寄账单文件、短信账单文件批量导出序号名称效率说明1入库效率200MB/s或20万条每秒，资源消耗20%实时入库，清单文件无积压。（清单文件最大2万条，最小1条记录。实时生产，平均每秒2个20MB的清单文件，高峰期到每秒10个20MB文件）2并发访问2000笔/秒支持每秒2000个查询。（旧系统做了每人每天6次查询限制，旧系统高峰期查询达200/秒，预计放开限制后，查询高峰能达2000/秒）3平均响应时间1秒每个查询小于1秒新详单项目实施情况（续）目前新详单系统很好的达到了我们的预期目标，下表是新详单系统上线后的关键性能统计：每15分钟加载，不存在积压，平均20%资源消耗每秒大于2000个并发查询支持稀疏表，轻松扩展任何字段138TB可用空间，并提供三份数据冗余总体投入不到小型机解决方案1/4多台服务器同时故障，也不中断业务常有文件积压，不能实时入库，系统负荷过重每秒小于200个并发查询自定义文件系统，只支持266字，扩展需要重新开发只有54TB可用空间如进行系统扩容，光硬件需投入2200万灾难恢复需要通过磁带，业务中断时间过长文件系统+关系型数据库BeforeNowVS旧详单系统与新详单系统实施效果对比2*P595小型机（48CPU）及DS8300高端存储97台X3650PC服务器集群企业级Hadoop集群新详单系统二期需求概要回顾新清帐单系统的定位，系统中的数据还有非常重要的生产工作，对结算、报表、高额信控、故障处理业务分析都能提供数据支持。但这部分功能在新清帐单系统中还未实现。省公司计划开展二期建设，继续完成旧系统已有但未完成功能。3.日常数据提取2.报表统计4.冲销5.高额、信控1.综合结算提供结算所需的清单和统计数据（对数据部、财务部）对日常统计需求提供生产数据的提取基于清账单中心的统计来实现，大大提升冲销的效率基于清单的报表提供统计数据（对财务部、市场部）基于清单的高额、信控功能二期主要扩展功能归类如下：•新详单系统二期功能点，拥有以海量数据批处理的明显特点Backup案例分享三银联大数据数据票据详单平台项目简介：银联大数据平台是银联处理票据详单，电子保单，银联交易详单平台。票据数据主要包括消费者在POS机上的消费签购单详和法人单位开具给个人的付费凭证。票据数据每个月有5000万到6000万条数据。该数据的使用者除了银联的内部用户外，也开放给参与交易的商户。银联大数据平台也包括电子保险单存储。每份保单文件为约3MB大小，一个城市每年约产出1500万份保单。银联大数据平台的第三项功能是银联交易详单，包括银联网存款，取款，转账详单。每月产生40TB到47TB数据。电子保险单存储和银联交易详单平台的用户主要是银联的内部用户。面临的挑战：采用IDH系统方案之前，银联的方案有困难1）在数据集达到半年数据规模时，采用XML方案的系统票据查询速度过慢导致无法实际使用该功能；2）电子保单存储和查询中，当存储的数据量达到一年的数据量时，查询速度过慢导致无法实际使用该功能。3）曾在交易详单项目上尝试采用开源的HBase,经常发生故障，而且没有管理监控报警功能，无法投入商业应用。IDH方案的实现：新的银联大数据平台项目采用英特尔Hadoop发行版平台，实现了以下功能1）将基于XML的票据查询方案转换为基于HBase的方案，外部导入程序将XML文件转换为HBase数据结构，实现了在海量票据数据中一秒之内的查询返回；2)电子保单数据和保单文件从关系数据库转换为HBase，使用IDH大对象存储的优化，性能比开源Hadoop成倍数提升；3)将开源HBase的交易详单应用部署到英特尔Hadoop发行版，提供更高的性能、稳定性和管理性。硬件配置：集群规模45个节点，namenode采用了ＨＡ，每个节点配１0块２ＴＢＳＡＴＡ数据硬盘组成ＪＢＯＤ，系统盘采用２块５００ＧＢＳＡＳ硬盘组成ＲＡＩＤ１，6４ＧＢ内存，双路６核ＣＰＵ，千兆网络。效果：在设计数据量下，票据查询和电子保单查询的速度都在秒级，达到设计标准。案例分享四某通信运营商全国用户上网记录业务背景随着移动互联网业务的发展，上网记录查询成为用户投诉的焦点问题来源目前，某省分公司3G客户数据流量问题争议占3G业务投诉达7-10%，且近几个月呈上升趋势，个别省分比例高达20%一些用户对3G业务流量产生及计费方式不了解，主观认为自己未使用或使用较少数据流量，要求运营商提供上网记录，而现有系统不具备此功能，从而导致投诉升级。3G流量费争议占总咨询投诉量比率移动互联网处于快速发展期：每6个月，流量翻一番移动互联网用户快速增加，智能终端迅速普及、户均流量显著增长，上网记录数据将进一步猛增难点分析上网记录是海量数据用户每月的上网记录约几万至数十万在Gn（SGSN与GGSN之间）接口上部署采集设备来生成用户上网记录用户手机访问一次网页，约会产生数十条，甚至数百条请求，意味着产生数十条和数百条上网记录访问手机新浪网首页，约产生20条记录访问新浪iPad首页，约产生40条记录在iPad中看一条新浪新闻，产生超过180条记录访问淘宝触摸屏版，约产生60条记录大量的DNS查询、推送服务记录（如苹果通知服务）等全国每日新增约10TB数据，每月近万亿条记录，存放6个月，约2PB。移动用户上网记录集中查询与分析支撑系统关键性能指标数据查询上网记录查询速度：不高于1秒（不含用户访问查询页面的时间）支持并发查询数目：1000请求/秒数据存储上网记录入库时间：一般小于30分钟，实际约10分钟具备存储全国移动用户不小于6个月的原始上网记录能力历史5个月+当前月统计分析的中间报表数据保存不小于5年全国集中的一级架构，国内