Hadoop平台架构--硬件篇

0顶
1踩

2016-01-29 13:32 by 副主编 mengyidan1988 评论(1) 有12193人浏览

hadoop hbase 框架

还记得刚接触Hadoop的时候,还是1.x版本,硬是在自己的4GB内存上面弄了3个虚拟机
学习,条件有些艰苦,Hadoop测试集群搭建不需要太多考虑,随着毕业开始进入企业,在企业中实践Hadoop,特别是一定规模的集群,逐渐涉及到硬件资源,网络规划,操作系统,软件栈等一系列问题！对于一个没有经验的小白来说,还是比较复杂的,还好公司有linux大牛配合上我从各种技术网站博客吸收的微薄知识，从0开始搭建集群稳定运行2年多,接近年关,今晚我把这些问题简单梳理一下,希望对出建集群的同学有些许帮助！

什么决定集群规模？
Hadoop资源包括：存储和计算,对于计算资源其实初建集群很难评估,所以可以先忽略计算资源评估，单从存储指标来规划.首先找准这个方向，接下来就是和数据团队沟通收集数据量,每天数据增长率,数据存储周期,尽量多了解信息,存储周期是1个月,3个月,半年来确认数据量,从而计算存储,从存储出发规划集群是前期最合理的方向。
比如：每天增长数据量为4T, 3倍冗余,存储3个月为周期,大概存储=4T390天=1080T,这个基础上面需要乘一个系数,考虑给用户,磁盘计算,临时空间留一部分存储,未来数据增长趋势,分析结果存储周期占用空间,这些都是HDFS相关！在HDFS存储的基础上面,还需要考虑LinuxOS(Linux分区规划).评估完成之后，最重要的还是考虑企业的投入意愿和财力现状.这个系数需要综合考量.如何合理规划分区,使用目录规范,存储初步确定集群规模.规划非常合理而被用户不合理利用资源,那合理的规划就变得不合理了,有关合理存储规划请参考《Hadoop平台架构—存储篇》

工作负载 && 软件栈?
几乎在很多场景,MapRdeuce或者说分布式架构,都会在IO受限,硬盘或者网络读取数据
遇到瓶颈.处理数据瓶颈CPU受限.大量的硬盘读写数据是海量数据分析常见情况！
IO受限例子：

索引
分组
数据倒入导出
数据移动和转换

CPU受限例子：

聚类/分类
复杂的文本挖掘
特征提取
用户画像
自然语言处理

目前Hadoop发展为一个无所不包的数据平台,所以不仅仅是MapReudce使用,多种计算模型可插拔和Hadoop无缝结合,Hadoop2.x版本Yarn资源管理器,可以兼容多种技术模型；如：内存计算代表的saprk,impala,tez,drill,presto.磁盘计算代表的hive,mapreduce,pig. 对于一个异构集群,会同时存在多种计算模型！在硬件配置上面就需要高内存,大磁盘; Impala推荐最低配置128G内存,才能发挥优势；spark典型的CPU密集型,需要更多CPU和内存。Hive,MR磁盘计算,多磁盘读写比较频繁！当你在为集群硬件选型的时候，需要考虑的软件组件包括Apache HBase、Cloudera Impala、Presto Or Drill、Apache Phoenix和Apache spark。
1、Hbase是一个可靠的列数据存储系统，它提供一致性、低延迟和随机读写。region的一些坑,在Hbase1.0+版本提供新的API，访问集群类似JDBC形式,增加了异步写入API，一主多从region, 解决region offline问题；Hbase-Region-split-policy！
2、Impala项目为Hadoop带来了可扩展的并行数据库技技术,使得用户可以向HDFS和HBase中存储的数据发起低延迟的SQL查询，而且不需要数据移动或转换。Cloudera开源;内存使用评估不合理,数据量太大,join性能低下！hive都跑完了,还没结束！
3、PrestoDb或者Drill,Presto让我们方便的查询Hive,Nosql(hbase,cassandra,redis),RDBMS(mysql,postgresql)；Facebook开源;有商业公司在支持;功能是把Hadoop和多种数据源联系起来,让Hadoop兼容更多数据源,实现无所不包的数据平台！一切看上去都是那么美好谁用谁知道…小声说一句木有写磁盘功能,内存不够直接报错,一部分节点失去联系，短时间使用不鸟了.
4、Drill和Presto非常类似可以支持SQL直接查询很多数据源：Hive,HDFS,Hbase,MongoDB,S3,RDBMS(Mysql,Oracle,postgresql,SQLServer)；MapR主推;把Hadoop和多种数据源联系起来,让Hdoop兼容更多数据源,实现无所不包的数据平台！
5、Hive提供稳定和可靠的SQL分析海量数据,也是最早的SQL on Hadoop解决方案！
6、Tez,HDP主推,可以替代Hive底层执行引擎MR,让hive拥有内存计算相当的性能！生产有使用过,可靠稳定,join有些时候不如Hive！
7、spark,对于这个框架,让人又爱又恨,主要用在机器学习和图计算吧！
SparkSQL做过一些性能测试,性能并没有外界宣称的那么牛X,生产环境也用过,
说多了都是泪啊,SQL模块投入力度比较小,也是最易用的吧,很多SQL on Hadoop方案都比它做的好,所以呵呵..！spark 1.6 新版Dataset API更好的内存管理,钨丝计划等提升性能！Spark宣传做的非常好；我们使用下来SQL性能不如其他方案,稳定性不够好！executor假死,甚至退出无法恢复,稳定性还不如Tez吧！当然也可能
是我们技术能力不够吧！用来做机器学习,图计算,通过API开发数据清洗入库Hbase
提供查询！替代MR做开发是一种选择吧！SQL模块Join性能低下,单表查询性能ok！
8、Phoenix,SQL-on-Hbase解决方案！这是除了Hive/Impala on Hbase比较好的方案,Phoenix底层是调用Hbase API实现查询,所以能用到Hbase的优化器,社区跟进Hbase也很快,是一个不错的方案！
SQL on Hadoop我个人花费了大量精力做性能测试,可能个人技术能力有限无法做到全面
，目前对于亿级表,足够大内存，全方位比较 Imapla > PrestoDb > SparkSQL > Tez > Drill > Hive。当然比如20-30亿单表查询检索PrestoDb,SparkSql,Hive能很快完成,而Impala写了磁盘,或某些节点压力太大崩溃了,性能急剧下降！针对这些SQL,NOSQL产品我们技术选型的时候做过tpch,tpcds,ycbs,业务场景等性能测试！目前
市面上开源的SQL-on-Hadoop基本没一个能跑全的！使用也很多坑,谁用谁知道…
有关集群存储格式如何选择请参考《Hadoop平台架构—存储篇》

引用

我们下面说的硬件选型都是基于异构集群！

硬件配置如何选择？
硬件的选择,要高配还是低配？
确定节点规模,cpu、内存、磁盘配比？

1、节点规模按照,数据增长率+浮动系数确定！弹性扩展节点,容灾,HA高可靠方面！
单个节点故障，对于20节点集群,计算能力失去20%,对于100节点的集群计算能力失去
1%。如果没有自动化,监控管理也是一大成本！
2、初建立集群建议考虑主流配置,平衡集群资源,存储不够,调整搞压缩比例算法,拿
CPU换存储；当CPU不足，以网络宽带换CPU。集群拥有多个机架，考虑Hdoop的机架感知
功能的配置！
3、软件层面的资源管理，比如所以计算框架都在Yarn申请资源,需要分配资源池等.有关各种软件层面的优化请参考相关yarn资源调优内容！
4、硬件配置参考

异构集群

小集群,次多增加硬件,规格不一致,需要考虑资源利用率问题？

注意：1块盘3T 理论大小应为 3*1024G =3096G 实际大小3000G，而我们实际计算时使用的是1024.

Hadoop版本如何选择？
在Hadoop的发行版包括：Apache hadoop、Cloudera cdh，Hortonworks HDP 。后两者是商业团队在原生apache hadoop之上做一些优化和调整,目前我们
主要选择Cloudera Hadoop发行版,如果公司有研发能力能够同时跟进几条Hdoop
家族软件发展，并且能fix bug，使用更多新功能新特性，可以考虑Apache Hdoop版本。
Cloudera CDH版本,基于Cloudrea强大的研发能力,能很快修复bug,更加可靠稳定，一套
好用ClouderaManager监控方案！如果你选择HDP版本，其实也和选择Apache版本比较接近了,HDP版本有商业公司支持,但是基本就是把开源的Hadoop家族做了一个安装包,号称是基于完全开源的软件栈构建，而权限控制模块是不开源的,和自己的基于完全开源
口号有些背道而驰；选择商业发行版,在搭建基础环境上面少浪费一些时间,可以多把时
间花在应用层面，你说你搭建个基础集群环境都弄几天，使用一个安装包,几个小时
就完成就专注于应用层面！甚至可以做出一键批量安装,从硬件上架通电之后,linux系统安装完成之后,集群就可以使用了！完全的自动化！配合好用的监控图标
降低运维成本！
当然,选择商业发行版,可定制性就低一些,重大bug需要等待新版本的发布.而且
某些Hadoop软件栈由于竞争或者某些利益关系,而在发行版中被砍掉,比如在CDH
版本中SparkSQL是被砍掉的,虽然两家公司在合作,也有hive on spark项目,但是
相对来说是有点抢Impala生意的！我们的做法是自己编译spark版本在CDH集群中
独立模式部署一套Spark集群,但是比如on Yarn模式是无法使用的！SparkSQL独立
模式和CDH其他组件配置使用时没有任何问题。比如资源管理就不能都统一在Yarn
管理！对于维护和使用都造成一定的麻烦！

节点该如何分配？
Hadoop包括两类节点：

引用

Master： CPU：16CPU*4核 ;内存：128G-512G; HA 需要两台Namenode,配置一致！

Slave: CPU：8CPU*4核-16CPU*4核;内存：16G-24G128G-256G;配置最好一致,如果不一致,资源分配需要着重考虑！

LinuxOS: redhat 6.3 or CentOS 6.6,NameNode节点存储区做RAID1！Datanode节点磁盘JBOD安装，无RAID。Linux系统盘做RAID1

硬件配置如果存在一定的差异需要考虑资源利用率问题！特别注意有单点的问题的统一放到一台主机！

集中式Master，将SPOF单点集中到一起:Namenode HA,HMaster HA,Spark Master,
JobTracker/ResourceManager HA ,Hive Metastore,HiveServer2,Impala StateStore,
Catalog Server,impala-LLAMA HA,Oozie,Sentry,Hue

Slave,例如：Impalad,TaskTracker/Nodemanager,RegionServer,spark worker

计算资源统一交给yarn分配,所有的作业分组，按部门，不同的作业类型,划分不同
的资源池，每个部门和作业类型分组，放入不同的资源池处理.有关资源分配内容,
请参考《Yarn资源分配性能调优》，Map slot,Reduce slot这些值怎么来的,Yarn的资源池
,Hadoop-2.6新功能,Hadoop YARN新特性—label based scheduling,基于标签的调度策略！
怎么优化来提升性能，怎么合理利用资源！请参考更多相关文章！
如果你对初建Hadoop集群前期硬件配置,版本选择等还有疑问欢迎讨论！

Yarn资源分配性能调优

结论
购买合适的硬件，对于一个Hapdoop群集而言，需要性能测试和细心的计划，从而全面理解工作负荷。然而，Hadoop群集通常是一个形态变化的系统，而Cloudera建议，在开始的时候，使用负载均衡的技术文档来部署启动的硬件。重要的是，记住，当使用多种体系组件的时候，资源的使用将会是多样的, 而专注与资源管理将会是你成功的关键。
参考：http://www.itweet.cn

本文转自：whoami的博客