Alluxio学习

Alluxio学习

1 基本概念

1.1 Alluxio是什么

参考

Alluxio,曾用名Tachyon,是一个开源的虚拟分布式存储系统。其实是提供API给上层计算应用,方便统一访问底层的各个存储系统如HDFS、OSS、S3等,当然Alluxio有多级缓存来加速访问,但他本身并不能算是个数据持久化系统。

Alluxio源自 UC Berkeley 的 AMPLab(见论文),在伯克利数据分析栈 (Berkeley Data Analytics Stack, BDAS) 中扮演数据访问层的角色

他将计算框架和存储层桥接,具体做法是将数据从存储层移动到距离数据驱动应用很近的地方,使得应用可以通过通用接口来以内存即速度快速访问数据量巨大的存储系统。 Alluxio内存至上的层次化架构可使得数据的访问速度能比现有方案快几个数量级。当然,首次访问时速度较慢,需要将数据加载到Alluxio缓存,以后就非常快了。

在一些大公司的生产实践中,Alluxio被用来管理PB级别的数据,最大的已经部署了超过1300个节点。

1.2 Alluxio在大数据生态中的位置

在这里插入图片描述
如上图所示,在整个大数据生态中,Alluxion位于数据驱动应用(如Spark、Presto、HBase、Hive、Flink、Tensorflow等)和数据持久化存储系统(如HDFS、OSS等)之间。Alluxio统一了这些不同数据源的数据存储,并为上层数据驱动因一共启动了统一的访问API、全局Namespace

  • Alluxio支持的底层存储:
    • HDFS
    • S3
    • 阿里云OSS
    • 其他扩展
  • Alluxio支持的计算应用:
    • Spark
    • MapReduce
    • HBase
    • Hive
    • Presto
    • 深度学习框架
    • Tensorflow

1.3 Alluxio优势

  • 统一访问入口,底层存储对用户透明
    Alluxio通过屏蔽底层存储细节,简化了应用程序访问其数据的方式,方便从异构数据源中提取信息。

    且Alluxio拥有对所有底层数据源的统一Namespace,并提供统一的标准化访问接口API(可透明地将标准客户端API转换为任何底层存储的API)。

  • 达到内存速度的 I/O
    Alluxio 可够用作分布式共享缓存服务,这样与 Alluxio 通信的计算应用程序可以对客户端透明地缓存那些频繁访问的数据(尤其是距离较远、访问成本较高数据),以提供内存级 I/O 吞吐率。

  • 多级缓存
    此外,Alluxio可充当读写底层数据源的缓存,他的层次化存储机制能够充分利用内存、SSD或磁盘,弹性可伸缩,从而降低成本。

    这些缓存细节对使用者透明。

  • 简化云存储和对象存储接入
    与传统文件系统相比,云存储系统和对象存储系统使用不同的语义,这些语义对性能的影响也不同于传统文件系统。

    比如,云存储和对象存储系统上进行常见的文件系统操作(如列出目录和重命名)通常会导致大量的性能开销。当访问云存储中的数据时,应用程序是没有Node级别的数据本地性或跨应用程序缓存的。

    这种场景下,如果将 Alluxio 与云存储或对象存储服务一起部署则可以缓解这些问题,用户可以直接从 Alluxio 中检索读取数据。

  • 简化数据管理
    除了可同时连接不同类型的数据源之外, 甚至还允许同时连接同一存储系统的不同版本,且无需复杂的系统配置和管理。

  • 应用开发简单
    Alluxio管理和应用、文件、对象存储间的通信,将用户的数据访问请求直接翻译为底层存储接口调用。

    而且Alluxio是Hadoop兼容的,也就是说如Spark、MR等数据分析程序可直接在Alluxio上运行而无需改动任何代码。

  • 统一

  • 清晰的Alluxio web UI

  • 应用和Alluxio配合
    Alluxio 管理应用程序和文件或对象存储之间的通信,将数据访问请求转换为底层具体存储接口的请求。Alluxio 与 Hadoop 生态系统兼容,现有的数据分析应用程序,如 Spark 和 MapReduce 程序,无需修改任何代码就能在 Alluxio 之上运行。

1.4 Alluxio架构

1.4.1 概述

参考

  • Alluxio-IArchitecture
    在这里插入图片描述
    Alluxio主要组件有

  • Master
    一个Leader,若干Standby

  • Worker
    若干

  • JobMaster
    一个Leader,若干Standby

    JobMaster和JobWorker可作为一个单独的、称为Alluxio Job Service的轻量级任务调度框架,负责分配不同类型的操作给JobWorker,这些任务如下:

    • 从底层文件系统加载数据到Alluxio
    • 持久化数据到底层文件系统
    • Alluxio内拷贝文件副本
    • 在底层文件系统或Alluxio之间移动或拷贝数据
  • JobWorker
    若干

    推荐将Worker和JobWorker部署在一起,以降低RPC延时和数据传输成本。

  • Client
    Client通过数据应用(如Spark、MR等)或Alluxio Cli、Alluxio FUSE layer等方式来和Alluxio服务端交互

1.4.2 Master

在这里插入图片描述

1.4.2.1 Master

在一个Alluxio集群中,有一个Leader,若干Standby。

Leader Master职责

  • 管理整个系统全局元数据
    包括文件系统元数据(inode树)、Block元数据、Worker资源元数据
  • 处理所有用户通过Client发起的元数据读或修改请求
  • 处理journal文件系统变更
    将所有的文件系统事务记录到分布式持久化存储位置,以在需要时恢复Master状态信息,这些记录就是journal
  • 接收所有Worker发送来的周期性的心跳信息,以保持他们存活认证。
    注意Master不会主动向其他组件发起通信请求,仅会通过RPC发出响应
  • 应用数据不会通过Master路由

Standby Master职责:

  • 在HA模式时需要部署在不同节点,以在Leader挂掉时重新选举出新的Leader来管理集群
  • 读取Leader写入的journal数据以更新自己的那份master状态信息副本,以备恢复使用
  • 不处理任何由其他组件发来的请求
1.4.2.2 JobMaster

异步调度负责文件系统操作,分配文件系统操作给JobWorker执行,任务如下:

  • 从底层文件系统加载数据到Alluxio
  • 持久化数据到底层文件系统
  • Alluxio内拷贝文件副本
  • 在底层文件系统或Alluxio之间移动或拷贝数据

将JobMaster从Master中分离出来的目的是让Master更单纯,用更多资源来服务更多的客户端请求。

1.4.3 Woker

在这里插入图片描述

1.4.3.1 Worker

负责:

  • 管理用户配置的分配给Alluxio的本地资源,如内存、SSD、传统HDD磁盘等
  • 将数据以Block形式存储
    这样能将读到的底层数据存储在Worker内存,立即对客户端可用;这样客户端就可以做的很轻量级,不需要管底层存储细节
  • 接收客户端的读写数据请求请求,这些请求就是在Block上操作的
  • Worker缓存有驱逐策略,在内存满时进行驱逐以腾出空间。
    缓存细节参考Tiered Storage

推荐将Worker和JobWorker部署在一起,以降低RPC延时和数据传输成本。

1.4.3.2 Job Worker

Job Worker相当于是Alluxio文件系统的客户端,职责:

  • 执行JobMaster分配的任务,对指定文件系统位置做以下操作
    • 从底层文件系统加载数据到Alluxio
    • 持久化数据到底层文件系统
    • Alluxio内拷贝文件副本
    • 在底层文件系统或Alluxio之间移动或拷贝数据

推荐将Worker和JobWorker部署在一起,以降低RPC延时和数据传输成本。

1.4.4 Client

用户用Client来和Alluxio服务端交互

  • 和Leader Master交互一致性元数据相关操作
  • 和Worker交互以读写数据
    Client不会直接访问底层文件系统
  • Alluxio 文件系统支持 Java、REST、Go、Python等API,同时提供了 HDFS API。

1.5 数据流-读

1.5.1 概述

以下描述Alluxio作为应用和底层存储间中间缓存的各种场景。

1.5.2 Local Cache命中

当请求命中驻留在Client所在机器的Alluxio Worker上的缓存数据时机触发Local Cache命中。
在这里插入图片描述
应用程序访问数据流程:

  1. 应用程序通过Alluxio Client访问Alluxio Master来查找数据所在的Worker位置
  2. Master将数据所在位置返回给Client
  3. 如果发现数据在Client本地,则Client直接使用short-circuit短路读
    具体来说,会绕开Worker直接读本地文件系统,避免了数据通过网络TCP传输,是Alluxio中最快的一种方式。

1.5.3 Remote Cache命中

当请求的目标数据存在于非Client所在机器的Alluxio Worker上时触发Remote Cache命中。

这种模式的读取速度受限于网络传输速度。

Alluxio会优先采用远程网络读取方式,而不是从底层文件系统读取,因为前者速度一般更快。
在这里插入图片描述
应用程序访问数据流程:

  1. 应用程序通过Alluxio Client访问Alluxio Master来查找数据所在的Worker位置

  2. Master将数据所在位置返回给Client

  3. Client向目标Worker发起远程读取

  4. Worker从内存中捞取数据

  5. Worker将数据发回给Client

  6. Client收到数据后,通知本地机器上的Worker创建一个本地副本,以使得未来读取该数据时可以直接读本地缓存。

    具体来说,会绕开Worker直接读本地文件系统,避免了数据通过网络TCP传输,是Alluxio中最快的一种方式。

1.5.4 Cache 未命中

如果目标数据不在Alluxio中,则会造成Cache 未命中。

此时会造成最大的延迟,因为必须从底层文件系统读取数据,但是首次读取数据时必须经历这一阶段。
在这里插入图片描述
应用程序访问数据流程:

  1. 应用程序通过Alluxio Client访问Alluxio Master来查找数据所在的Worker位置
  2. Master告知Client当前系统无此数据
  3. Client将读底层存储请求代理给本机Worker执行
  4. Worker从底层存储读取数据
  5. 读取到数据后,Worker将数据缓存到本地内存
  6. 最后Worker将数据返回给Client

关于异步缓存(asynchronous caching)

  • 如果Client只是读取一个Block的部分数据或是非顺序读取Block时,客户端会通知Worker异步的缓存整个Block
  • 此时不会阻塞Client,但如果Alluxio和底层存储系统间的网络带宽是瓶颈时,还是会影响性能。
  • 相关参数为Worker上的alluxio.worker.network.async.cache.manager.threads.max,默认8

1.5.5 禁用Cache

Client的设置以下配置:

  • alluxio.user.file.readtype.default=NO_CACHE

1.6 数据流-写

1.6.1 概述

用户可以用不同的写入模式来配置数据怎么写入,Client参数为alluxio.user.file.writetype.default

以下描述不同模式的性能表现。

1.6.2 MUST_CACHE

数据只写到Alluxio 缓存,不写到底层存储系统,配置值为MUST_CACHE
在这里插入图片描述

  1. 应用程序通过Alluxio Client访问Alluxio Master来查找数据应该写入的Worker位置
  2. Master告知Client应存位置
  3. Client将数据存入本地Alluxio内存缓存RAM
    如果开启了短路写(short-circuit write),则Alluxio Client直接写数据,不经过Worker,避免了网络传输。

注意,因为只写到了内存,所以此模式可能会在机器崩溃或内存不足需要为新的写入驱逐旧数据时,导致数据丢失。也就是说,MUST_CACHE适合于用在可容忍数据丢失时,比如临时数据。

1.6.3 CACHE_THROUGH

同步写到一个Alluxio Worker和底层存储系统,配置值为CACHE_THROUGH
在这里插入图片描述

  1. 应用程序通过Alluxio Client访问Alluxio Master来查找数据应该写入的Worker位置
  2. Master告知Client应存位置
  3. Client将写底层存储请求代理给本机Worker执行
  4. Worker同时将数据写入本地内存缓存和底层存储系统
    所以此时写入数据速度取决于写底层存储系统的速度
  5. 最后Worker告知Client写数据成功

CACHE_THROUGH模式适合于数据必须持久化时。

因为写了本地缓存,所以未来读取这些数据时,就可以直接从内存快速读取。

1.6.4 ASYNC_THROUGH

先同步写到一个Alluxio Worker内存,再异步在后台持久化到底层存储系统,配置值为ASYNC_THROUGH
在这里插入图片描述

  1. 应用程序通过Alluxio Client访问Alluxio Master来查找数据应该写入的Worker位置
  2. Master告知Client应存位置
  3. Client将写底层存储请求代理给本机Worker执行
  4. Worker同步地将数据写入本地内存缓存
  5. Worker异步地在后台将数据写入底层存储系统

ASYNC_THROUGH模式可提供接近于MUST_CACHE的写入速度,但还多了一项可持久化数据的功能,更可靠。

从Alluxio 2.0开始,ASYNC_THROUGH称为默认选项。

有一个重要的Client配置alluxio.user.file.replication.durable,默认为1,设置了新数据在写入内存完成后、持久化到底层文件系统之前的目标副本层级( target replication level)。

1.6.5 THROUGH

只写到底层文件系统。

本模式下,数据会同步地写入底层文件系统,而不会缓存到Alluxio Worker。

保证了数据在写入完后后持久化,但速度受限于底层文件系统吞吐。

2 Alluxio下载、安装、配置和部署

可参考:

2.1 下载

下载页面:https://www.alluxio.io/download/

分为免费的社区版和收费的企业版。

我们这里下载社区版。

2.2 安装

将下载好的alluxio-2.3.0-bin.tar.gz解压:

tar -zxvf alluxio-2.3.0-bin.tar.gz

2.3 配置

进入解压的目录,并执行:

cp conf/alluxio-site.properties.template conf/alluxio-site.properties
vim conf/alluxio-site.properties

增加以下属性:

  • alluxio.master.hostname=192.168.1.1
    192.168.1.1 改成你要堆外提供访问的主机名

  • alluxio.master.mount.table.root.ufs=/tmp/alluxio
    设置本地磁盘的一个临时文件夹。

    默认配置下,local模式的Alluxio使用的是本地磁盘作为底层存储,路径就是本项配置指定。

2.4 检查运行环境

通过以下命令检测系统环境是否能兼容运行Alluxio服务,会打印出检查报告。

./bin/alluxio validateEnv COMMAND [NAME] [OPTIONS]
  • COMMAND

    • local: 在本地运行所有检查任务
    • master: 在本地运行检查master任务
    • worker: 在本地运行检查worker任务
    • all: 在所有master和worker节点运行对应的检查任务
    • masters: 在所有master节点运行检查master任务
    • workers: 在所有slave节点运行检查worker任务
    • list: 展示所有检查任务
  • NAME
    可选的。不填时运行所有检查,如果写一个单词会前缀会检查以你的输入开头的所有配置项。

  • OPTIONS

实践中,我发现以下命令其实无法展现出到底错误是啥?

./bin/alluxio validateEnv local

2020-07-14 19:56:16,365 INFO  ExtensionFactoryRegistry - Loading core jars from /local/service/alluxio-2.3.0/lib
2020-07-14 19:56:16,405 INFO  ExtensionFactoryRegistry - Loading extension jars from /local/service/alluxio-2.3.0/extensions
Validating local environment...
Validating worker.web.port.available...
ValidateAlluxioPorts
Validating ufs.hdfs.config.version...
ValidateHdfsVersion
Validating java.native.libs...
ValidateJavaNativeLibPaths
Validating ufs.path.superuser...
ValidateSuperUserPrivilege
Validating ssh.nodes.reachable...
ValidateSshAccessibility
Validating ufs.path.accessible...
ValidateUfsDir
Validating master.ufs.hdfs.security.kerberos...
ValidateKerberosForSecureHdfsMaster
Validating master.rpc.port.available...
ValidateAlluxioPorts
Validating proxy.web.port.available...
ValidateAlluxioPorts
Validating worker.ramdisk.mount.privilege...
ValidateRamDiskMountPrivilege
Validating ufs.hdfs.config.correctness...
ValidateHdfsConf
Validating worker.ufs.hdfs.security.kerberos...
ValidateKerberosForSecureHdfsWorker
Validating ufs.hdfs.config.proxyuser...
ValidateProxyUserConf
Validating master.web.port.available...
ValidateAlluxioPorts
Validating worker.storage.space...
ValidateStorageSpace
Validating ufs.hdfs.config.parity...
ValidateHdfsServerAndClientConf
Validating cluster.conf.consistent...
ValidateClusterConfConsistency
Validating ulimit.nofile...
ValidateUserLimit
Validating ulimit.nproc...
ValidateUserLimit
Validating worker.rpc.port.available...
ValidateAlluxioPorts
1 failures 1 warnings 1 skipped

此时我换用以下命令:

./bin/alluxio validateEnv all

2020-07-14 19:57:21,633 INFO  ExtensionFactoryRegistry - Loading core jars from /local/service/alluxio-2.3.0/lib
2020-07-14 19:57:21,677 INFO  ExtensionFactoryRegistry - Loading extension jars from /local/service/alluxio-2.3.0/extensions
Validating master environment on 192.168.1.1...
Error: Alluxio requires Java 8, currently Java 1.7.0_99 found.
Connection to 192.168.1.1 closed.
Validating worker environment on 192.168.1.1...
Error: Alluxio requires Java 8, currently Java 1.7.0_99 found.
Connection to 192.168.1.1 closed.
Validating cluster environment...
Validating cluster.conf.consistent...
ValidateClusterConfConsistency

Validation succeeded.

可以看出我的jdk版本不符合Alluxio要求。

如果确认自己是配置正确的,但是alluxio一直找不到正确的jdk路径,可以在/alluxio-2.3.0/libexec/alluxio-config.sh中加入:source /etc/profile 以使得环境变量配置生效。

2.5 格式化

Alluxio需要在首次启动前先对Journal和Worker存储目录执行格式化(只需要在首次启动时执行,否则会造成Alluxio上存储的所有数据和元数据全部被清除,当然,这不会影响底层文件系统中的数据):

./bin/alluxio format

首次本地启动可能报错:

java.nio.file.NoSuchFileException: /mnt/ramdisk/alluxioworker

直接创建该目录:

mkdir -p /mnt/ramdisk/alluxioworker

2.6 启动

在local模式下,默认Alluxio会在本地启动一个master和一个worker进程:

  • 还没有挂在RAMDIK或想重新挂载(比如想改变他的大小)
./bin/alluxio-start.sh local SudoMount
  • 已经挂载过RAMDIK
./bin/alluxio-start.sh local

注意:用户在linux系统下运行上述命令,可能需要输入密码来获取sudo权限以启动RAMFS。如果用户不想每次运行都输入密码、或没有sudo权限,可以参考FAQ

2.7 Web页面

启动成功后,

可通过访问 http://localhost:19999 查看 Alluxio master 的运行状态:
在这里插入图片描述
http://localhost:30000 查看 Alluxio worker 的运行状态。
在这里插入图片描述

2.8 检测运行状态

./bin/alluxio runTests

2.9 停止

./bin/alluxio-stop.sh local

./bin/alluxio-stop.sh all

2.10 集群模式(HA)

可参考

可通过在不同机器运行多个Alluxio Master进程节点来保证Alluxio集群服务高可用:

  • 其中一个Master会被选举为Leader Master,为所有Worker和Client提供服务。
  • 其他Master节点作为StandBy Master节点,通过追踪共享的journal来维护和主master相同的文件系统状态

3 Alluxio Shell

3.1 概述

可参考

Alluxio提供的交互式命令行工具。

3.2 文件系统基本操作

  • ./bin/alluxio fs
    查看所有文件系统相关命令列表

  • ./bin/alluxio fs ls /
    查看指定路径文件夹和文件情况

  • ./bin/alluxio fs copyFromLocal LICENSE /LICENSE
    将本地LICENSE文件放入 Alluxio的/目录下,重命名为LICENSE。上传后,可以查看该文件:

    ./bin/alluxio fs ls /LICENSE
    -rw-r--r--  root           root                     27040       PERSISTED 07-15-2020 17:36:56:978 100% /LICENSE
    

    可以看到,该命令和在linux系统里执行类似,可以看到一些基础属性。
    此外,PERSISTED代表该文件已经持久化到底层存储,如果是NOT_PERSISTED则表示为持久化;100%表示100%的该文件缓存在Alluxio中。

    上传后,如果是local模式可以在本机磁盘上的/tmp/alluxio上看到该文件。

    $ ll /tmp/alluxio
    total 32
    drwxr-xr-t 2 root root  4096 Jul 15 17:31 default_tests_files
    -rw-r--r-- 1 root root 27040 Jul 15 17:36 LICENSE
    
  • ./bin/alluxio fs cat /LICENSE
    查看Alluxio上的/LICENSE文件内容

  • ./bin/alluxio fs persist /LICENSE
    可以将NOT_PERSISTED状态的/LICENSE文件持久化到底层存储之上。

    此时,我们可以通过master web来查看Alluxio中存储的所有文件状态。
    在这里插入图片描述

3.3 文件挂载

3.3.1 概述

前面提到过,Alluxio最牛的地方就是对所有底层存储提供了一个统一的NameSpace,详见:

用户可以利用这个特性来将不同存储系统挂载到Alluxio Namespace,统一访问入口。

3.3.2 命令

  • ./bin/alluxio fs mkdir /mnt
    在alluxio namespace中创建一个路径为/mnt的挂载点

4 将HDFS作为Alluxio底层存储

可参考

4.1 配置

修改conf/alluxio-site.properties:

  • alluxio.master.mount.table.root.ufs=hdfs://:
    将hdfs根目录挂载到alluxio

    要获得hdfs运行的地址,可执行:

hdfs getconf -confKey fs.defaultFS
  • alluxio.master.mount.table.root.ufs=hdfs://:/alluxio/data
    将hdfs上的/alluxio/data目录挂载到alluxio。

4.2

5 在MR上配置Alluxio

这是在Hive上配置Alluxio的前提。

6 在Hive上配置Alluxio

7 在Spark上配置Alluxio

更多好文

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Alluxio Journal 是 Alluxio 这个开源分布式存储系统中的一种核心组件。它的作用是记录所有重要的元数据和操作信息,以实现数据的持久化和容错性。 Alluxio Journal 使用一种叫作 JournalWriteAheadLog 的技术来记录元数据和操作信息。这是一种高效的日志记录方式,可以将所有操作以日志的形式追加到顺序写的日志文件中,而不需要频繁的磁盘随机写入。这种写入方式可以提高系统的写入性能,并保证数据的一致性和持久性。 通过使用 JournalWriteAheadLog 技术,Alluxio Journal 可以确保在系统发生故障时能够快速地恢复和恢复数据的一致性。当系统启动时,Alluxio Journal 会读取日志文件来重放之前的所有操作,并将元数据状态恢复到故障发生之前的状态。这样,即使有异常发生,Alluxio Journal 也可以保证数据的一致性。 此外,Alluxio Journal 还支持主从模式,即能够将日志复制到多个节点上,以提供更高的容错性和可靠性。如果主节点发生故障,可以快速切换到备用从节点上,从而实现故障转移和高可用性。 总之,Alluxio Journal 是 Alluxio 存储系统的重要组件,通过使用 JournalWriteAheadLog 技术,它可以记录和恢复所有重要的元数据和操作信息,以实现数据的持久化和容错性。它还支持主从模式,提供了高可用性和可靠性。这些特性使得 Alluxio Journal 在分布式存储系统中起着至关重要的作用。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值