HDFS异构存储篇
HDFS异构存储篇
node
做者：尹正杰数据库
版权声明：原创做品，谢绝转载！不然将追究法律责任。vim
一.异构存储概述缓存
1>.数据分类及存储策略概述网络
一般，公司或者组织老是有至关多的历史数据占用昂贵的存储空间。对于异构公司来讲，典型的数据使用模式是新传入的数据被应用程序大量使用，从而该数据被标记为"热"数据。随着时间的推移，存储的数据每周被访问几回，而不是一天几回，这时认为其是"暖"数据。在接下来的几周和几个月中，数据使用率降低得更多，成为"冷"数据。若是不多使用数据，例如每一年查询一次或两次，这时甚至能够根据其年龄建立第四个数据分类，并将这组不多被查询的旧数据称为"冻结数据"。 Hadoop容许将不是热数据或者活跃数据的数据分配到比较便宜的存储上，用于归档或冷存储。能够设置存储策略，将较旧的数据从昂贵的高性能存储上转移到性价比较低(较便宜)的存储设备上。 Hadoop 2.5及以上版本都支持存储策略，在该策略下，不只能够在默认的传统磁盘上存储HDFS数据，还能够在SSD(固态硬盘)上存储数据。
2>.不一样存储类型的性能特色架构
为了了解异构存储策略和Hadoop归档存储，咱们来比较一下不一样存储的性能特色。能够根据成本，介质的耐用性及其性能来比较替代存储介质。成本一般以每兆字节存储的成原本衡量。耐久性与存储介质故障率有关。性能是在吞吐量(最大读/写速率，兆字节/秒)和每秒I/O操做的基础上测量的，它受限于介质能够提供的读取和写入数据的请求速度。 硬盘驱动器(HDD)是Hadoop的标准磁盘存储设备，能够提供至关高的吞吐量而且价格便宜。高吞吐量是批量数据处理的理想选择。可是，磁盘离可能在任意时间失败。 固态硬盘(SSD)提供计告的吞吐量和每秒I/O,但它比磁盘存储设备贵数倍。与磁盘同样，SSD设备具备中的故障率，而且可能在任意时间失败。 基于RAM的存储为全部类型的工做提供了极高的性能，可是其很是昂贵。RAM不提供持久存储，由于一切都存储在内存中。 使用异构存储背后的驱动因素是成本，几乎没有计算力的archive层的每GB存储比正常磁盘存储速度便宜不少。根据节点的畜栏里能力里将存储分为多个层次，能够最佳地利用存储。Hadoop提供了一种特殊的移动工具，它能够将数据块的副本或所有副本移动到成本较低的存储中，由于随着时间的推移，数据使用的频率会下降。
3>.对异构HDFS存储的需求app
在传统上，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>.文件的存储首选项ide
应用程序能够在建立文件时指定存储首选项，向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 ~]#
三.管理存储策略
舒适提示: 经过上面的描述，咱们知道"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 ~]#
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 #直接运行不加任何参数，若不指定路径则默认将根目录("/")做为默认路径。 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 -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 ~]#
五.实现归档的步骤
当你看完上面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的一个组成部分。
相关文章
- 1. HDFS异构存储
- 2. HDFS异构存储实战
- 3. HDFS异构存储机制
- 4. HDFS的异构存储测试
- 5. HDFS异构存储机制研究
- 6. HDFS_异构存储
- 7. [技术笔记][Hadoop][HDFS]异构存储-存储类型与策略
- 8. Hadoop存储——HDFS
- 9. HBase&HDFS异构存储的使用&简单介绍
- 10. HDFS存储结构剖析（HADOOP）
- 更多相关文章...
- • MySQL存储过程简介 - MySQL教程
- • MySQL存储引擎精讲（附带各种存储引擎的对比） - MySQL教程
- • 三篇文章了解 TiDB 技术内幕——说存储
- • 再有人问你分布式事务，把这篇扔给他
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. HDFS异构存储
- 2. HDFS异构存储实战
- 3. HDFS异构存储机制
- 4. HDFS的异构存储测试
- 5. HDFS异构存储机制研究
- 6. HDFS_异构存储
- 7. [技术笔记][Hadoop][HDFS]异构存储-存储类型与策略
- 8. Hadoop存储——HDFS
- 9. HBase&HDFS异构存储的使用&简单介绍
- 10. HDFS存储结构剖析（HADOOP）