播报：腾讯 Alluxio：加速新一代大数据与 AI 变革-- 迪族网

播报：腾讯 Alluxio：加速新一代大数据与 AI 变革

来源：DataFunTalk 　2023-01-20 06:25:51

17位高级专家共同打造，涉及 15个领域， 133个体系框架， 1000个细分知识点！

关注公众号“大话数智” ，免费下载这份《数据智能知识地图》⬇️

(资料图片仅供参考)

导读： 今天分享的题目是腾讯 Alluxio：加速新一代大数据与 AI 变革。

本文包括四大方面的内容：

大数据架构演进 Alluxio 研发进展落地案例典型案例分享未来工作

分享嘉宾｜陈寿纬/毛宝龙腾讯大数据/Alluxio

编辑整理｜曾新宇对外经贸大学

出品社区｜DataFun

大数据架构演进

1. 大数据生态圈和 Alluxio 的昨天

Alluxio 项目诞生得非常早，2012 年叫 Tachyon，是 Berkeley 下 AMPlab 的实验室项目。那个时候的大数据生态圈还不够开放，属于闭门造车的状态，各有自己的组团算法、自己的数据工厂，项目参与人数也不多。

图1 10年前的大数据生态圈

2012 年时只有 1 个 contributor，到 2015 年有 70 个 contributor，与现在的规模无法相提并论。项目也偏向传统 Spark 和云存储，没有现在架构结合的这么完美。

图2 15年Alliuxio介绍

2. 大数据生态圈和 Alluxio 的今天

到目前为止，大数据生态圈已经和 10 年前完全不同；Alluxio 和之前也完全不同。从2013 年到今天，项目在 Github开源，已经累计有超过 32000 个提交（commits）；有来自全球超过 100 个组织机构的 1100 多位贡献者参与开发。

2020 年在 Google 以及 OpenSSF 的开源指标被评为最有影响力的 Java 开源项目第 9 名。

图3 基于开源的全球化协作

现在 Alluxio 已经是一个非常大的项目。最初只是作为 Memory 的管理工具，而现在已经被称之为 Alluxio 数据编排平台。能够在跨集群、区域任何云（私有/公有云/混合云）中将数据更紧密的编排，接近数据分析、AI/ML 应用程序，从而向上层应用提供内存速度的数据访问。一方面可以做到数据加速的效果；另一方面提供简单化使用不同的存储和计算引擎的能力。

图4 Alluxio数据编排平台

3. 腾讯与 Alluxio

腾讯是 Alluxio 非常重要的合作伙伴，已有 20 多个 Contributor，并发表多篇文章。一人被提升为 PMC Maintainer，2 人提升为 Commitor，10 多次分享以及 400 多次 PR Merged。后期将继续合作完成社区版本发布、以及版本的灰度测试。

图5 腾讯与Alluxio的合作成果

4. 展望明天

基于近几年大数据发展的数据趋势，做进一步的工作。

图6 大数据的发展趋势

趋势 1: 数据分享

针对不同计算平台的统一数据接口

对于存储行业和计算行业，每个公司的设占比都达不到 10%。在许多公司都有计算平台和存储平台的整合工作。Alluxio 想去解决这个问题，无论对接的存储，还是对接的计算，都可以通过 Alluxio 进行统一的 API 整合。

业务级可以无感知的去使用这些计算平台和数据平台，避免进行较大规模的数据迁移与改动。

趋势 2: 数据权限与管理

无拷贝的数据管理基于缓存技术的数据移动

在一个规模比较大的公司或具有异地办公情景的公司，通常会有比较多的数据中心，进行数据拷贝和管理非常困难。Alluxio 基于这种场景，提出基于无拷贝、使用缓存的数据权限与管理的方案。

趋势 3: 云上弹性集群

服务计算存储分离架构的多层数据策略

Alluxio基于计算存储分离架构，通过 Alluxio 数据编排层，把数据和存储连接在一起。

5. 2022年的技术演进方向：Alluxio 核心

2022 年Alluxio有两块核心发展方向。一块是 Alluxio 核心，基于与腾讯非常深入的合作，实现 3 个方面的工作改进：

图7 Alluxio核心发展方向

（1）优化元数据服务（Master）

更高效率、更可靠的高可用模式 (基于 Raft)，解决基于 Raft 协议的性能问题；更大规模集群，目标是具有数千台 Worker 的高效管理；同时进行Master进程内存资源消耗的优化；包括线程池的优化。

（2）对数据服务的优化（Worker）

主要是优化 Worker 的存储效率，使用更少的缓存服务更多的业务；优化 Worker 进程内存资源的消耗。

（3）实现更简单的数据迁移和持久化的动作，努力优化 Job Service

支持更高效可控的 distributed Load，Persist，AsyncWrite。

6. 2022年的技术演进方向：对应用的场景优化

除了对 Alluxio 核心优化外，第二块希望对应用场景进行非常深入的优化。

作为一个通用性平台，难以针对特定的计算引擎进行深入的优化。需要对理论与实现之间进行平衡。今年要下力气进行深入的优化。

图8 优化应用场景

首先与 kubernetes 环境进行更深度的集成。让它变成更容易运维的部署方案；

其次与 Hudi，Iceberg 更深度的集成，对元数据和数据分层的 Caching；

第3点在AI场景下优化：

超大规模小文件数据集、文件写的优化 FUSE 进程对内存消耗的优化

第4点是在 OLAP（如 PreSto）场景下与不同的合作伙伴，对热数据集的估算和监控的优化。

Alluxio 研发进展

1. 腾讯 Alluxio 进展

腾讯在社区中贡献了 400+ 个 Prerequisite，大大小小的功能很多，这里只介绍几个典型功能。

（1）JNIFUSE 模块

JNIFUSE 模块是 Alluxio 在 AI 场景 POSIX API 的具体实现。它的性能比JNR-FUSE 的实现有很大改善。腾讯也是这个模块的维护者。在这个模块中，不仅扩展了功能，还改善了性能，还实现了一个比较有意思的功能：FUSE Shell。这个功能可以通过访问本地文件系统的方式，与 FUSE 进行交互，获取 FUSE 里面的一些状态，也可以进行干预和触发。下面的例子就是可以获取 metadatacache 的 size；另一个例子是清空当前 metadatacache，也称之为 dropAll；除此之外还可以获取进程中所有的 metrics；甚至对 Alluxio cache 进行管理，比如：free，load 等等；也可以做 tag 的更新。

JNIFUSE 开启 RPC Server 也是可以进行交互。但 JNIFUSE 被定义为轻量级服务，额外的内部服务就没有必要开启，因此没有开启 RPC Server。如果开启 RPC 及 web server 都势必引入线程池，会造成额外的 Overhead。

（2）Alluxio Worker 下线功能

Alluxio Worker 优雅下线功能很简单，只是开启了 admin 的命令：decommission Workers。有几种方式去触发它，包括指定哪些节点需要下线。也可以有个配置文件把 Workers exclude 掉或 include 进来。

这个功能不仅是让 Master 忘记一个 Worker，后面还会做一些数据的迁移。Alluxio的定义是一个缓存层，无需对数据的安全性和持久化负责，因为还有底层的存储。考虑到缓存的有效性，还有缓存的命中率，对 worker 下线也有要求：把 worker 的缓存数据块迁移到其它 worker 里面。

（3）底层存储集成

此外还实现了基础功能 Ozone, cephfs，cosn 等底层存储的集成。这是推广业务的基石。也是给社区的贡献。

（4）基于容量选 worker 的策略

如果没有这样的策略，Client 会有很多策略，比如基于随机、本地优先、基于剩余空间选 worker 的策略。

如果集群里面是大小盘、异构存储，有些盘大有些盘小。如果按剩余空间去算，大盘剩余空间永远会很多。大盘就会变热小盘就会比较冷落。所以发明了基于容量选worker的策略。容量大，承担读请求的几率就会大一些，容量小就会小一些。但是保证大家都会被访问到。

（5）腾讯 Alluxio 进展

在没有这个功能之前，只有 Alluxio Primary Master，可以显示 Web 页面，也只有Primary Master 可以被监控到。在实现生产中会遇到 Standby Master 不做 CheckPoint，该切没有切等现象，其实内部有遇到一些问题，这些都需要监控到。所以把所有的 Master 其 Web Server 都打开，把监控都导出来，有了这样的功能，所有的节点都被监控到。所有服务都正常，而非只有 Primary Master。另外在页面里面可以很清晰看到当前启动的节点是什么。例如启动角色是 FOLLOWER，也可以展示我的 Leader 是谁。

下图右侧是在 Grafana Dashboard中做一个下拉框，可以选择当前指标所属 Master。

图9 腾讯Alluxio进展

此外还有一个特别有用的功能 ratis-shell。起初 Alluxio 和 Ozone 基于 ratis 开源项目实现底层增值一致性的服务。各自都在实现如 HA 切换、获取 HA 信息等方面的功能。后来发现不需要把这样的功能放在上层，可以放在与 ratis 相同的底层，就发明了 ratis-shell。自从诞生之日起，就已经支持了很多功能，例如：[election] 可以选择把 Leader Transfer 给谁；[stepDown] 可以让当前 Leader 下台；调试时 [pause] 可以防止 Leader 被切走，让 ratis 的[peer] 停下来选举，就可以放心去调试 Leader。调试完成后，还可以用 [resume] 恢复选举。[group] 可以[list] [info]当前 group 的状态，包括哪些成员。也可以[peer]加减或者设置成员的优先级。[snapshot]功能创建当前[peer]的[snapshot]。这个功能也是比较有用的，目前如果对集群做灰度上线，可能把 FOLLOWER 也称之为 Stanby Master 下掉。如果下掉再起来，如果不生成[snaphot]，下次启动时会有很多 raft log 要求回放，会比较慢。如果有[snapshot[create]]功能，下次就可以快速启动。这个功能集成在 Alluxio 的软件包中和镜像里，后面也会推送到 Alluxio 社区和 Ozone 社区，让这两个社区都能享受到这样一个功能。Ratis-Shell 模块已经推到 Apache Ratis 仓库中，作为它的一个模块。以后 Ratis 每次 Release 都会带着 Ratis-Shell 软件包。

（6）其它有价值的贡献

其它有价值的贡献，包括：

支持 jmx 抓取指标的能力。众所周知，基于 HDFS 指标抓取已经形成业界规范，外围很多工具都是参考 HDFS 指标的抓取方式抓取的，Ozone 也是基于这一方式去实现的。Alluxio 也基于这种方式进行了实现。另外，在 Alluxio 的 stacks 页面里可以看到 Alluxio 的线程栈。当 Alluxio Master 卡住或者有些 Bug 死锁，可以通过这个线程栈找到一些线索。 Mount table 挂载表可以看每个挂载点详细的信息。增加 worker 预注册的流程，可以避免老的 worker 有不属于该集群的 Block 脏数据污染集群的现象支持配置使用 IP 作为通信 host，支持域名作为 host 的方式，适用于不同的场景。使用 IP 的场景包括测试环境、内部的环境。所有机器的 hostname 相互之间并不认识，如果没有这样的功能，只能去编辑\etc\hosts文件，工作量大，且容易出现漏编辑最后导致出现通讯不畅。另外一个有用的功能是 Job service auditlog（审计日志）。Job service 作为 Alluxio 后台功能的服务，同样也需要调优。通过 Job service auditlog 可以看到当前用户、命令，执行时间。

图10 其它有价值的贡献

（7）开源社区暂未发布的功能

功能未贡献到社区的原因有两个：

尚在测试中腾讯内部使用的功能

图11 其它有价值的贡献

这些功能包括：

① Alluxio getFileInfo 性能提升，性能能够提升到原来的 2 倍。这个在纯读和读占绝大部分比例时，对于优化吞吐还是非常重要的。通过右下角的火焰图可以看到，可以抓到瓶颈热点：get blocklist 需要反复从 raft 里获取，这个性能开销非常大。优化后，性能能够提升到原来的 2 倍。

② Load 性能也是同样的现象。Load 命令把数据读回来，另一种 distribute load 发请求，通过 Job service 再发送给所有 job worker 做 load task，再开始 task 再发给worker。这样的流程特别长，对于大文件还不是大问题，对于海量小文件的 cache，这个大的流程全消耗在调度任务和 RPC 上。所以对此进行优化，简化了一些流程。Load 性能提升 6 倍。如果对其它部分也进行优化，性能提升远不止于此。

③ Alluxio Client 自适应 URI 能力。

左侧图是介绍 Alluxio Client 自适应 URI 能力的原理简介。在异常情况下，Client 可以自动去访问底层存储；当异常排除后，Client 自动恢复访问 Alluxio，从而达到自适应 Alluxio 异常的情况。从而提升访问的可靠性，并不需要完全依赖 Alluxio。 Alluxio 挂载表不存在的路径，也可以直接访问底层存储。 Alluxio 自动 URI 转换。对于应用和用户，这些功能非常方便。无需更改 Location，还是以为自己在访问 HDFS 和 Ozone 的访问方式，而请求已经被转到 Alluxio 中。

④ Alluxio 长 Client 管理。左下角的图展现了这样的界面。可以先展示长服务，比如Alluxio FUSE，POSIX，Prestos 作为长 Client 附主，都可以展示在 Client List 里，就像管理 worker 一样管理长 Client。而一起而过的小 Client 进程不在管理之列。

通过这样的界面，Alluxio Client metadata cache 可以展现出来，并可为 Client 推送一些 Command 做一些相应的操作。比如去清理缓存，还有内部其它的一些操作。

⑤ Alluxio Client metadata cache 一致性管理

Client 端有 metadata cache，当前版本并未保持和 master 的一致性，仅设置 Interval 超期后失效。一致性管理就是在 Client 和 Master 之间是有交互，能够知道 Master 源数据出现变更，对源数据缓存进行更新。

⑥ 还有安全方面的功能。包括：认证和鉴权。认证是腾讯的内部认证。鉴权支持CosRanger，HDFSRanger，OzoneRanger。

⑦ 用户组映射，基于 Ldap，左图中就是基于 Ldap 配置的用户和组，这样用户就可以和 Ldap 通讯，获取属主。

图12 用户组映射

此外对于优化是针对关键的瓶颈点进行优化，而非全部优化。

（8）开源社区的合作

不仅仅限于 Alluxio，围绕 Alluxio 为中心的开源项目都会参与并作出贡献。贡献比较多的有 Ozone，Presto，Ratis，等等。

图13 开源社区合作

Alluxio 典型案例

1. 合作案例一

腾讯内部的某项目，类似 Presto 的查询引擎，底层存储是 HDFS。采用 Alluxio 后性能得到提升 2.44 倍，所有查询提升的中位数水平是 121%。

图14 合作案例一

这个是与腾讯 PCD 团队的深入合作，是腾讯 Alluxio 版本的第一个用户。

2. 合作案例二

Supersql 是腾讯内部跨数据源、跨数据中心、跨执行引擎的高性能、安全的大数据SQL 引擎。Supersql 引擎也是解耦应用和计算。后面可以产生各种各样的查询引擎。

目前的优化是基于内部的查询引擎 Presto。具体是腾讯内部各种各样的业务都在使用Supersql Presto和 Alluxio 的结合。

Alluxio 和 Presto 混合部署 TPC-DS 测试引入 Alluxio 的平均加速比 2.6，直接使用Alluxio，访问 Alluxio 时需要更改路径，在类似 HMS，存储表加了一些字段管理表、DB、partation 需要进行缓存；缓存的 Location 在 Alluxio 的位置，也就是白名单功能。

还有一些自适应的功能，如 Alluxio 失败时如何访问底层数据。这些能力都是在 Presto里面实现。注意：前面介绍相同内容是在 Alluxio Client 里面实现。以后都会转换到 Alluxio Client 里面实现。

图15 合作案例二

3. 合作案例三

另外一种用法是 Alluxio Local Cache，把 Alluxio 当作 Client 使用。采用 Fatjut 方式，就不会再访问 Alluxio 集群，所有缓存都在本地，一样可以带来很好的性能收益。对比之下会有 3-10 倍的性能提升。

Local Cache 最大的特点就是部署非常简单，只需把 Alluxio Local Cache 在 Presto中配置即可。

腾讯的贡献包括：

Local Cache 支持多盘 Local Cache 一致性保持，能够感知数据发生的变化实现 presto iceberg connector支持 Alluxio Local Cache presto/pull/16942 Presto SOFT_AFFINITY 支持按 split 粒度分配 presto/pull/17058，之前是按文件粒度，效果不理想。

图16 合作案例三

还有一种用法是 Alluxio with SDS，既是文件缓存也是元数据缓存。简单来说就是在Alluxio Master 中实现类似 HMS 服务的功能。它的下面是 HMS，自身缓存相应的表。改造内容包括：

Alluxio SDS 相关挂载点优化和增加 attachdb 配置文件，支持lgnore 和 bypass 的某些 Table 和表，才能用于生产中；不可能把 DB 中所有的 Table 和表，用 SDS 管理起来；修复 SDS 某些 tablesync 失败导致后，table 也挂载失败的情况修复有 VIRTUAL_VIEW 类型的 table 时，报错的问题 SDS 通过正则表达式，配置挂载参数 Bypass 指定分区功能 group 挂载点，提升挂载性能。否则一个路径一个挂载点，就会有上百个挂载点需要进行管理和查询

4. 合作案例四

这个案例是在游戏 AI 中，Alluxio 加速 cephFS 的方式。是在游戏中做模型的数据处理的阶段，会访问 ceph。cephFS 是一个非常优秀完全实现 POSIX 的分布式文件系统，但是在纯读的场景中 MDS 就会带来性能上的一些问题。在引入 Alluxio 集群以后，Alluxio-fuse 250k 的任务量失败率只有 0.73%；相比之下 ceph-fuse 的失败率高达 2.8%。

通过左侧压力图可以看到，前半部分使用了Alluxio，后半部分没有使用Alluxio。可以明显看到能够有效减少 ceph MDS 的压力。实现存储和应用双赢的结果。

部署时把 Alluxio 集群和 FUSE 都部署到 cephFS上，方便进行弹性管理，资源空闲时也可以得到释放，需求增加时，也可以相应增加资源。

图17 合作案例四

未来工作

1. 基础设施建设

建设可靠的自动化测试平台。服务于 Alluxio 社区和内部减少内部代码与 Alluxio 开源代码冲突，趋近于自动合并实现 Alluxio 部署运维配套系统

2. Alluxio 安全

支持更多认证方式，以及代理用户身份支持更多鉴权系统支持多租户

3. Alluxio 生态工具建设与完善

ratis-shell 继续完善，支持更多功能 Alluxio 智能预热预测系统建设实现缓存动态自均衡和手动均衡能力

4. Alluxio 功能扩展

利用 Alluxio 实现无感冷热数据迁移，自动降冷利用 Alluxio 实现访问代理、流量控制多 master 联邦，observer master read