分布式文件系统：alluxio核心能力

一、缓存

1. Alluxio存储概述

本文档的目的是向用户介绍Alluxio存储和 在Alluxio存储空间中可以执行的操作背后的概念。 与元数据相关的操作 例如同步和名称空间，请参阅 [有关命名空间管理的页面] (…/…/en/core-services/Unified-Namespace.html)

Alluxio在帮助统一跨各种平台用户数据的同时还有助于为用户提升总体I / O吞吐量。 Alluxio是通过把存储分为两个不同的类别来实现这一目标的。

• UFS(底层文件存储，也称为底层存储)-该存储空间代表不受Alluxio管理的空间。 UFS存储可能来自外部文件系统，包括如HDFS或S3。 Alluxio可能连接到一个或多个UFS并在一个命名空间中统一呈现这类底层存储。 -通常，UFS存储旨在相当长一段时间持久存储大量数据。
• Alluxio存储
  • Alluxio做为一个分布式缓存来管理Alluxio workers本地存储，包括内存。这个在用户应用程序与各种底层存储之间的快速数据层带来的是显著提高的I / O性能。
  • Alluxio存储主要用于存储热数据，暂态数据，而不是长期持久数据存储。
  • 每个Alluxio节点要管理的存储量和类型由用户配置决定。
  • 即使数据当前不在Alluxio存储中，通过Alluxio连接的UFS中的文件仍然 对Alluxio客户可见。当客户端尝试读取仅可从UFS获得的文件时数据将被复制到Alluxio存储中。

Alluxio存储通过将数据存储在计算节点内存中来提高性能。 Alluxio存储中的数据可以被复制来形成”热”数据，更易于I/O并行操作和使用。 Alluxio中的数据副本独立于UFS中可能已存在的副本。 Alluxio存储中的数据副本数是由集群活动动态决定的。 由于Alluxio依赖底层文件存储来存储大部分数据， Alluxio不需要保存未使用的数据副本。 Alluxio还支持让系统存储软件可感知的分层存储，使类似L1/L2 CPU缓存一样的数据存储优化成为可能。

2.1 配置Alluxio存储

2.1. 单层存储

配置Alluxio存储的最简单方法是使用默认的单层模式。 请注意，此部分是讲本地存储，诸如mount之类的术语指在本地存储文件系统上挂载，不要与Alluxio的外部底层存储的mount概念混淆。 在启动时，Alluxio将在每个worker节点上发放一个ramdisk并占用一定比例的系统的总内存。 此ramdisk将用作分配给每个Alluxio worker的唯一存储介质。 通过Alluxio配置中的alluxio-site.properties来配置Alluxio存储。 详细信息见configuration settings。 对默认值的常见修改是明确设置ramdisk的大小。 例如，设置每个worker的ramdisk大小为16GB：

alluxio.worker.ramdisk.size=16GB

另一个常见更改是指定多个存储介质，例如ramdisk和SSD。 需要 更新alluxio.worker.tieredstore.level0.dirs.path以指定想用的每个存储介质 为一个相应的存储目录。 例如，要使用ramdisk(挂载在/mnt/ramdisk上)和两个 SSD(挂载在/mnt/ssd1和/mnt/ssd2):

alluxio.worker.tieredstore.level0.dirs.path=/mnt/ramdisk,/mnt/ssd1,/mnt/ssd2
alluxio.worker.tieredstore.level0.dirs.mediumtype=MEM,SSD,SSD

请注意，介质类型的顺序必须与路径的顺序相符。 MEM和SSD是Alluxio中的两种预配置存储类型。alluxio.master.tieredstore.global.mediumtype是包含所有可用的介质类型的配置参数，默认情况下设置为MEM，SSD，HDD。 如果用户有额外存储介质类型可以通过修改这个配置来增加。 提供的路径应指向挂载适当存储介质的本地文件系统中的路径。 为了实现短路操作，对于这些路径，应允许客户端用户在这些路径上进行读取，写入和执行。 例如，对于与启动Alluxio服务的用户组同组用户应给予770权限。 更新存储介质后，需要指出每个存储目录分配了多少存储空间。 例如，如果要在ramdisk上使用16 GB，在每个SSD上使用100 GB：

alluxio.worker.tieredstore.level0.dirs.quota=16GB,100GB,100GB

注意存储空间配置的顺序一定与存储目录的配置相符。 Alluxio在通过Mount或SudoMount选项启动时，配置并挂载ramdisk。 这个ramdisk大小是由alluxio.worker.ramdisk.size确定的。 默认情况下，tier 0设置为MEM并且管理整个ramdisk。 此时alluxio.worker.tieredstore.level0.dirs.quota的值同alluxio.worker.ramdisk.size一样。 如果tier0要使用除默认的ramdisk以外的设备，应该显式地设置alluxio.worker.tieredstore.level0.dirs.quota选项。

2.2. 多层存储

通常建议异构存储介质也使用单个存储层。 在特定环境中，工作负载将受益于基于I/O速度存储介质明确排序。 Alluxio假定根据按I/O性能从高到低来对多层存储进行排序。 例如，用户经常指定以下层：

• MEM(内存)
• SSD(固态存储)
• HDD(硬盘存储)

2.2.1. 写数据

用户写新的数据块时，默认情况下会将其写入顶层存储。如果顶层没有足够的可用空间， 则会尝试下一层存储。如果在所有层上均未找到存储空间，因Alluxio的设计是易失性存储，Alluxio会释放空间来存储新写入的数据块。 根据块注释策略，空间释放操作会从worker中释放数据块。块注释政策。 如果空间释放操作无法释放新空间，则写数据将失败。 **注意:**新的释放空间模型是同步模式并会代表要求为其要写入的数据块释放新空白存储空间的客户端来执行释放空间操作。 在块注释策略的帮助下，同步模式释放空间不会引起性能下降，因为总有已排序的数据块列表可用。 然而，可以将alluxio.worker.tieredstore.free.ahead.bytes(默认值：0)配置为每次释放超过释放空间请求所需字节数来保证有多余的已释放空间满足写数据需求。 用户还可以通过configuration settings来指定写入数据层。

2.2.2. 读取数据

如果数据已经存在于Alluxio中，则客户端将简单地从已存储的数据块读取数据。 如果将Alluxio配置为多层，则不一定是从顶层读取数据块， 因为数据可能已经透明地挪到更低的存储层。 用ReadType.CACHE_PROMOTE读取数据将在从worker读取数据前尝试首先将数据块挪到 顶层存储。也可以将其用作为一种数据管理策略 明确地将热数据移动到更高层存储读取。

2.2.3. 配置分层存储

可以使用以下方式在Alluxio中启用分层存储配置参数。 为Alluxio指定额外存储层，使用以下配置参数：

alluxio.worker.tieredstore.levels
alluxio.worker.tieredstore.level{x}.alias
alluxio.worker.tieredstore.level{x}.dirs.quota
alluxio.worker.tieredstore.level{x}.dirs.path
alluxio.worker.tieredstore.level{x}.dirs.mediumtype

例如，如果计划将Alluxio配置为具有两层存储，内存和硬盘存储， 可以使用类似于以下的配置：

# configure 2 tiers in Alluxio
alluxio.worker.tieredstore.levels=2
# the first (top) tier to be a memory tier
alluxio.worker.tieredstore.level0.alias=MEM
# defined `/mnt/ramdisk` to be the file path to the first tier
alluxio.worker.tieredstore.level0.dirs.path=/mnt/ramdisk
# defined MEM to be the medium type of the ramdisk directory
alluxio.worker.tieredstore.level0.dirs.mediumtype=MEM
# set the quota for the ramdisk to be `100GB`
alluxio.worker.tieredstore.level0.dirs.quota=100GB
# configure the second tier to be a hard disk tier
alluxio.worker.tieredstore.level1.alias=HDD
# configured 3 separate file paths for the second tier
alluxio.worker.tieredstore.level1.dirs.path=/mnt/hdd1,/mnt/hdd2,/mnt/hdd3
# defined HDD to be the medium type of the second tier
alluxio.worker.tieredstore.level1.dirs.mediumtype=HDD,HDD,HDD
# define the quota for each of the 3 file paths of the second tier
alluxio.worker.tieredstore.level1.dirs.quota=2TB,5TB,500GB

可配置层数没有限制 但是每个层都必须使用唯一的别名进行标识。 典型的配置将具有三层，分别是内存，SSD和HDD。 要在HDD层中使用多个硬盘存储，需要在配置alluxio.worker.tieredstore.level{x}.dirs.path时指定多个路径。

2.3. 块注释策略

Alluxio从v2.3开始使用块注释策略来维护存储中数据块的严格顺序。 注释策略定义了跨层块的顺序，并在以下操作过程中进行用来参考: -释放空间 -动态块放置。 与写操作同步发生的释放空间操作将尝试根据块注释策略强制顺序删除块并释放其空间给写操作。注释顺序的最后一个块是第一个释放空间候选对象，无论它位于哪个层上。 开箱即用的注释策略实施包括:

• LRUAnnotator:根据最近最少使用的顺序对块进行注释和释放。这是Alluxio的默认注释策略。
• LRFUAnnotator :根据配置权重的最近最少使用和最不频繁使用的顺序对块进行注释。
  • 如果权重完全偏设为最近最少使用，则行为将 与LRUAnnotator相同。
  • 适用的配置属性包括alluxio.worker.block.annotator.lrfu.step.factoralluxio.worker.block.annotator.lrfu.attenuation.factor。

workers选择使用的注释策略由Alluxio属性alluxio.worker.block.annotator.class决定。 该属性应在配置中指定完全验证的策略名称。当前可用的选项有:

• alluxio.worker.block.annotator.LRUAnnotator
• alluxio.worker.block.annotator.LRFUAnnotator

2.3.1. 释放空间模拟

旧的释放空间策略和Alluxio提供的实施现在已去掉了，并用适当的注释策略替换。 配置旧的Alluxio释放空间策略将导致worker启动失败，并报错java.lang.ClassNotFoundException。 同样，旧的基于水位标记配置已失效。因此，以下配置选项是无效的: -alluxio.worker.tieredstore.levelX.watermark.low.ratio-alluxio.worker.tieredstore.levelX.watermark.high.ratio 然而，Alluxio支持基于自定义释放空间实施算法数据块注释的仿真模式。该仿真模式假定已配置的释放空间策略创建一个基于某种顺序释放空间的计划，并通过定期提取这种自定义顺序来支持块注释活动。 旧的释放空间配置应进行如下更改。 (由于旧的释放空间实施已删除，如未能更改基于旧实施的以下配置就会导致class加载错误。) -LRUEvictor-> LRUAnnotator -GreedyEvictor-> LRUAnnotator -PartialLRUEvictor-> LRUAnnotator -LRFUEvictor-> LRFUAnnotator

2.4. 分层存储管理

因为块分配/释放不再强制新的写入必须写到特定存储层，新数据块可能最终被写到任何已配置的存储层中。这样允许写入超过Alluxio存储容量的数据。但是，这就需要Alluxio动态管理块放置。 为了确保层配置为从最快到最慢的假设，Alluxio会基于块注释策略在各层存储之间移动数据块。 每个单独层管理任务都遵循以下配置:

• alluxio.worker.management.task.thread.count:管理任务所用线程数。 (默认值:CPU核数)
• alluxio.worker.management.block.transfer.concurrency.limit:可以同时执行多少个块传输。 (默认:CPU核数/2)

2.4.1. 块对齐(动态块放置)

Alluxio将动态地跨层移动数据块，以使块组成与配置的块注释策略一致。 为辅助块对齐，Alluxio会监视I/O模式并会跨层重组数据块，以确保较高层的最低块比下面层的最高块具有更高的次序。 这是通过”对齐”这个管理任务来实现的。此管理任务在检测到层之间 顺序已乱时，会通过在层之间交换块位置来有效地将各层与已配置的注释策略对齐以消除乱序。 有关如何控制这些新的后台任务对用户I/O的影响，参见管理任务推后部分。 用于控制层对齐:

• alluxio.worker.management.tier.align.enabled:是否启用层对齐任务。 (默认:true)
• alluxio.worker.management.tier.align.range:单个任务运行中对齐多少个块。 (默认值:100)
• alluxio.worker.management.tier.align.reserved.bytes:配置多层时，默认情况下在所有目录上保留的空间大小。 (默认:1GB) 用于内部块移动。
• alluxio.worker.management.tier.swap.restore.enabled:控制一个特殊任务，该任务用于在内部保留空间用尽时unblock层对齐。 (默认:true) 由于Alluxio支持可变的块大小，因此保留空间可能会用尽，因此，当块大小不匹配时在块对齐期间在层之间块交换会导致一个目录保留空间的减少。

2.4.2. 块升级

当较高层具有可用空间时，低层的块将向上层移动，以便更好地利用较快的磁盘介质，因为假定较高的层配置了较快的磁盘介质。 用于控制动态层升级:

• alluxio.worker.management.tier.promote.enabled:是否启用层升级任务。 (默认:true)
• alluxio.worker.management.tier.promote.range:单个任务运行中升级块数。 (默认值:100)
• alluxio.worker.management.tier.promote.quota.percent:每一层可以用于升级最大百分比。 一旦其已用空间超过此值，向此层升级将停止。 (0表示永不升级，100表示总是升级。)

2.4.3. 管理任务推后

层管理任务(对齐/升级)会考虑用户I/O并在worker/disk重载情况下推后运行。 这是为了确保内部管理任务不会对用户I/O性能产生负面影响。 可以在alluxio.worker.management.backoff.strategy属性中设置两种可用的推后类型，分别是Any和DIRECTORY。 -ANY; 当有任何用户I/O时，worker管理任务将推后。 此模式将确保较低管理任务开销，以便提高即时用户I/O性能。 但是，管理任务要取得进展就需要在worker上花更长的时间。 -DIRECTORY; 管理任务将从有持续用户I/O的目录中推后。 此模式下管理任务更易取得进展。 但是，由于管理任务活动的增加，可能会降低即时用户I/O吞吐量。 影响这两种推后策略的另一个属性是alluxio.worker.management.load.detection.cool.down.time，控制多长时间的用户I/O计为在目标directory/worker上的一个负载。

3. Alluxio中数据生命周期管理

用户需要理解以下概念，以正确利用可用资源:

• free:释放数据是指从Alluxio缓存中删除数据，而不是从底层UFS中删除数据。 释放操作后，数据仍然可供用户使用，但对Alluxio释放文件后尝试访问该文件 的客户端来讲性能可能会降低。
• load:加载数据意味着将其从UFS复制到Alluxio缓存中。如果Alluxio使用 基于内存的存储，加载后用户可能会看到I/O性能的提高。
• persist:持久数据是指将Alluxio存储中可能被修改过或未被修改过的数据写回UFS。 通过将数据写回到UFS，可以保证如果Alluxio节点发生故障数据还是可恢复的。
• TTL(Time to Live):TTL属性设置文件和目录的生存时间，以 在数据超过其生存时间时将它们从Alluxio空间中删除。还可以配置 TTL来删除存储在UFS中的相应数据。

3.1. 从Alluxio存储中释放数据

为了在Alluxio中手动释放数据，可以使用./bin/alluxio文件系统命令 行界面。

$./bin/alluxio fs free ${PATH_TO_UNUSED_DATA}

这将从Alluxio存储中删除位于给定路径的数据。如果数据是持久存储到UFS的则仍然可以访问该数据。有关更多信息，参考命令行界面文档 注意，用户通常不需要手动从Alluxio释放数据，因为 配置的注释策略将负责删除未使用或旧数据。

3.2. 将数据加载到Alluxio存储中

如果数据已经在UFS中，使用alluxio fs load

$./bin/alluxio fs load ${PATH_TO_FILE}

要从本地文件系统加载数据，使用命令alluxio fs copyFromLocal。 这只会将文件加载到Alluxio存储中，而不会将数据持久保存到UFS中。 将写入类型设置为MUST_CACHE写入类型将不会将数据持久保存到UFS， 而设置为CACHE和CACHE_THROUGH将会持久化保存。不建议手动加载数据，因为，当首次使用文件时Alluxio会自动将数据加载到Alluxio缓存中。

3.3. 在Alluxio中持久化保留数据

命令alluxio fs persist允许用户将数据从Alluxio缓存推送到UFS。

$./bin/alluxio fs persist ${PATH_TO_FILE}

如果您加载到Alluxio的数据不是来自已配置的UFS，则上述命令很有用。 在大多数情况下，用户不必担心手动来持久化保留数据。

3.4. 设置生存时间(TTL)

Alluxio支持命名空间中每个文件和目录的”生存时间(TTL)”设置。此 功能可用于有效地管理Alluxio缓存，尤其是在严格 保证数据访问模式的环境中。例如，如果对上一周提取数据进行分析， 则TTL功能可用于明确刷新旧数据，从而为新文件释放缓存空间。 Alluxio具有与每个文件或目录关联的TTL属性。这些属性将保存为 日志的一部分，所以集群重新后也能持久保持。活跃master节点负责 当Alluxio提供服务时将元数据保存在内存中。在内部，master运行一个后台 线程，该线程定期检查文件是否已达到其TTL到期时间。 注意，后台线程按配置的间隔运行，默认设置为一个小时。 在检查后立即达到其TTL期限的数据不会马上删除， 而是等到一个小时后下一个检查间隔才会被删除。 如将间隔设置为10分钟，在alluxio-site.properties添加以下配置：

alluxio.master.ttl.checker.interval=10m

请参考配置页CN以获取有关设置Alluxio配置的更多详细信息。

3.4.1. API

有两种设置路径的TTL属性的方法。

1. 通过Alluxio shell命令行
2. 每个元数据加载或文件创建被动设置

TTL API如下:

SetTTL(path，duration，action)
`path` 		Alluxio命名空间中的路径
`duration`	TTL动作生效前的毫秒数，这会覆盖任何先前的设置`
action`	生存时间过去后要执行的`action`。 `FREE`将导致文件            
            从Alluxio存储中删除释放，无论其目前的状态如何。 `DELETE`将导致            
            文件从Alluxio命名空间和底层存储中删除。            
            注意:`DELETE`是某些命令的默认设置，它将导致文件被            
            永久删除。

3.4.2. 命令行用法

了解如何使用setTtl命令在Alluxio shell中修改TTL属性参阅详细的命令行文档。

3.4.3. Alluxio中文件上的被动TTL设置

Alluxio客户端可以配置为只要在Alluxio命名空间添加新文件时就添加TTL属性。 当预期用户是临时使用文件情况下，被动TTL很有用 ，但它不灵活，因为来自同一客户端的所有请求将继承 相同的TTL属性。 被动TTL通过以下选项配置:

• alluxio.user.file.create.ttl-在Alluxio中文件上设置的TTL持续时间。 默认情况下，未设置TTL持续时间。
• alluxio.user.file.create.ttl.action-对文件设置的TTL到期后的操作 在Alluxio中。注意：默认情况下，此操作为”DELETE”，它将导致文件永久被删除。

TTL默认情况下处于不使用状态，仅当客户有严格数据访问模式才启用。 例如，要3分钟后删除由runTests创建的文件:

$./bin/alluxio runTests -Dalluxio.user.file.create.ttl=3m \  
-Dalluxio.user.file.create.ttl.action=DELETE

对于这个例子，确保alluxio.master.ttl.checker.interval被设定为短 间隔，例如一分钟，以便master能快速识别过期文件。

4. 在Alluxio中管理数据复制

4.1. 被动复制

与许多分布式文件系统一样，Alluxio中的每个文件都包含一个或多个分布在集群中存储的存储块。默认情况下，Alluxio可以根据工作负载和存储容量自动调整不同块的复制级别。例如，当更多的客户以类型CACHE或CACHE_PROMOTE请求来读取此块时Alluxio可能会创建此特定块更多副本。当较少使用现有副本时，Alluxio可能会删除一些不常用现有副本 来为经常访问的数据征回空间(块注释策略)。 在同一文件中不同的块可能根据访问频率不同而具有不同数量副本。 默认情况下，此复制或征回决定以及相应的数据传输 对访问存储在Alluxio中数据的用户和应用程序完全透明。

4.2. 主动复制

除了动态复制调整之外，Alluxio还提供API和命令行 界面供用户明确设置文件的复制级别目标范围。 尤其是，用户可以在Alluxio中为文件配置以下两个属性:

1. alluxio.user.file.replication.min是此文件的最小副本数。 默认值为0，即在默认情况下，Alluxio可能会在文件变冷后从Alluxio管理空间完全删除该文件。 通过将此属性设置为正整数，Alluxio 将定期检查此文件中所有块的复制级别。当某些块 的复制数不足时，Alluxio不会删除这些块中的任何一个，而是主动创建更多 副本以恢复其复制级别。
2. alluxio.user.file.replication.max是最大副本数。一旦文件该属性 设置为正整数，Alluxio将检查复制级别并删除多余的 副本。将此属性设置为-1为不设上限(默认情况)，设置为0以防止 在Alluxio中存储此文件的任何数据。注意，alluxio.user.file.replication.max的值 必须不少于alluxio.user.file.replication.min。

例如，用户可以最初使用至少两个副本将本地文件/path/to/file复制到Alluxio:

$./bin/alluxio fs -Dalluxio.user.file.replication.min=2 \
copyFromLocal /path/to/file /file

接下来，设置/file的复制级别区间为3到5。需要注意的是，在后台进程中完成新的复制级别范围设定后此命令将马上返回，实现复制目标是异步完成的。

$./bin/alluxio fs setReplication --min 3 --max 5 /file

设置alluxio.user.file.replication.max为无上限。

$./bin/alluxio fs setReplication --max-1 /file

重复递归复制目录/dir下所有文件复制级别(包括其子目录）使用-R:

$./bin/alluxio fs setReplication --min 3 --max-5-R /dir

要检查的文件的目标复制水平，运行

$./bin/alluxio fs stat /foo

并在输出中查找replicationMin和replicationMax字段。

5. 检查Alluxio缓存容量和使用情况

Alluxio shell命令fsadmin report提供可用空间的简短摘要 以及其他有用的信息。输出示例如下:

$./bin/alluxio fsadmin report
Alluxio cluster summary:    
    Master Address: localhost/127.0.0.1:19998    
    Web Port: 19999    
    Rpc Port: 19998    
    Started: 09-28-2018 12:52:09:486    
    Uptime: 0 day(s), 0 hour(s), 0 minute(s), and 26 second(s)    
    Version: 2.0.0    
    Safe Mode: true    
    Zookeeper Enabled: false    
    Live Workers: 1    
    Lost Workers: 0    
    Total Capacity: 10.67GB        
          Tier: MEM  Size: 10.67GB    
    Used Capacity: 0B        
          Tier: MEM  Size: 0B    
    Free Capacity: 10.67GB

Alluxio shell还允许用户检查Alluxio缓存中多少空间可用和在用。 获得Alluxio缓存总使用字节数运行:

$./bin/alluxio fs getUsedBytes

获得Alluxio缓存以字节为单位的总容量

$./bin/alluxio fs getCapacityBytes

Alluxio master web界面为用户提供了集群的可视化总览包括已用多少存储空间。可以在http:/{MASTER_IP}:${alluxio.master.web.port}/中找到。 有关Alluxio Web界面的更多详细信息可以在相关文档中找到。

二、统一命名空间

1. 介绍

Alluxio通过使用透明的命名机制和挂载API来实现有效的跨不同底层存储系统的数据管理。

1.1. 统一命名空间

Alluxio提供的主要好处之一是为应用程序提供统一命名空间。 通过统一命名空间的抽象，应用程序可以通过统一命名空间和接口来访问多个独立的存储系统。 与其与每个独立的存储系统进行通信，应用程序可以只连接到Alluxio并委托Alluxio来与不同的底层存储通信。

master配置属性alluxio.master.mount.table.root.ufs指定的目录挂载到Alluxio命名空间根目录，该目录代表Alluxio 的”primary storage”。在此基础上，用户可以通过挂载API添加和删除数据源。

voidmount(AlluxioURIalluxioPath,AlluxioURIufsPath);
voidmount(AlluxioURIalluxioPath,AlluxioURIufsPath,MountOptionsoptions);
voidunmount(AlluxioURIpath);
voidunmount(AlluxioURIpath,UnmountOptionsoptions);

例如，可以通过以下方式将一个新的S3存储桶挂载到Data目录中

mount(newAlluxioURI("alluxio://host:port/Data"),newAlluxioURI("s3://bucket/directory"));

1.2. UFS命名空间

除了Alluxio提供的统一命名空间之外，每个已挂载的基础文件系统 在Alluxio命名空间中有自己的命名空间； 称为UFS命名空间。 如果在没有通过Alluxio的情况下更改了UFS名称空间中的文件， UFS命名空间和Alluxio命名空间可能不同步的情况。 发生这种情况时，需要执行UFS元数据同步操作才能重新使两个名称空间同步。

2. 透明命名机制

透明命名机制保证了Alluxio和底层存储系统命名空间身份一致性。

当用户在Alluxio命名空间创建对象时，可以选择这些对象是否要在底层存储系统中持久化。对于需要持久化的对象， Alluxio会保存底层存储系统存储这些对象的路径。例如，一个用户在根目录下创建了一个Users目录及Alice和Bob两个子目录，底层存储系统也会保存相同的目录结构和命名。类似地，当用户在 Alluxio命名空间中对一个持久化的对象进行重命名或者删除操作时，底层存储系统中也会对其执行相同的重命名或删除操作。 Alluxio能够透明发现底层存储系统中并非通过Alluxio创建的内容。例如，底层存储系统中包含一个Data文件夹， 其中包含Reports和Sales文件，都不是通过Alluxio创建的，当它们第一次被访问时，如用户请求打开文 件，Alluxio会自动加载这些对象的元数据。然而在该过程中Alluxio不会加载文件内容数据，若要将其内容加载到Alluxio， 可以用FileInStream来读数据，或者通过Alluxio Shell中的load命令。

3. 挂载底层存储系统

定义Alluxio命名空间和UFS命名空间之间的关联是通过将底层存储系统挂载到Alluxio文件系统命名空间的机制完成的。 在Alluxio中挂载底层存储与在Linux文件系统中挂载一个卷类似。 mount命令将UFS挂载到Alluxio命名空间中文件系统树。

3.1. 根挂载点

Alluxio命名空间的根挂载点是在masters上’conf/alluxio-site.properties’中配置的。 下一行是一个配置样例，一个HDFS路径挂载到 Alluxio命名空间根目录。

alluxio.master.mount.table.root.ufs=hdfs://HDFS_HOSTNAME:8020

使用配置前缀来配置根挂载点的挂载选项： alluxio.master.mount.table.root.option. 例如，以下配置为根挂载点添加AWS凭证。

alluxio.master.mount.table.root.option.s3a.accessKeyId=
alluxio.master.mount.table.root.option.s3a.secretKey=

以下配置显示了如何为根挂载点设置其他参数。

alluxio.master.mount.table.root.option.alluxio.security.underfs.hdfs.kerberos.client.principal=client
alluxio.master.mount.table.root.option.alluxio.security.underfs.hdfs.kerberos.client.keytab.file=keytab
alluxio.master.mount.table.root.option.alluxio.security.underfs.hdfs.impersonation.enabled=true
alluxio.master.mount.table.root.option.alluxio.underfs.version=2.7

3.2. 嵌套挂载点

除了根挂载点之外，其他底层文件系统也可以挂载到Alluxio命名空间中。 这些额外的挂载点可以通过mount命令在运行时添加到Alluxio。--option选项允许用户传递挂载操作的附加参数，如凭证。

#the following command mounts an hdfs path to the Alluxio path `/mnt/hdfs`
$./bin/alluxio fs mount /mnt/hdfs hdfs://host1:9000/data/
#the following command mounts an s3 path to the Alluxio path `/mnt/s3` with additional options specifying the credentials
$./bin/alluxio fs mount \  
--option s3a.accessKeyId=--option s3a.secretKey= \  
/mnt/s3 s3://data-bucket/

注意，挂载点也允许嵌套。 例如，如果将UFS挂载到alluxio:///path1，可以在alluxio:///path1/path2处挂载另一个UFS。

3.3. 使用特定版本挂载UFS

Alluxio支持挂载特定不同版本HDFS。 因此，用户可以将不同版本的HDFS挂载到同一个Alluxio命名空间中。 有关更多详细信息，请参考HDFS底层存储。

4. Alluxio和UFS命名空间之间的关系

Alluxio提供了一个统一的命名空间，充当一个或多个底层文件存储系统的数据缓存层。 本节讨论Alluxio如何与底层文件系统交互来发现和通过Alluxio呈现这些文件。 通过Alluxio访问UFS文件的与直接通过UFS访问文件的相同。 如果UFS根目录是s3://bucket/data，则列出alluxio:///下内容应该与列出s3://bucket/data相同。 在alluxio:///file上运行cat的结果应与在s3://bucket/data/file上运行cat的结果相同。 Alluxio按需从UFS加载元数据。 在上面的示例中，Alluxio在启动时并没有有关s3://bucket/data/file的信息。 直到当用户试图列出alluxio:///或尝试使用catalluxio:///file时，才发现该文件。 这样好处是可以防止在安装新的UFS时进行不必要的文件发现工作。 默认情况下，* Alluxio预期所有对底层文件系统修改都是通过Alluxio 来进行的*。 这样Alluxio只需扫描每个UFS目录一次，从而在UFS元数据操作很慢情况下显著提高性能。 当出现在Alluxio之外对UFS进行更改的情况下， 就需要用元数据同步功能用于同步两个命名空间。

4.1. UFS元数据同步

UFS元数据同步功能新增自版本1.7.0。 当Alluxio扫描UFS目录并加载其子目录元数据时， 它将创建元数据的副本，以便将来无需再从UFS加载。 元数据的缓存副本将根据alluxio.user.file.metadata.sync.interval客户端属性配置的间隔段刷新。 此属性适用于客户端操作。 例如，如果客户执行一个命令基于间隔设置为一分钟的配置， 如果最后一次刷新是在一分钟之前，则相关元数据将据UFS刷新。 设值为0表示针对每个操作都会进行实时元数据同步， 而默认值-1表示在初始加载后不会再重新同步元数据。 低间隔值使Alluxio客户端可以快速发现对UFS的外部修改， 但由于导致调用UFS的次数增加，因此是以降低性能为代价的。 元数据同步会保留每个UFS文件的指纹记录，以便Alluxio可以在文件更改时做出相应更新。 指纹记录包括诸如文件大小和上次修改时间之类的信息。 如果在UFS中修改了文件，Alluxio将通过指纹检测到该修改，释放现有文件 元数据，然后重新加载更新文件的元数据。 如果在UFS中添加或删除了文件，Alluxio还将更新对其命名空间中的元数据做出相应刷新。

4.2. 用于管理UFS同步的方法

4.2.1. 定期元数据同步

如果UFS按计划的间隔更新，可以在更新后手动触发sync命令。 运行以下命令将同步间隔设置为0：

$./bin/alluxio fs ls-R-Dalluxio.user.file.metadata.sync.interval=0 /path/to/sync

4.2.2. 集中配置

对于使用来自频繁更新的UFS数据的集群作业， 每个客户端指定一个同步间隔很不方便。 如果在master配置中设置了同步间隔，所有请求都将以默认的同步间隔来处理。 在master点上的alluxio-site.properties中设置： alluxio.user.file.metadata.sync.interval=1m 注意，需要重新启动master节点以便启用新配置。

4.3. 其他加载新UFS文件的方法

建议使用前面讨论的UFS同步的方法来同步UFS中的更改。 这是是其他一些加载文件的方法： *alluxio.user.file.metadata.load.type：此客户端属性可以设置为ALWAYS，ONCE或NEVER。此属性类似alluxio.user.file.metadata.sync.interval， 但有注意事项： 1.它只会发现新文件，不会重新加载修改或删除的文件。 1.它仅适用于exists，list和getStatusRPC。

`ALWAYS`配置意味者总会检查UFS中是否有新文件，`ONCE`将使用默认值 仅扫描每个目录一次，而`NEVER`配置下Alluxio根本不会 扫描新文件。

*alluxio fs ls -f /path:ls的-f选项相当于设置alluxio.user.file.metadata.load.type为ALWAYS。它将发现新文件，但 不检测修改或删除的UFS文件。 要检测修改或删除的UFS文件的唯一方法是通过传递-Dalluxio.user.file.metadata.sync.interval=0选项给ls。

5. 示例

以下示例假设Alluxio源代码在${ALLUXIO_HOME}文件夹下，并且有一个本地运行的Alluxio进程。

5.1. 透明命名

先在本地文件系统中创建一个将作为底层存储挂载的临时目录：

$cd /tmp
$mkdir alluxio-demo
$touch alluxio-demo/hello

将创建的目录挂载到Alluxio命名空间中，并确认挂载后的目录在Alluxio中存在：

$cd${ALLUXIO_HOME}
$./bin/alluxio fs mount /demo file:///tmp/alluxio-demo
Mounted file:///tmp/alluxio-demo at /demo
$./bin/alluxio fs ls-R /
... #note that the output should show /demo but not /demo/hello

验证对于不是通过Alluxio创建的内容，当第一次被访问时，其元数据被加载进入了Alluxio中:

$./bin/alluxio fs ls /demo/hello
... #should contain /demo/hello

在挂载目录下创建一个文件，并确认在底层文件系统中该文件也被以同样名字创建了：

$./bin/alluxio fs touch /demo/hello2/demo/hello2 has been created$ls /tmp/alluxio-demohello hello2

在Alluxio中重命名一个文件，并验证在底层文件系统中该文件也被重命名了：

$./bin/alluxio fs mv /demo/hello2
 /demo/worldRenamed /demo/hello2 to /demo/world
$ls /tmp/alluxio-demo
hello world

在Alluxio中删除一个文件，然后确认该文件是否在底层文件系统中也被删除了：

$./bin/alluxio fs rm 
/demo/world/demo/world has been removed
$ls /tmp/alluxio-demo
hello

卸载该挂载目录，并确认该目录已经在Alluxio命名空间中被删除，但该目录依然保存在底层文件系统中。

$./bin/alluxio fs unmount 
/demoUnmounted /demo$./bin/alluxio fs ls-R /... #should not contain /demo$ls /tmp/alluxio-demohello

5.2. HDFS元数据主动同步

在2.0版中，引入了一项新功能，用于在UFS为HDFS时保持Alluxio空间与UFS之间的同步。 该功能称为主动同步，可监听HDFS事件并以master上后台任务方式定期在UFS和Alluxio命名空间之间同步元数据。 由于主动同步功能取决于HDFS事件，因此仅当UFS HDFS版本高于2.6.1时，此功能才可用。 你可能需要在配置文件中更改alluxio.underfs.version的值。 有关所支持的Hdfs版本的列表，请参考HDFS底层存储。 要在一个目录上启用主动同步，运行以下Alluxio命令。

$./bin/alluxio fs startSync /syncdir

可以通过更改alluxio.master.ufs.active.sync.interval选项来控制主动同步间隔，默认值为30秒。 要在一个目录上停止使用主动同步，运行以下Alluxio命令。

$./bin/alluxio fs stopSync /syncdir

注意：发布startSync时，就预定了对同步点进行完整扫描。 如果以Alluxio超级用户身份运行，stopSync将中断所有尚未结束的完整扫描。 如果以其他用户身份运行，stopSync将等待完整扫描完成后再执行。

可以使用以下命令检查哪些目录当前处于主动同步状态。

$./bin/alluxio fs getSyncPathList

5.2.1. 主动同步的静默期

主动同步会尝试避免在目标目录被频繁使用时进行同步。 它会试图在UFS活动期寻找一个静默期，再开始UFS和Alluxio空间之间同步，以避免UFS繁忙时使其过载。 有两个配置选项来控制此特性。 alluxio.master.ufs.active.sync.max.activities是UFS目录中的最大活动数。 活动数的计算是基于目录中事件数的指数移动平均值的启发式方法。 例如，如果目录在过去三个时间间隔中有100、10、1个事件。 它的活动为100/10 * 10 + 10/10 + 1 = 3alluxio.master.ufs.active.sync.max.age是在同步UFS和Alluxio空间之前将等待的最大间隔数。 系统保证如果目录”静默”或长时间未同步(超过最大期限)，我们将开始同步该目录。 例如，以下设置

alluxio.master.ufs.active.sync.interval=30sec
alluxio.master.ufs.active.sync.max.activities=100
alluxio.master.ufs.active.sync.max.age=5

表示系统每隔30秒就会计算一次此目录的事件数， 并计算其活动。 如果活动数少于100，则将其视为一个静默期，并开始同步 该目录。 如果活动数大于100，并且在最近5个时间间隔内未同步，或者 5 * 30 = 150秒，它将开始同步目录。 如果活动数大于100并且至少已在最近5个间隔中同步过一次，将不会执行主动同步。

5.3. 统一命名空间

此示例将安装多个不同类型的底层存储，以展示统一文件系统命名空间的抽象作用。 本示例将使用属于不同AWS账户和一个HDSF服务的两个S3存储桶。 使用相对应凭证和将第一个S3存储桶挂载到Alluxio中：

$./bin/alluxio fs mkdir /mnt
$./bin/alluxio fs mount \  
--option s3a.accessKeyId=\  
--option s3a.secretKey=\  
/mnt/s3bucket1 s3://data-bucket1/

使用相对应凭证’’和’’将第二个S3存储桶挂载到Alluxio：

$./bin/alluxio fs mount \  
--option s3a.accessKeyId=\  
--option s3a.secretKey=\  
/mnt/s3bucket2 s3://data-bucket2/

将HDFS存储挂载到Alluxio：

$./bin/alluxio fs mount /mnt/hdfs hdfs://:/

所有这三个目录都包含在Alluxio的一个命名空间中：

$./bin/alluxio fs ls-R /... #should contain /mnt/s3bucket1, /mnt/s3bucket2, /mnt/hdfs

6. 资源

• 一篇博客文章，解释了统一命名空间
• 关于[优化以加快元数据操作速度]的博客文章(https://www.alluxio.io/blog/how-to-speed-up-alluxio-metadata-operations-up-to-100x/)

其他

参考：https://www.alluxio.com.cn/quickstart/unified-namespace/