Alluxio 1.4版本的重要新特性介绍

  • 时间:
  • 浏览:1
  • 来源:uu快3预测_uu快3窍门_骗局

REST API由两种类型的端点组成:

版权申明:本文由南京大学顾荣等专家翻译分派自Alluxio公司技术博客,由Alluxio公司授权云栖社区及CSDN首发(联合),版权归Alluxio公司所有,未经版权所有者同意请勿转载。

2.2.4 上传文件

以下命令创建/hello-world.txt文件,写入内容并将其关闭:

原来拥有10Gbps网络链路(约1Gbps用于计算)的数据中心在Alluxio和远程存储集群之间有1ms 的传输下行速率 。在此链路上传输1MB数据块的I / O时间为1MB / 1GBps = 1 ms。在写1MB文件时,create操作中元数据的往返次数将从10减少到1(在Ceph中提升了10倍),执行总时间从11ms(10ms+1ms)减少到2ms(1ms+1ms),获得了超过5倍的性能提升。以此类推,对于10MB的数据块后来 得到约两倍的性能提升。以上例子说明了优化元数据性能是怎么能能有效改善小文件和小规模读取性能的。在远程存储集群网络距离非常遥远时,性能提升将变得更加明显。

Alluxio 1.4.0在对象存储上的小文件和小规模读取的性能方面有了重大改进。改进UFS API提升了对象存储中获取元数据的性能。下面的实验数据还需用表明了带来的好处:

1.1.1 创建或删除空文件的性能

2.2.1 新建目录以下命令创建/ hello / world目录; 参数 recursive = true用于递归创建缺少的父目录:

Alluxio 1.4.0后来 发布了少量的新功能和改进。本篇博客介绍Alluxio 1.4.0开源版本的许多重要特征。

• 改进的Alluxio底层存储API

• 文件系统REST接口

• 数据包流

类似于REST接口客户端支持的功能,如今集成新的对象存储仅需用实现少得多的法律妙招。只需用原来 实现的法律妙招中的一半即可。在源代码行数方面,现在仅需用必须30行代码即可完成新的对象存储的集成,必须原来 的一半。

2.文件系统原生REST接口

新引入的REST接口提供了与Alluxio native Java API的对等性,其目的是利于非Java环境与Alluxio的交互。

REST接口通过名为Alluxio proxy的Alluxio多线程 实现,该多线程 使用原来内部人员Alluxio Java客户端对REST接口和Alluxio服务器之间的通信进行代理。

2.3 性能

为了获得最佳性能,朋友 儿建议将Alluxio代理与Alluxio服务多线程 倒进共同。这还需用让非java应用以内存级的下行速率 访问存储在Alluxio中的数据,共同最小化Alluxio代理和Alluxio服务之间额外网络的开销。

3.数据包流

Alluxio 1.4.0引入了两种新的网络传输协议,旨在充分利用Alluxio组件之间的可用网络下行速率 。为了实现你是什么 点,朋友 儿减少了网络传输期间使用的缓存,后来 依赖于使用连续流传输协议取代数据传输中的请求-响应协议。

3.1 优势1.在标准网络中高达2倍的I / O性能改进,以及在高延迟吞吐量产品环境下取得更好的结果







Alluxio proxy的启动法律妙招如下:

2.2.2 列出目录

以下命令列出/ hello目录的内容:





3.2 协议细节通过使用你是什么 法律妙招,朋友 儿能确保网络管道持续饱和,后来 朋友 儿不需用发送周期性的额外数据请求。而按照原来 的法律妙招,在读取请求的往返时间内,网络管道将发生空闲情况汇报。这将带来显着的I/O性能改进,有点儿是在往返时间相当长后来 可用吞吐量大的情况汇报下。

2.2.3 删除目录

以下命令删除/ hello目录的内容; recursive = true参数用于递归删除目录:

1.1 优化的对象存储连接器

1.改进的Alluxio底层存储API

2.1 API

host参数还需用是运行Alluxio代理的任何机器。

端点path通过路径执行给定的操作(类似,列表情况汇报,创建或删除文件)。其余参数以JSON对象的形式传递到端点。

许多path端点,有点儿是在创建文件或打开文件时,会创建原来流并返回原来整数句柄id。 此句柄可用于调用流端点以执行给定操作(类似读取,写入或关闭)。

2.2 Examples本节通过curl命令与本地Alluxio代理进行通信介绍许多REST API的功能。

1.2 繁复的对象存储集成

2.2.5 下载文件

以下命令打开/hello-world.txt文件,读取内容并将其关闭:

在Alluxio 1.4.0带来的变化中,受到显著影响的操作之一是在底层存储中创建零字节文件。对于写性能,在S3A中提升了5倍,在Ceph中提升了10倍。注意,对Ceph的性能提升更大;Alluxio 1.3.0中针对S3A的优化,即称为ObjectUnderFileSystem的新抽象,现在也适用于所有许多对象存储。原来 受到较大影响的操作是删除,在S3A和Ceph中分别带来了3倍与15倍的性能提升。

1.1.2 粗略计算

Alluxio是计算和数据存储之间的桥梁。底层存储API的初始版本是Alluxio文件系统API的镜像,并针对底层存储系统进行了裁剪,哪些地方地方底层存储系统提供了类HDFS的文件系统API。对象存储,无论是公共的还是私有的,后来 日益成为各种用例的后台存储确定。后来 ,底层存储 API需用改进,以更好地为对象存储和文件系统存储提供最好的服务。

对象存储具有扁平的命名空间,其必须原来发生顶层的类似目录的实体(桶)。但它还需用创建伪目录,就好像底层存储中的目录一样。后来 对象存储API不区分文件对象和目录对象,文件系统API对于对象存储是非常低效的。类似,UFS API中删除路径指令并谁能谁能告诉我该路径指向的是文件还是目录,需用调用远程查询获取该元数据。后来 与远程存储系统通信发生延迟,对象存储之上的元数据操作代价是非常高的。在Alluxio 1.4.0中,UFS API后来 更新以更好发生理原来 的情况汇报,其妙招是在大偏离 情况汇报下,使得哪些地方地方调用高效的额外元数据往往后来 被Alluxio获取了。

改进底层存储API使Alluxio对对象存储更友好主要有以下原来优势: