设为首页 加入收藏

TOP

HDFS对象存储服务:Ozone的元数据管理
2019-02-09 00:19:51 】 浏览:43
Tags:HDFS 对象 存储 服务 Ozone 数据管理
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Androidlushangderen/article/details/74860017

前言

HDFS作为一套成熟的分布式存储系统,它能够存储TB甚至,PB规模级别的数据。依托于如此强大的存储能力,目前越来越多的公司、企业已经开始将越来越多的数据往HDFS上迁移。但是当数据量达到一定规模,HDFS不见得能承受的了。可能有人有疑问了,刚刚不是说HDFS能支撑PB规模级别的数据吗,这不是自相矛盾的说法了?其实笔者在这里想说的是元数据管理会受到瓶颈,HDFS面对如此巨大的元数据信息,凭借单单一个NameNode,是肯定撑不住。目前NameNode对于存储在HDFS内的所有文件、目录信息都存在于它的内存中。很显然,这是一个瓶颈点,当里面的文件数量越来越多的时候,NameNode所在节点的内存迟早会被撑爆的。笔者曾经在工作中发现这样一组有趣的数据:当集群内大约有1.5亿个Block块时的时候,NameNode使用的内存达到了64GB,启动的时间竟然达到10分钟以上(加载fsimage+apply editlog)。所以在这种情况下,NameNode是很容易被触发GC操作的。所以HDFS的小文件问题是很多人比较头疼的问题。往往我们再使用HDFS作数据存储时,不会特意关注其中的细节,有的时候程序写了一堆小文件进去,我们都不知道。久而久之,NameNode会维护一堆这样无效的文件信息在内存里。当然笔者本文不是讨论什么HDFS小文件问题解决方案的,而是打算介绍HDFS目前在做的一个对象存储服务Ozone的元数据管理机制。可以这么说,Ozone的原型设计在一定程度上吸取了NameNode元数据管理上的一些教训,而且它就是用来方便用户存储各式各样的小文件数据的。因为笔者最近一段时间在帮社区做Ozone方面的工作,所以这两天系统地梳理了一下,相信下面的阐述会对大家有所收获。


Ozone的概念

这里还是得先介绍一下Ozone的概念。

Ozone是什么?用来做什么的?与现有的HDFS有什么区别?

首先Ozone的定义从它的JIRA(HDFS-7240)名称就可以知道了:Object store in HDFS.笔者用最简单的一句话来概括Ozone的用途:在HDFS内部做了一个类似AWS的S3对象存储服务,内部定义的API基本也是类似的。但是有一点需要注意,Ozone功能不是在现有的NameNode-DataNode体系中做的,而是独立搞的一套,只是共用了DataNode服务。具体的架构体系笔者之前介绍过,这里内容就略去了,可见文章:HDFS对象存储--Ozone架构设计


Ozone存储概念定义

在Ozone体系内,提供存储单元的是容器(Container)的概念,这些Container是在DataNode中被划分出来的,每个Container有size大小,如果一个DataNode没有空间了,也就分配不出Container了。这些Container同样拥有副本的概念,也会形成Pipeline。所以从这个层面上讲,Ozone体系下的Container完全类似于以前HDFS下的Block概念。然后这些DataNode中的容器会被一个叫做SCM(StorageContainerManager)的服务所管理。下面为相关的结构图


可能有人比较好奇,这里Container如何存储数据呢?我们继续往下看。

在真正进行数据写入时,在Container内部会分配出Block,一个Block对应一个Key。这个Key就是对象存储中,putKey操作中的key。也就是说,在一个Container中会被Block所划分,如下图。


Block也是一个逻辑上的概念,它是反馈给外部的一个对象,使得调用方对于Container是完全透明的。在Block中,包含了2个关键信息,存储的key值与存储此Block的所有Container的位置信息。

其实从这里我们可以看到,这里有一些元信息需要被关联:

1.Key--->Container的信息。通过key找到对应的Container。

2.Container--->Pipeline。通过Container名称找到Pipeline信息,方便后续的数据写入。

2.集群内有效的Container信息。

很显然这些信息是要被SCM所持有和管理的。按照往常的逻辑,可能我们不禁会联想SCM难道也是一次性load到内存?如果分配的Block足够多,这样的信息也会挺大的,这样会重蹈NameNode的覆辙?答案在后面揭晓。


Ozone的元数据信息管理

这里终于到了我们非常关心的Ozone元数据信息管理方面的内容了。在Ozone体系内,里面的元信息主要为所有的Volume,Bucket和Key的信息,这些信息被一个叫做KSM(KeySpaceManager,类似于现有HDFS中的NameNode的角色)的服务所管理。这些信息的数量将会是很庞大的,尤其是最下层的key信息,因为一个Key对应的就是一个文件。在Ozone文档设计中,是明确说明能够支持存储10亿数量级别的Key的存储的。我们这么设想,如果10亿个文件存在NameNode里,Block数至少10亿吧,NameNode节点有256G内存估计都不管用。所以在这里,我们可以大胆猜测,Ozone绝对不会一次性将数据全落在内存里,应该采用了外部一些存储DB。笔者要揭晓最终答案了,答案就是LevelDB。我们知道LevelDB是把数据存在文件里的,它很好的一点是会将近期活跃的数据hold在内存里,不活跃的数据就会写出到磁盘上去了。LevelDB的数据存储格式是K-V存储的,所以Ozone存入内容的格式如下:

Volume/Bucket/Key---->PBObjectInfo

也就是说,它存入的对象是键值+PB对象,取出的时候做相应的反解析。所以KSM这里也会有一个LevelDB做存储。

所以总的来看,KSM用到1个LevelDB store,SCM是3个,总共就是4个。层级结构如下图所示。


当然在未来,可能会有比LevelDB性能更好的K-V存储框架,在Ozone中完全也可以进行替换,同时保证元数据的接口层不变即可。从这里我们可以看出,Ozone在设计的时候,考虑了自身系统的特点,很好的借用了外部的存储系统,来辅助系统数据的管理。


Ozone未来的展望

笔者个人觉得Ozone的设计实现是具有重要意义的,它在DataNode内抽象出了Container的概念。而Ozone对象存储,只是其中的一个服务应用,也就是说在未来,我们完全可以基于此提供其它类似服务,比如说目前还有CBlock的服务(这块笔者还没深入看过,也在HDFS-7240内开发)。如下图:


Ozone的设计吸取了HDFS NameNode服务太重的教训,做了很多的拆分剥离,KSM,SCM的出现就是典型的例子。最后希望大家能够多多关注HDFS Ozone,关注HDFS-7240,这个功能在未来几个月内很快就要问世了。


编程开发网
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇sqoop   把 hdfs 和关系型数.. 下一篇hdfs的四大机制

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

array(4) { ["type"]=> int(8) ["message"]=> string(24) "Undefined variable: jobs" ["file"]=> string(32) "/mnt/wp/cppentry/do/bencandy.php" ["line"]=> int(214) }