HDFS异构存储篇

                HDFS异构存储篇

                                   作者:尹正杰

版权声明:原创作品,谢绝转载!否则将追究法律责任。

 

 

一.异构存储概述

1>.数据分类及存储策略概述

  通常,公司或者组织总是有相当多的历史数据占用昂贵的存储空间。对于异构公司来说,典型的数据使用模式是新传入的数据被应用程序大量使用,从而该数据被标记为""数据。随着时间的推移,存储的数据每周被访问几次,而不是一天几次,这时认为其是""数据。在接下来的几周和几个月中,数据使用率下降得更多,成为""数据。如果很少使用数据,例如每年查询一次或两次,这时甚至可以根据其年龄创建第四个数据分类,并将这组很少被查询的旧数据称为"冻结数据"。

  Hadoop允许将不是热数据或者活跃数据的数据分配到比较便宜的存储上,用于归档或冷存储。可以设置存储策略,将较旧的数据从昂贵的高性能存储上转移到性价比较低(较便宜)的存储设备上。

  Hadoop 2.5及以上版本都支持存储策略,在该策略下,不仅可以在默认的传统磁盘上存储HDFS数据,还可以在SSD(固态硬盘)上存储数据。

2>.不同存储类型的性能特点

  为了了解异构存储策略和Hadoop归档存储,我们来比较一下不同存储的性能特点。可以根据成本,介质的耐用性及其性能来比较替代存储介质。成本通常以每兆字节存储的成本来衡量。耐久性与存储介质故障率有关。性能是在吞吐量(最大读/写速率,兆字节/秒)和每秒I/O操作的基础上测量的,它受限于介质可以提供的读取和写入数据的请求速度。

  硬盘驱动器(HDD)是Hadoop的标准磁盘存储设备,可以提供相当高的吞吐量并且价格便宜。高吞吐量是批量数据处理的理想选择。但是,磁盘离可能在任意时间失败。

  固态硬盘(SSD)提供计告的吞吐量和每秒I/O,但它比磁盘存储设备贵数倍。与磁盘一样,SSD设备具有中的故障率,并且可能在任意时间失败。

  基于RAM的存储为所有类型的工作提供了极高的性能,但是其非常昂贵。RAM不提供持久存储,因为一切都存储在内存中。

  使用异构存储背后的驱动因素是成本,几乎没有计算力的archive层的每GB存储比正常磁盘存储速度便宜很多。根据节点的畜栏里能力里将存储分为多个层次,可以最佳地利用存储。Hadoop提供了一种特殊的移动工具,它可以将数据块的副本或全部副本移动到成本较低的存储中,因为随着时间的推移,数据使用的频率会降低。

3>.对异构HDFS存储的需求

  在传统上,Hadoop用于批处理,其中磁盘存储器提供批处理所需的高连续吞吐能力。Hive和其它使用Hadoop运行交互式畜栏里的应用程序更多地依赖于存储(如SSD)提供的高随机I/O性能。虽然由于成本较高,无法使用SSD设备构建整个集群,但是在同一个集群中提供多种存储类型是可写的,因此不同类型的应用程序可以选择最合适的存储设备。

  通常在Hadoop集群中存储有不同类型的数据集,不同团队运行多种类型的工作负载来处理数据。以下是随着时间的推移,数据使用的典型进展:
    (1)最初,在加载新数据之后,该数据大量使用,这时数据集被认为是热的,我们习惯称之为"热数据";
    (2)几个星期之后,此数据的使用频率下降,变为"暖数据";
    (3)几个月后,数据使用频率进一步下降,变为"冷数据";
    (4)过了很长一段使劲按后,这些数据很少被使用,可视为冻结数据,因为它旨在极少数情况下被访问;

  如下图所示,显示了Hadoop集群中各种类型的数据,以及如何将它们分配给不同的类型的存储。Hadoop的异构存储功能允许创建和维护多层存储,以反映HDFS数据随时间变化的使用模式。

 

4>.存储体系结构的变化

  在早期的Hadoop版本中,NameNode和HDFS客户端将DataNode看作有个存储单元,而没有感知到DataNode使用的存储类型。Hadoop 2.5和更高版本对HDFS存储架构进行了根本性的改造,因此DataNode允许NameNode感知不同的存储类型及其适用统计信息。这使得NameNode在放置块副本时选择具有特定存储类型的DataNode。

  DataNode在默认情况下每三秒使用TCP握手的方式向NameNode发送一次心跳(健康报告),已宣布它们活着并处于健康状态,并且此心跳还包含一个摘要存储报告,该报告记录了存储容量和使用信息。另外,DataNode发送周期性块报告(列出该DataNode上的所有块)到NameNode(第十次心跳包括块报告,因此每30秒发送一次块报告),而且这些块报告时可以是完全块报告或增量块报告。

  在早期Hadoop版本中,存储报告和块报告仅包含有关存储信息的聚合信息。在Hadoop 2.5及以上版本中,DataNode开始按使用的存储类型区分的使用情况统计信息和块报告。

  空间配额方案也已被扩展,为每个HDFS目录添加每个存储类型的空间配额。如果父目录未指定存储类型配额,则强制在该目录上创建每种存储类型的空间配额。如果父目录已经指定了每个存储类型的空间配额,则父级或子目录上的最小空间配额将是HDFS强制执行的空间配额。因此,管理员可以在父目录上指定每个存储类型的空间配额为零,以防止子目录使用该特定存储类类型中的任何空间。

5>.文件的存储首选项

  应用程序可以在创建文件时指定存储首选项,向HDFS发送关于应用程序希望存储块副本的首选项的提示。应用程序还可以修改现有文件的存储首选项。存储首选项可以包括复制因子以及文件块复制的目标存储类型。

  当应用程序指定存储首选项时,HDFS尝试满足首选项,但要考虑存储空间的可用性以及存储空间配额的可用性。如果目标存储类型没有足够的可用空间来满足首选存储类型,则将选择不同的存储类型。例如,应用程序有限使用SSD存储类型,但没有足够的SSD存储空间,这时HDFS会将副本存储在备用存储介质(如HDD)上。

 

二.设置归档存储

  为了能够维护不同的存储类型,Hadoop不仅使用磁盘进行存储,还使用备用存储介质(如SSD和内存)存储。可以将不同的存储策略于备用存储类类型进行组合,以在环境中设置Hadoop归档存储。

1>.为HDFS配置多个存储层

  HDFS管理员必须配置一些用于实现HDFS异构存储的东西。以下时需要在"hdfs-site.xml"文件中配置的参数。
    dfs.storage.policy.enabled:
       此参数用于启用或禁用异构存储策略,其默认值为"true",即允许用户更改文件和目录的存储策略。

    dfs.datanode.data.dir:
      在每个DataNode上设置此参数,应该为存储位置分配一个只是存储类型的标签。这样可根据存储策略将数据块放置在不同的存储类型上。
      官方原话:"确定DFS数据节点应在本地文件系统上的哪个位置存储其块。如果这是逗号分隔的目录列表,则数据将存储在所有命名的目录中,通常在不同的设备上。对于HDFS存储策略,应使用相应的存储类型([SSD] / [DISK] / [ARCHIVE] / [RAM_DISK])标记目录。如果目录没有显式标记的存储类型,则默认存储类型为DISK。如果本地文件系统权限允许,将创建不存在的目录。"

  一定要熟悉"dfs.datanode.data.dir"参数,它指定HDFS使用的本地存储目录。在异构的存储策略下,可以添加异构名为"StorageType"的枚举类型来指定存储层,例如指定为ARCHIVE。只需使用[ARCHIVE]前缀修饰本地目录位置即可表示此目录属于ARCHIVE存储层。
  
  接下来我们一起来看几个案例(需要注意的是,如果不标记存储类型,DataNode的存储位置的默认存储类型是传统的DISK存储类型哟~):
      为DISK存储类型上的"/yinzhengjie/data/hdfs/dn/disk01"存储位置指定存储类型方式如下:
        [DISK]file:///yinzhengjie/data/hdfs/dn/disk01
      为SSK存储类型上的"/yinzhengjie/data/hdfs/dn/ssd01"存储位置指定存储类型方式如下:
        [SSD]file:///yinzhengjie/data/hdfs/dn/ssd01
      为ARCHIVE存储类型上的"/yinzhengjie/data/hdfs/dn/archive01"存储位置指定存储类型的方式如下:
        [ARCHIVE]file:///yinzhengjie/data/hdfs/dn/archive01
      为RAM-DISK存储类型上的"/yinzhengjie/data/hdfs/dn/ram01"存储位置指定存储类型的方式如下:
        [RAM_DISK]file:///yinzhengjie/data/hdfs/dn/ram01
  
  扩容案例:
    假设集群有50个节点,每个节点有100TB的存储空间,那么总共提供了5PB的存储空间。如果现在添加另外20个节点,每个具有100TB的存储空间,则可以通过将此新存储标记为ARCHIVE来形成ARCHIVE层。
    使用[ARCHIVE]为所有新的本地存储目录添加前缀来来标记新存储。现在,集群中有两层存储,DISK层有5OB,ARCHIVE层中有2PB.

2>.不同的存储类型

  最初,只能使用一种物理存储类型,即DISK用于HDFS的数据存储。DISK是默认存储类型,但现在还可以使用ARCHIVE存储类型,它具有非常高的存储密度(PB级存储),但计算能力较低。

  除了DISK和ARCHIVE存储类型外,还可以使用SSD和RAM_DISK作为替代存储类型。SSD和RAM_DISK提供了比传统磁盘存储更好的性能。ARCHIVE存储类型也是基于磁盘的存储类型,其通过提供高存储密度和低计算能力支持归档存储。下面总结了可用的HDFS存储类型:
    DISK:
      默认的存储类型,对应于HDFS使用的标准基于磁盘的存储。
    ARCHIVE:
      基于磁盘的存档,使用密集存储节点存储历史数据或使用频率较低的数据。
    SSD:
      使用SSD存储低延迟读/写工作负载数据的闪存存储。
    RAM_DISK:
      向RAM提供单个副本写入的内存存储,对永久数据的磁盘进行异步写入。

  温馨提示:
    从Hadoop 2.5开始,可以使用StorageType枚举类型对这些存储卷进行特定类型的存储,例如归档存储和闪存存储。这里的关键思想是在DISK存储层中以较高的计算能力在节点上存储大量使用的(热)数据。
    因此,如果使用默认的HDFS复制因子3,则可用保留热数据的所有三个副本在DISK层。
    对于暖数据,可用在DISK层保留3个副本中的2个副本,并将其中异构副本移动到ARCHIVE层。
    对于冷数据,可用将2个副本移动到ARCHIVE层,在DISK层只保留1个副本。
    如果你的数据几乎是纯历史数据,则可以将其分类为冻结数据,此时将所有的3个副本移动到ARCHIVE层。

3>.多个存储策略

  HDFS允许根据预测将不同的文件存储在不同的存储类型中。可以设置以下类型的存储策略。
    HOT:
      应用于当前正在处理的数据,所有副本都存储在DISK存储类型上。
    COLD:
      这时具有优先计算能力的存储,应用于需要归档的数据,所有副本都存储在基于ARCHIVE存储类型的介质中。
    WARM:
      1个副本存储在磁盘(DISK存储类型)上,其它副本存储在归档存储(ARCHIVE存储类型)上。
    ALL_SSD:
      所有副本都存储在SSD中(在创建文件期间强制执行的策略)。
    ONE_SSD:
      1个副本存储在SSD中,其它副本存储在DISK中(在文件创建期间强制执行该策略)。
    LAZY_PERSIST:
      用于在内存中使用单个副本写入快。该策略适用于写入临时或易于重现的数据应用程序。该副本首先被发送到RAM_DISK存储类型,然后被移动到DISK存储类型。

  存储策略包含用于放置块的存储类型列表,并且有两个单独的存储类型列表(被称为回退存储类型),1个用于文件创建,另一个用于复制。当块放置的存储类型运行空间不足时,块将被放置于用于文件创建和复制的回退存储类型中。


  通过以下命令列出Hadoop支持的所有存储策略:
[root@hadoop101.yinzhengjie.com ~]# 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]}
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs storagepolicies             #该命令除了找出当前的存储策略外,还有其它作用,具体可参考"-help"对应的帮助信息。
Usage: bin/hdfs storagepolicies [COMMAND]
          [-listPolicies]
          [-setStoragePolicy -path <path> -policy <policy>]
          [-getStoragePolicy -path <path>]
          [-unsetStoragePolicy -path <path>]
          [-help <command-name>]

Generic options supported are:
-conf <configuration file>        specify an application configuration file
-D <property=value>               define a value for a given property
-fs <file:///|hdfs://namenode:port> specify default filesystem URL to use, overrides 'fs.defaultFS' property from configurations.
-jt <local|resourcemanager:port>  specify a ResourceManager
-files <file1,...>                specify a comma-separated list of files to be copied to the map reduce cluster
-libjars <jar1,...>               specify a comma-separated list of jar files to be included in the classpath
-archives <archive1,...>          specify a comma-separated list of archives to be unarchived on the compute machines

The general command line syntax is:
command [genericOptions] [commandOptions]

[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs storagepolicies -help listPolicies
[-listPolicies]

List all the existing block storage policies.
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs storagepolicies             #该命令除了找出当前的存储策略外,还有其它作用,具体可参考"-help"对应的帮助信息。

 

三.管理存储策略

温馨提示:
  通过上面的描述,我们知道"dfs.storage.policy.enabled"参数默认为"true",表示启用存储策略功能。将该参数设置为false可以禁用该功能。
[root@hadoop101.yinzhengjie.com ~]# vim ${HADOOP_HOME}/etc/hadoop/hdfs-site.xml          #假设我们有5个设备,此时我们可以设置5个挂载点,配置方式如下。(需要把配置同步到对应的DN节点哟~)
......
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>[DISK]file://${hadoop.tmp.dir}/dn1,[DISK]file://${hadoop.tmp.dir}/dn2,[ARCHIVE]file://${hadoop.tmp.dir}/dn3,[SSD]file://${hadoop.tmp.dir}/dn4,[RAM_DISK]file://${hadoop.tmp.dir}/dn5</value>        
     <description>可以只当多个目录,DN节点会根据这些提供的目录存储数据,生产环境中每个路径对应的一块磁盘挂载点,以提升I/O性能.</description>
    </property>
......
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# vim ${HADOOP_HOME}/etc/hadoop/hdfs-site.xml          #假设我们有5个设备,此时我们可以设置5个挂载点,配置方式如下。(需要把配置同步到对应的DN节点哟~)

1>.查看文件或目录的当前存储策略

[root@hadoop101.yinzhengjie.com ~]# hdfs dfs -ls /
Found 3 items
--w-------   2 jason yinzhengjie     316968 2020-08-16 11:37 /hosts
drwx------   - root  admingroup           0 2020-08-14 19:19 /user
drwxr-xr-x   - root  admingroup           0 2020-08-14 23:22 /yinzhengjie
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs storagepolicies -getStoragePolicy -path /hosts        #很明显,创建HDFS目录或文件时,默认是没有为他们附加存储策略的。
The storage policy of /hosts is unspecified
[root@hadoop101.yinzhengjie.com ~]# 

2>.为文件或目录指定存储策略

[root@hadoop101.yinzhengjie.com ~]# hdfs dfs -ls /
Found 3 items
--w-------   2 jason yinzhengjie     316968 2020-08-16 11:37 /hosts
drwx------   - root  admingroup           0 2020-08-14 19:19 /user
drwxr-xr-x   - root  admingroup           0 2020-08-14 23:22 /yinzhengjie
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs storagepolicies -setStoragePolicy -path /hosts -policy HOT      #此处我们指定存储策略为"HOT"
Set storage policy HOT on /hosts
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs storagepolicies -getStoragePolicy -path /hosts
The storage policy of /hosts:
BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}
[root@hadoop101.yinzhengjie.com ~]# 

 

四.移动数据

1>.存储策略工作原理概述

  可以将数据从Hot存储策略迁移到Warm存储策略,然后再迁移到Cold存储策略。请注意,可以将数据集的一个,两个或所有副本移动到不同的存储层,以优化对HDFS存储容量的使用。

  可以再一种类型的存储层上保留特定数据集的一些副本,其余的副本存储在其它存储类型上。访问数据的应用程序完全忽略使用多个存储层的事实。由于ARCHIVE层被设计为不具有太多(或任何)处理能力,因此在提供DISK存储的节点上运行的mapper任务需要从提供ARCHIVE存储的节点读取数据。这当然意味着集群会产生额外的网络流量用来移动数据。

  以下是存储策略工作原理的总结:
    (1)当更新文件或目录的存储策略时,HDFS不会自动强制执行新的存储策略。
    (2)不仅可以在创建文件时执行存储策略,也可以在创建文件之后执行(具体可参考上面的案例)。
    (3)首次在集群存储数据时,存储在默认的DISK层中。
    (4)基于数据的分类(由配置的存储策略指定),一个或多个副本将随时间的推移被移动到ARCHIVE层。

2>.mover工具概述

  新mover工具可以将数据从一个存储层移动到另一个存储层。它的工作原理与HDFS平衡器非常相似,只不过它是在不同的存储类型之间移动块副本。

  可以使用mover工具扫描HDFS文件,以确定块位置是否与配置的存储策略匹配。如果一个块未根据配置的存储策略存放,则mover会将副本移动到相应的存储类型。

  可以定期运行mover,将所有文件迁移到使用存储策略配置的存储类型中。

  温馨提示:
    如果将某些数据规划未ARCHIVE存储类型,但随后发现使用此数据的应用程序使用的频率远远超出了预期,则可以将该数据重新分类为"HOI"或"WARM"数据。可以将一个或多个副本移动到更快的DISK存储,而不会带来从ARCHIVE节点读取数据所造成的额外网络开销。
    假设管理员将COLD存储策略应用于要存储在归档存储层节点上的数据集。由于数据集已经存在,因此mover通过将归档数据从"WARM"存储转移到"COLD"存储来来实施"COLD"存储策略。将所有冷数据移入Hadoop归档存储是一个很好的做法。
[root@hadoop101.yinzhengjie.com ~]# hdfs mover -help                          #mover命令的关键选项说明
Usage: hdfs mover [-p <files/dirs> | -f <local file>]
    -p <files/dirs>    a space separated list of HDFS files/dirs to migrate.
    -f <local file>    a local file containing a list of HDFS files/dirs to migrate.

Generic options supported are:
-conf <configuration file>        specify an application configuration file
-D <property=value>               define a value for a given property
-fs <file:///|hdfs://namenode:port> specify default filesystem URL to use, overrides 'fs.defaultFS' property from configurations.
-jt <local|resourcemanager:port>  specify a ResourceManager
-files <file1,...>                specify a comma-separated list of files to be copied to the map reduce cluster
-libjars <jar1,...>               specify a comma-separated list of jar files to be included in the classpath
-archives <archive1,...>          specify a comma-separated list of archives to be unarchived on the compute machines

The general command line syntax is:
command [genericOptions] [commandOptions]

[root@hadoop101.yinzhengjie.com ~]# 


mover命令的关键选项说明如下:
    -p:
      指定HDFS文件或目录路的迁移列表,该选项接收以空格分割的文件或目录列表哟。
    -f:
       还可以使用包含HDFS文件和目录列表的本地文件来迁移数据,使用"-f"选项指定该文件。

温馨提示:
    除了HDFS路径和目标参数之外,mover还接收replica count作为参数。
[root@hadoop101.yinzhengjie.com ~]# hdfs mover -help              #mover命令的关键选项说明
[root@hadoop101.yinzhengjie.com ~]# hdfs mover          #直接运行不加任何参数,若不指定路径则默认将根目录("/")作为默认路径。
20/08/17 04:27:32 INFO mover.Mover: namenodes = {hdfs://hadoop101.yinzhengjie.com:9000=null}
20/08/17 04:27:33 INFO net.NetworkTopology: Adding a new node: /rack002/172.200.6.103:50010
20/08/17 04:27:33 INFO net.NetworkTopology: Adding a new node: /rack001/172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741838_1892 with size=316968 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741848_1024 with size=69 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741848_1024 with size=69 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741857_1033 with size=1331 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741857_1033 with size=1331 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741840_1016 with size=1309 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741840_1016 with size=1309 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741844_1020 with size=5701 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741838_1892 with size=316968 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741844_1020 with size=5701 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741862_1038 with size=371 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741862_1038 with size=371 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741852_1028 with size=69 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741852_1028 with size=69 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741853_1029 with size=1664 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741853_1029 with size=1664 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741858_1034 with size=5701 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741858_1034 with size=5701 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741842_1018 with size=630 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741842_1018 with size=630 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741843_1019 with size=1331 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741843_1019 with size=1331 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Start moving blk_1073741847_1023 with size=951 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:33 INFO balancer.Dispatcher: Successfully moved blk_1073741847_1023 with size=951 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:43 INFO net.NetworkTopology: Adding a new node: /rack002/172.200.6.103:50010
20/08/17 04:27:43 INFO net.NetworkTopology: Adding a new node: /rack001/172.200.6.102:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741862_1038 with size=371 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741848_1024 with size=69 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741862_1038 with size=371 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741848_1024 with size=69 from 172.200.6.102:50010:SSD to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741852_1028 with size=69 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741852_1028 with size=69 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741853_1029 with size=1664 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741857_1033 with size=1331 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741853_1029 with size=1664 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741858_1034 with size=5701 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741857_1033 with size=1331 from 172.200.6.102:50010:ARCHIVE to 172.200.6.102:50010:DISK through 172.200.6.102:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741858_1034 with size=5701 from 172.200.6.103:50010:SSD to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Start moving blk_1073741847_1023 with size=951 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
20/08/17 04:27:43 INFO balancer.Dispatcher: Successfully moved blk_1073741847_1023 with size=951 from 172.200.6.103:50010:ARCHIVE to 172.200.6.103:50010:DISK through 172.200.6.103:50010
Mover Successful: all blocks satisfy the specified storage policy. Exiting...
Aug 17, 2020 4:27:53 AM  Mover took 20sec
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs mover                 #直接运行不加任何参数,若不指定路径则默认将根目录("/")作为默认路径。
[root@hadoop101.yinzhengjie.com ~]# hdfs mover -p /yinzhengjie/        #指定迁移的目录为"/yinzhengjie",他会将该目录下的文件数据块根据存储策略移动到咱们定义的存储类型设备上。
20/08/17 04:42:11 INFO mover.Mover: namenodes = {hdfs://hadoop101.yinzhengjie.com:9000=[/yinzhengjie]}
20/08/17 04:42:12 INFO net.NetworkTopology: Adding a new node: /rack001/172.200.6.102:50010
20/08/17 04:42:12 INFO net.NetworkTopology: Adding a new node: /rack002/172.200.6.103:50010
Mover Successful: all blocks satisfy the specified storage policy. Exiting...
Aug 17, 2020 4:42:21 AM  Mover took 9sec
[root@hadoop101.yinzhengjie.com ~]# 
[root@hadoop101.yinzhengjie.com ~]# hdfs mover -p /yinzhengjie/        #指定迁移的目录为"/yinzhengjie",他会将该目录下的文件数据块根据存储策略移动到咱们定义的存储类型设备上。

 

五.实现归档的步骤

  当你看完上面4个知识点后,则可以直接忽略当前知识点,因为你自己也能总结出实现归档的步骤。

  需要注意的是,可以在每个DataNode节点上单独设置归档存储。步骤如下:
    (1)停止DataNode(hadoop-daemon.sh stop datanode)

    (2)编辑hdfs-site.xml文件,指定dfs.datanode.data.dir参数将归档存储类型分配给Datanode。由于DISK是默认的存储类型,因此不必设置DISK存储类型。但是如何指定DataNode使用ARCHIVE存储,则必须在本地文件系统路径的开头插入"[ARCHIVE]",如下所示。
        <property>
          <name>dfs.datanode.data.dir</name>
          <value>[DISK]file://${hadoop.tmp.dir}/dn1,[DISK]file://${hadoop.tmp.dir}/dn2,[ARCHIVE]file://${hadoop.tmp.dir}/dn3,[SSD]file://${hadoop.tmp.dir}/dn4,[RAM_DISK]file://${hadoop.tmp.dir}/dn5</value> 
           <description>可以只当多个目录,DN节点会根据这些提供的目录存储数据,生产环境中每个路径对应的一块磁盘挂载点,以提升I/O性能.</description>
        </property>

    (3)使用"hdfs storagepolicies -setStoragePolicy"命令设置存储策略,具体使用方式可参考我上面的案例。

    (4)启动DataNode(hadoop-daemon.sh start datanode)

    (5)由于更新了文件或目录上的存储策略,因此必须使用HDFS mover工具根据配置的新存储策略迁移块,具体使用方式可参考我上面的案例。

 

六.HDFS中的INotify(了解即可)

  在HDFS上运行的应用程序通常使用某种类型的索引或缓存部分数据,这意味着这些应用程序必须在添加或删除新文件时更新缓存和索引。因此,应用程序必须执行本质上无效的定期扫描,以保持自己所有HDFS同步。

  在Hadoop 2.6中,有一项全新的功能,称为"HDFS iNotify",当发生任何与HDFS相关的文件系统更改时,其将通知发送给应用程序。

  在应用程序需要监视Hive数据库中的文件和目录更改时可以使用HDFS iNotify功能。Solr等应用程序也需要通过文件和目录更改。有一个由第三方提供的Hadoop事件通知系统,但是在Hadoop 2.6中,HDFS通知已成为Hadoop的一个组成部分。

 

posted @ 2020-07-16 23:34  JasonYin2020  阅读(1217)  评论(0编辑  收藏  举报