作者介绍
毛宝龙 腾讯高级工程师,Alluxio PMC & Maintainer,Apache Ozone committer,腾讯 Alluxio OTeam 开源协同团队负责人。主要负责腾讯 Alluxio 的研发和落地工作和 Apache Ozone 的文件系统方向的研发工作。
DOP(Data Orchestration Platform) 是腾讯推出的数据编排平台服务。定位通用数据编排。无论是大数据和AI,无论公有云、私有云和腾讯内网都在使用统一的数据编排平台 DOP,如腾讯云DLC、EMR等产品,在DLC上更是实现了“0”成本的2-5倍缓存加速效果。
DOP 与腾讯大数据生态紧密结合。充分利用硬件剩余资源,与计算配合,为用户提供计算加速、数据转换、数据无感迁移、统一存储服务、智能数据路由等能力。
加速机器学习和人工智能等 AI 业务访问存储等能力。
腾讯 Alluxio(DOP) 团队自成立以来,一路走到现在,在三网都有大规模落地,也构建了业内最大的 Alluxio 单集群规模。
DOP 为了解决存算分离架构下,多数据源,多计算框架等复杂的数据访问问题,作为计算和存储之间的数据编排层,屏蔽了不同存储系统的差异,提供统一的数据入口。此外,DOP 提供的统一自适应 SDK,可以通过 DOP 的缓存集群访问数据,从而达到数据加速效果,也可以直接访问底层存储,此外,DOP 还可以当做一个完成的文件系统。
如下部分功能会陆续贡献开源社区
在 Alluxio 中,一个底层存储系统是可以插拔的,任何文件存储系统和对象存储系统都可以集成到 Alluxio 中。因此,用户可以挂载不同的存储,像 AWS S3 或者 HDFS 等存储系统都可以挂载到 Alluxio 中。Alluxio 将 UnderFileSystem 框架设计成模块化,为了让用户可以很容易地扩展自己的底层文件系统支持。
HDFS 底层存储连接器(UFS connector),扩展了Alluxio 提供的 ConsistentUnderFileSystem 基类,并把所有文件系统访问操作通过 HDFS 的 Filesystem 抽象接口进行访问,因此,通过 HDFS 底层存储连接器模块,也可以做出简单的代码扩展,即可实现对 Ozone,COSN,Cephfs-hadoop,CHDFS 的存储适配,目前 HDFS 底层存储连接器模块使用最广泛,维护度最高。其中 Ozone 底层存储模块,支持 o3fs/ofs 两种连接 scheme,也就可以支持如下方式挂载:
$ bin/alluxio fs mount --option alluxio.underfs.version=1.2.1 --option alluxio.underfs.hdfs.configuration=/opt/ozone-site.xml /ozone-ofs o3fs://bucket1.vol1/$ bin/alluxio fs mount --option alluxio.underfs.version=1.2.1 --option alluxio.underfs.hdfs.configuration=/opt/ozone-site.xml /ozone-ofs ofs://localhost:9862/
现有的大数据生态应用当从原有的存储系统切换到 Alluxio时,一般需要应用把 location 修改为 Alluxio 的 location。Hadoop Client 自适应功能,可以允许用户访问现有存储系统,无需在应用程序修改 location。这需要在Alluxio Hadoop Client 侧和 master 端配置,从而能够把外部 URI 访问,映射成对 Alluxio 的访问。原理如下图所示,原本 Hadoop 兼容文件系统框架,按照 scheme 对应的实现类,访问对应的存储系统。
但是配置使用Hadoop Client自适应功能后,把scheme对应的实现类,改为配置使用 ShimFileSystem,就可以实现访问的方式与访问原有文件系统一样,但是请求会发送给 Alluxio Master,由Alluxio Master 做出自适应路径转换,从而完成对 Alluxio 的访问,当访问Alluxio失败时,也可以支持自动的 fallback 到原来的底层文件系统中。
为了能让 Alluxio 接受非 AlluxioURI 的访问请求,应用程序需要配置新的hadoop兼容文件系统 client 端实现。Hadoop 兼容的计算框架定义了从系统方案到文件系统实现的映射。ShimFileSystem 可以与任意URI实现的方案相关联。配置方案是设置 fs.<scheme>.impl
和 fs.AbstractFileSystem.<scheme>.impl
。例如:hdfs 的 URI 映射 ShimFileSystem
。
<property><name>fs.hdfs.impl</name><value>alluxio.hadoop.ShimFileSystem</value></property><property><name>fs.AbstractFileSystem.hdfs.impl</name><value>alluxio.hadoop.AlluxioShimFileSystem</value></property>
hadoop 兼容文件系统实现类 ShimFileSystem 将根据配置,将使用本地已有的底层存储 client 的实现,访问某些前缀匹配的路径。配置 alluxio.user.shimfs.bypass.ufs.impl.list,可以覆盖对底层存储 hadoop 兼容客户端的配置,冒号分隔配置项和配置值,逗号分隔多组配置。配置 alluxio.user.shimfs.bypass.prefix.list,可以配置哪些前缀的访问,会直接选用底层存储客户端,使用逗号分隔。
当自适应客户端访问 DOP 失败,可以直接访问底层存储。该功能默认不开启,配置alluxio.user.shimfs.fallback.enabled=true则可开启此功能。同时配置 alluxio.user.shimfs.bypass.ufs.impl.list,指定原始底层存储客户端的待覆盖的配置。例如:开启fallback的应用程序访问 hdfs://testdir/.当 Master 无响应或访问失败时,自适应客户端会通过本机原始底层存储Client直接访问 hdfs://testdir/。
自适应URI功能可以支持未挂载路径可以直接访问底层存储,默认不开启,配置alluxio.user.shimfs.transparent.enabled=true开启此功能,同时配置 alluxio.user.shimfs.bypass.ufs.impl.list,指定原始底层存储客户端的待覆盖的配置。例如:应用程序访问未挂载的 hdfs://testdir/unmountDir,自适应客户端会通过本机原始底层存储 Client 直接访问。
配置 ShimFileSystem
完成后,Alluxio Master 需要将 client 发送来的 URI,使用设定的 UriTranslator 进行路径转换。
设置指定的 UriTranslator 的方法是设置 alluxio.master.uri.translator.impl
,为指定的实现类。
实现类 | 简述 |
---|---|
alluxio.master.file.uritranslator.DefaultUriTranslator | 默认实现,不做 URI 转换 |
alluxio.master.file.uritranslator.AutoMountUriTranslator | 将路径,转换为 DOP 的路径,如果该路径未在 DOP 中挂载,则尝试自动挂载 |
alluxio.master.file.uritranslator.MergeAuthorityToPathUriTranslator | 将路径中的 Authority 部分与 Path 部分合并在一起 |
alluxio.master.file.uritranslator.CompositeUriTranslator | 可以设置不同的 URI 前缀对应不同的 URITranslator |
默认实现,不做URI转换。
来自客户端的请求中的 URI,会被该转换器,根据挂载表中的挂载信息,转换为对 DOP 的请求,如果现有的挂载表不能进行 URI 转换,也可以通过设置 alluxio.master.shimfs.auto.mount.enabled=true
启用自动挂载功能。例如:配置了 ShimFileSystem 的应用程序 fs.hdfs.impl
访问 hdfs://ns1/foo/bar. ShimFileSystem 使用原始 URI 将请求中继到 Alluxio。Alluxio 检测到 hdfs://ns1/ 已挂载到 /ns1/. 给定 URI 被透明地转换为 alluxio://ns1/foo/bar 并提供请求。当开启了自动挂载功能,传入的外部 URI 不能被现有的 DOP 挂载表转换时,DOP 可以自动挂载目标存储系统,而无需外部管理员操作。默认情况下禁用自动挂载。如果需要启用,需要在 DOP Master上配置 alluxio.master.shimfs.auto.mount.enabled=true
。启用后,如果在 DOP 挂载中找不到外部 URI,DOP 将尝试将该 URI 的存储系统挂载到 DOP 命名空间中的指定文件夹。目前自动挂载功能只对 alluxio.master.file.uritranslator.AutoMountUriTranslator
以及配置配置了该 URITranslator 的 CompositeUriTranslator
生效。
例如:hdfs://ns1/foo/bar/baz.txt 主服务器接收到的路径。没有找到现有的挂载点,因此触发了自动挂载。尝试将 hdfs://ns1/foo 挂载到 DOP 的 /auto-mount/hdfs/ns1/foo 挂载点。当访问权限不足,自动挂载失败,会继续尝试挂载下一级目录。尝试将 hdfs://ns1/foo/bar 挂载到 DOP 的 /auto-mount/hdfs/foo/bar 挂载点。自动挂载成功。
此功能支持把 uri 中的 authority 合并到 path 中,配置 alluxio.master.uri.translator.impl=alluxio.master.file.uritranslator.MergeAuthorityUriTranslator
则可开启此功能。
应用程序访问 o3fs://bucket1.volume1/key1
,MergeAuthorityUriTranslator
会将请求转换为 /bucket1.volume1/key1
.
此功能支持为指定目录使用指定的 URI Translator,如果想使用复合URI处理方法,配置 alluxio.master.uri.translator.impl=alluxio.master.file.uritranslator.CompositeUriTranslator
则可开启此功能。
使用 alluxio.master.composite.uri.translator.impl
可以配置指定的路径前缀选用特定的 URITranslator
实现类。Master 会根据路径前缀匹配,多个 URITranslator
通过 “,” 分割。
例如:在 Master 配置 alluxio.master.composite.uri.translator.impl=hdfs://=alluxio.master.file.uritranslator.AutoMountUriTranslator,/testdir=alluxio.master.file.uritranslator.DefaultUriTranslator
时,
应用程序访问 /testdir/dir1
,会使用 DefaultUriTranslator
,也就是不做任何路径转换处理。应用程序访问 hdfs://ns1/testdir
,会使用 AutoMountUriTranslator
,会查询挂载点,将请求转换为其对应的挂载点目录,如 /hdfs/ns1/testdir
。
我们在 Alluxio 开源版的基础上,做了如下扩展,以更好的适应腾讯复杂的业务场景。
腾讯 Alluxio 目前支持本地缓存(LocalCache) 模式,和集群缓存模式(System Cache)。这两种模式的关系为 L1 和 L2 缓存。
两种缓存具体如下表
缓存类型 | 本地缓存(LocalCache) | 集群缓存(SystemCache) |
---|---|---|
缓存层级 | L1 | L2 |
缓存范围 | 单机缓存 | 集群缓存 |
部署难度 | 只需 jar 包放入 classpath 以及修改配置 | 需要搭建 Alluxio 集群。 |
成本消耗 | 无需额外启动进程,只需引入缓存存储介质,一般复用本机器存储介质。 | 需要部署 Alluxio master 和 worker 组成 Alluxio集群,因此需要额外的机器成本,master 和 worker 服务本身也会消耗部分 cpu 算力和内存。但如果当前应用机型适合 Alluxio 混部,比如 Presto + Alluxio 混部,并没有引入额外的机器成本,多出来的,只是 worker 自身的消耗。 |
优势概括 | 简单,易于部署,占用资源少 | 可以管理和共享超大规模完整专业的缓存管理,提升缓存复用。 |
劣势概括 | 单机模式,无法缓存复用,功能尚未健全,缺少认证、代理用户、缓存清理、缓存失效等功能 | 需要额外部署集群,引入额外的服务占用资源成本。 |
Presto 的架构如下图所示,client 的请求,会递交给 Coordinator 进行处理,而元数据信息由 HiveMetaStore(HMS) 进行管理。那么表或分区的 location 信息,也在 HMS 中存放,因此,如果想把表或分区的数据放到 Alluxio 里,则不得不修改 HMS 的信息,这增加了HMS 的维护成本,而且 HMS 是全局共享服务,它修改了,其它计算框架就没有办法保持访问原来的路径了。
Alluxio LocalCache 相比 Alluxio 集群模式而言,是以 lib 的形式提供缓存能力的。分片调度策略,使用SOFT_AFFINITY,以 HDFS Path 为 key,将数据缓存到本地。这种形式,目前 Alluxio LocalCache 帮助 Presto 实现了本地缓存,相比通过集群模式缓存或直接访问底层存储,性能都会有较大提升,已有的能力已经生产可用。Alluxio 分布式 LocalCache: 相比集群模式,目前的 Alluxio LocalCache 模式还未实现分布式缓存,也就是每一个 Presto worker 都在单独缓存,后续可以实现多个 Presto worker 节点共同组成一个分布式的 Alluxio 本地缓存。
比如创建删除文件,客户端会感知到,并把元数据缓存进行自动的清理。
Alluxio 作为一个中间缓存系统,随着时间推移,可能触碰到的底层文件系统的元数据会越来越多,而且只增不减,为了保持元数据在一定的承受范围内,我们需要如下功能。
当我们遇到某些 worker 节点机器需要挪为他用,或者希望减少 worker 数量,从而节省成本时,需要腾讯 Alluxio 提供的 Worker 下线功能。
worker 下线命令需要提供待下线 worker的host信息,目前有两种方式提供,第一种是将 worker host 信息写入配置文件$ALLUXIO_HOME/conf/excluded-workers
(如果没有,需要新建),另一种是直接将待下线 worker host 作为命令行参数传入。
配置文件内容是待下线 worker 的 ip,形式如下:
192.168.xxx.xxx192.168.xxx.xxx192.168.xxx.xxx
配置完成后,即可执行命令进行下线:
$ bin/alluxio fsadmin decommissionWorkers start
至此,配置文件中的 worker 会从 master 的注册信息中移除,下线完成,如果想要将已经下线的 worker 重新注册激活,只需要将 worker 信息从配置文件种移除,然后重新执行上面的命令即可。如果配置文件为空,那么下线命令将激活所有已经下线的 worker。
下线 worker 的 start 命令 help 信息如下:
start [-h] [-a] [--excluded-hosts <host1>,<host2>,...,<hostN>]
-h:选项打印帮助信息,
-a:选项表示只增加需要下线的 worker,不改变已下线 worker 的状态。如果没有这个选项,执行下命令会将本次没有涉及到的 workers(之前已经下线)重新激活。
--excluded-hosts:需要下线的 worker host 列表,以逗号分割。例如:bin/alluxio fsadmin decommissionWorkers start --excluded-hosts 192.168.1.100,192.168.100.1
此命令将下线 192.168.1.100 和 192.168.100.1 这两个 worker。
由于新增 Worker 节点,或者选择 worker 节点不均衡,导致 Alluxio 集群的缓存分布不均衡。通过 Alluxio re-balance 机制可以让集群的 worker 节点重新均衡。提供如下命令,执行 balance 动作。
$ bin/alluxio fsadmin balancer[-policy <policy>] The balancing policy[-threshold <threshold>] Percentage of worker capacity[-exclude [-f <hosts-file> | <comma-separated list of hosts>]] Excludes the specified workers.[-include [-f <hosts-file> | <comma-separated list of hosts>]] Includes only the specified workers.[-source [-f <hosts-file> | <comma-separated list of hosts>]] Pick only the specified workers as source nodes.[-flowcontrol <bandwidth>] Set the bandwidth data transfer between alluxio wo
Alluxio 中添加 Balancer 组件,提供 Shell balance tool 执行 re-balance 动作,Balancer 可以划分为两个功能部分:Balancer Manager 和 Balancer Controller。Balancer Manager 管理配置,从 Alluxio master 中获取 worker storage 信息,得到集群的 Worker Storage 使用量视图, 根据 Storage View 和 re-balance 策略生成 (Source, target) 集合,Manager 维护 Balancer 的 生命周期。Balancer Controller 将 处理 re-balance 的 worker 集合,从每个 source worker 选择 合适的block(blockId),向 Target worker 发送 re-balance 请求。
腾讯 Alluxio 在众多团队的共同努力和协作之下,落地项目非常多,仅列举如下典型案例。
腾讯数据湖计算解决了数据湖敏捷高效的分析和计算问题,是腾讯云推出一款开箱即用的数据湖分析服务。DLC 搭配 alluxio localCache模式,提速性能 2 - 5 倍。《云原生数据湖为什么要选择腾讯云大数据DLC,一份性能分析报告告诉你!》
随着企业大数据规模和应用的增长和发展,计算与存储分离的架构渐渐成为主流,Alluxio 解决了计算量和存储量不匹配问题, 实现了算力的按需使用。腾讯 Alluxio 团队与开源社区合作,探索出了开箱即用的计算存储分离优化版本。https://www.infoq.cn/article/KFQqjM9hsZb1qCZARDok
腾讯 Alluxio 团队与 CDG 数据团队,TEG supersql 团队和 konajdk 团队进行通力协作,解决了金融场景落地腾讯 DOP 过程中遇到的各种问题,最终达到了性能和稳定性都大幅提升的效果。https://cn.alluxio.io/tencent-use-case-on-financial-scenario/
灯塔作为腾讯公司内部的数据分析和展示平台,Impala 作为灯塔-融合分析引擎的主引擎,Alluxio 融合Impala,不但使得 Impala 充分享受了存算分离技术架构带来的诸多好处,也成功规避了存储分离技术架构带来的问题。性能提升 200%,失败率降低 29%。https://zhuanlan.zhihu.com/p/270737380
Supersql是跨数据源、跨数据中心、跨执行引擎的高性能、安全的大数据SQL引擎。Alluxio 和 Presto 混合部署,TPC-DS测试,引入 Alluxio 的平均加速比 2.6。目前 Supersql 搭配 Alluxio 的方案广泛应用于大数据查询场景。https://cloud.tencent.com/developer/article/1938465
AI 特征计算业务场景中引入 CAlluxio, 将大部分游戏版本数据 Load 到 Alluxio 缓存, 利用 Alluxio元数据访问能力降低底层 ceph 的压力,从而支持更多核数的并发任务,并且降低业务作业的失败率下降到四分之一。 https://cloud.tencent.com/developer/article/1889789
推荐阅读
关注腾讯云大数据公众号
邀您探索数据的无限可能
点击“阅读原文”,了解相关产品最新动态
↓↓↓