MPP初稿大数据实施指导意见v0.2

1、中国移动经分系统大数据实施指导意见版本号：1.0.02013-5-24中国移动通信研究院目录1概述11.1大数据的定义11.2引入原则21.3编写目的21.4文档组织结构22大数据技术的引入32.1大数据时代技术发展32.2中国移动大数据特征42.3hadoop与mpp对比43hadoop实施指导意见53.1应用场景53.1.1批量数据etl63.1.2详单查询63.1.3机器学习和数据挖掘73.1.4小结83.2方案设计阶段83.2.1整体规划83.2.2软件选择83.2.3硬件选择93.2.4节点规模评估103.2.5网络及组网123.3建设阶段133.3.1部署架构133.3.2软件参数

2、建议143.3.3上线前准备193.4运维阶段203.4.1任务调度203.4.2监控管理203.4.3告警管理223.4.4部署管理223.4.5配置管理233.4.6安全管理233.4.7日志管理243.5培训与技术支持254mpp数据库指导意见254.1应用场景254.1.1数据集市254.1.2分析挖掘数据集市264.1.3历史库264.1.4场景小结264.2方案设计阶段264.2.1整体规划264.2.2软件选择264.2.3硬件选择264.2.4容量评估方法264.2.5网络评估方法274.3实施阶段284.3.1服务器常见配置284.3.2数据分布建议294.4运维阶段304.

3、5培训与技术支持315系统集成实施指导意见建议315.1系统集成面临的挑战315.2数据互通325.2.1目的325.2.2建议方案335.2.3实现技术355.3统一管理监控375.4透明访问386附录a-大数据技术介绍396.1hadoop及生态圈396.1.1hadoop 简介396.1.2hadoop生态圈系统486.1.3hadoop1.0 特性506.1.4hadoop2.0 特性;516.1.5hadoop选型546.1.6hadoop ha 方案对比546.2mpp数据库586.2.1mpp数据库定义586.2.2mpp数据库基本架构596.2.3mpp平台技术规范和要点616

4、.2.4mpp主要产品介绍616.3x86服务器介绍616.3.1cpu架构616.3.2大数据场景下机器选型626.4ib网络和万兆网 组网 (hw)636.4.1ib网络636.4.2万兆网666.4.3千兆网676.4.4适用场景676.5硬盘686.5.1硬盘类型介绍686.5.2硬盘比较分析696.5.3硬盘选购建议706.6虚拟化706.6.1概念706.6.2虚拟化技术介绍716.6.3适用场景727附录b-参考案例727.1hadoop实施案例727.1.1案例1：河南互联网内容分析727.1.2案例2：湖南移动经营分析云平台737.1.3案例3：联通总部3g上网详单查询分析7

5、77.1.4案例:4：广东移动清帐单查询分析787.1.5案例:5：河南经分etl797.1.6案例6：上海电信网优项目797.1.7案例7：baidu的hadoop部署807.2mpp实施案例817.2.1安徽移动数据集市817.2.2山东移动经分云数据仓库系统827.2.3江西移动信令监测系统837.2.4重庆电信数据集市项目848附录c-faq868.1hadoop软件类868.1.1hadoop的balance影响868.1.2hadoop mapreduce 数据倾斜：878.1.3如何解决shuffle易见错误878.1.4如何解决too many fetch-failures88

6、8.1.5如何解决找不到数据块易见错误888.1.6如何解决outofmemoryerror内存溢出问题898.2hadoop硬件类898.2.1硬件损坏处理898.3mpp类898.3.1数据库运行缓慢898.3.2segment故障切换与恢复908.3.3gp导入数据中失败908.3.4对一张表长时间不能清空919附录d-其他参考配置919.1.1cloudera建议配置919.1.2hadoop部署注意项9310编制历史93前言本报告针对经分系统各省对大数据技术引入的需求，整合了2012年经分云etl试点、2012年经分mpp数据仓库测试以及hadoop及数据仓库混搭架构方案研究三个课题

7、的输出成果，针对大数据处理技术中hadoop和mpp技术的规划、实施和运维管理提供指导意见，用于指导中国移动各省公司引入大数据技术的实践。1 概述（加术语，解释权，应用场景放在后面）1.1 大数据的定义（大数据的范围，哪些属于大数据范畴）大数据在业界有不同的定义，其中比较有代表性的是是国际数据公司(international data corporation, idc) 给出的大数据定义。idc认为大数据具备4v特征，即海量的数据规模（volume）、快速的数据流转和动态的数据体系（velocity）、多样的数据类型（variety）和巨大的数据价值（value）。大数据处理技术可以认为是从各

8、种各样类型的数据中，快速获得有价值信息的能力。大数据（big data）正在影响着it产业，利用hadoop和关系数据库混搭来解决大数据难题是当前通常采用的方法。gartner在评价2011年的数据仓库产品魔力象限的时候，将其作为一项重要的“远见”考察内容（其称之为逻辑数据仓库ldw）。随着信令数据、互联网数据等新型数据源的引入，业务需求对数据深度分析及探索的增加，经营分析领域的大数据呈现出数据规模增大及分析复杂度增加的趋势。经营分析领域的大数据具备如下的特征：1、规模特征：信令xdr、互联网等数据每天的规模非常大，已经超过了语音、订购类数据，而且还处在不断增长的趋势，数据入库阶段的转换加载及

9、轻度汇总压力增大。如某省2012年每天的cmwap日志、cmnet日志、wlan话单、gn口信令每天达1.3tb。2、类型特征：目前大部分数据为结构化数据，但是互联网的网页数据、社交网络数据等半结构化、非结构化数据也在不断增长。实时营销的业务需求需要接入和处理海量的流式数据。3、使用特征：随着业务的发展，出现了海量历史数据的高并发查询及深度挖掘、对当前数据的深度分析及自助探索等数据消费方式。详单等数据需要存储较长的周期供查询或数据挖掘使用，传统使用磁带库存储历史数据的方式已经越来越不能满足数据使用的需求。经营分析系统接入的数据规模不断增大，数据类型也由单一的结构化数据向非结构化数据、流式数据等

10、发展，同时根据业务场景不同其存储及计算的方式也各不相同，需要引入多种大数据技术来共同支撑大数据的分析及处理。1.2 引入原则大数据技术的引入需要坚持分阶段逐步引入的方式，以解决当前的业务发展的痛点为基础，同时结合长远的技术架构规划，首先在部分业务场景中引入特定的大数据处理技术。可以参考如下的几个引入原则：1、先增量后存量。现有的数据处理系统引入大数据处理技术，面临着模型改造、流程改造等一系列的问题，可以首先在新上线应用引入大数据处理技术2、先边缘后核心。对于原有功能的迁移，可以先迁移非关键的应用系统。不涉及到关键生产任务，可以忍受数据处理延迟，故障修复时间较高等可能出现问题。3、先简单后复杂。

11、数据处理较简单的应用也可以首先尝试引入大数据处理技术，降低实施的复杂度，积累运维经验通过在大数据处理技术的规划、实施及运维过程中积累经验及教训，不断提升和完善大数据技术的应用水平，逐步拓展大数据技术应用领域。1.3 编写目的目前大数据处理技术还在蓬勃发展，各种新兴的处理技术也在不断的涌现，本文整合了2012年经分云etl试点、2012年经分mpp数据仓库测试以及hadoop及数据仓库混搭架构方案研究三个课题的输出成果和部分省公司试点经验，针对大数据处理技术中hadoop和mpp技术的规划、实施和运维管理提供指导意见，用于指导中国移动各省公司有序引入大数据技术。1.4 文档组织结构本文第一章为概

12、述，介绍了大数据基本概念，中国移动经分系统引入大数据技术的基本原则以及编写目的。第二章针对经分系统场景所面临的大数据困境，分析了需要多种技术解决方案。第三章围绕hadoop展开，总结出经分系统中适合hadoop的应用场景，进而提出规划阶段、实施阶段、运维阶段的相关建议。第四章围绕mpp数据库展开，总结出经分中适合mpp数据库的应用场景，进而提出规划阶段、实施阶段、运维阶段的相关建议。第五章给出mpp、hadoop与现网已有系统集成的相关建议。附录a为大数据技术介绍，附录b为参考案例，附录c为faq，附录d为其他参考配置材料。2 大数据技术的引入2.1 大数据时代技术发展随着社交网络的逐渐成熟，

13、移动带宽的迅速提升，物联网应用的更加丰富，更多的传感设备、移动终端接入到网络，由此产生的数据及增长速度将比历史上的任何时期都要多、都要快，idc最新的数字宇宙(digital universe)研究：预计到2020年，世界上的数据存储总额将达到35 zb。idc给出了大数据技术的4v特性：大数据技术用于在成本可承受的条件下，通过非常快速（velocity）的采集、发现和分析，从大量化（volumes）、多类别（variety）的数据中提取价值（value）。在大数据时代，传统it基础架构中小型机、数据仓库所具备的高密集计算优势，面对海量、多样化数据以及高速响应的需求是难以满足的，包括：传统it

14、系统采用scale-up设计路线，扩展性较弱；小型机unix系统的封闭性导致系统扩容时，利旧性差；且成本很高。而云计算的分布式处理方式的scale-out设计路线可以很好解决海量数据的快速分析处理，且基于x86架构的设计具有良好的标准化基础，系统扩容时可以直接增加节点，且成本较低。大数据时代也涌现了多种技术，典型技术如下：l hadoop：基于hdfs和mapreduce，被互联网厂商广泛用于非结构化数据处理和半结构化日志处理。优点是编程灵活，针对问题优化，扩展性好，且基于廉价的x86标准硬件。l mpp数据库：基于关系代数，面向结构化数据处理设计。近年演进方向包括：采用mpp提高扩展性、高性

15、能优化支持快速复杂查询、引入x86降低成本、一体机性能优化及高集成度、列存储、打通与hadoop交互l nosql：抛弃了关系数据库复杂的关系操作、事务处理等功能，仅提供简单的键值对(key,value)数据的存储与查询，换取高扩展性和高性能 。例如，cassendra, hbasel 流计算技术：在流数据不断变化的运动过程中实时地进行分析，捕捉到可能对用户有用的信息，并把结果发送出去。例如systems， storml 内存数据库：内存计算充分发挥多核cpu的能力，内存计算可以对大规模海量数据做实时的分析运算。例如hana、exaanalytic、tm12.2 中国移动大数据特征中国移动经分

16、系统目前在数据量、数据类别、数据应用需求方面具有典型的大数据特征，包括：1、 容量巨大：现在全网经分数据仓库结构化数据总量已达8pb，引入上网日志和信令数据后数据更会呈现爆发性增长；2、 类别多样：除了传统的清单等结构化数据，还包括日志类半结构化数据，网页、gis信息、语音信息等非结构化数据；3、 数据处理方式多样：除了传统的按日和按月的批处理以外，为了及时高效处理数据，逐步引入了小批量多次处理和实时流计算等多种数据处理方式；4、 访问需求多样：除了传统的olap型数据访问需求外，对于客户标签、营销目标用户等，还有类似oltp类大量小查询访问需求，此外即席查询（ad-hoc）等访问需求也逐步高

17、涨。5、 数据价值不同：不同内容的数据，不同时间的需求具有不同的价值，如果用一种存储方式存储要么浪费了资源，要么满足不了访问需求。可以看出，任何一种单一技术都难以适应中国移动全部的数据采集、存储、处理和对外服务的需求，多种技术并存才是发展趋势。本文针对经分系统中迫切需要的，且相对技术最为成熟的两种主流大数据技术hadoop和mpp展开，给出在中国移动经分系统场景下hadoop与mpp技术的最佳实践建议。2.3 hadoop与mpp对比各自适合与不适合的场景1：高并发，hadoop不适合2：大表关联3：各自的机制，架构上的差异（附录是否阐述明白了？）4：不同产品的特点5： 传统数据库的加进去，把

18、oracle db2,放进去，mpp是中等价格，高、低没意义，按照tb估算一下。数据处理的规模，优势劣势。6：运维复杂度，可管理性、除障能力提高了。hadoop和mpp两种技术的介绍请参见附录a。虽然这两种技术同属于分布式计算，但由于依据的理论和采取的技术路线不同而有各自的优缺点和适用范围。两种技术的对比如下：hadoopmpp开放性高低运维复杂度高，与运维人员能力相关低，厂商提供扩展能力高部分高成本低高sql支持相对低高数据规模pb级别部分pb计算性能对非关系型操作效率高对关系型操作效率高数据结构结构化和非结构数据结构化数据综合而言：hadoop 在处理非结构数据和半架构数据上具备优势，尤其

19、适合海量数据批处理等应用需求。当然随着hadoop技术的成熟，基于hadoop的实时分析等技术也逐渐崭露头角。比如仿照dremel的开源项目apache drill以及cloudera impala。mpp适合替代现有关系数据结构下的大数据处理，具有较高的效率，但其在大规模集群（超过100个节点）下的可用性还存在疑点。针对具体的经分业务来讲： mpp适合多维度数据自助分析、数据集市等；hadoop 适合海量数据存储查询（详单存储和查询）、批量数据etl、非结构化数据分析（日志分析、文本分析）等。3 hadoop实施指导意见本章主要对hadoop平台在实施前、实施过程中和实施后的运维过程中需要注

20、意的问题提出指导意见。3.1 应用场景hadoop技术和产品在经分中可以用于以下场景（包括但不限于）。3.1.1 批量数据etl3.1.2 详单查询3.1.3 机器学习和数据挖掘3.1.4 小结从实际案例看，hadoop目前在电信业务领域可以提供下面几大类成熟应用： 基于map/reduce以及hive的类sql引擎，提供大数据的etl、数据分析、数据挖掘能力。应用于bi生产数据的抽取、清洗、转换、分析、非结构化数据的处理分析以及各系统之间的数据交换。3.2 方案设计阶段3.2.1 整体规划整体规划包括选择合适的应用场景，确定数据范围，及系统的外围边界等等。（未完）3.2.2 软件选择3.2.

21、2.1 软件适用特性依据hadoop系列软件的特性，我们可以做出基本的选择，进而通过测试验证。 hdfs用于非结构化文件存储， hive主要用于数据仓库，。 hbase： mahout：基于mapreduce上的挖掘算法实现，主要用于数据挖掘； oozie：适用于简单etl场景，经分场景中，建议使用现有etl中的场景来调用hadoop hive与mapreduce的选择3.2.3 硬件选择 硬件设备一般选择主流设备，针对整体规划中，不同用途可选择不同的配置。项目内容x86服务器高度cpu个数及核心数硬盘数内存电源功率及数量网卡型号 内存的选择 cpu的选择 配置优化

22、结论: 硬件冗余 raid方案3.2.4 节点规模评估从hadoop上运行的业务功能角度分析，建立硬件配置模型，评估可以分以下几个步骤：第一步,划分配置对象，不同功能和角色的机器进行不同的配置。我们以整理在大数据平台上运行的业务场景，根据不同的功能域或业务处理过程划分配置对象。比如某项目hadoop集群配置对象包括以下内容：功能模块配置对象功能点hadoop计算集群ftp数据抽取 1. ftp从ftp服务端下载文件到hdfs存储 数据处理1.数据校验。对数据进行唯一性校验、外键校验、字段长度类型等记录级校验。输出校验成功和错误的记录2.平行转换。完成数据记录的清洗、

23、过滤、字段变换等处理类sql操作。汇总表数据数据加载到db2数据库经过处理、汇总的数据输出到db2数据库。流程调度平台流程调度实现业务流程调度等hadoop监控平台集群监控实现集群监控等以上考虑hadoop计算集群为主要需要进行容量评估平台。可以依照计算能力和存储能力二维分析方法进行容量评估。ftp加载我们以加载性能要求进行评估，测算每个节点并发加载速度，在根据业务要求选择节点个数。数据处理部分基本思路是根据计算能力和存储能力评估之后，在两者中选择大容量作为评估结果。1，计算能力评估依据小规模基准测试针对所需的业务类型进行模拟测试，依据近似线性扩展原理，根据业务需求可计算出计算能力节点个数。例

24、如：业务需求为10分钟响应，根据小规模基准测试中（例如10节点），满足10分钟需求的数据处理量为1tb，则可得每节点处理能力为1tb/10/10*60，依据次处理能力，进一步可估算出整个数据范围，所需的计算节点个数。而业务熟的增加，我们依据串行能力评估。如果有并发需求，则在小规模基准测试时应同时考虑。2，存储能力平台考虑因子：压缩比，副本数，冗余量业务考虑因子：存储周期依据以上因子，针对数据存储容量进行预估，在确定节点个数3，内存能力内存一般按照通用配置，一个cpu核配2g内存设计，而hadoop的map和reduce槽位个数设计与内存大小有关，一般一个槽位配1g内存。4，输出总体配置建议考虑

25、各配置对象是否有并发情况，如果没有并发，计算需求、存储取配置对象中最大值，存储需求取配置对象总和，最终输出业务相关所需计算、存储等资源。再综合考虑hadoop自己本身所需资源得出最终配置。3.2.5 网络及组网所以一般建议是需要给hadoop提供专用的私有网络，用于内部数据的交互，网络带宽为万兆网。万兆网不仅仅10倍与千兆网的带宽，在峰值流量下，其时延也大大低于千兆网。根据hortonworks的建议，对于较小的集群至少保证所有节点点到点千兆网连接，对于更大的集群使用千兆网可能造成性能的下降，在超级的数据中心，yahoo的做法是同一个机架的20台刀片中每台通过2个千兆网卡绑定的方式和其他刀片通

26、信，对于机架使用2条万兆网连接。目前主流交换机为万兆交换机。 组网建议3.3 建设阶段3.3.1 部署架构图中hadoop节点主要分成两类，管理节点（master）和数据存储运算节点(slave)。master节点上的组件逻辑上划分成 namenode, standby namenode, jobtracker, hamster,zookeeper，监控管理服务器. 逻辑组件可以与物理服务器一一对应，也可以一个物理服务器承载多个逻辑组件。 是否拆分，取决于负责状况slave节点上的逻辑组件包括，datanode，tasktracker， regionserver，master服务

27、器一样。逻辑组件可以与物理服务器一一对应，也可以一个物理服务器承载多个逻辑组件。是否拆分，取决于负责状况组网要求客户端或者中间件，必须能够与所有master节点和slave节点进行通信。3.3.2 软件参数建议 配置参数hdfs配置文件：hdfs-site.xml参数名参数值说明dfs.block.size 根据文件规模修订，大文件建议修订为128mb或者更大默认的块大小 文件：hadoop-env.sh参数名参数值说明hadoop_heapsize2000namenode所使用的最大内存mapreduce配置文件：core-site.xml参数名参数值说明hadoop.tmp.

28、dir/data2/tmp转移map过程中的系统盘压力，但是对挂载磁盘的io性能压力比较大文件：mapred-site.xml参数名参数值说明mapred.task.timeout/mapreduce任务默认的超时设置mapred.min.split.size /split输入最小尺寸，决定了map任务数量mapred.reduce.tasks /设定reduce任务数量tasktracker的中间输出目录: mapred.local.dir。map和reduce任务mapreduce产生的中间数据会特别多，为了减少磁盘压力，如果机器有多个磁盘，也可以像datanode的数据目录设为”/dis

29、k1/local,/disk2/local,/disk3/local”,参考配置属性文件：hadoop-env.sh参数名参数值说明hadoop_heapsize4000jobtracker所使用的最大内存hbase配置文件：hbase-env.sh参数名参数值说明hbase_heapsize8192hbase所使用的最大内存hbase_manages_zkfalse设置hbase不自行管理zk服务，在tbe中，是额外提供zk集群的服务文件：hbase-site.xml参数名参数值说明hbase.regionserver.handler.count20regionserver的请求处理io线程

30、数，对于高并发，适当调高以提升性能hbase.client.pause3000客户端在重试前的等待时间hbase.hregion.memstore.flush.size/ region上memstore的大小是64mb；hbase.regionserver.handler.count /一个regionserver的最大并发handler数目；hbase.regionserver.coprocessorhandler.count /一个regionserver的coprocessor最大并发handler数目； 压缩算法以下是常用压缩算法情况，目前测试用snappy较多。（待定）

31、参考辽宁etl试点 常用压缩算法工具算法文件扩展名多文件可分割性（支持mapreduce并行处理）snappysnappysnappysnappy是是lzolzoplzo.lzo不是 副本个数 块大小 slot数3.3.3 上线前准备上线前准备，包括对数，正确率。数据入库完整性数据入库逻辑失真特殊字符失真汇总逻辑参见辽宁etl总结2.9 3.4 运维阶段hadoop系统因为其分布式特性，容忍一定数量节点的异常，并影响其整体可用性，异常处理被定义为正常运维操作，所以相应的运维管理有其特殊性，对自动化程度要求比较高，关键节点可靠性要求高。对应运维管理中，应

32、该包括监控、告警、部署、配置、日志、安全以及升级等功能。具体每个子模块，应该包括相应基础能力。目前开源hadoop自带ui中，监控粒度比较大，只能查询到节点运行是否正常，mapreduce任务执行进度和结果，以及hbase数据访问日志。无法对整个hadoop平台当前运行指标进行综合评估与展示。 建议使用开源软件或者使用第三方厂商提供的运维和管控平台。目前hadoop中，hdfs、mapreduce 以及hbase均支持jmx协议下的内部运行参数监控接口，支持与第三方监控工具集成。 开源监控工具包括：ganglia、nagios等。3.4.1 任务调度3.4.2 监控管理监控管理包含2个方面：基

33、础指标监控和关键业务参数监控。同时监控管理作为第三方辅助模块还应该具备如下能力： 低性能损耗：监控模块开启时，对宿主机器性能平均损耗不能超过5%； 低资源抢占；对于共享资源如cpu、网络带宽、内存等其峰值不能超过10%； 可控开关： 在特殊情况下，支持监控平台开关能力； 数据可视化： 监控数据简单易懂 第三方数据采集接口： 支持第三方系统数据调用，便于与企业现有监控平台数据采集和整合； 基础指标监控l 机器性能指标；如磁盘io、cpu使用率、硬盘使用率、网络带宽占用率l 集群性能指标： 基础机器指标进行计算后的相关指标数据，如平均使用率、机器使用热度分布、机器空闲率等、jvm使用率等； 业务指

34、标监控，包含大数据平台中的主要模块关键业务参数值l hadoop-hdfs：l hadoop-mapreducel zookeeperl hbasel hadoop ： namenodel hbase ： hmaster；l mapreduce ： jobtracker；l mapreduce2 ： resourcesmanager；l 元数据库： 大数据平台中存储元数据的关系数据库（如mysql）3.4.3 告警管理告警管理主要用于针对大数据平台重要事件发送告警信息，提醒运维人员即使进行后续处理操作。告警管理应该具备如下基础能力： 事件触发：主要用于针对服务、机器异常等事件 阀值触发；主要用

35、于核心监控数值在出现异常前的提前警告； 第三方接口： 用于与第三方系统集成； 告警方式 声音； 短信； 邮件； 自定义；目前hadoop中没有任何告警管理功能，开源nagios具备此能力，但需要与hadoop平台进行整合，也可以使用第三方告警平台。 另外与移动经分已有告警接口整合均需要进行二次开发。3.4.4 部署管理部署管理主要用于大数据部署、扩容、升级等操作。 通过自动化方式降低大数据平台的运维复杂度。主要包括： 大数据系统安装； 平台扩容； 平台节点移除； 平台节点升级；hadoop的自有的部署管理都是在命令行方式下执行的，这中操作方式人运维人员要求非常高，在进群规模超过30台以上，异常

36、问题的排查将会非常号时间。 可以采用开源部署工具如puppet 降低部署管理复杂度，也可以直接提供商相关企业版工具。3.4.5 配置管理配置管理主要用于通过自动化方式实现大数据平台配置信息快速同步，避免手动修改造成的人为错误，提高可靠性，具体功能包括 配置文件修改同步； 配置文件修改历史记录； 配置文件修改痕迹保留；3.4.6 安全管理安全管理包含2个层面 大数据网段访问控制：防火墙。 内部访问控制:包括节点与节点之间，应用与应用之间授权访问，启动hadoop 安全认证。认证模式不仅支持用户密码访问模式，最好能够支持强认证模式。3.4.7 日志管理日志管理用于搜集大数据平台的关键业务日志，便于

37、运维和上层研发人员定位系统问题，提高异常处理速度。主要功能包括： 日志搜集； 日志查询； 日志级别过滤； 模块日志搜集开关；在配置hadoop时候，将日志目录配置在统一目录下，便于查询，同时由于是分布式系统，日志是分散在不同节点上，这导致日志查询和管理上非常不方便。hadoop中使用log4j 和 sl4j作为日志输出模块，所有日志输出目录修改hadoop安装目录下的perties配置文件，配置到指定目录即可。 同时由于节点多，日志量大，需要定时清理日志。建议方案：l 修改日志级别和适配器，讲日志统一存储在共享存储介质上； l 使用第三方产品提供的日志搜集和管理模块；3.5

38、培训与技术支持4 mpp数据库指导意见本章主要对mpp数据库在实施前、实施过程中和实施后的运维过程中需要注意的问题提出指导意见。4.1 应用场景（建议放在后面，可以简单写一下，不列出小标题）mpp数据库产品在经分中可以用于以下场景（包括但不限于）。4.1.1 数据集市基础数据平台是三种整合，则数据集市被定位为逻辑集市。把数据集市的概念明确。mpp数据库在数据集市中引入，存储数据集市中的数据并对外提供数据服务，这种方式减少了数据仓库主库的压力，引入低成本x86平台降低整体投资。经分系统，图不合适4.1.2 分析挖掘数据集市（也是集市，规范中没这说法）4.1.3 历史库（历史库的含义，目前也没有这

39、个）4.1.4 场景小结4.2 方案设计阶段4.2.1 整体规划描述规划内容，选择场景，确定范围，定义流程。（未完）关联计算，什么类型的操作。客户标签。方案架构图4.2.2 软件选择mpp多种数据库常见的mpp软件比较4.2.3 硬件选择4.2.4 容量评估方法影响容量评估的因素1 做raid镜像损失空间 r2 操作系统与应用软件使用空间 o3 格式化系统损失空间 f4 数据库压缩比 c5 数据库系统空间 s6 数据库最优工作空间容量比 u 7 实际处理数据的大小 k 9 实际数据转换为数据库空间的比率 kr 10 裸磁盘空间 l评估步骤：（作为一个示例）计算硬盘格式化后提供的文件系统空间 f

40、d = l（裸磁盘空间） - r （镜像损失空间） - f （格式化损失空间）每个数据几点去除操作系统和应用软件的使用空间 dd = fd - o（操作系统空间和应用软件空间）（单独考虑）考虑文件系统转化为数据库空间的比率（t）最终数据库空间 g = dd * t （这一步再确认下）综合公式 g = （l - r - f - o） * t * u = k * kr / c下面以gp数据库容量计算作为示例： 有60t的数据，主机配置如下 2 c * 6 core 2.8mhz 磁盘为1t 并有24插口，请给出需要主机和磁盘的数量。 解答：假定数据文件转载数据库后空间不变（kr=1），数据库压缩比

41、为 2（c=2）， 实际数据库空间 g = 60 * 1 / 2 = 30 t，对于gp需要考虑镜像与系统表使用空间 g =30 *2 + 30 * 1/3 = 70 t假定使用raid5，故作raid损失1张盘，格式划不损失空间，操作系统与应用软件损失0.5t，最优工作比u = 0.7 ，设定盘为x，主机数量为y（x-1）* 1 - 0.5）* y * 1 * 0.7 = 70 ty= 70 / ( 0.7 * ( x - 1.5 ) = 100/(x-1.5)当每台主机挂 12块1t的盘需要100/(12-1.5) = 10台数据节点 （9.523 台），建议在生产环境下可以增加1块600

42、g的sas盘供系统使用考虑到稳定性，需要部署两台master主机，故整个集群需要12台主机4.2.5 网络评估方法由于mpp数据库在运作期间，在复杂的关联操作时，会将负载较高的节点的数据传输至负载较低节点进行处理，以使得负载均衡，及结果数据的汇总排序等，都对内部互连网络有较高的要求。推荐使用万兆网卡和交换机，每台机器配置两个万兆网口就可以保证网络带宽，以及ha的要求4.3 实施阶段4.3.1 服务器常见配置先写一下原则，再写个例子。 控制节点： 两台x86服务器，一台是master，另一台为standby，保证系统冗余，避免单点故障。配置两颗6核以上的cpu，48gb内存。四到六块硬盘，采用s

43、ata或者sas均可，容量按需选择，做raid5或者raid1+0。配置两万兆口，至少一个千兆口。其中standby节点由于负载很小，同时可以用来作为etl服务器。 数据节点：最少4台起，配置两颗6核以上的cpu，主频不低于2.5ghz，因为做一些复杂join和函数运算时，会大量消耗cpu，而每台数据节点存取的数据量都很大。与数据库类似，mpp数据库也需要较高的io性能，建议最少配置12块sas盘，单块600gb。如果业务复杂度不高，并发用户数不多，也可以酌情采用900gb的sas盘，或者1tb的sata盘。建议采用比较好的raid卡，支持虚拟磁盘功能，即对一个raid卷进行逻辑切分，可以在系

44、统层显示为多个物理磁盘。这样可以提高磁盘利用率和整体io性能。配置两万兆口。 以太网网络交换机：2台万兆以太网交换机，用于mpp内部数据交换。1台千兆以太网交换机，用来连接前台应用，和做为管理监控入口。 数据加载服务器：部分mpp数据库产品支持并行加载方式，针对此类产品，可以配置多台数据加载服务器，提高加载效率。可以把数据分布至多台数据服务器上，这些服务器通过万兆内网与mpp中的数据节点内连，可以大大提高加载速度。故此，etl服务器的部署数量取决于对于数据规模和加载速度的要求，由于其上的数据都是大规模的连续写和连续读，所以建议采用大容量的sata硬盘即可。4.3.2 数据分布建议mpp数据库的

45、所有表都是分布式存储的，在创建表时都需要指定分布键，分布键可以是单一字段，也可以是复合字段，然后通过hash方式去分布。如果难以确定分布键也可以使用随机分布方式。如上图所示，通过分布键的选择，数据将均匀分布在每个节点、每块磁盘上，发挥每个节点、每块磁盘的性能，从根本上解决io瓶颈。分布键选择的是否合理，将直接影响mpp数据库的性能表现，在选择表的分布策略时，需要重点考虑以下问题（问题由重要程度由高到低列出）均匀的数据分布 - 为了尽可能达到最好的性能，所有的数据节点应该尽量存储等量的数据。若数据的分布不平衡或倾斜，那些存储了较多数据的节点在处理自己那部分数据时将需要耗费更多的工作量。为了实现数

46、据的均匀分布，尽量选取具有唯一性的分布键，如主键。但往往有很多表没有唯一键，那么尽量选择数据分布规律性强且取值范围非常大的字段作为分布键。本地操作与分布式操作 - 在处理查询时，很多处理如关联、排序、聚合等，若能够在节点本地完成，其效率将远高于跨节点（需要在各节点间交叉传输数据）的操作。当不同的表使用相同的分布键时，在分布键上的关联或排序操作将会以最高效的方式在本地完成。本地操作大约比分布操作快5倍。如果采用随机分布策略，将大大限制本地操作的可能。所以在实际的使用中，如果一个字段被大量的join使用的话，建议以该字段作为分布键。平坦的查询处理 - 在查询正被处理时，我们希望所有的节点都能处理等

47、量的工作负载，从而尽可能达到最好的性能。有时候查询场景与数据分布策略很不吻合，这就会导致工作负载的倾斜。例如，有一张销售交易表，该表的分布键为公司名称，那么数据分布的hash算法将基于公司名称的值来计算，假如有一个查询以某个特定的公司名称作为查询条件，该查询任务将仅在一个节点上执行，其他节点处于闲置状态。工作负载倾斜就是如此发生的。4.4 运维阶段安全方面的要求各自的安全特性。参考hadoop的结构来写。由于mpp所面向的olap数据仓库，其软件设计复杂度远没有oltp类数据库高，所以其维护一般都比较方便，一般都无需配置专职的dba。mpp数据库是成熟的商业化产品，因此一般情况下，厂商都会提供

48、相应的监控、管理、开发平台。监控管理平台示例（以greenplum为例），如下图所示greenplum commander center可对greenplum集群实时系统监控和管理，包括数据库整体运行状况、节点、硬件、网络、磁盘、sql等运行状况的实时监控。n 互动的基于web的性能监控工具n 支持邮件snmp等监控集成n 支持实时和历史视图，问题回溯n 实时资源利用情况n 实时sql执行情况n 问题和查询内部细节而开发工具方面，厂商也会提供相应的平台，除此之外还有很多第三方的开发工具，通过jdbc等接口连接，例如：squirrel sql、isql-viewer、razorsql等。开发维护

49、人员可以通过该类工具，使用sql管理和研发。4.5 培训与技术支持5 附录a-大数据技术介绍5.1 mpp数据库5.1.1 mpp数据库定义mpp数据库即大规模并行处理数据库，与其相对应的是smp（symmetrical multi-processing），是指在一个计算机上汇集了一组处理器(多cpu),各cpu之间共享内存子系统以及总线结构，多个处理器运行操作系统的单一复本。在 mpp 系统中，每个节点内的 cpu 不能直接访问另一个节点的内存，节点之间的信息交互通过节点互联网络实现，这个过程一般称为数据重分配 (data redistribution) 。因为mpp系统不共享资源（shar

50、e-nothing），资源的水平扩展比较容易实现。传统数据库采用的是shared-everything架构，早期数据库产品均采用此技术，数据库装在单台服务器上，直连存储或者硬盘。此架构只能通过增强服务器配置，采用高速存储总线和换用高速存储或者磁盘去提高性能，属于标准的scale-up扩展模式。由于单机系统的负载能力总是有限的，当系统负载达到极限时，数据库系统的整体运行效率就会严重下降。为了应对shared-everything的性能瓶颈，shared-storage架构出现，通过采用san和共享存储，由多台服务器组成数据库集群，节点之间内存可以互相访问，把计算负载分散到多个节点上去处理，从而横

51、向扩展数据库处理能力，即scale-out模式。这种架构的典型产品例如oracle rac。但该架构的性能并非线性增长，由于节点和存储之间带宽并不能无限提升，而共享存储的性能增长仍旧属于scale-up模式，当集群规模达到一定程度之后，再添加节点服务器，其性能也不会进一步增长。因为shared-storage架构在scale-out模式下走得并不彻底，从而催生了shared-nothing架构的出现，在shared-nothing模式下，数据均匀分布在多台服务器组成的集群中。每个节点存储并处理自己所拥有的数据，其自有资源以及数据均不向其他节点共享，当有sql任务要执行时，各个节点各自对数据进行

52、处理，再把结果汇总返回，这其中各家厂商都会通过自有的算法和机制确保负载是平衡的。由于数据和资源均无共享，所以其规模可以近乎于无限制的扩展，通过加入新的节点服务器，扩展处理能力和存储容量，且性能呈线性增长。常见的oltp数据库系统常常采用shared everything和shared-storage架构，而shared-nothing由于其在线性扩展能力和批量处理能力的优势，一般用在联机分析处理olap（on-line analytical processing），决策支持和数据挖掘方面。在运营商业务中，mpp适合用在ods（运营数据仓库）和edw（企业数据仓库）的搭。mpp数据库本身是标准的

53、关系型数据库，而非nosql数据库，是成熟的商业数据库产品，整合成熟的监控管理、安全和开发工具等，所以可以做到快速部署，对前台应用的改动也相对较小，也无须众多的管理维护人员。5.1.2 mpp数据库基本架构常见的mpp数据库架构如下图所示：如图所示，master节点即控制节点，其类型一般分为两种，有独立控制节点和无独立控制节点。有独立控制节点的mpp数据库，其控制节点的职能主要是建立客户端连接和管理，生成执行计划，收集各节点返回的执行结果，其上负载一般不高；而数据节点只负责数据存取与执行计算，客户端无需直接与数据节点进行交互。但在数据加载过程中，控制节点只负责调度，数据的加载不经过控制节点，而是直接在数据节点和加载服务器间进行。正常情况下，控制节点需要做冗余以实现ha。如下图所示：无独立控制节点的mpp数据库，其控制节点的职能分布在数据库的物理节点之上，可能是一台物理节点，也可能是多台物理节点，具体看厂商的架构策略而定，两种架构各有所长。无独立控制节点的mpp数据库架构如下图所示:mpp 将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。5.1.3 mpp平台技术规范和要点目前主流的mpp数据库的产品理念遵循以下标准：