HDFS的存储策略

我们在安装HDFS的时候,我们在hdfs-site.xml配置过DataNode的数据存储的文件目录,如下:

<property>
    <name>dfs.datanode.data.dir</name>
    <value>/home/hadoop-twq/bigdata/dfs/data</value>
    <description>DataNode存放数据的地方</description>
</property>

  目录/home/hadoop-twq/bigdata/dfs/data就是DataNode存放数据的地方,这个目录对应的存储介质就是普通的磁盘(DISK)。除了普通磁盘,存储介质其实还有固态硬盘(SSD)等。那么,在了解HDFS存储策略之前,我们先了解下HDFS支持的存储类型

存储类型

HDFS支持如下4种存储类型:

  1. DISK:表示普通磁盘(机械磁盘)
  2. SSD:表示固态硬盘
  3. RAM_DISK:表示内存硬盘,参考虚拟内存盘,说白了就是内存
  4. ARCHIVE:这个并不是特指某种存储介质,而是为了满足高密度存储而定义的一种存储类型,一般对于归档的、访问不怎么频繁的数据可以以 ARCHIVE 的形式存储。

以上四种的存储类型的存取的速度大小为:RAM_DISK->SSD->DISK->ARCHIVE。但是单bit存储成本由高到低

那么我们在配置DataNode的存储路径的时候,我们可以分别为上面四种存储类型配置存储位置,如下图:

<property>
    <name>dfs.datanode.data.dir</name>
    <value>[RAM_DISK]file:///ram_disk,[SSD]file:///ssd1/dn,[DISK]file:///disk1/dn,[ARCHIVE]file:///archive1/dn</value>
    <description>DataNode存放数据的地方</description>
</property>

 上面配置的DataNode的多个存储位置由逗号隔开,每一个存储位置由存储类型和存储物理路径组成。HDFS通过该配置感知底层存储的位置和类型

 

存储策略

上面介绍了HDFS的数据可以存储的存储类型,那么数据真实是存储在哪一中类型的存储介质中呢?这个就是HDFS存储策略需要解决的问题了。接下来,我们详细看下HDFS支持的存储策略

我们先在master机器上执行如下的命令,来查看HDFS支持的存储策略:

hdfs storagepolicies -listPolicies

  

返回结果如下:

Block Storage Policies:
	BlockStoragePolicy{COLD:2, storageTypes=[ARCHIVE], creationFallbacks=[], replicationFallbacks=[]}
	BlockStoragePolicy{WARM:5, storageTypes=[DISK, ARCHIVE], creationFallbacks=[DISK, ARCHIVE], replicationFallbacks=[DISK, ARCHIVE]}
	BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}
	BlockStoragePolicy{ONE_SSD:10, storageTypes=[SSD, DISK], creationFallbacks=[SSD, DISK], replicationFallbacks=[SSD, DISK]}
	BlockStoragePolicy{ALL_SSD:12, storageTypes=[SSD], creationFallbacks=[DISK], replicationFallbacks=[DISK]}
	BlockStoragePolicy{LAZY_PERSIST:15, storageTypes=[RAM_DISK, DISK], creationFallbacks=[DISK], replicationFallbacks=[DISK]}

 

我们分别来解释上面HDFS支持的六种存储策略:

COLD

BlockStoragePolicy{COLD:2, storageTypes=[ARCHIVE], creationFallbacks=[], replicationFallbacks=[]}

  

这个存储策略的名称是COLD,策略ID是2,存储类型是ARCHIVE。这种存储策略是用于存储冷数据,也就是很少会使用的归档数据可以设置为这个存储策略。

creationFallbacks:这个是指当创建数据块的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型

replicationFallbacks:这个是当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型

对于COLD的存储策略,所有的数据都存储在ARCHIVE存储类型对应的存储位置上,数据块创建或者复制的时候都没有备选的存储类型

WARM

BlockStoragePolicy{WARM:5, storageTypes=[DISK, ARCHIVE], creationFallbacks=[DISK, ARCHIVE], replicationFallbacks=[DISK, ARCHIVE]}

  

这个存储策略的名称是WARM,策略ID是5,存储类型是DISK, ARCHIVE半冷半热的数据可以设置这个存储策略。设置为这个存储策略的时候,如果数据块的备份数是n的话,那么,创建的第一个数据块的数据存储在DISK类型的存储目录中,其他复制的(n - 1)个数据块的数据存储在ARCHIVE类型的存储目录中。

在这种存储策略下:

当创建数据块的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是DISK, ARCHIVE

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是DISK, ARCHIVE

HOT

BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}

  

这个存储策略的名称是HOT,策略ID是7,存储类型是DISK。**热(其实就是经常会使用)**的数据可以设置这个存储策略。设置为这个存储策略的时候,如果数据块的备份数是n的话,那么,不管是新建的数据块还是复制的数据块的数据都存储在DISK类型中对应的存储位置上

在这种存储策略下:

当创建数据块的时候,没有备选存储类型

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是ARCHIVE

ONE_SSD

BlockStoragePolicy{ONE_SSD:10, storageTypes=[SSD, DISK], creationFallbacks=[SSD, DISK], replicationFallbacks=[SSD, DISK]}

  

这个存储策略的名称是ONE_SSD,策略ID是10,存储类型是SSD, DISK这个策略是HDFS的默认的数据存储策略

设置为这个存储策略的时候,如果数据块的备份数是n的话,那么,1个新建的数据块存储在SSD类型的对应的位置上,其他的(n - 1)个复制的数据块存储在DISK类型的对应的位置上。

在这种存储策略下:

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是SSD, DISK

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是SSD, DISK

ALL_SSD

BlockStoragePolicy{ALL_SSD:12, storageTypes=[SSD], creationFallbacks=[DISK], replicationFallbacks=[DISK]}

  

这个存储策略的名称是ALL_SSD,策略ID是12,存储类型是SSD。设置为这个存储策略的时候,如果数据块的备份数是n的话,那么,不管是新建的还是复制的n个数据块都存储在SSD类型对应的位置上

在这种存储策略下:

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是DISK

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是DISK

LAZY_PERSIST

BlockStoragePolicy{LAZY_PERSIST:15, storageTypes=[RAM_DISK, DISK], creationFallbacks=[DISK], replicationFallbacks=[DISK]}

  

这个存储策略的名称是LAZY_PERSIST,策略ID是15,存储类型是RAM_DISK, DISK。设置为这个存储策略的时候,如果数据块的备份数是n的话,那么,1个新建的数据块存储在RAM_DISK类型的对应的位置上,其他的(n - 1)个复制的数据块存储在DISK类型的对应的位置上。

在这种存储策略下:

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是DISK

当数据块复制的时候,如果当前存储策略指定的存储类型的空间不足的时候的备选存储类型是DISK

总结

从上我们可以看出,HDFS支持六种数据存储策略,分别是:

  1. COLD
  2. WARM
  3. HOT
  4. ONE_SSD
  5. ALL_SSD
  6. LAZY_PERSIST

按照ALL_SSD -> ONE_SSD -> HOT -> WARM -> COLD的顺序,面向的数据是越来越

LAZY_PERSIST比较特殊,如果一个文件的存储策略被指定为LAZY_PERSIST,在写入时会先写入内存,再异步地写入磁盘,即主要用来降低小数据量的写入延迟,代价是在某些情况下会有数据丢失。

官方对LAZY_PERSIST的解释如下:

Applications can choose to use Lazy Persist Writes to trade off some durability guarantees in favor of reduced latency

最后,我们用一张图表来总结上面六种存储策略:

策略ID 策略名称 数据块放置情况(n个备份) creationFallbacks replicationFallbacks
2 COLD ARCHIVE: n    
5 WARM DISK: 1, ARCHIVE: n-1 ARCHIVE, DISK ARCHIVE, DISK
7 HOT(默认策略) DISK: n   ARCHIVE
10 ONE_SSD SSD: 1, DISK: n-1 SSD, DISK SSD, DISK
12 ALL_SSD SSD: n DISK DISK
15 LAZY_PERSIST RAM_DISK: 1, DISK: n-1 DISK DISK

我们要开启HDFS的存储策略的功能的话,我们需要配置参数dfs.storage.policy.enabledtrue,当然,这个配置默认的值是true,即HDFS的默认是支持存储策略的。

存储策略的设置

我们可以先通过下面的命令来查看一个HDFS路径是否设置了存储策略:

hdfs storagepolicies -getStoragePolicy -path /user/hadoop-twq/cmd

  执行上面的命令的输出是:

The storage policy of /user/hadoop-twq/cmd is unspecified

  

说明这个路径没有设置存储路径,那么这个路劲就是用默认的存储策略,即HOT存储策略

我们可以通过下面的命令来为某个路径设置存储策略:

hdfs storagepolicies -setStoragePolicy -path /user/hadoop-twq/cmd -policy HOT

  执行上面的命令的输出是:

Set storage policy HOT on /user/hadoop-twq/cmd

  

说明文件路径/user/hadoop-twq/cmd的存储策略已经设置为HOT。我们可以再次使用下面的命令来查看这个路径的存储策略:

hdfs storagepolicies -getStoragePolicy -path /user/hadoop-twq/cmd

  这个时候的返回是:

The storage policy of /user/hadoop-twq/cmd:
BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}

  可以看出,路径/user/hadoop-twq/cmd确实被设置为HOT的存储策略

原文地址:https://www.cnblogs.com/tesla-turing/p/11487838.html

时间: 2024-10-11 20:09:39

HDFS的存储策略的相关文章

HDFS内存存储

前言 上一篇文章主要阐述了HDFS Cache缓存方面的知识,本文继续带领大家了解HDFS内存存储相关的内容.在HDFS中,CacheAdmin设置的目标文件缓存是会存放于DataNode的内存中,但是另外一种情况也可以将数据存放在DataNode的内存里.就是之前HDFS异构存储中提到的内存存储策略,LAZY_PERSIST.换句话说,本文也是对HDFS内存存储策略的一个更细致的分析.考虑到LAZY_PERSIST内存存储与其他存储策略类型的不同之处,做这样的一个分析还是比较有意义的. HDF

HDFS副本放置策略

前言 前一篇文章中刚刚分析完HDFS的异构存储以及相关的存储类型选择策略,浏览量还是不少的,说明大家对于HDFS的异构存储方面的功能还是很感兴趣的.但是其实一个文件Block块从最初的产生到最后的落盘,存储类型选择策略只是其中1步,因为存储类型选择策略只是帮你先筛选了一些符合存储类型要求的存储节点目录位置列表,通过这些候选列表,你还需要做进一步的筛选,这就是本文所准备阐述的另外一个主题,HDFS的副本放置策略.在写本文之前,我搜过网上关于此方面的资料与文章,还是有许多文章写的非常不错的,所以我会

再理解HDFS的存储机制

再理解HDFS的存储机制 1. HDFS开创性地设计出一套文件存储方式,即对文件分割后分别存放: 2. HDFS将要存储的大文件进行分割,分割后存放在既定的存储块(Block)中,并通过预先设定的优化处理,模式对存储的数据进行预处理,从而解决了大文件储存与计算的需求: 3. 一个HDFS集群包括两大部分,即NameNode与DataNode.一般来说,一个集群中会有一个NameNode和多个DataNode共同工作: 4. NameNode是集群的主服务器,主要是用于对HDFS中所有的文件及内容

Documents下存储文件被拒解决方法(文件存储策略应对)

苹果在iOS 5系统时,对app的文件存储提出了新的要求.从它的guildline来看,是推荐开发者尽量把app生成的文件放在Caches目录下的.原文如下: Only user-generated data or that cannot otherwise be recreated by your application, should be stored in the /Documents directory and rest should be stored to /Library/Cac

HDFS副本放置策略及机架感知

副本放置策略 副本放置策略的基本思想是: 第一个block副本放在和client所在的node里(如果client不在集群范围内,则这第一个node是随机选取的,当然系统会尝试不选择哪些太满或者太忙的node). 第二个副本放置在与第一个节点不同的机架中的node中(随机选择). 第三个副本和第二个在同一个机架,随机放在不同的node中. 如果还有更多的副本就随机放在集群的node里. Hadoop的副本放置策略在可靠性(block在不同的机架)和带宽(一个管道只需要穿越一个网络节点)中做了一个

利用QJM实现HDFS的HA策略部署与验证工作记录分享

1.概述  Hadoop2.X中的HDFS(Vsersion2.0)相比于Hadoop1.X增加了两个重要功能,HA和Federation.HA解决了Hadoop1.X  Namenode中一直存在的单点故障问题,HA策略通过热备的方式为主NameNode提供一个备用者,并且这个备用者的状态一直和主Namenode的元数据保持一致,一旦主NameNode挂了,备用NameNode可以立马转换变换为主NameNode,从而提供不间断的服务.另外,Federation特性,主要是允许一个 HDFS

HDFS——数据平衡策略

Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况,比如集群中添加新的数据节点.当HDFS出现不平衡状况的时候,将引发很多问题,比如MR程序无法很好地利用本地计算的优势,机器之间无法达到更好的网络带宽使用率,机器磁盘无法利用等等.可见,保证HDFS中的数据平衡是非常重要的. 在Hadoop中,包含一个Balancer程序,通过运行这个程序,可以使得HDFS集群达到一个平衡的状态,使用这个程序的命令如下: sh $HADOOP_HOME/bin/start-balancer

大数据笔记05:大数据之Hadoop的HDFS(数据管理策略)

        HDFS中数据管理与容错 1.数据块的放置       每个数据块3个副本,就像上面的数据库A一样,这是因为数据在传输过程中任何一个节点都有可能出现故障(没有办法,廉价机器就是这样的),为了保证数据不能丢失,所以存在3个副本,这样保证了硬件上的容错,保证数据传递过程中准确性.       3个副本数据,放在两个机架上.比如上面机架1存在2个副本,机架2存在1个副本.   (1)如果就像下面的DataNode1数据块无法使用了,可以在机架1上的DataNode2和DataNode3

HDFS副本选择策略

在client向DataNode写入block之前,会与NameNode有一次通信,由NameNode来选择指定数目的DataNode来存放副本.具体的副本选择策略在BlockPlacementPolicy接口中,其子类实现是BlockPlacementPolicyDefault.该类中会有多个chooseTarget()方法重载,但最终调用了下面的方法: 1 /** 2 * This is not part of the public API but is used by the unit t