Hadoop平台架构--硬件篇
还记得刚接触Hadoop的时候，还是1.x版本，硬是在⾃⼰的4GB内存上⾯弄了3个虚拟机
学习，条件有些艰苦,Hadoop测试集搭建不需要太多考虑，随着毕业开始进⼊企业，在企业中实践Hadoop，特别是⼀定规模的集，逐渐涉及到硬件资源,⽹络规划，操作系统，软件栈等⼀系列问题！对于⼀个没有经验的⼩⽩来说，还是⽐较复杂的，还好公司
有linux⼤⽜配合上我从各种技术⽹站博客吸收的微薄知识，从0开始搭建集稳定运⾏2年多，接近年关，今晚我把这些问题简单梳理⼀下，希望对出建集的同学有些许
帮助！
什么决定集规模？
Hadoop资源包括：存储和计算，对于计算资源其实初建集很难评估,
所以可以先忽略计算资源评估，单从存储指标来规划.⾸先准这个⽅向，接下来就是和数据团队沟通收集数据量，每天数据增长率，数据存储周期，尽量多了解信息，存储周期是1个⽉,3个⽉，半年来确认数据量，从⽽计算存储，从存储出发规划集是前期最合理的⽅向。
⽐如：每天增长数据量为4T, 3倍冗余，存储3个⽉为周期,⼤概存储=4T390天=1080T,
这个基础上⾯需要乘⼀个系数，考虑给⽤户，磁盘计算，临时空间留⼀部分存储，未来数据
增长趋势，分析结果存储周期占⽤空间，这些都是HDFS相关！在HDFS存储的基础上⾯，还需要考虑LinuxOS(Linux分区规划).评估完成之后，最重要的还是考虑企业的投⼊意愿
和财⼒现状.这个系数需要综合考量.如何合理规划分区，使⽤⽬录规范，存储初步确定集
规模.规划⾮常合理⽽被⽤户不合理利⽤资源，那合理的规划就变得不合理了，有关合理存储
规划请参考《》
⼯作负载 && 软件栈?
⼏乎在很多场景,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形式，异步写⼊
，⼀主多从region, 解决region offline问题！
2、Impala项⽬为Hadoop带来了可扩展的并⾏数据库技技术，使得⽤户可以向HDFS和HBase中存储的数据发起低延迟的SQL
查询，⽽且不需要数据移动或转换。Cloudera开源！
内存使⽤评估不合理，数据量太⼤,join性能低下！hive都跑完了，还没结束！
3、PrestoDb或者Drill,Presto让我们⽅便的查询Hive,Nosql(hbase,cassandra,redis),RDBMS(mysql,postgresql)；
Facebook开源！
hadoop分布式集搭建
把Hadoop和多种数据源联系起来，让Hdoop兼容更多数据源，实现⽆所不包的数据平台！
⼀切看上去都是那么美好，谁⽤谁知道…⼩声说⼀句,⽊有写磁盘功能，内存不够直接
报错,⼀部分节点失去联系，短时间使⽤不鸟了.
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基本没⼀个能跑全的！
使⽤也很多坑，谁⽤谁知道…
有关集存储格式如何选择请参考《》
我们下⾯说的硬件选型都是基于异构集！
硬件配置如何选择？
硬件的选择，要⾼配还是低配？
确定节点规模,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  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集前期硬件配置，版本选择等还有疑问欢迎讨论！
结论
购买合适的硬件，对于⼀个Hapdoop集⽽⾔，需要性能测试和细⼼的计划，从⽽全⾯理解⼯作负荷。然⽽，Hadoop集通常是⼀个形态变化的系统， ⽽Cloudera建议，在开始的时候，使⽤负载均衡的技术⽂档来部署启动的硬件。重要的是，记住，当使⽤多种体系组件的时候，资源的使⽤将会是多样的, ⽽专注与资源管理将会是你成功的关键。
原创⽂章，转载请注明： 转载⾃的博客

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。