腾讯云发布新品数据编排平台（dop）- 与大数据生态紧密结合，提供通用数据编排服务

作者介绍

毛宝龙腾讯高级工程师，Alluxio PMC & Maintainer，Apache Ozone committer，腾讯 Alluxio OTeam 开源协同团队负责人。主要负责腾讯 Alluxio 的研发和落地工作和 Apache Ozone 的文件系统方向的研发工作。

DOP(Data Orchestration Platform) 是腾讯推出的数据编排平台服务。定位通用数据编排。无论是大数据和 AI，无论公有云、私有云和腾讯内网都在使用统一的数据编排平台 DOP，如腾讯云 DLC、EMR 等产品，在 DLC 上更是实现了“0”成本的 2-5 倍缓存加速效果。

腾讯 Alluxio(DOP) 历程

DOP 与腾讯大数据生态紧密结合。充分利用硬件剩余资源，与计算配合，为用户提供计算加速、数据转换、数据无感迁移、统一存储服务、智能数据路由等能力。

加速机器学习和人工智能等 AI 业务访问存储等能力。

腾讯 Alluxio(DOP) 团队自成立以来，一路走到现在，在三网都有大规模落地，也构建了业内最大的 Alluxio 单集群规模。

腾讯 Alluxio(DOP) 技术积累

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/

Hadoop 自适应客户端 + 服务端 URI 转换器

现有的大数据生态应用当从原有的存储系统切换到 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 到原来的底层文件系统中。

Hadoop 自适应客户端

• 配置使用客户端自适应功能实现类。

为了能让 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>

• 配置使用 bypass 功能

hadoop 兼容文件系统实现类 ShimFileSystem 将根据配置，将使用本地已有的底层存储 client 的实现，访问某些前缀匹配的路径。配置 alluxio.user.shimfs.bypass.ufs.impl.list，可以覆盖对底层存储 hadoop 兼容客户端的配置，冒号分隔配置项和配置值，逗号分隔多组配置。配置 alluxio.user.shimfs.bypass.prefix.list，可以配置哪些前缀的访问，会直接选用底层存储客户端，使用逗号分隔。

• 异常 Fallback 功能

当自适应客户端访问 DOP 失败，可以直接访问底层存储。该功能默认不开启，配置 alluxio.user.shimfs.fallback.enabled=true 则可开启此功能。同时配置 alluxio.user.shimfs.bypass.ufs.impl.list，指定原始底层存储客户端的待覆盖的配置。例如：开启 fallback 的应用程序访问 hdfs://testdir/.当 Master 无响应或访问失败时，自适应客户端会通过本机原始底层存储 Client 直接访问 hdfs://testdir/。

• 非挂载路径自适应 URI 功能

自适应 URI 功能可以支持未挂载路径可以直接访问底层存储，默认不开启，配置 alluxio.user.shimfs.transparent.enabled=true 开启此功能，同时配置 alluxio.user.shimfs.bypass.ufs.impl.list，指定原始底层存储客户端的待覆盖的配置。例如：应用程序访问未挂载的 hdfs://testdir/unmountDir，自适应客户端会通过本机原始底层存储 Client 直接访问。

Master 端 URITranslator

配置 ShimFileSystem 完成后，Alluxio Master 需要将 client 发送来的 URI，使用设定的 UriTranslator 进行路径转换。

设置指定的 UriTranslator 的方法是设置 alluxio.master.uri.translator.impl，为指定的实现类。

• DefaultUriTranslator

默认实现，不做 URI 转换。

• AutoMountUriTranslator

来自客户端的请求中的 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 挂载点。自动挂载成功。

• MergeAuthorityUriTranslator

此功能支持把 uri 中的 authority 合并到 path 中，配置 alluxio.master.uri.translator.impl=alluxio.master.file.uritranslator.MergeAuthorityUriTranslator 则可开启此功能。

应用程序访问 o3fs://bucket1.volume1/key1，MergeAuthorityUriTranslator 会将请求转换为 /bucket1.volume1/key1.

• CompositeUriTranslator

此功能支持为指定目录使用指定的 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。

增强的 LocalCache 部署模式

我们在 Alluxio 开源版的基础上，做了如下扩展，以更好的适应腾讯复杂的业务场景。

• 扩展到所有 HCFS 实现

• 支持元数据一致性检查

• 支持多块盘作为缓存介质

• Presto Iceberg 表支持 LocalCache

腾讯 Alluxio 目前支持本地缓存(LocalCache) 模式，和集群缓存模式(System Cache)。这两种模式的关系为 L1 和 L2 缓存。

两种缓存具体如下表

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 本地缓存。

客户端元数据自动一致性同步

• client 端发现元数据不一致则清理缓存，发现缓存一致则继续保持。

比如创建删除文件，客户端会感知到，并把元数据缓存进行自动的清理。

• master 维护长 Client 信息，并在页面展示。由于 Client 会向 Master 汇报心跳信息，Master 也可以展示这些 Client 的信息，如下图所示，可以展示 Client 的主机名，进程号，客户端 ID，距上次心跳的时间，元数据缓存个数，客户端连接时间。

元数据淘汰

Alluxio 作为一个中间缓存系统，随着时间推移，可能触碰到的底层文件系统的元数据会越来越多，而且只增不减，为了保持元数据在一定的承受范围内，我们需要如下功能。

1. 支持手动指定文件夹元数据释放。bin/alluxio fs rm -R --alluxioOnly --resetDirectChildrenLoadState <ALLUXIO_PATH>

2. 支持对已有的文件夹或指定的 path 设定 ttl 以及新增的 ttlaction EVICT_META。bin/alluxio fs setTtl --action EVICT_META /test 30000 # 设定 /test 文件夹，30 秒后释放元数据

3. 指定文件夹重置 directchildrenloaded 功能。

4. 高校团队合作，利用 cuki 算法识别最冷部分元数据功能，实现高低水位元数据淘汰功能。

Alluxio worker 下线功能

当我们遇到某些 worker 节点机器需要挪为他用，或者希望减少 worker 数量，从而节省成本时，需要腾讯 Alluxio 提供的 Worker 下线功能。

worker 下线命令需要提供待下线 worker 的 host 信息，目前有两种方式提供，第一种是将 worker host 信息写入配置文件$ALLUXIO_HOME/conf/excluded-workers(如果没有，需要新建)，另一种是直接将待下线 worker host 作为命令行参数传入。

• 配置下线 worker 文件

配置文件内容是待下线 worker 的 ip，形式如下：

192.168.xxx.xxx192.168.xxx.xxx192.168.xxx.xxx

配置完成后，即可执行命令进行下线:

$ bin/alluxio fsadmin decommissionWorkers start

至此，配置文件中的 worker 会从 master 的注册信息中移除，下线完成，如果想要将已经下线的 worker 重新注册激活，只需要将 worker 信息从配置文件种移除，然后重新执行上面的命令即可。如果配置文件为空，那么下线命令将激活所有已经下线的 worker。

• 传入 worker host 参数下线

下线 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 balancer

由于新增 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 请求。

定制缓存块置换策略

• 支持指定文件名规则对应特定的块 TTL。

• 支持基于容量的随机块位置选择策略。

• 支持缓存客户端块位置选择策略。

HA 扩展

• 集成自研 ratis-shell 支持 HA 切换，加入删除 Peer，选举控制等操作。

• 修复若干 HA 相关的 BUG，提升 HA Journal Flush 性能

• 减少停顿时间

• 减少失去 Primacy 身份时重置状态导致性能损耗

性能极致优化

• 元数据读性能提升 30% , 写性能提升 70%。

• 支持并发 list。测试多线程并发 list ，会比单线程快两倍。

• load 性能提升 6 倍。LoadMetadata 功能提升 2 倍。

• 支持顺序读识别并进行预读，提升读性能。

• 利用并发扫盘，streaming 块汇报，分离注册和块汇报等技术，提升 worker 启动速度和性能。

• LostFileCandidate 回收，解决内存泄露问题。

安全支持

• 透明用户身份/代理用户

  腾讯 Alluxio 不仅支持 Alluxio 客户端作为代理用户代理其它用户访问 Alluxio master，也支持 Alluxio 作为 Alluxio 客户端的代理用户，代理访问底层存储系统。

• Alluxio 支持 Ranger 鉴权能力

  增强实现 hdfs ranger connector 转换 ozone 路径，从而支持与 ozone 共用一套 ranger policy。

  支持 cos ranger，chdfs ranger。

• 各种认证支持

  支持 TBDS 认证

  支持 TAuth 认证

  Kerberos 认证

• 支持 OpenLDAP 管理 Alluxio 用户组映射功能。

  腾讯 Alluxio 提供了用户组映射扩展，LDAP 用户组映射功能，为用户提供了使用 LDAP 作为用户组服务的功能。用户需启动一个 LDAP 服务，创建好用户和属主的关系。如下图所示，可以在 LDAP 服务中配置用户组映射信息。

腾讯 Alluxio 团队典型开源贡献

• Alluxio FUSE

  Alluxio JNIFUSE 模块的创建和维护者。

  Alluxio FUSE shell 功能。实现通过访问文件系统的形式，访问 fuse 的 metadatacache 和 metrics 等内部数据结构的信息。Alluxio FUSE 写入操作清理缓存支持。

• UFS 扩展，Ozone、Cephfs、cosn 模块的创建和指导创建。

• Alluxio 任意 master 支持 webui、指标监控等功能

• Alluxio LocalCache 支持多盘缓存功能。

• distributed load 支持 load 到指定的 LocalityId、host

• Job master 增加 auditlog

• 实现了 Presto iceberg connector 支持 Alluxio LocalCache 功能。

• 增加众多指标，增强可监控性。

• 增加了 worker 预注册的流程, 可以避免 worker 脏数据污染集群

• 增加基于 web 的 jmx 指标导出方式

• 增加了监控相关 helm chart

腾讯 Alluxio 团队开源贡献统计

• 腾讯 Alluxio 团队向开源社区贡献了 400+ 个 commit，在除 Alluxio 公司之外贡献最大的公司。

• 在 2021 年，Alluxio 开源社区一共晋升 1 名 PMC maintainer(Alluxio 公司外仅有 2 名)， 2 名 committer，全部都来自腾讯 Alluxio 团队。

• 腾讯 DOP 团队对外输出了多篇 Alluxio 公众号文章，数次 Alluxio 社区技术直播分享。DOP 团队与 Alluxio 社区合作联合举办了 Alluxio Day 会议。

• 腾讯 Alluxio 团队与 Alluxio 公司协同发布 2.8 版本。

• 腾讯 Alluxio 的技术影响力，成功吸引多名业内技术人才。

腾讯 Alluxio 典型案例

腾讯 Alluxio 在众多团队的共同努力和协作之下，落地项目非常多，仅列举如下典型案例。

• DLC 产品集成 Alluxio LocalCache 实现性能提升 2-5 倍。

  腾讯数据湖计算解决了数据湖敏捷高效的分析和计算问题，是腾讯云推出一款开箱即用的数据湖分析服务。DLC 搭配 alluxio localCache 模式，提速性能 2 - 5 倍。《云原生数据湖为什么要选择腾讯云大数据DLC，一份性能分析报告告诉你！》

• EMR 产品集成 Alluxio 带宽削峰 20%-50%，节省总带宽 10%-50%，同时能在 IO 密集型场景提升性能 5%-40%。

  随着企业大数据规模和应用的增长和发展，计算与存储分离的架构渐渐成为主流，Alluxio 解决了计算量和存储量不匹配问题， 实现了算力的按需使用。腾讯 Alluxio 团队与开源社区合作，探索出了开箱即用的计算存储分离优化版本。https://www.infoq.cn/article/KFQqjM9hsZb1qCZARDok

• 助力 FiT 业务显著提升查询性能

  腾讯 Alluxio 团队与 CDG 数据团队，TEG supersql 团队和 konajdk 团队进行通力协作，解决了金融场景落地腾讯 DOP 过程中遇到的各种问题，最终达到了性能和稳定性都大幅提升的效果。https://cn.alluxio.io/tencent-use-case-on-financial-scenario/

• 基于 Alluxio 提升 PCG 多维度查询引擎 200%。

  灯塔作为腾讯公司内部的数据分析和展示平台，Impala 作为灯塔-融合分析引擎的主引擎，Alluxio 融合 Impala，不但使得 Impala 充分享受了存算分离技术架构带来的诸多好处，也成功规避了存储分离技术架构带来的问题。性能提升 200%，失败率降低 29%。https://zhuanlan.zhihu.com/p/270737380

• 助力 Supersql 查询性能提速 2.6 倍。

  Supersql 是跨数据源、跨数据中心、跨执行引擎的高性能、安全的大数据 SQL 引擎。Alluxio 和 Presto 混合部署，TPC-DS 测试，引入 Alluxio 的平均加速比 2.6。目前 Supersql 搭配 Alluxio 的方案广泛应用于大数据查询场景。https://cloud.tencent.com/developer/article/1938465

• 落地千节点 Alluxio 游戏 AI 业务，并发上限提升 2 倍 ，失败率下降到四分之一。

  AI 特征计算业务场景中引入 CAlluxio， 将大部分游戏版本数据 Load 到  Alluxio 缓存,  利用 Alluxio 元数据访问能力降低底层 ceph 的压力，从而支持更多核数的并发任务，并且降低业务作业的失败率下降到四分之一。 https://cloud.tencent.com/developer/article/1889789

腾讯 Alluxio 未来规划

• 将内网大规模验证过的腾讯 Alluxio 更多的输出私有化场景以及公有云用户，统一全网数据编排与缓存场景需求。

• 与 Alluxio 开源社区以及 OTeam 协同团队更紧密的合作，帮助更多团队使用腾讯 Alluxio。

• 扩充业务领域。支持大数据、AI、数据迁移等多个领域业务。