1 HDFS数据存储与数据管理
1.1 HDFS REST HTTP API
我们之前所学习的HDFS shell客户端和Java客户端,都客户端上安装了HDFS客户端。之前我们在windows上也配置了HDFS的windows版本客户端,否则,我们将无法操作HDFS。而且,客户端的版本如果不匹配,有可能会导致无法操作。接下来,我们将学习几种基于HTTP协议的客户端,HTTP是跨平台的,它不要求客户端上必须安装Hadoop,就可以直接操作HDFS。
1.1.1 WebHDFS
概述:WebHDFS其实是HDFS提供的HTTP RESTFul API接口,并且它是独立于Hadoop的版本的,它支持HDFS的完整FileSystem / FileContext接口。它可以让客户端发送http请求的方式来操作HDFS,而无需安装Hadoop。
在我们经常使用的HDFS Web UI,它就是基于webhdfs来操作HDFS的。
1.1.2 关于RESTful
1.1.2.1 REST
- REST(表现层状态转换,英语:Representational State Transfer)是Roy Thomas Fielding博士于2000年在博士论文中提出来的一种万维网软件架构风格,目的是便于不同软件/程序在网络(例如互联网)中互相传递信息。
- REST是基于超文本传输协议(HTTP)之上而确定的一组约束和属性,是一种设计提供万维网络服务的软件构建风格。符合或兼容于这种架构风格(简称为 REST 或 RESTful)的网络服务,允许客户端发出以统一资源标识符访问和操作网络资源的请求,而与预先定义好的无状态操作集一致化。
- 因此REST提供了在互联网络的计算系统之间,彼此资源可交互使用的协作性质(interoperability)。相对于其它种类的网络服务,例如SOAP服务,则是以本身所定义的操作集,来访问网络上的资源。
- 目前在三种主流的Web服务实现方案中,因为REST模式与复杂的SOAP和XML-RPC相比更加简洁,越来越多的Web服务开始采用REST风格设计和实现。例如,Amazon.com提供接近REST风格的Web服务运行图书查询;雅虎提供的Web服务也是REST风格的。
- 需要注意的是,REST是设计风格而不是标准。REST通常基于HTTP、URI、XML以及HTML这些现有的广泛流行的协议和标准。
- 资源是由URI来指定。
- 对资源的操作包括获取、创建、修改和删除,这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
- 通过操作资源的表现形式来操作资源。
- 资源的表现形式则是XML或者HTML,取决于读者是机器还是人、是消费Web服务的客户软件还是Web浏览器。当然也可以是任何其他的格式,例如JSON。
1.1.2.2 RESTFul API
概述:符合REST设计风格的Web API称为RESTful API。它从以下三个方面资源进行定义:
- 直观简短的资源地址:URI,比如:
http://example.com/resources
- 传输的资源:Web服务接受与返回的互联网媒体类型,比如:JSON,XML,YAML等
- 对资源的操作:Web服务在该资源上所支持的一系列请求方法(比如:POST,GET,PUT或DELETE)。
资源 | GET | PUT | POST | DELETE |
---|---|---|---|---|
一组资源的URI,比如 https://example.com/resources | 列出URI,以及该资源组中每个资源的详细信息。 | 使用给定的一组资源替换当前整组资源。 | 在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。 | 删除整组资源。 |
单个资源的URI,比如https://example.com/resources/142 | 获取指定的资源的详细信息,格式可以自选一个合适的网络媒体类型(比如:XML、JSON等) | 替换/创建指定的资源。并将其追加到相应的资源组中。 | 把指定的资源当做一个资源组,并在其下创建/追加一个新的元素,使其隶属于当前资源。 | 删除指定的元素。 |
- PUT和DELETE方法是幂等方法
- GET方法是安全方法(不会对服务器端有修改,因此当然也是幂等的)
PUT请求类型和POST请求类型的区别:
- PUT和POST均可用于创建或者更新某个资源(例如:添加一个用户、添加一个文件),用哪种请求方式取决我们自己。
- 我们主要使用是否需要有幂等性来判断到底用PUT、还是POST。PUT是幂等的,也就是将一个对象进行两次PUT操作,是不会起作用的。而如果使用POST,会同时收到两个请求。
1.1.3 HDFS HTTP RESTFUL API
HDFS HTTP RESTFUL API它支持以下操作:
HTTP GET:
- OPEN (等同于FileSystem.open)
- GETFILESTATUS (等同于FileSystem.getFileStatus)
- LISTSTATUS (等同于FileSystem.listStatus)
- LISTSTATUS_BATCH (等同于FileSystem.listStatusIterator)
- GETCONTENTSUMMARY (等同于FileSystem.getContentSummary)
- GETQUOTAUSAGE (等同于FileSystem.getQuotaUsage)
- GETFILECHECKSUM (等同于FileSystem.getFileChecksum)
- GETHOMEDIRECTORY (等同于FileSystem.getHomeDirectory)
- GETDELEGATIONTOKEN (等同于FileSystem.getDelegationToken)
- GETTRASHROOT (等同于FileSystem.getTrashRoot)
- GETXATTRS (等同于FileSystem.getXAttr)
- GETXATTRS (等同于FileSystem.getXAttrs)
- GETXATTRS (等同于FileSystem.getXAttrs)
- LISTXATTRS (等同于FileSystem.listXAttrs)
- CHECKACCESS (等同于FileSystem.access)
- GETALLSTORAGEPOLICY (等同于FileSystem.getAllStoragePolicies)
- GETSTORAGEPOLICY (等同于FileSystem.getStoragePolicy)
- GETSNAPSHOTDIFF
- GETSNAPSHOTTABLEDIRECTORYLIST
- GETECPOLICY (等同于HDFSErasureCoding.getErasureCodingPolicy)
- GETFILEBLOCKLOCATIONS (等同于FileSystem.getFileBlockLocations)
HTTP PUT:
- CREATE (等同于FileSystem.create)
- MKDIRS (等同于FileSystem.mkdirs)
- CREATESYMLINK (等同于FileContext.createSymlink)
- RENAME (等同于FileSystem.rename)
- SETREPLICATION (等同于FileSystem.setReplication)
- SETOWNER (等同于FileSystem.setOwner)
- SETPERMISSION (等同于FileSystem.setPermission)
- SETTIMES (等同于FileSystem.setTimes)
- RENEWDELEGATIONTOKEN (等同于DelegationTokenAuthenticator.renewDelegationToken)
- CANCELDELEGATIONTOKEN (等同于DelegationTokenAuthenticator.cancelDelegationToken)
- CREATESNAPSHOT (等同于FileSystem.createSnapshot)
- RENAMESNAPSHOT (等同于FileSystem.renameSnapshot)
- SETXATTR (等同于FileSystem.setXAttr)
- REMOVEXATTR (等同于FileSystem.removeXAttr)
- SETSTORAGEPOLICY (等同于FileSystem.setStoragePolicy)
- ENABLEECPOLICY (等同于HDFSErasureCoding.enablePolicy)
- DISABLEECPOLICY (等同于HDFSErasureCoding.disablePolicy)
- SETECPOLICY (等同于HDFSErasureCoding.setErasureCodingPolicy)
HTTP POST:
- APPEND (等同于FileSystem.append)
- CONCAT (等同于FileSystem.concat)
- TRUNCATE (等同于FileSystem.truncate)
- UNSETSTORAGEPOLICY (等同于FileSystem.unsetStoragePolicy)
- UNSETECPOLICY (等同于HDFSErasureCoding.unsetErasureCodingPolicy)
HTTP DELETE:
- DELETE (等同于FileSystem.delete)
- DELETESNAPSHOT (等同于FileSystem.deleteSnapshot)
1.1.4 文件系统URL和HTTP URL
WebHDFS的文件系统schema是webhdfs://。WebHDFS文件系统URL具有以下格式。
webhdfs://<HOST>:<HTTP_PORT>/<PATH>
上面的WebHDFS URL对应于下面的HDFS URL。
hdfs://<HOST>:<RPC_PORT>/<PATH>
在RESTAPI中,在路径中插入前缀“/webhdfs/v1”,并在末尾追加一个查询。因此,对应的HTTPURL具有以下格式。
http://<HOST>:<HTTP_PORT>/webhdfs/v1/<PATH>?op=...
请求URL:http://node1.itcast.cn:9870/webhdfs/v1/?op=LISTSTATUS
该操作表示要查看根目录下的所有文件以及目录,相当于 hdfs dfs -ls /
1.1.5 webHDFS创建文件
在/data/hdfs-test目录中创建一个名字为webhdfs_api.txt文件,并写入内容。
创建一个请求,设置请求方式为PUT,请求url为:
http://node1.itcast.cn:9870/webhdfs/v1/data/hdfs-test/webhdfs_api.txt?op=CREATE&overwrite=true&replication=2&noredirect=true
HTTP会响应一个用于上传数据的URL链接。
- 提交HTTP PUT请求,而不会自动跟随重定向,也不会发送文件数据。
- 通常,请求被重定向到要写入文件数据的DataNode。
- 如果不希望自动重定向,则可以设置noredirected标志。
1.1.6 webHDFS写入数据
使用Location标头中的URL提交另一个HTTP PUT请求(如果指定了noredirect,则返回返回的响应),并写入要写入的文件数据。
curl -i -X PUT -T <LOCAL_FILE> "http://<DATANODE>:<PORT>/webhdfs/v1/<PATH>?op=CREATE..."
- LOCAL_FILE 为本地文件地址
- PATH为创建文件放回的URL链接
1.2 HttpFS
概述:
- HttpHDFS本质上和WebHDFS是一样的,都是提供HTTP REST API功能,但它们的区别是HttpHDFS是HttpFS,是一个独立于HadoopNameNode的服务,它本身就是Java JettyWeb应用程序。
- 因为是可以独立部署的,所以可以对HttpHDFS设置防火墙,而避免NameNode暴露在墙外,对一些安全性要求比较高的系统,HttpHDFS会更好些。
- HttpFS是一种服务器,它提供REST HTTP网关,支持所有HDFS文件系统操作(读和写)。并且它可以与WebhdfsREST HTTPAPI
- HttpFS可用于在运行不同版本Hadoop(克服RPC版本控制问题)的集群之间传输数据,例如使用HadoopDiscreCP。
- HttpFS可用于在防火墙后面的集群上访问HDFS中的数据(HttpFS服务器充当网关,是允许跨越防火墙进入集群的唯一系统)。
- HttpFS可以使用HTTP实用程序(例如curl和wget)和来自Java以外的其他语言的HTTP库Perl来访问HDFS中的数据。
- 这个Webhdfs客户端文件系统实现可以使用Hadoop文件系统命令访问HttpFS(hdfsdfs)行工具以及使用Hadoop文件系统JavaAPI的Java应用程序。
- HttpFS内置了支持Hadoop伪身份验证和HTTP、SPNEGOKerberos和其他可插拔身份验证机制的安全性。它还提供Hadoop代理用户支持。
操作方式:
- HttpFS是一个独立于HadoopNameNode的服务。
- HttpFS本身就是Java JettyWeb应用程序。
- HttpFS HTTP Web服务API调用是HTTPREST调用,映射到HDFS文件系统操作。例如,使用curl/Unix命令:
$curl ‘http://httpfs-host:14000/webhdfs/v1/user/foo/README.txt?op=OPEN&user.name=foo’
返回HDFS的内容/user/foo/README.txt档案。
$curl ‘http://httpfs-host:14000/webhdfs/v1/user/foo?op=LISTSTATUS&user.name=foo’
返回HDFS的内容/user/foo目录中的JSON格式。
$curl ‘http://httpfs-host:14000/webhdfs/v1/user/foo?op=GETTRASHROOT&user.name=foo’
返回路径/user/foo/.trash,如果/是加密区域,则返回路径。/.Trash/Foo。看见更多细节关于加密区域中的垃圾路径。
$curl -X POST‘http://httpfs-host:14000/webhdfs/v1/user/foo/bar?op=MKDIRS&user.name=foo’
创建HDFS/user/foo/bar目录。
- HttpFS默认端口号为14000
1.2.1 配置Hadoop-HttpFS
1 编辑Hadoop的core-site.xml,并将运行HttpFS服务器的Unix用户定义为proxyuser。例如:
<property>
<name>hadoop.proxyuser.#HTTPFSUSER#.hosts</name>
<value>httpfs-host.foo.com</value>
</property>
<property>
<name>hadoop.proxyuser.#HTTPFSUSER#.groups</name>
<value>*</value>
</property>
2 重要:替换#HTTPFSUSER#使用将启动HttpFS服务器的Unix用户。
例如:
<property>
<name>hadoop.proxyuser.root.hosts</name>
<value>*</value>
</property>
<property>
<name>hadoop.proxyuser.root.groups</name>
<value>*</value>
</property>
3 重启Hadoop
4 启动HttpFS
hdfs --daemon start httpfs
5 测试HttpFS工作
http://node1.itcast.cn:14000/webhdfs/v1?user.name=root&op=LISTSTATUS
1.2.2 WebHDFS和HttpFS之间区别
webHDFS
- HDFS内置、默认开启
- 基于REST的HDFS API
- 重定向到资源所在的datanode
- 客户端会和nn、dn交互
httpFS
- 独立服务,手动开启
- 基于REST的HDFS API
- 数据先传输到该httpfs server,再由其传输到client
- 客户端不跟hdfs直接交互
2 Hadoop常用文件存储格式
概述:
-
文件格式是定义数据文件系统中存储的一种方式,可以在文件中存储各种数据结构,特别是Row、Map,数组以及字符串,数字等。
-
在Hadoop中,没有默认的文件格式,格式的选择取决于其用途。而选择一种优秀、适合的数据存储格式是非常重要的。
-
后续我们要学习的,使用HDFS的应用程序(例如MapReduce或Spark)性能中的最大问题、瓶颈是在特定位置查找数据的时间和写入到另一个位置的时间,而且管理大量数据的处理和存储也很复杂(例如:数据的格式会不断变化,原来一行有12列,后面要存储20列)。
-
Hadoop文件格式发展了好一段时间,这些文件存储格式可以解决大部分问题。我们在开发大数据中,选择合适的文件格式可能会带来一些明显的好处:
- 可以保证写入的速度
- 可以保证读取的速度
- 文件是可被切分的
- 对压缩支持友好
- 支持schema的更改
-
某些文件格式是为通用设计的(如MapReduce或Spark),而其他文件则是针对更特定的场景,有些在设计时考虑了特定的数据特征。因此,确实有很多选择。
-
每种格式都有优点和缺点,数据处理的不同阶段可以使用不同的格式才会更有效率。通过选择一种格式,最大程度地发挥该存储格式的优势,最小化劣势。
2.1 行式存储、列式存储
行式存储(Row-Based):同一行数据存储在一起。
列式存储(Column-Based):同一列数据存储在一起。
优缺点:
- 行存储的写入是一次性完成,消耗的时间比列存储少,并且能够保证数据的完整性,缺点是数据读取过程中会产生冗余数据,如果只有少量数据,此影响可以忽略;数量大可能会影响到数据的处理效率。行适合插入、不适合查询。
- 列存储在写入效率、保证数据完整性上都不如行存储,它的优势是在读取过程,不会产生冗余数据,这对数据完整性要求不高的大数据处理领域,比如互联网,犹为重要。列适合查询,不适合插入。
2.2 Hadoop的文件类型
2.2.1 Text File
- 文本格式是Hadoop生态系统内部和外部的最常见格式。通常按行存储,以回车换行符区分不同行数据。
- 最大缺点是,它不支持块级别压缩,因此在进行压缩时会带来较高的读取成本。
- 解析开销一般会比二进制格式高,尤其是XML 和JSON,它们的解析开销比Textfile还要大。
- 易读性好。
- 常见类型有:txt、xml、csv、json等
2.2.2 Sequence File
- Sequence File,每条数据记录(record)都是以key、value键值对进行序列化存储(二进制格式)。
- 序列化文件与文本文件相比更紧凑,支持record级、block块级压缩。压缩的同时支持文件切分。
- 通常把Sequence file作为中间数据存储格式。例如:将大量小文件合并放入到一个Sequence File中。
- record就是一个kv键值对。其中数据保存在value中。可以选择是否针对value进行压缩。
- block就是多个record的集合。block级别压缩性能更好。
2.2.3 Avro File
- Apache Avro是与语言无关的序列化系统,由Hadoop创始人 Doug Cutting开发
- Avro是基于行的存储格式,它在每个文件中都包含JSON格式的schema定义,从而提高了互操作性并允许schema的变化(删除列、添加列)。除了支持可切分以外,还支持块压缩。
- Avro是一种自描述格式,它将数据的schema直接编码存储在文件中,可以用来存储复杂结构的数据。
- Avro直接将一行数据序列化在一个block中.
- 适合于大量频繁写入宽表数据(字段多列多)的场景,其序列化反序列化很快。
2.2.4 RCFile
- Hive Record Columnar File(记录列文件),这种类型的文件首先将数据按行划分为行组,然后在行组内部将数据存储在列中。很适合在数仓中执行分析。且支持压缩、切分
- 但不支持schema扩展,如果要添加新的列,则必须重写文件,这会降低操作效率。
2.2.5 ORC File
- ORC File(Optimized Row Columnar)提供了比RC File更有效的文件格式。它在内部将数据划分为默认大小为250M的Stripe。每个条带均包含索引,数据和页脚。索引存储每列的最大值和最小值以及列中每一行的位置。
- 它并不是一个单纯的列式存储格式,仍然是首先根据Stripe分割整个表,在每一个Stripe内进行按列存储。
- ORC有多种文件压缩方式,并且有着很高的压缩比。文件是可切分(Split)的。
- ORC文件是以二进制方式存储的,所以是不可以直接读取。
2.2.6 Parquet File
- Parquet是面向分析型业务的列式存储格式,由Twitter和Cloudera合作开发,2015年5月从Apache的孵化器里毕业成为Apache顶级项目。
- Parquet文件是以二进制方式存储的,所以是不可以直接读取的,文件中包括该文件的数据和元数据,因此Parquet格式文件是自解析的。
- 支持块压缩。
结构:
- Parquet 的存储模型主要由行组(Row Group)、列块(Column Chuck)、页(Page)组成。
- 在水平方向上将数据划分为行组,默认行组大小与HDFS Block 块大小对齐,Parquet 保证一个行组会被一个 Mapper 处理。行组中每一列保存在一个列块中,一个列块具有相同的数据类型,不同的列块可以使用不同的压缩。Parquet 是页存储方式,每一个列块包含多个页,一个页是最小的编码的单位,同一列块的不同页可以使用不同的编码方式。
- 文件的首位都是该文件的Magic Code,用于校验它是否是一个Parquet文件。
2.2.7 Apache Arrow
概述:
-
Apache Arrow是一个跨语言平台,是一种列式内存数据结构,主要用于构建数据系统。
-
Apache Arrow在2016年2月17日作为顶级Apache项目引入。
-
Arrow促进了许多组件之间的通信。
-
极大的缩减了通信时候序列化、反序列化所浪费的时间。
性能提高:
- 利用Arrow作为内存中数据表示的两个过程可以将数据从一种方法“重定向”到另一种方法,而无需序列化或反序列化。例如,Spark可以使用Python进程发送Arrow数据来执行用户定义的函数。
- 无需进行反序列化,可以直接从启用了Arrow的数据存储系统中接收Arrow数据。 例如,Kudu可以将Arrow数据直接发送到Impala进行分析。
- Arrow的设计针对嵌套结构化数据(例如在Impala或Spark Data框架中)的分析性能进行了优化。
3 Hadoop文件压缩
压缩算法优劣指标:
- 压缩比:原先占100份空间的东西经压缩之后变成了占20份空间,那么压缩比就是5,显然压缩比越高越好。
- 压缩/解压缩吞吐量(时间):每秒能压缩或解压缩多少MB的数据。吞吐量也是越高越好。
- 压缩算法实现是否简单、开源
- 是否为无损压缩。恢复效果要好。
- 压缩后的文件是否支持split(切分)
3.1 hadoop支持的文件压缩对比
压缩格式 | 工具 | 算法 | 文件扩展名 | 是否可切分 | 对应的编码解码器 |
---|---|---|---|---|---|
DEFLATE | 无 | DEFLATE | .deflate | 否 | org.apache.hadoop.io.compress.DefaultCodec |
Gzip | gzip | gzip | .gz | 否 | org.apache.hadoop.io.compress.GzipCodec |
bzip2 | bzip2 | bzip2 | .bz2 | 是 | org.apache.hadoop.io.compress.BZip2Codec |
LZO | lzop | LZO | .lzo | 是(切分点索引) | com.hadoop.compression.lzo.LzopCodec |
LZ4 | 无 | LZ4 | .lz4 | 否 | org.apache.hadoop.io.compress.Lz4Codec |
Snappy | 无 | Snappy | .snappy | 否 | org.apache.hadoop.io.compress.SnappyCodec |
- 压缩比
- 压缩、解压缩时间
使用原则:
- 压缩的合理使用可以提高HDFS存储效率
- 压缩解压缩意味着CPU、内存需要参与编码解码
- 选择压缩算法时不能一味追求某一指标极致。综合考虑性价比较高的。
- 文件的压缩解压需要程序或者工具的参与来对数据进行处理。大数据相关处理软件都支持直接设置。
4 HDFS异构存储和存储策略
4.1 HDFS异构存储类型
冷、热、温、冻数据
通常,公司或者组织总是有相当多的历史数据占用昂贵的存储空间。典型的数据使用模式是新传入的数据被应用程序大量使用,从而该数据被标记为"热"数据。随着时间的推移,存储的数据每周被访问几次,而不是一天几次,这时认为其是"暖"数据。在接下来的几周和几个月中,数据使用率下降得更多,成为"冷"数据。如果很少使用数据,例如每年查询一次或两次,这时甚至可以根据其年龄创建第四个数据分类,并将这组很少被查询的旧数据称为"冻结数据"。
Hadoop允许将不是热数据或者活跃数据的数据分配到比较便宜的存储上,用于归档或冷存储。可以设置存储策略,将较旧的数据从昂贵的高性能存储上转移到性价比较低(较便宜)的存储设备上。
Hadoop 2.5及以上版本都支持存储策略,在该策略下,不仅可以在默认的传统磁盘上存储HDFS数据,还可以在SSD(固态硬盘)上存储数据。
异构存储概述:
- 异构存储是Hadoop2.6.0版本出现的新特性,可以根据各个存储介质读写特性不同进行选择。
- 例如冷热数据的存储,对冷数据采取容量大,读写性能不高的存储介质如机械硬盘,对于热数据,可使用SSD硬盘存储。
- 在读写效率上性能差距大。异构特性允许我们对不同文件选择不同的存储介质进行保存,以实现机器性能的最大化。
HDFS中声明定义了4种异构存储类型:
- RAM_DISK(内存)
- SSD(固态硬盘)
- DISK(机械硬盘),默认使用。
- ARCHIVE(高密度存储介质,存储档案历史数据)
问:如何让HDFS知道集群中的数据存储目录是哪种类型存储介质?
答:配置属性时主动声明。HDFS并没有自动检测的能力。
配置参数dfs.datanode.data.dir = [SSD]file:///grid/dn/ssdO
如果目录前没有带上[SSD] [DISK] [ARCHIVE] [RAM_DISK] 这4种类型中的任何一种,则默认是DISK类型 。
4.2 块存储类型选择策略
概述:
- 块存储指的是对HDFS文件的数据块副本储存。
- 对于数据的存储介质,HDFS的BlockStoragePolicySuite类内部定义了6种策略。
- HOT(默认策略):用于存储和计算。流行且仍用于处理的数据将保留在此策略中。所有副本都存储在DISK中。
- COLD:仅适用于计算量有限的存储。不再使用的数据或需要归档的数据从热存储移动到冷存储。所有副本都存储在ARCHIVE中。
- WARM:部分热和部分冷。热时,其某些副本存储在DISK中,其余副本存储在ARCHIVE中。
- ALL_SSD:将所有副本存储在SSD中。
- ONE_SSD:用于将副本之一存储在SSD中。其余副本存储在DISK中。
- LAZY_PERSIST:用于在内存中写入具有单个副本的块。首先将副本写入RAM_DISK,然后将其延迟保存在DISK中。
- 前三种根据冷热数据区分,后三种根据磁盘性质区分。
4.3 块存储类型选择策略–命令
- 列出所有存储策略
hdfs storagepolicies -listPolicies
- 设置存储策略
hdfs storagepolicies -setStoragePolicy -path <path> -policy <policy>
- 取消存储策略
hdfs storagepolicies -unsetStoragePolicy -path <path>
在执行unset命令之后,将应用当前目录最近的祖先存储策略,如果没有任何祖先的策略,则将应用默认的存储策略。
- 获取存储策略
hdfs storagepolicies -getStoragePolicy -path <path>
4.3 HDFS内存存储策略支持
LAZY PERSIST介绍:
- HDFS支持把数据写入由DataNode管理的堆外内存;
- DataNode异步地将内存中数据刷新到磁盘,从而减少代价较高的磁盘IO操作,这种写入称为 Lazy Persist写入。
- 该特性从Apache Hadoop 2.6.0开始支持。
LAZY PERSIST执行流程:
- 对目标文件目录设置 StoragePolicy 为 LAZY_PERSIST 的内存存储策略 。
- 客户端进程向 NameNode 发起创建/写文件的请求 。
- 客户端请求到具体的 DataNode 后 DataNode 会把这些数据块写入 RAM 内存中,同时启动异步线程服务将内存数据持久化写到磁盘上。
- 内存的异步持久化存储是指数据不是马上落盘,而是懒惰的、延时地进行处理。
LAZY PERSIST设置使用:
- Step1:虚拟内存盘配置
mount -t tmpfs -o size=1g tmpfs /mnt/dn-tmpfs/
将tmpfs挂载到目录/mnt/dn-tmpfs/,并且限制内存使用大小为1GB 。
- Step2:内存存储介质设置
将机器中已经完成好的虚拟内存盘配置到dfs.datanode.data.dir 中,其次还要带上 RAM_DISK 标签.
- Step3:参数设置优化
dfs.storage.policy.enabled
是否开启异构存储,默认true开启
dfs.datanode.max.locked.memory
用于在数据节点上的内存中缓存块副本的内存量(以字节为单位)。默认情况下,此参数设置为0,这将禁用 内存中缓存。内存值过小会导致内存中的总的可存储的数据块变少,但如果超过 DataNode 能承受的最大内 存大小的话,部分内存块会被直接移出 。
- Step4:在目录上设置存储策略
hdfs storagepolicies -setStoragePolicy -path <path> -policy LAZY_PERSIST
mnt/dn-tmpfs/,并且限制内存使用大小为1GB 。
- Step2:内存存储介质设置
将机器中已经完成好的虚拟内存盘配置到dfs.datanode.data.dir 中,其次还要带上 RAM_DISK 标签.
[外链图片转存中…(img-gJq9FwH8-1668077793343)]
- Step3:参数设置优化
dfs.storage.policy.enabled
是否开启异构存储,默认true开启
dfs.datanode.max.locked.memory
用于在数据节点上的内存中缓存块副本的内存量(以字节为单位)。默认情况下,此参数设置为0,这将禁用 内存中缓存。内存值过小会导致内存中的总的可存储的数据块变少,但如果超过 DataNode 能承受的最大内 存大小的话,部分内存块会被直接移出 。
- Step4:在目录上设置存储策略
hdfs storagepolicies -setStoragePolicy -path <path> -policy LAZY_PERSIST