Alluxio2.X简要介绍
本文基于将alluxio 2.X集成到大数据发行版的经验,从各个方面介绍alluxio
什么是alluxio?
alluxio是一个以内存为中心的分布式虚拟存储系统
为什么需要alluxio?
借用官网的一张图来说明
最主要有两点功能:
- 在数据分析系统和底层存储之间架起桥梁,alluxio像胶水一样,将不同的底层存储用统一的接口统一暴露给上层的计算引擎,起到了一个文件系统gateway的作用
- 内存优先的分布式架构,领先其他方案数量级的差别,alluxio支持多级缓存,优先使用内存缓存,同时也可以设置ssd缓存,hdd缓存
alluxio的优势
- 内存速度I/O,相对于磁盘I/O来说更加快速
- 简化云存储和对象存储,解决了应用没有节点级缓存或者跨节点的分布式缓存
- 简化数据管理,多个数据源可以使用alluxio进行统一的入口访问
- 应用易于部署,应用侧不需要修改代码即可集成
alluxio服务的几个组件
组件名称 | 作用 |
---|---|
client | 集成到其他计算框架中,调用alluxio服务端 |
master | 1.管理全局的元数据信息,包括:目录树(inode tree),块信息(block),worker的容量信息;2.worker发送心跳; 3.client获取元数据 |
worker | 1.底层数据存储在worker中供客户端使用; 2.alluxio客户端不依赖底层存储 |
jobmaster | 1.负责在Alluxio中异步调度许多重量级文件系统操作,提高master吞吐量;2.为后期复杂操作提供扩展性 |
jobworker | 执行job master分配的任务,建议与worker放在同一节点上 |
alluxio读场景数据流
- 命中本地worker
client请求master获取存储的worker在本机,直接从本地内存或磁盘读取,避免远程交互 - 命中远程worker
client请求master获取存储的worker在其他节点的worker,client使用远程请求获取数据,并且在本地的worker缓存该数据(用户可通过配置禁用本地副本写入) - 未命中worker
client请求master发现需要的数据没有缓存在alluxio中,client会通过worker从底层的存储系统中获取一个完整的数据块,异步缓存至alluxio,并且将数据返回给client
写入时的四种缓存策略
策略 | 注释 |
---|---|
MUST_CACHE | 只写入缓存 |
CACHE_THROUGH | 同步写入缓存和底层存储系统 |
ASYNC_THROUGH | 异步写入缓存和底层存储系统,调用jobmaster和jobworker完成 |
THROUGH | 只写入底层存储 |
实践过程中需要注意的点
1.编译源码需要使用git clone下来的代码
编译过程中会用到git命令获取对应的tag,如果不使用源码的git仓库,则需要修改maven打包相关的配置
2.alluxio相关的配置项过多
集成的过程中需要的配置非常多,需要记录成功配置的信息,避免后边遇到配置问题时难处理
3.实际业务场景下alluxio的优劣
优势
- 在底层文件系统压力比较大的情况下,能够缓解压力
劣势
- 不适用写操作较多的场景
alluxio 1.X 和 2.X主要差别
从实践看来最主要的有两方面的差别
1.增加了jobmaster和jobworker组件
2.X版本为了增加alluxio服务的稳定性和扩展性,将比较重量级的操作都交给了jobmaster和jobworker组件进行,后边进行类似的操作也都放在jobmaster和jobworker中,当前有以下四个操作放在了jobmaster中:
- Loading data into Alluxio from a UFS 从用户文件系统加载到alluxio
- Persisting data to a UFS 将alluxio文件传递到UFS中
- Replicating files within Alluxio 在alluxio中复制文件
- Moving or copying data between UFS or Alluxio locations 在用户文件系统和alluxio中移动或者拷贝文件
2.高可用选主支持zookeeper和自带的选主逻辑
在alluxio1.X中,master选主只能支持zookeeper配置,在2.0版本中加入了自带的高可用逻辑,并且官方推荐使用这种方式,减少了对其他组件的依赖