导读 ：今天分享的刘嘉题目是Alluxio元数据和数据的同步 ，从设计实现和优化的设计实现角度进行讨论 。主要包括以下几个方面的和优化角内容 ：
01
Alluxio简介
Alluxio是云原生的数据编排平台 ，通过解耦计算和存储层，度浅在中间产生了一个数据编排层，元数负责对上层计算应用隐藏底层的据同时间细节 。Alluxio提供了统一的刘嘉存储命名空间 ，在中间层提供了缓存和其他数据管理功能 。设计实现在下图可以看到有Spark 、和优化角Hive、度浅Map reduce这一类传统的元数Hadoop大数据计算应用 、Presto 这种OLAP类型的据同数据分析 ，还有像Tensorflow、刘嘉Pytorch这样的设计实现AI应用 。存储层比较丰富 ，和优化角包括各种各样的存储 。
图1 Alluxio简介
下面是Alluxio用户列表 ，这些公司都公开展示了Alluxio的使用场景。通过粗略分类 ，看到非常多的行业 ，包括互联网 、金融、电子商务、娱乐、电信等 。感兴趣的同学可以关注公众号 ，上面有相关文章的汇总 。
图2 Alluxio的用户展示
--
02
Alluxio数据挂载
这部分将首先回顾Alluxio如何通过数据挂载实现统一编排层；之后讨论Alluxio如何和底层存储保持一致；介绍元数据和数据同步功能；Alluxio的时间原理和优化；最后对不同场景的推荐配置给出建议 。
1. Alluxio统一的数据命名空间
首先介绍数据挂载这个功能。Alluxio通过把底层存储挂载到Alluxio层上 ，实现了统一的数据命名空间 。
图3 Alluxio统一命名空间
上图的例子中Alluxio挂载了HDFS和对象存储 。Alluxio的文件系统树就是由左右两棵树合成 ，形成了一个虚拟文件系统的文件系统树。它可以支持非常多的底层存储系统 ，统一把它们称作Under File System 。称为Under是因为它们都处于Alluxio的抽象层下 。Alluxio支持各种各样不同的底层存储系统，比如不同版本的HDFS ，支持NFS, Ceph, Amazon S3, Google Cloud之类不同的对象存储 。除此之外还支持非常多其他类型的对象存储 ，比如微软Azure 、阿里 、华为 、腾讯 ，也包括国内其他供应商 ，如七牛对象存储 。左下图中的例子是在自己的电脑上运行Alluxio ，可以挂载不同的存储 ，比如挂载HDFS ，另外还可以挂载不同版本的HDFS ，挂载对象存储，挂载网盘 。
2. Alluxio挂载点
Alluxio的统一命名空间 ，实际就是把挂载合成了一个Alluxio的虚拟层 。Alluxio的挂载点可以粗略分成两种 ：
图4 Alluxio挂载点
根挂载点直接挂在根节点上 ，组成了Alluxio的根节点 。如果没有根节点 ，无法产生 ，继续形成下面的结构 。所以要求在配置文件里面定义根挂载点 ，系统启动的时候就进行挂载 ，不挂载就没有办法启动。
嵌套挂载点比较灵活 ，可以通过指令进行挂载 。通过这个命令行，发出通知 ，做挂载的操作 。同样地，可以挂载 ，也可以卸载，就是把Mount换成Unmount 。嵌套挂载点是嵌套在目录的下面 ，可以挂在某个部分下面，不一定挂载在根节点下面 。这里有个要求，即两个嵌套点的树不能互相覆盖 ，这样带来的好处是比较灵活。如果根挂载点将来需要更换 ，为了避免需要改配置和重启服务 ，可以使用一个dummy的根挂载点 ，比如就挂载在本地路径下面，不使用它 ，且不在它下面创建任何文件 ，它存在的唯一目的就是可以启动Alluxio服务。然后在此基础上 ，把所有要管理的存储 ，都以嵌套挂载点的方式挂载上去 。之后如果要改变，就直接卸载更换为其它挂载点 ，这样就很灵活。所有挂载和挂载操作 ，都会记录在日志里 ，重启系统 ，并重启服务之后 ，无需再手动操作 。
3. Alluxio策略化数据管理
图5 Alluxio策略化数据管理
挂载操作有一个进阶版操作 ，目前只包含在商业版本里面 。所做的事情就是让用户可以把两个存储挂载到同一个路径下，可以互相覆盖 。同时通过配置读写策略 ，定义读写文件到哪个存储里 ，并给出操作的先后顺序 。同时Alluxio有一个迁移策略 ，让文件可以自动在Alluxio的管理下 ，在多个存储之间进行迁移 。例如 ，把HDFS和对象存储同时挂载到同一路径下 ，上层用户只能看到这样一棵树 ，但是实际上背后有两个不同的存储 。通过配置 ，让Alluxio把HDFS的数据 ，根据一些规则 ，定期迁移进S3 ，例如规定将超过七天的数据 ，认定是不常用到的冷数据之后 ，把它从HDFS的集群拿出来 ，迁移到S3 ，节省HDFS的存储空间。
--
03
Alluxio底层存储一致性
在把底层存储挂载到Alluxio的统一命名空间上之后 ，如何保持Alluxio和底层存储的一致性 ？我们在这一部分进行分析 。
图6 Alluxio与一致性
Alluxio和底层存储的一致性，要从Alluxio命名空间中文件的来源说起 。文件的操作分为两类 ：
一致性可以分为两个部分 ：
下面先看写数据的一致性 。
1. Alluxio写文件流程
首先Alluxio写文件的流程可以把它抽象成两步 。第一步是客户端到Alluxio ，第二步是Alluxio到UFS 。
图7 Alluxio写文件流程
其中的每一步都可以抽象成下面的三个步骤：
同样Alluxio到存储系统也可以同样地抽象提取。
客户端和Alluxio之间 ，主要流程分三步 ：
同样Alluxio到存储系统也抽象成三步 。不同存储系统的抽象和具备的一致性，都不同 ，此处进行抽象只是为了便于理解 。比如要求强一致性保证 ，但是很多对象存储 ，给的一致性保证会弱很多，比如写进去之后不能马上读到这个数据。在这里 ，不考虑这种本身的不一致性的问题 。假设Alluxio向存储提交了之后 ，就能保证存储端的文件就是需要的样子 。
Alluxio为了满足不同的需求 ，设计了几种不同的写策略 ，下面逐一分析写策略的流程以及带来的数据一致性保证 。
2. Must-Catch写模式
图8 Alluxio ：MUST_CACHE写模式
首先是常用的MUST_CACHE模式 。在这种模式下，只会写Alluxio缓存不写UFS 。这个模式分为三步 ：
首先客户端会向Alluxio 发出创建文件请求 ，创建的文件只是一个空文件 ，作为一个占位；
之后Alluxio Worker实现具体数据的写操作 ，具体数据会被分割成多个数据块，作为Block存在于Alluxio Storage里面 。
在缓存写之后 ，客户端对Master做提交文件的请求 ，告诉Master写了这些数据块 ，写到Worker，然后更新对应的元数据 ，也知道了这些数据块和Worker所对应的位置 。
在这样的流程之后 ，Alluxio不会向UFS创建这个文件 ，也不会写这个文件 ，所以Alluxio和UFS之间的元数据和数据都不一致 。
3. Through写模式
图9 Alluxio ：Through写模式
THROUGH的写模式有所不同 ，这里同样的 createfile() 发出一个请求 ，然后找Worker写数据 。Worker会做三件事：
在第二步结束后 ，客户端会向Alluxio 提交这个文件 。因为Alluxio 的提交是发生在文件写完了之后 ，所以 ，Alluxio和UFS此时的元数据是一致的 。因为没有数据缓存，所以也不存在数据一致性的问题 。
Alluxio的缓存是在需要读之后才会产生 ，而这种THROUGH模式是比较适合用来写已知不再会被Alluxio读取的数据 。所以在这种情况下，元数据是一致的 ，也不存在数据不一致的问题 。
4. CACHE_THROUGH写模式
下面的CACHE_THROUGH模式就是前面两种模式的结合 。
图10 Alluxio ：CATCH_THROUGH写模式
唯一的不同点是在第二步 ，写缓存的同时又写了UFS 。在这两个都成功之后 ，第二步才会成功 ，之后客户端才会做提交操作 。同样的道理，因为Alluxio在UFS更新之后才更新 ，所以两者的元数据和数据都是一致的 。
5. ASYNC_THROUGH写模式
最后是ASYNC_THROUGH异步写模式 ，和前面的模式唯一的区别是第二步中的UFS写变成了异步，放在了第四步 。
图11 Alluxio ：ASYNC_THROUGH写模式
在Alluxio写缓存之后 ，首先创建了文件之后 ，在第二步写了Alluxio缓存；在第二步缓存写完之后，Worker就向客户端返回成功；然后由客户端向Master提交文件 。注意在这个时候 ，Worker还没有去UFS创建这个文件 ，也没有向UFS写文件 。在Alluxio向客户端返回请求成功之后 ，在之后的某个时间 ，由Job Service把这个文件创建到时里面 ，并且持久化 。
需要注意：在异步的模式下 ，持久化由于某些原因失败了 ，比如Alluxio成功之后 ，突然有人直接向里面创建了一个同名的文件 ，在第四步的时候 ，由于缓存和之间产生了不一致 ，导致这个文件无法创建 、无法写入 。这个时候 ，Alluxio会有不一致的问题 ，此时需要人工介入来解决这个冲突 。
6. 读文件流程
前文介绍以上四种不同的写模式以及一致性保证 ，现在来看Alluxio的读文件流程 。读文件也可以粗略分成两种 ：冷读和热读 。
图12 Alluxio ：读文件流程
简单来说 ，冷读情况下Alluxio不知道这个文件 ，需要从加载元数据和数据 。热读的时候 ，缓存命中 ，不需要加载元数据和数据 。
① 冷读文件
图13 Alluxio ：冷读文件
在冷读流程里，客户端向Alluxio请求元数据 ，此时Master还没有这个元数据 ，所以会向UFS发出一个请求 ，并从UFS加载这个元数据 ，这也称之为元数据同步 。
在客户端具体读数据的时候 ，客户端找到Worker，Worker此时还没有缓存，于是Worker会向UFS做缓存的加载 ，这就是常说的缓存冷读 。在做完这两个步骤之后 ，缓存是和元数据一致的。
② 热读文件
图14 Alluxio：热读文件
在热读的情况下 ，元数据可以在缓存里面找到 ，数据可以在Worker里面找到；此时不会有对UFS的读请求。
在缓存命中的时候 ，如何保证缓存与和是一致的 ？这里包括元数据的一致和数据的一致 。这个简单的来说 ，就是通过Alluxio的元数据和数据的同步机制 ，也就是下一部分的内容 。
--
04
Alluxio和UFS元数据和数据同步
1. 检查Alluxio元数据/数据一致性
首先考虑这个问题：在什么时候需要检查Alluxio的元数据和数据的一致性 ？
首先在写数据的时候需要检查。如果这个文件在已经存在了，作为缓存，除了放弃这个操作之外 ，也没有其他的选项 。因为不能在用户不知情的情况下 ，覆盖掉用户在里面的数据 。
在读数据的时候 ，同样需要考虑如果文件在里面已经更新了 ，那缓存也需要对应进行更新 ，需要UFS考虑里面的文件是否发生了变化 。
图15 检查Alluxio：元数据/数据一致性
2. 保证Alluxio元数据/数据一致性
元数据和数据的一致性分成两步来逐个讨论 。首先讨论如何保证Alluxio元数据和一致 。Alluxio通过两种方式来保证：
图16 保证Alluxio ：元数据/数据一致性
① 通过基于时间的假设
第一种是通过基于时间的假设，在里面的文件 ，在一段时间内它是不变的 。判断方法是在每一次文件源信息 、元数据请求的时候 ，检查Alluxio的元数据是否足够新 。
这个判断分成了两个不同的部分：
这种元数据的同步机制是惰性的 ，只有在请求的时候才会进行检查 。这样设计的理念是尽量避免访问慢的操作、昂贵的操作 。这样的事情越少越好、越懒越好 。如果Alluxio所知的文件信息足够新 ，就假设Alluxio和UFS是一致的 。如果不够新 ，就放弃这个假设再做一次同步；同时更新Alluxio里面的元数据。
② 基于通知
另外一个思路就是抛弃基于时间的假设 ，基于通知，依赖文件更改的告知 。这个不是假设，是一个确定的信息 。如果没有通知文件有变化 ，就确定Alluxio和现在的文件是一致的 。
其次是如何保证Alluxio和UFS的数据保持一致 。思路也非常简单：保持数据的一致 ，只需要确定元数据及是否一致 。这里做出的假设是 ：如果UFS的数据 ，文件内容有所改变 ，那这个改变一定会反映在文件的元数据上 。要么是文件的长度改变 ，要么是这个文件的Hash ，也就是哈希值会发生改变 。通过观察这个Alluxio和的元数据 ，可以发现这些变化点 。
如果基于这个假设，Alluxio的元数据和UFS保持一致时缓存和UFS也会一致 。如果观察元数据发现内容有变化，那么就更新元数据并抛弃已有缓存 。在下一次读的时候，重新加载缓存 。如果发现文件的内容没有变化 ，只做必要的元数据更新 ，不抛弃数据缓存 。
3. 数据同步机制
Alluxio提供两种同步机制 ，这里先介绍时间戳机制 ，再介绍基于消息的同步机制 。
① 基于元数据时间戳的同步机制
下面先看一下第一种机制 ，基于元数据时间戳的同步机制 。
图17 基于元数据时间戳同步
时间戳主要是通过配置项alluxio.user.file.metadata.sync.interval，通常称之为sync.interval或者interval 。比较同步数据上次同步的时间戳和配置项 。配置项中有几种不同的配置方式 ：
图18 元数据同步的开销
② 同步时间间隔配置
图19 同步时间间隔配置
这个时间间隔具体配置有三个 ，优先级是由低到高 ，后面的配置可以覆盖前面的配置。
Alluxio还提供一些语法糖指令 ，比如 ：loadMetadata指令就是专门为了触发元数据同步。如果加上-F选项 ，实际上的意思就是把sync.interval设成0 ，相当于强制进行一次元数据的刷新 。ls和metadata这两个指令的区别 ：ls把文件展示在面前 ，ls的RPC有网络开销 ， 会把信息发给你 ，客户端要保存下来 ，并且展示出来 。这个不是每一次都需要 ，假如只是想要触发一次元数据的同步 ，只需loadMetadata就可以 ，返回值只有成功或者失败 ，可以节约很多网络带宽和的内存开销 。
③ 基于消息的同步机制
以上是基于时间的同步机制 ，下面看一下另外一种思路 ，就是基于消息同步机制。
图20 基于消息同步
首先需要Alluxio 2.0版本以上 ，以及Hadoop 2.6.1版本以上 ，因为HDFS底层的inotify机制是在2.6版本加进去的 。实际上发生的就是从HDFS的namenode直接读取HDFS有哪些文件发生了变化 。实现原理就是维护了一个Alluxio和namenode之间通过HDFS的inotify机制保持了一个信息流 。Alluxio定期心跳从这个信息流里面去读 ，有哪些文件发生了变化 ，然后根据这个变化的具体的类型 ，Alluxio决定要不要再去namenode触发一次元数据的同步。
这样的元数据同步是有的放矢 ，不再是基于时间猜测 。每一次同步都是有理有据 ，知道文件已经改变 ，称为Active Sync ，也是因为在这里化被动为主动 ，不再被动去猜 ，而是主动知道了有哪些变化 ，然后主动去触发同步 。但是这个inotify只能告诉告诉我们哪些文件发生了变化以及变化是什么类型 ，包含的信息很少，具体要做同步还需要一个元数据同步的机制 ，所以这一步是绕不开的 。具体的使用也非常简单 ，可以通过指令来开启它 ，也可以关闭，或者查看现在有哪些HDFS路径或挂载点开启了这个功能 ，这些指令也受Journal日志保护，当开启了Active Sync功能之后，就会被记录在Journal日志里面 ，在重启集群之后 ，无需重敲一遍指令 。
4. Active Sync性能取舍
Active Sync也不是万能药 ，它做了一些功能的取舍 。每种设计都有它的取舍 ，因此也有适合和不适合的场景 。
图21 Active Sync性能取舍
Active Sync在确定了文件更改之后 ，再去做同步操作 ，它省掉了那些没有变化 、无用的同步操作 。但是每一个文件的更改 ，都会触发同步操作 。具体文件的更改并不一定是客户端的请求，虽然是主动加载它，但实际上并不一定用到 ，有可能是多余的操作 。
Active Sync和基于时间戳的同步机制，各有利弊。具体选择时需要进行考量 ，在后面的章节会总结分析哪种场景适合的配置 。同时要注意Active Sync只支持HDFS ，原因是只有HDFS提供API ，其他存储没有机制可以知道有哪些文件发生了变化，所以没有办法来实现 。
--
05
元数据同步实现与优化
在了解了机制后 ，现在了解一下元数据同步的实现原理 ，然后再看元数据同步的优化 。
1. 元数据同步原理
目前元数据的同步粗略分为左下角的这几个步骤 。左上角我们列出了元数据同步的参与者 。包括了RPC线程 ，就是Master端，来自于RPC的线程池 。第2个参与者称作同步线程池（sync thread pool）。第3个参与者称作预取线程池（prefetch thread pool） 。这里有一个InodeTree，就是Alluxio里面维护的所有文件的元数据，形成了一个树状的结构。图中的UFS代表着实际的底层存储 。所有对UFS的连线都是一个对外部系统的RPC ，是比较昂贵的操作 。
图22 元数据同步原理
同步步骤分三步：
① RPC线程向UFS读取文件的元信息 。在处理请求ls -R 时 ，对根节点全量的文件树进行一次ls操作。此时基于时间戳，需要触发元数据同步 ， RPC线程就会读取文件根节点的信息 ，检查挂载HDFS://alluxio根节点的信息。如果发现信息有更新，就去InodeTree里面找根节点，则RPC线程对应地更新/创建/删除Alluxio的Inode元信息，并且这个节点进行更新 。
② 如果在处理递归的时候 ，发现下面还有其他目录，整棵树都需要进行一次搜索 ，此时把递归文件/文件夹提交到同步线程池（sync thread pool） 。用广度优先搜索的方式进行遍历 ，也就是常说的BFS 。当提交这个任务后 。会去同步线程池 ，在BFS的过程中 ，按照一定的顺序遍历这棵树，data -> user -> others -> report …
在这个过程中 ，主要是做两件事情：
就把任务提前交给预取线程池 ，告诉它去读HDFS里面相关的这些路径 ，这也就是称为预取的原因 。在真正处理这个路径之前 ，就提前告诉它 ，因为操作会需要很长的时间 ，保证性能最好的方式就是提前做这个事情；等任务处理到的时候 ，已经准备好了 。这样最高地利用了多线程的并发 。
在处理每个节点的时候 ，确认预取线程池准备好的结果；如果有更新 ，就更新自己的InodeTree 。
③ 预取线程池负责从读取文件或者文件夹信息 ，把结果交给这个同步线程池 ，来加速这个具体的同步过程。
2. 性能优化-缓存
在这个时间原理的基础上 ，进行了一系列的优化 。
图23 性能优化-缓存
首先就是做了缓存的优化 。主要的设计理念就是因为UFS操作非常贵、非常慢 ，希望尽可能多的地缓存结果，节省的操作 。
缓存优化涉及下面这几种缓存 ：
3. 算法优化-锁优化
在缓存优化之外 ，基于Alluxio的版本迭代 ，也做了各种各样的元数据同步优化 ，其中比较大的就是算法的优化 。
图24 算法优化-锁优化
在Alluxio2.3版本之前 ，所有的RPC线程是自己进行元数据的同步 。如果递归基于DFS自己遍历这棵树，从头到尾都持有路径的写锁 。如果是递归，实际上是写锁锁住了整个子树。在锁住子树的过程中，其他线程就无法读取子树里的内容，并发度低，由于是单线程 ，做了非常多需要Block时间长的操作 。
在Alluxio2.3里面非常大的优化 ，就是把它改成了多线程并发同步的算法 ，更多利用线程池操作 ，DFS改成了BFS 。根据需要 ，读锁升级 ，而非从头至尾持有写锁 。读写锁的好处就是让不同的线程之间有了更高的并发度。这样在同步某一棵子树的过程中 ，其他线程还有机会可以读到这里面的内容 ，所以整体的并发会更高 。
4. 性能优化-调整并行度
第三个优化来自于用户对线程池的配置 。
图25 性能优化-并行度
在Alluxio 2.3里面加入了线程池之后，可以通过配置参数调整元数据同步的并行度 。之前单线程没有配置可言 。调整并行度一般是通过这三个参数 。
两个线城池的大小，建议配置成CPU数的倍数 ，具体比例以及系统应该配多大 ，取决于这两个线程所做工作的时间 ，以及中间的配合方式 。所以没有给出统一建议 ，建议根据具体程序运行的时候，CPU比如可以做一些火焰图 、分析延迟以及inodetree更新的延迟 ，做一个更加合理的配比。默认的配比都是CPU的倍数 ，如果没有在无数据同步看到非常明显的瓶颈，不需要进行特别细粒度的调节 。
--
06
对不同场景的推荐配置
最后针对不同的场景具体分析问题 ，推荐比较好的配置 。
1. 场景1
图26 场景一配置
最简单的场景就是 ：所有的写和读全都经过了Alluxio 。无疑Alluxio所有的元数据都是最新 ，此时无需做元数据同步 。可以关闭元数据同步 ，提升性能 。
2. 场景2
第二个场景稍微复杂一些 。大部分的操作经过Alluxio ，但是不排除还有一些场景 ，会绕过Alluxio直接改动原来里面的文件 。
图27 场景二配置
在这种场景下 ，为了保证Alluxio和UFS元数据和数据的一致 ，还是要保留一部分元数据同步的操作。在这里分HDFS和非HDFS进行考虑 ，主要是因为这些HDFS比别人多一个选项Active Sync 。
HDFS的情况下 ，需要考虑这几个点 ：如果HDFS更新非常频繁 ，就是绕过Alluxio的更新非常频繁 ，或者HDFS的namenode的压力比较大 ，不建议使用Active Sync，而是使用基于时间的被动同步 。使用被动同步的原因是Active Sync是基于Alluxio心跳，去namenode拉取具体有哪些文件发生了改动 ，每一次拉取都是一次RPC ，给namenode施加的压力 。同时如果文件发生了改动 ，Alluxio就又会向namenode发起RPC去同步这些文件。因此希望尽量减少这些操作来降低namenode的压力 。
如果基于时间的被动同步，能给予减少元数据同步操作的机会 ，则使用基于时间的被动同步；反之要使用Active Sync，因为更加主动，时效性更高。如果不会带来性能负担 ，完全可以去尝试一下 。
如果不是HDFS ，只能用基于时间的被动同步 。
建议尽量节约元数据同步的操作 ，具体做法考虑每个数据、每个路径更新的频率大概是如何 。基于这样的考量 ，尽量给sync interval设一个比较大的值 ，尽量减少元数据的触发 。
3. 场景3
第三个场景稍微有些不同 。大部分或全部更新都不经过Alluxio ，而更新又非常频繁 。
图28 场景三配置
在这种情况下 ，使用HDFS而且时效性又非常重要，使用Active Sync是唯一方案 。因为如果把sync interval调到一个特别低的值 ，甚至可能触发比Active Sync更多的同步 。如果把它设成零之后 ，每一次都不会触发同步，会进一步加大同步的操作开销 。
如果时效性并不十分重要 ，建议使用这个基于时间的被动同步 。通过节省开销 ，减少元数据同步的操作 ，就能提升系统的性能。同样如果不是HDFS ，则使用基于时间的被动同步 。
以上是三个场景的分析，也是今天分享的全部内容 。
--
07
答疑
Q ：在ASYNC_THROUGH mode当中 ，因UFS原因导致ASYNC上传始终失败 ，这种情况怎么优雅地处理 ，以避免不一致 ？
A ：这个问题非常好 ，问到了痛点 。目前没有一个特别优雅的解决方案 。
在异步方式下没有call back ，或者hook的自动介入 ，只能人为介入 。Alluxio2.4商业版中加入了一个job service dashboard查看异步任务的状态 。如果异步持久化失败了 ，这个地方可以看到所有失败的异步任务 。目前只能通过这个方式观察究竟有哪些东西失败了 ，然后再人为进行干预 。
我们已经注意到job service的问题，打算重新设计整个job service ，从几个方向 ，可扩展Scalability, Fault-tolerance ，包括monitoring, failure mode, 恢复等。未来版本里面会做出更好的设计，有很多场景 ，并加入人工干预模式 。通过开放一些接口 ，可以自动化地读到这些东西 ，或是可能会增加界面 ，让用户定义一些方式 。
Alluxio到了一个新的阶段 ，要好好思考 ，用更加scalable的方案去解决这些问题 。这些异步的操作已经提上了议事日程 。
Q ：和HDFS可以不同路径设置不同的同步时间吗？
A ：可以用配置参数的方法去实现。
今天的分享就到这里 ，谢谢大家 。
阅读更多技术干货文章 、下载讲师PPT ，请关注微信公众号“DataFunTalk” 。
分享嘉宾：刘嘉承 Alluxio 核心组研发工程师
编辑整理 ：曾新宇 对外经贸大学
出品平台 ：DataFunTalk
分享嘉宾 ：
关于我们 ：
DataFun ：专注于大数据、人工智能技术应用的分享与交流 。发起于2017年，在北京 、上海 、深圳 、杭州等城市举办超过100+线下和100+线上沙龙 、论坛及峰会 ，已邀请超过2000位专家和学者参与分享 。其公众号 DataFunTalk 累计生产原创文章700+ ，百万+阅读 ，14万+精准粉丝 。
欢迎转载分享评论 ，转载请私信。
产品展示 
联系方式