来自： http://www.itweet.cn/2016/01/25/Hadoop-Disk-Planning/

刚刚开始使用Hadoop集群的时候,目录没有有个规范,大家都根据自己的喜好
创建各种不同的目录,权限控制也没有开启,随着应用越来越多，使用的人员也
多了起来，导致目录混乱,终于在新规划集群的时候,对目录做了规范和权限控制.
下面简单介绍一下我们HDFS目录规范和HDFS存储规划,希望对初建Hadoop集群的
同学能有一些帮助。

简介

Hadoop的目的是基于一种新的方法来存储和处理复杂的数据。通过把数据均衡分布
到集群上,通过复制副本以确保数据的可靠性和容错。存储和计算都分布到多个机器,
充分体现数据的本地性,现在的很多数据库也都支持数据分片技术，通过把传统的个
人英雄主义转变为集团作战，英雄难觅，普通人确很容易寻找。
就如超强一体机和普通PC Server对比，一个价格高昂甚至需要定制,价格高到连
淘宝这样的土豪公司都难以承受,提出去IOE的口号,Oracle一体机确实比较贵,而小型的Pc Server容易购买。由于是量产机型,成本低。而Hadoop就是可以运行在低配置的Pc Server服务器上面的分布式集群技术,通过把海量数据分布式存储后,通过分布式计算模型
来进行海量数据分析。通俗易懂点说，就是把一台超级服务器跑10天完成的任务,交给20台
小型机构建的集群20分钟完成！而且20小型Pc机是一台超级服务器价格的20%！相比较之下
优势明显：

- 效率提高 - 弹性扩容 - 价格优势 - 弹性计算

这就是分布式存储和计算的巨大好处！

走向分布式

一个系统走向分布式，一定有其不得不为的理由。
可扩展性是最常见的理由之一。

我先简单的将“可伸缩”的需求分成两种：

• Data Scalability: 单台机器的容量不足以 (经济的) 承载所有资料，所以需要             分散。如：NoSQL  • Computing Scalability: 单台机器的运算能力不足以 (经济的) 及时完成运算所                     以需要分散。如：科学运算。不管是哪一种需求，在决定采用分布式架构时，               就几乎注定要接受一些牺牲：        

• 1.牺牲效率：网路延迟与节点间的协调，都会降低执行效率。
• 2.牺牲 AP 弹性：有些在单机上能执行的运算，无法轻易在分布式环境中完成。
• 3.牺牲维护维运能力：分散式架构的问题常常很难重现，也很难追踪.另外，跟单机系统一样，也有一些系统设计上的 tradeoffs(权衡)
• 4.CPU 使用效率优化或是 IO 效率优化
• 5.读取优化或是写入优化
• 6.吞吐率优化或是 网络延迟优化
• 7.资料一致性或是资料可得性,选择了不同的 tradeoff，就会有不同的系统架构。

存储规划

Hadoop资源包含：存储和计算。前期你对计算资源其实很难评估，建议初期可以忽略计算资源的评估，单纯从存储这个指标来规划。那么我们的存储应该怎么选择？这个需要根据平台数据增长率来计算，也因为Hadoop集群后期可以水平扩展。一般的公司很难遇到瓶颈。

一个真实的案例,我们平台新规划一个集群,某种数据来源,每天增长的数据为4T,我们3被冗余,以不同存储周期规划如下：

评估硬件存储：

我们的业务是IO密集型+CPU密集型都有的业务,一个系统中既有离线任务(mr,hive),
也有基于内存计算(hbase,impala,spark),流计算(storm,sparkstreaming)等多种类型
的作业,长ETL任务,短SQL-on-Hadoop任务,SQL-on-Hbase的实时入库查询！对内存,
网络,CPU,磁盘IO都会在不同的时间段有瓶颈！目前我们计算资源是统一由Yarn来,
并且在同一个集群拥有不同的机器配置(最初我们只有mr,hive任务，随着内存技术
发展和成熟，引进了impala,spark等技术，刚开始20个节点,32G内存,32T磁盘,
引入内存技术后,新购10台服务器是128G内存,113T磁盘,主机资源不一致,
资源分配就遇到一个大问题？),刚开始我们是使用对集群角色分组,
比如Datanode分为3组,不同组机器配置不同,但是慢慢我们发现集群资源利用
率并不高,某些机器资源利用率很低,后期慢慢的引入了Yarn的资源池,Label
based scheduling基于标签的调度机制，并且升级了Hadoop版本,它可以跟其他调度
策略混合使用！基于标签的调度策略是hadoop yarn新引入的feature，它能让
YARN更好地运行在异构集群中，进而更好地管理和调度混合类型的应用程序。

• 1、Linux系统所在磁盘制作Raid1,需要损失一块盘，比如：一台主机12块盘，2块盘做raid1安装linux os，则hdfs使用9块盘！
• 2、Namenode配置,比如做了HA,就需要2台cpu,mem强大的机器,磁盘存储小的服务器！
  比如：XeonE7-4880v2(2.5GHz/15c)/8.0GT/37.5ML3 * 4 Member: 512G or 256G
• 3、Datanode配置,XeonE5-2660v3(2.6GHz/10c)/9.6GT/25ML3 * 2 Member：128G
• 4、根据存储周期划分,一台主机123T磁盘,Namenode不计入存储,Datanode节点linux os 使用2块3T盘raid1,103T=30T做为HDFS存储！
• 5、比如存储周期是1个月,hdfs存储=4T303=360T,考虑分析结果数据预估存储20%=72T,内存计算,磁盘计算需要计算空间=HDFS总存储30%,考虑零时空间,测试数据等！HDFS总存储5%
• 6、综合上面几点,HDFS总存储=720T,Datanode数n=(720T+n3T2)/123=24台,2台Namenode,1台客户机,总共24+2+1=27台！
  公式,N主机数：N=(720T+N3T2)/123T

注意：这里的值都是预估值,刚开始可以这样规划,由于Hadoop可以弹性扩容,后期可以
可以增加主机,这里Datanode 主机采用CentOS-6.6_X86-64系统,并且系统做了radi1,
其实如果不甘心损失那么多存储,Datanode主机可以不用做raid,HDFS存储全都做成
JBOD安装，无RAID。我们自然有我们的考量,如果你有觉得不妥的欢迎指正.详细选型
主机配置请参考：《Hadoop平台架构—硬件篇》

HDFS目录规划

底层数据存储规划，这个模块比较重要，由于前期建设规划不合理，导致数据存储目录规划混乱，导致很多数据存储目录很深，在清理hdfs存储空间的时候，造成了不小的麻烦，所以重新规划了目录分布！底层操作系统默认raid5.戴尔服务器.后修改为系统盘raid1(两块盘做radi1),总共11块盘一台机器。其余盘做JBOD！

linux os目录规划

1

Linux系统分区方案说明：  在很多业务服务器数量多且复杂的运维场景，会有专门的系统安装工程师，由于这些基础系统安装工程师无法确定服务器的业务需求，因此，会根据公司的要求只分出：      /boot   200M      Swap    内存*2      /   （列如： 100G）  然后剩余的分区保留不分，fdisk(不适合大于2t的分区)，parted(适合大于2T的分区)  这样后续使用的服务器的不同业务产品的运维部门就可以根据具体的业务在规划后面的分区，这样的方法也是值得推荐的分区思路！    上面的/data{1..10}目录，表示，如果有10块硬盘，挂载点为10个目录，取名/data1, /data2, /data3, / data..这些目录都用来存储hdfs数据的数据目录！  有关根目录/ ，主要是存储/var，/home，/tmp，/opt等！

linux主机名规划

hdfs目录规划

计算框架临时目录

由于数据量越来越大，检索数据太大，导致无法所有数据放入内存，很多中间结果数据会写到磁盘，目前规划总存储的20%做为计算磁盘空间！如果低于20%，计算的时候会导致磁盘空间不足的情况，或者很多任务出现警告和运行缓慢等情况！

存储格式选择和效率如何权衡？

1 

  组件      格式     数据量     压缩大小   原始大小      Imapla    Parquet  ?           30.1 G     98.6 G    Sparksql  Parquet  ?           69.4 G     98.6 G    Hive      Rcfile   ?           93.4 G     98.6 G    Presto    Orcfile  ?           16.2 G     98.6 G      Hbase     Snappy   ?           0.35T      2.3T    # 每天入hbase数据量        注意：考虑生成压缩文件的效率,时间换空间的操作！    >>>>>>>>Txt格式        组件                  耗时        Hive                  342.235s        Presto                73.4s        Impala                20.57s        Sparksql              169.465s        Sparksql[chache]      95.9s      >>>>>>>>Parquet格式         组件                  耗时         Hive                  322.201s         Presto                37.91s         Impala                17.57s         Sparksql              124.9s         Sparksql[chache]      108s    >>>>>>>>Orc格式         组件                  耗时         Hive                  276.179s         Presto                101.4s         Impala                0s  #不支持此格式         Sparksql              46s         Sparksql[chache]      35s    >>>>>>>>RcFile格式         组件                  耗时         Hive                  306.264s         Presto                36s         Impala                18.14s         Sparksql              177.799s         Sparksql[chache]      176.5s    >>>>>>>>>>>>>2组join FcFile文件格式         组件             耗时         其它问题记录         Hive             1600s          Presto           700s          Impala           1175.29s            Sparksql         689.047s         Sparksql[chache]              效率提升不明显,未测试                  组件              耗时        其它问题记录         Hive              300s           Presto            60s          Impala            2.67s         Sparksql          40 s         Sparksql[chache]              效率提升不明显,未测试    >>>>>>>>>>>>>>>>>大大表两两关联（亿级+百万级）测试  ==>TextFile         组件         耗时       其它问题记录         Hive         641.937s     第一次执行                  Impala       267.526s     第一次执行         Impala       262.727s     第二次执行         Spark-sql    300.355s     第一次执行         Spark-sql    294.922s     第二次执行    ==>Parquet         组件        耗时        其它问题记录         Hive        57.702s      第一次执行                  Impala      1.359s       第一次执行         Impala      1.232s       第二次执行         Spark-sql   2.977s       第一次执行         Spark-sql   2.857s       第二次执行    Hadoop压缩算法选择：    •mapreduce.map.output.compress.codec     •mapreduce.output.fileoutputformat.compress.codec     •mapreduce.output.fileoutputformat.compress.type       – org.apache.hadoop.io.compress.DefaultCodec       – org.apache.hadoop.io.compress.SnappyCodec [最佳选择]      – org.apache.hadoop.io.compress.BZip2Codec /GzipCodec【GzipCodec压缩最高，但是时间上比较耗时】

结束语

这是我对于Hadoop存储硬件规划的一个小小总结，如有不妥之处欢迎指正,如果想了解非常详细的硬件参数,欢迎参考《Hadoop平台架构—硬件篇》

参考：http://www.itweet.cn

原创文章，转载请注明： 转载自whoami的博客
本博客的文章集合: http://www.itweet.cn/archives/