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形式,增加了异步写入api，一主多从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兼容更多数据源,实现无所不包的数据平台！一切看上去都是那么美好谁用谁知道…小声说一句木有写磁盘功能,内存不够直接报错,一部分节点失去联系，短时间使用不鸟了.
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包括两类节点：



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

本文转自：

来自: