HDFS对象存储--Ozone架构设计

最新推荐文章于 2024-09-25 07:30:00 发布
最新推荐文章于 2024-09-25 07:30:00 发布
阅读量8.5k 收藏 12
点赞数 4
分类专栏： Hadoop HDFS Ozone 文章标签： 对象存储 hadoop hdfs ozone
Hadoop 同时被 3 个专栏收录
181 篇文章 28 订阅
订阅专栏
HDFS
123 篇文章 48 订阅
订阅专栏
Ozone
60 篇文章 32 订阅
订阅专栏

前言

现在做云存储的公司很多,举2个比较典型的AWS的S3和阿里云.他们都提供了一个叫做对象存储的服务,就是目标数据是从Object中进行读写的,然后可以通过key来获取对应的Object,就是所谓的key-object的存储.这样的好处就在于用户使用起来很方便的,不需要走冗杂的操作流程.但是本文所要阐述的则是HDFS中的对象存储,对于这样的需求,Hadoop作为一套完善的分布式系统,当然也要与时俱进,在HDFS-7240中进行了实现,目前此功能真在开发中,名叫Ozone,内部有很多的概念与业界的都是类似的,例如Bucket,Object等.下面是本人对于Ozone设计文档的一个译文,可能会有翻译不到位的地方,附上原文链接:Ozone-architecture-v1.pdf

目录

  1. 介绍
    1.1 基本要求
    1.2 大小要求

  2. 高层次设计
    2.1 与HDFS共享Datanode Storage存储
    2.2 Storage Container存储容器
    2.3 Storage Container Identifier存储容器标志符
    2.4 Storage Container存储容器服务的调用
    2.5 Datanode中的Ozone Handler
    2.6 Storage Container Manager存储容器管理器

  3. 具体实现
    3.1 对象键值到存储容器的映射
    3.2 范围分区Vs哈希分区
    3.3 bucket到存储容器的映射
    3.4 Storage Container存储容器的要求
    3.5 Storage Container存储容器实现要点
    3.6 Pipeline数据一致性

  4. 未来工作
    4.1 Ozone API
    4.2 集群层级API
    4.3 Storage Volumes层级API
    4.4 Bucket层级API
    4.5 Object层级API

  5. 引用

介绍

Ozone提供了一个key-object键值-对象存储的服务,类似AWS的S3服务. Key和Object对象是随机的字节数组.单个key的大小期望是小于1k,但是values对象可以从小到几百字节大到几百兆.键值/对象被组织进了bucket的概念中.一个bucket拥有唯一的key集合.Bucket存在于Storage-Volume中,并且在Storage-Volume中拥有唯一的名字.一个storage volume拥有全局唯一的名字.更近一步的说,storage volume对buckets和存储的数据有配额上的限制.在私有云中,它可以被用来创建给用户(例如home目录),工程项目,或者租有者.管理员可以分配一定配额限制的私有storage volume给个体用户或者公有的共享storage volume.在公有云中,多storage volume可以以独立的配额分配在每个云中.
一个bucket被2部分名字的组合唯一标识: storage-volumeName/bucketName.一个对象的名字被storage-volumeName/bucketName/objectKey 3部分所标识.
我们的模式类似于Azure Blob Storage(WASB).他们的bucket在每个帐户中是唯一的.但是,我们用storage volume来取代了这个帐户概念.因此相比之下,S3的bucket在所有帐号中保持唯一.
数据的组织结构可以以下面的图形进行展示.
这里写图片描述

基本要求

Ozone中基本的操作如下(API方法在文档尾部将会给出):

  • 管理员创建Storage Volume.
  • 创建/删除 buckets.每个bucket拥有一个独立的URL.Buckets不能被重命名.只有storage volume的所属者或所属组才能创建/删除volume中的bucket.
  • 在一个storage volume中列出buckets列表.
  • 根据给定的key在bucket中创建/删除object对象.对象的数据或值可以流式的传输到Ozone服务中.当对象被写满的时候将只会允许读操作.同时不保证对象的局部写.
  • 列举出bucket的内容
  • 创建/更新/删除 buckets的ACL访问控制列表

大小要求

本节列举了少部分的限制值来具体化一些要求.下面是目标版本1的一些指标:

  • Storage Volume名字: 3~64字节
  • Bucket 名称: 3~64字节
  • Key大小: 1KB
  • Object大小: 5G
  • 系统总buckets数量: 1000w
  • 每个bucket中对象数量: 100w
  • 每个storage volume中的bucket数: 1000

Ozone元数据包括以下内容:

  • Storage Volume层级元数据
    • Storage volume所属者
    • Storage Volume名称
  • Bucket层级元数据
    • Bucket所属者: 拥有此bucket中数据的所属用户.
    • Bucket ACL访问控制信息
    • 全局唯一的Bucket名称
    • Bucket Id: 与bucket相关的系统产生的数字型的标识

高层级设计

与HDFS共享Datanode数据存储

DataNode同时为HDFS和Ozone存储数据.Ozone的数据用的是独立的blockPool并拥有独立的blockPool Id.也就是说可以同时存在多种volume命名空间,每个volume有属于自己的block pool.同样的可以同时存在多个独立的Ozone命名空间在所属的block pool下.一个DN可以同时存储多个HDFS和Ozone的block pool.此关系结构如下图所示:
这里写图片描述

Storage Container容器

一个storage container从概念上来说,指的是用来存储Ozone数据(就是bucket中的数据)和Ozone元数据的一个存储单元.Storage container与HDFS的block一样,共同存储于DataNode上.但是与HDFS不同的一点,Ozone没有一个类似于NameNode的中心节点,相反地,他是一个分离的元数据的存储.这些元数据分布式的存在于各个storage container中.每个storage container以whole的形式存在(类似于HDFS中的block).我们对container副本的成功操作保证了强一致性.Storage container的最大值的大小取决于他的副本复制能力以及从节点故障中恢复的能力.最大值的大小是可配的,但是他至少要大于一个简单对象所允许的最大值.

一个bucket可以拥有百万数量级的对象并且在存储的大小级别上可以达到T级别,这远远大于一个storage container.因此一个bucket会被分为很多partion分区,每片分区会存储在一个container中.(一个storage container可以包含最大值数量的的分区,然而对象只能来自一个bucket.)在我们的初始设计实现中,一个object对象是完全存在于一个单一的container中,这么做后面可能会轻松一些.

Storage container是靠DataNode来实现的(用户可以通过配置来禁用此功能如果用户只需要使用HDFS的block功能).本节定义了storage container的一些语义和要求.Storage container需要存储以下多种类型的数据,每类数据有略微不同的语义:

  • Bucket元数据

    • 个体单元的数据是非常小的-kb级别.每个storage container可以保存上百万bucket的元数据.
    • 这点要求能够更新,因为一个bucket的ACL是能够被更新的,并且要能保证操作的原子性.
    • 满足基本的Get/Put的API设计已经足够.
    • 在container中能执行列表操作以便展示所有的bucket.

  • Bucket数据

    • Storage container需要能够存储小到几百kb大到上百mb的对象数据.
    • 对象需要通过对象的key进行访问(所以container存储数据也必须包含存储对象的索引).
    • 必须能支持个体对象读写的流式API.
    • 数据中的对象不支持追加写以及原地更新.

在后面的小节,我们将阐述DataNode如何实现storage container来达到以上的要求.

Storage Container标识符

每个storage container都被独立的storage container标识符所独立标识.它是一个逻辑上的独立标识(类似于HDFS中的blockId)并且不包含真正意义上container的网络位置.

对象的key会映射到storage container标识符.这个标识符会传入storage container manager管理器去定位包含目标对象container所在的DataNode.类似的,bucket的名称也会映射到storage container标识符,这个container保存有bucket的元数据.在后面的小节中,我们会具体提到这个映射关系是如何实现的.Storage container标识符是64位的,类似于hdfs中的block id.在未来,我们将把它扩展到128位.但是那将会是一个大的改变,因为我们想尽可能的复用hdfs的block管理器相关的代码.

Storage Container Service中的过程调用

下面的图形展示了Ozone中的典型过程调用,其中主要包含了Storage Container Service服务和Ozone Handler处理器:
这里写图片描述

DataNode中的Ozone Handler

Ozone handler是Ozone中的模块组件,被DataNode所持有并对外提供Ozone服务.Handler包含了一个http server并实现了Ozone REST方式API.Ozone Handler与storage container manager管理器交互来查询container的位置.与DataNode中的storage container交互实现不同的操作.这个功能组件可以被禁用如果用户只想要使用HDFS而不需要Ozone功能.

Storage Container Manager管理器

Storage container manager管理器非常类似于HDFS中block manager中的管理功能.Storage container manager管理器从各个DataNode中收集心跳,处理storage container的报告并跟踪每个storage container的位置.他包含了一个storage container映射图,以此提供了前缀匹配的方式去查询storage container.之前提到过DN能够同时存储HDFS和Ozone的数据.Ozone的数据所属的是分离的block pool并且用的是Storage container manager管理器提供的分离的blockPool Id.图形展示效果如下.我们计划尽可能的复用NameNode已有的block管理部分的代码实现来实现container的管理.我们同样可以复用DataNode 中block pool service服务的实现代码.
这里写图片描述

具体实现

映射object-key到storage container

在我们的设计中,我们计划使用哈希分区的模式来映射key到他所存储的storage container.Key的值是被哈希计算的,同时会带上bucketId的前缀.结果值通过前缀匹配可以映射到storage container.当container逐渐变大,我们会对此进行分割,并用扩展哈希算法重新映射key到对应container的映射关系.Storage container manager管理器会存储这些映射关系到前缀树中以此实现高效的前缀匹配.每个bucket都有属于自己的前缀树.

范围分区 vs 哈希分区

在数据库和对象存储中,范围分区是另外一项比较受欢迎的用来对key进行分区的技术.以下是2个技术的简短的比较.我们偏向于使用哈希分区的方法,因为它相比较能更简单的去实现并且能满足我们的需求.

  • 范围分区模式需要范围索引.范围索引同样非常巨大并且需要分布式的存储.这复杂化了分割多个分区的操作,因为他额外需要索引的更新.
  • 范围分区在搜索过程中多引进了一种额外的跳跃,当第一次范围索引需要去读.
  • 范围分区同样有热点问题.相似名字的key会造成相同范围内的大并发量的访问.
  • 然而,范围分区提供了有序访问以及有序列表展示的优势.但是我们认为对于一个对象存储而言,一个有序的访问并不是一个重要的要求.列表有序的展示可以在后面的阶段内用二级索引的方式来实现.我们同样相信对于目前的设计而言是足够灵活的,如果我们在未来想要对此添加范围索引的话.

映射bucket到storage container

Bucket的元数据同样存储在storage container中.Bucket的名字是被用来作为key做哈希计算的.多个bucket的元数据可以存在于storage container中.我们在所有与storage container关联的bucket中设计了一个特殊的bucketId,bucketId前缀中会带上container Id.

Storage Container要求

Storage Container存储在各个DataNode上.对于Storage Container我们有以下的要求:

  • Storage Container能够可靠地被复制.
  • Storage Container保持严格的一致性.
  • Storage Container对于内部存储的对象能提供高效的键值对的查询方式.
  • Storage Container必须能够以流式的方式对object进行读写操作.
  • Storage Container必须能够支持get/put接口,来存储和更新bucket元数据.
  • Storage Container对于内部存储的bucket必须能提供一个原子的更新操作.
  • Storage Container能够进行分裂当他们达到一定大小限制的时候.

Storage Container的实现要点

  • 我们倾向于尽可能的复用HDFS现有的block pool管理方面的功能代码.因此我们会将StorageContainer作为Block类的扩展类.一个hdfs block由一个标识符,生成时间记录和大小组成.这3个属性同样可以应用到storage container中.
  • 为了保证一致性和持久性,storage container实现了少量的原子性和持久化的操作,比如事务.Container对这些操作提供了可靠的保证.在第一阶段中,我们实现以下事务操作:
    • Commit: 这个操作促进了对象从被写到最后的确认结束.一旦这个操作成功,这个container就会保证对象是可读的.
    • Put: 这个操作适用于小规模的写操作,例如元数据的写动作.
    • Delete: 删除对象.
  • Container中的每个事务会有一个事务ID,并且必须被持久化.
  • 我们计划为storage container实现一个新的data-pipeline,因为他要求一个不同类型的更新和恢复语义操作.在下一小节中我们会给出data-pipeline的设计概述.
  • 我们正在考虑利用leveldbjni来作为storage container的原型设计,leveldbjni正好能满足我们storgae container键值对存储的需求.

Data Pipeline一致性

Data-Pipeline管道链流式复制副本数据到container中.Container的副本也有产生记录类似于HDFS的block.每个pipeline副本的标记记录在pipeline创建的时候会被更新,所以任何旧的container会被撤销.HDFS在block恢复的时候额外使用了block length副本长度来判断副本是否已经更新到最新.类似地, storage container用了事务ID来判断container副本是最新的.更多的pipeline设计细节将会上传到对应hdfs jira上.

未来工作

我们并没有在文档中仔细阐述下述的要求,但是我们将会在后面阶段的工作中实现这些功能:

  • High availability: 高可用性,Storage container manager管理器需要是高可用的服务.一个解决方案是利用HDFS Journal的QJM机制实现Active/Standby的方式.另外一种方式做成所有Active的服务配上Paxos环的方式.我们会在第二阶段的工作中对这个问题进行社区内的讨论.
  • Security: 安全,我们可以利用HDFS的kerberos认证机制
  • Cross cool replication: 跨类型副本拷贝,我们将会使用一种对HDFS和Ozone都有利的方式去实现这个功能.

Ozone API

Cluster层级APIs

  • PUT StorageVolumes
    • API - PUT /admin/volume/{StorageVolume}
      • 创建一个storage volume
      • 只有管理员才允许调用这个操作
  • HEAD StorageVolume
    • API - HEAD /admin/volume/{StorageVolume}
      • 检测Storage Volume是否存在
      • 只有管理员才能调用这个操作
  • GET
    • 列出集群中所有的Storage Volume.
  • DELETE Storage Volumes
    • API - DELETE /amin/volume/{StorageVolume}
      • 删除一个volume如果他是空的

Storage Volume层级APIs

  • GET Buckets
  • API - GET /
    • 利用用户的认证信息登录
    • 返回请求发送者所拥有的buckets列表
  • Get User Buckets
    • API - GET /admin/user/userid
      • 利用用户认证信息进行登录, 如果他/她有权限阅读其他用户的信息,返回那个用户所独有的buckets列表信息.

Bucket层级API

  • LIST objects in a bucket
    • API - GET/{bucketName}
      • 返回buckets中最多1000个数量的对象key
  • PUT bucket
    • API - PUT/{bucketName}
      • 为请求发送者创建bucket
    • GET/PUT Bucket ACL
      • API - /{Bucket}?acl
      • 允许用户获取/设置bucket的ACL
  • HEAD bucket
    • API - HEAD/{bucketName}
    • 检查bucket是否存在,前提是请求发送者有权限访问此bucket
  • DELETE bucket
    • API - DELETE/{bucketName}
      • 删除bucket如果此bucket为空的话

Object层级APIs

  • GET object
    • API - GET/{bucketName}/{key}
      • 返回给定key所代表的对象值,如果这个值存在
      • 在第一阶段暂不支持ACL,因此只有所属用户才能读写自身的bucket.
  • PUT object
    • API - PUT/{bucketName}/{key}
      • 在bucket中创建一个对象
      • 在第一阶段暂不支持ACL,因此只有所属用户才能读写自身的bucket.
      • 不支持局部的上传,只有对象全部上传成功了才被认为是一次成功的操作.
  • HEAD object
    • API - HEAD/{bucketName}/{key}
      • 检测对象是否存在
      • 在第一阶段只有bucket的所属用户才能调用此操作
  • DELETE object
    • API - DELETE/{bucketName}/{key}
      • 删除对象

引用

1.Extendible Hashing(扩展哈希算法)-
http://en.wikipedia.org/wiki/Extendible_hashing
2.leveldbjni - A Java Native Interface(Java本地接口) to
LevelDB. https://github.com/fusesource/leveldbjn

Android路上的人
关注
专栏目录
HDFS的新方向：Ozone对象存储
走在前往架构师的路上
04-30 7389
前言HDFS在近几年中得到了迅速的发展，作为性价比比较高的存储系统，用户、企业只需利用若干台低配廉价的节点机型，就可以构建能够承受TB甚至PB级别的大数据集群，然后在上面做各种类型任务的作业，而且在底层方面，我们完全可以依赖HDFS自身实现的容错机制来应当各种异常情况。但是在当今数据使用场景日益多元化的背景下，HDFS并不是能满足所有的应用需求。如何能够以一种更加高效，方便的方式去存储用户想要保存的
HDFS对象存储服务：Ozone的元数据管理
走在前往架构师的路上
07-09 2970
前言HDFS作为一套成熟的分布式存储系统，它能够存储TB甚至，PB规模级别的数据。依托于如此强大的存储能力，目前越来越多的公司、企业已经开始将越来越多的数据往HDFS上迁移。但是当数据量达到一定规模，HDFS不见得能承受的了。可能有人有疑问了，刚刚不是说HDFS能支撑PB规模级别的数据吗，这不是自相矛盾的说法了？其实笔者在这里想说的是元数据管理会受到瓶颈，HDFS面对如此巨大的元数据信息，凭借单单
分布式对象存储（Apache Ozone）
最新发布
weixin_43156294的博客
09-25 1105
Apache Ozone是基于Hadoop的可扩展、冗余和分布式对象存储，适用于容器环境，如Kubernetes和YARN。Ozone支持多协议，包括S3和Hadoop文件系统API。
HDFS_对象存储
Regan_Hoo的博客
11-21 3091
纠删码技术的含义（HDFS EC——Hadoop Erasure Coding）通过在原始数据中加入新的校验数据，使得各个部分的数据产生关联性。在一定范围的数据出错情况下，通过纠删码技术都可以进行恢复。 纠删码技术的原理把一行数据块组称为条带（strip），每行条带由n个数据块和m个校验块组成：① 如果校验数据块发生错误，通过对原始数据块进行编码重新生成② 如果原始数据块发生错误，通过校验数据块的解
听说你想把对象存储当 HDFS 用，我们这里有个方案...
云存储小天使的博客
11-24 342
传统的大数据集群往往采用本地中心化的计算和存储集群。比如在谷歌早期的【三驾马车】中，使用 GFS 进行海量网页数据存储，用 BigTable 作为数据库并为上层提供各种数据发现的能力，同时用 MapReduce 进行大规模数据处理。 但随着互联网业务的发展，本地中心化的架构开始受到以下两个方面的挑战： 数据增长越来越快，并且数据格式更加丰富多样，非结构化数据越来越多。传统的分布式存储引擎难以大规模存储和处理文本、音视频等非结构化数据。 计算和存储强耦合在本地应用上，缺少弹性。强耦合的模..
5-1+如何让Ozone成为HDFS的下一代分布式存储系统.pdf
03-18
HDDS FS在文件夹操作方面的优势表明，它在某些场景下可以优于Ozone自身的对象存储设计。 综上所述，Apache Ozone通过提供更先进的分布式存储解决方案，有望克服HDFS的局限性。虽然在替代HDFS的过程中还有许多挑战，...
大数据存储及分层实践-4-5 JuiceFS 在数据湖存储架构上的一些探索.zip
05-30
在数据湖存储架构中，JuiceFS可以作为统一的数据访问层，连接不同的数据源，如HDFS、S3等，提供统一的文件系统视图。这有助于简化数据的管理和分析流程，提高工作效率。此外，JuiceFS的分层存储策略可以自动将不常...
大数据存储及分层实践-5-4 Apache Ozone 下一代大数据存储解密.zip
05-30
本讲座“大数据存储及分层实践-5-4 Apache Ozone 下一代大数据存储解密”深入探讨了Ozone的设计理念、架构及其在大数据存储中的应用。 Ozone 起源于Hadoop生态系统，它是一个分布式的对象存储系统，设计目标是提供...
一文读懂HDFS分布式存储框架分析
HDFSpt的博客
08-25 346
一文读懂HDFS分布式存储框架分析 HDFS是一套基于区块链技术的个人的数据存储系统，利用无处不在的私人PC存储空间及便捷的网络为个人提供数据加密存储服务，将闲置的存储空间利用起来，服务于正处于爆发期的个人数据存储市场。 HDFS属于什么结构体系？ 1、HDFS框架分析 HDFS是Master和Slave的主从结构。主要由Name-Node、Secondary NameNode、DataNode构成。 NameNode 管理HDFS的名称空间和数据块映射信存储元数据与文件到数据块映射的地方。 如果Name
Ozone系列（一）整体架构
Badme
10-26 4416
注：本文主要翻译自Ozone的官方文档。有兴趣的小伙伴可以自己看documentation。链接如下： https://hadoop.apache.org/ozone/docs/1.0.0/concept/overview.html 介绍 Ozone 的整体架构，主要包括元数据层、数据层、协议、数据复制层和 Recon等概念，这些概念对于深入理解 ozone 的原理有极大帮助。 Ozone 是一个...
Hadoop 原生分布式对象存储 Ozone
SunnyRivers
06-01 378
Ozone 客户端 先和 Ozone Manager 通信，提供需要创建的Key 的信息，包括 /volume/bucket/key，数据的大小，备份数，和其他用户自定义Key的属性。Ozone Manager 收到 Ozone 客户端的请求后，调用SCM 的服务，寻找足够容纳数据的Open Container，将Container 对应的Pipeline 的Datanode 列表信息返回给Ozone Manager。HDFS是业界默认的大数据存储系统，在业界的大数据集群中有非常广泛的使用。
Ozone Datanode的分布式元数据管理
走在前往架构师的路上
12-28 1980
文章目录前言Ozone的分布式元数据Ozone Datanode数据的layout 前言 众所周知，当元数据空间达到一个比较庞大的规模量级的时候，HDFS会遇到一定的扩展性问题。首先HDFS将这些元数据INode信息都load在内存中进行管理，而且还有附属相关的mapping信息，这些庞大的信息被HDFS的NameNode所管理。相应地，NameNode也将会面临更大规模量级的请求处理。从更本质...
性能依然感人：在对象化存储上无损部署大数据应用
Alluxio的博客
05-08 328
简介 随着企业收集和分析的数据量不断增长，人们越来越关注会影响到性能的数据存储成本的管理。Hadoop提供了一种可扩展且快速的方式来存储和分析数据，但在Hadoop中存储数据通常比对象存储等替代方案的成本更高。 对于寻求可扩展、经济高效存储的企业而言，内部部署和云部署（例如AWS S3）采用对象存储的方案更普遍。然而，对象存储相较于Hadoop性能更低，因此程序开发者可能不愿意在两者间进行权衡选择...
大数据存储系统HDFS和对象存储(OOS/S3)的比较
xxxx000的专栏
05-14 5017
虽然Apache Hadoop以前都是使用HDFS的，但是当Hadoop的文件系统的需求产生时候也能使用S3。Netflix的利用这个特性把数据存储在S3上而不是HDFS上。笔者曾经工作经历的大数据集群存储都是用HDFS，当前工作接触到对象存储S3，在实践中比较两者的不同之处。
HDFS Ozone整体概述
走在前往架构师的路上
10-07 4946
前言 HDFS Ozone对象存储最近会有一个大动作：merge到主代码分支。这就动作具有十分大的意义，因为它意味着Ozone将在下一个最近发布的hadoop版本中出现并可以被广大用户所使用。所以在这个背景下，Ozone第一版本的代码和结构基本已经确定完毕，这个时候，我们再从大的层面来学习、了解这个框架、体系显然还是很有必要的。官方社区已经有许多相应的介绍文档在介绍这方面的内容了。笔者也大致
对象存储、HDFS、CDN之间的关系
Lucky小黄人的博客
10-03 1207
先说结论： 对象存储是一个种存储数据的方式，HDFS是一种分布式存储文件的方式，对象存储和HDFS因为底层存储结构设计的不同使得两者的存储的应用场景不同，适合存储的数据类型也不同。如果需要RESTful HTTP接口、不需要目录结构、数据修改也不频繁，扁平数据管理结构的对象存储是比较好的选择。 CDN是一种加速数据库访问的分发策略。其中存储的静态资源完美契合了对象存储的应用场景，所以CDN底层数...
HDFS和Ozone的数据删除原理对比思考
走在前往架构师的路上
05-31 1293
文章目录前言现有HDFS删除操作的性能问题HDFS删除操作的brainstorm改进想法相关设计：Ozone系统内的删除操作处理 前言 前段时间笔者一直在折腾HDFS大目录删除的性能问题，也尝试了很多不同的方案来降低大目录删除所带来的性能影响，包括改INodeDirectly内部child list结构，或者是在Snapshot层面做改进优化等等（详见此文章：HDFS大目录文件删除方案的实践思考）。不过后续笔者在对比HDFS的删除操作和新一代存储Ozone系统内部的删除操作时，发现二者还是存在不少区别的，
聊聊HDFS和Ozone的融合
走在前往架构师的路上
11-05 5869
前言Ozone的出现的初衷就是要解决HDFS namespace的扩展性问题，那么现在问题了，未来如何将这两大从设计上上来已经完全大改变的系统整合起来呢？这个听起来非常有意思，本文笔者结合最近社区的一些讨论，来简单聊聊这个话题。Ozone的核心结构社区在设计Ozone的时候，提出了一个具有关键性意义的概念：Storage Container。而不是HDFS中的块（block）概念。二者的关系是：St
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值