Hadoop平台架构--存储篇
刚刚开始使用Hadoop集群的时候,目录没有个规范,大家都根据自己的喜好创建各种不同的目录,权限控制也没有开启。随着应用越来越多，使用的人员也多了起来，导致目录混乱,因此在新规划集群的时候,对目录做了规范和权限控制.
下面简单介绍一下我们HDFS目录规范和HDFS存储规划。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-Data | gz | 4T | 4T*3=12T | 2302859808 | 43429 | 360T | 720T | 1080T | 集群硬件规划 |
评估硬件存储：
| 总存储 | HDFS总存储 | 数据存储 | 数据类型 | 存储周期 | 30%计算空间(预留来自HDFS) | linux os | 存储评估 |
|---|---|---|---|---|---|---|---|
| 864 T | 720 T | 464T | XX-HTTP-Data+应用分析结果数据 | 1个月 | 216 T | 40T | 存储评估 |
我们的业务是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目录规划
| 目录 | 大小 | Linux版本 |
|---|---|---|
| /boot | 1024M | CentOS 6.6 |
| /boot | 1024M | CentOS 6.6 |
| /swap | 内存大小*{1~2} | CentOS 6.6 |
| / | 60G | CentOS 6.6 |
| /var | 针对两个主节点100G,其余节点50G | CentOS 6.6 |
| /data{1..10} | Hdfs数据 | CentOS 6.6 |
| /tmp | 40G | CentOS 6.6 |
| /home | 80G | CentOS 6.6 |
1 2 3 4 5 6 7 8 9 10 |
Linux系统分区方案说明： 在很多业务服务器数量多且复杂的运维场景，会有专门的系统安装工程师，由于这些基础系统安装工程师无法确定服务器的业务需求，因此，会根据公司的要求只分出： /boot 200M Swap 内存*2 / （列如： 100G） 然后剩余的分区保留不分，fdisk(不适合大于2t的分区)，parted(适合大于2T的分区) 这样后续使用的服务器的不同业务产品的运维部门就可以根据具体的业务在规划后面的分区，这样的方法也是值得推荐的分区思路！ 上面的/{1..10}目录，表示，如果有10块硬盘，挂载点为10个目录，取名/data1, /data2, /data3, / ..这些目录都用来存储hdfs数据的数据目录！ 有关根目录/ ，主要是存储/var，/home，/tmp，/等！ |
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平台架构–硬件篇》