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

简介

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被冗余,以不同存储周期规划如下：








数据源数据格式数据大小/天数据3倍镜像冗余/天数据条数/天文件个数/天存储周期(1个月)存储周期(2个月)存储周期(3个月)硬件评估
XX-HTTP-Datagz4T4T*3=12T230285980843429360T720T1080T集群硬件规划

评估硬件存储：








总存储HDFS总存储数据存储数据类型存储周期30%计算空间(预留来自HDFS)linux os存储评估
864 T720 T464TXX-HTTP-Data+应用分析结果数据1个月
216 T40T存储评估

我们的业务是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+N    3T2)/123T

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

HDFS目录规划

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

linux os目录规划





























目录 大小 Linux版本
/boot1024MCentOS 6.6
/boot1024MCentOS 6.6
/swap内存大小*{1~2}CentOS 6.6
/60GCentOS 6.6
/var针对两个主节点100G,其余节点50GCentOS 6.6
/data{1..10}Hdfs数据CentOS 6.6
/tmp40GCentOS 6.6
/home80GCentOS 6.6
1
2
3
4
5
6
7
8
9
10
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主机名规划








目录 Linux版本
bigdata-server{01…100} CentOS 6.6

hdfs目录规划



































目录 含义 Linux版本
/data/external 外部抽取数据源存储路径 CentOS 6.6
/data/external/db 表示oracle-数据 CentOS 6.6
/data/external/ftp 表示从ftp获取的数据 CentOS 6.6
/user/hive/warehouse 各种内部表库地址 CentOS 6.6
/tmp 用来存储一些临时数据文件，每周清理一遍 CentOS 6.6
/xxx 一些默认自动生成的目录 CentOS 6.6
/apps App运行所需jar包 CentOS 6.6
/scripts 各种脚本备份路径 CentOS 6.6
/user 用户空间，存储用户私有数据，仅用户自己可以访问. CentOS 6.6
/hbase Hbase HDFS数据目录 CentOS 6.6

计算框架临时目录

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
  组件      格式     数据量     压缩大小   原始大小

  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平台架构–硬件篇》