版本发布说明
DA-3.2-8.0.2
Alluxio DA-3.2-8.0.2在客户端 UFS 回退机制、CLI命令以及与 Trino 和 Spark 的集成等方面新增了多项改进。
变更日志
新增配置选项以跳过 setAttribute，支持当 UFS 为 S3 时的 INSERT 语句
支持将阿里云 OSS 作为 Spark 和 Trino 的 UFS
CLI 命令中同时支持 Alluxio 路径和 UFS 路径
当没有可用的工作节点时触发回退机制
如果 URL 无法解析为挂载表中现有的挂载点，则触发回退机制
由于不同 UFS 类型之间的哈希算法不同，因此在复制任务中不做内容哈希校验
优化客户端与 ETCD的通信超时设置，以更快地触发回退机制
配置变更
（新）
alluxio.user.file.set.attribute.noop.enabled，默认值为false
DA-3.2-8.0.1
Alluxio DA-3.2-8.0.1 增加了两项小改进，以优化工作节点内存利用率。
DA-3.2-8.0.0
我们很高兴推出第一个面向数据分析场景的 Alluxio Enterprise 3.x 版本——Alluxio DA 3.2。该版本基于 Alluxio 的新一代架构 DORA（已在 Alluxio Enterprise AI 产品中使用)，同时还包含了多个近期专门为 3.x 产品系列开发的重要功能。
亮点
DORA (Distributed Object Repository Architecture， 去中心化对象存储架构 )
DORA 架构在性能和可扩展性方面均带来显著提升，现可用于数据分析领域的工作负载。其亮点包括：
元数据去中心化，分散存储在 Alluxio worker上
使用页存储（以1MB为最小缓存单位）作为细粒度缓存，减少读取放大
使用 Netty 实现零拷贝网络传输
稳定的集群，稳定的数据 I/O
DORA 架构使与 Alluxio 交互的客户端应用能够在不需要与中心化的 master 进程通信的情况下发现缓存所在的 Alluxio worker。移除了 Alluxio master 这一单点故障点后，整个集群的稳定性得到提升，master 单点带来的限制也得以解除。例如，Alluxio 缓存的文件总数，现在可扩展到 100 亿以上。
Kubernetes 原生
通过将 Kubernetes 作为部署环境，并部署定制化的 Kubernetes operator，可解决将 Alluxio 作为分布式系统部署和管理所面临的许多挑战。除了在容器内隔离 Alluxio 进程的优势外，标准化使用 Kubernetes 还让我们能够提供以下功能：
就绪检查和自动重启有问题的进程
配置管理和统一地传播到所有 Pod
我们默认推荐使用 Kubernetes 作为部署环境，并会持续通过强化 Kubernetes operator 来改善最终用户体验。尽管该系统可在物理机上部署，但是部署后无法利用上述功能。
从 Alluxio Enterprise 2.x 升级
鉴于存在多项基础性的修改，Alluxio 3.x 与 Alluxio 2.x 完全不兼容，无法直接升级。在替换之前的 Alluxio 2.x 部署之前，须对 Alluxio 3.x 的使用进行阶段性验证。
两个版本之间的主要区别有：
使用单个 coordinator 进程替代 master 进程：Master 进程不再是关键组件，其部分功能由轻量级的 coordinator 进程替代。新版本只需一个 coordinator 进程，并且重启该进程不会干扰数据 I/O 操作。这也意味着系统中移除了日志（Journal）组件。
移除 proxy 进程：在之前的版本中，proxy 组件提供了对北向 REST API 和 S3 API 的接口转换服务。目前，此功能已嵌入到 worker 进程中，可以以类似的方式使用。
用页存储替代块存储：如前所述，页存储（1MB）的细粒度缓存比基于数据块（64MB）的存储更高效，但也可能需要根据平均文件大小进行适当调整。
bin/alluxio CLI 命令： CLI 命令已重构。大多数 2.x 命令都有对应的 3.x 命令（ 3.x 移除的功能除外）。不过，由于某些输入参数的格式可能不同，因此不可能提供完全向后兼容的脚本，例如部分指令使用 UFS 路径（s3://bucket/path/to/object），而非 Alluxio 路径（alluxio:///some/path）。
截止当前版本，Alluxio 3.x 完全支持 Alluxio 2.x 的核心功能子集。如果您目前是 Alluxio 2.x 用户，无论使用的是企业版（EE）还是社区版（CE），我们都希望帮助您成功升级到我们的新一代产品。
Last updated