Hadoop平台架构--硬件篇

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

什么决定集群规模?

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包括两类节点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
  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.cloudera.com/content/www/en-us/documentation.html
http://blog.cloudera.com/
http://docs.hortonworks.com/
http://databricks.com/blog

原创文章,转载请注明: 转载自Itweet的博客
本博客的文章集合: http://www.itweet.cn/blog/archive/