共计 2351 个字符，预计需要花费 6 分钟才能阅读完成。
各位的社区小伙伴们大家好，咱们很快乐的发表，ByConity 0.2.0 版本正式公布了，这个版本提供多项有用的新个性，同时修复了若干已知的问题，进一步晋升了零碎的性能和稳定性。
重要新个性：
- 冷读优化，包含 IOScheduler 和 Preload 能力
- 数据湖反对，包含 Hive，Hudi，Multi-Catalog 等反对
- ELT 长时工作反对，包含异步执行，队列，算子 Spill 等
- RBAC
欢送大家应用体验，期待听到大家的反馈和倡议。
https://github.com/ByConity/ByConity/releases
冷读优化
因为 ByConity 的存算拆散架构，对远端存储的冷读相比本地磁盘有肯定的性能差距，在 0.2.0 版本专门针对冷读进行了性能优化，次要伎俩有：
IOScheduler
为了缩小单个申请端到端的耗时，晋升节点的吞吐，同时升高肯定工夫范畴外的查问的数量。咱们引入 IOScheduler 对远端数据进行读取，能达到如下指标：
- 缩小 IO 申请的数量并升高节点带宽的应用；
- 在慢 IO 比例肯定的状况下，缩小 IO 数量能缩小查问受到慢 IO 影响的可能性；
- 对大 IO 的切分与并行执行，缩小大 IO 的耗时；
- 反对 Prefetch 容许将数据预取回来，缩小查问端到端的耗时；
- 对 S3 的冷读相比于上一个版本有 3 倍的晋升。
Preload
反对被动将远端存储数据预拉取到 Disk Cache 中。反对：
主动 Preload：当表产生 insert、merge 后会主动把更新后的数据拉取到本地，可通过配置项开启；
手动 Preload：应用 ALTER 语句手动 Preload 特定范畴的数据。
数据湖反对
Hive 表引擎
从 0.2.0 版本开始，ByConity 能够通过建设表面的模式拜访 Hive 数据，创立 Hive 表面时，ByConity 会获取并解析 Hive table 元数据，主动推断表的构造（列名，类型，分区），并通过 Hive 引擎读取 Parquet 以及 ORC 格局的 Hive 数据，同时反对将 Hive 的统计信息集成到 ByConity 的优化器。该版本同时反对 HDFS 和 S3 存储。
Hudi 表引擎
该版本实现 Hudi 两种类型表的反对：Copy On Write 表和 Merge On Read 表。ByConity 实现了对 Hudi CoW 表的进行快照查问。在开启 JNI Reader 后能够反对 MoR 表的读取。ByConity 引入 JNI 模块来调用 Hudi Java 客户端读取数据。并且通过 Arrow 实现内存数据在 Java 与 C++ 之间的替换。
Multi-Catalog
为了更不便地连贯到多个内部数据目录，以加强 ByConity 的数据湖剖析和表面查问性能，ByConity 引入 Multi-Calalog 能力，容许用户在同一个 Hive 实例中同时连贯多个不同的存储和元数据服务，而不用为每个存储创立独自的 Hive 实例。这简化了数据管理和查问的复杂性，使组织可能更好地治理和利用其多样化的数据资源。目前曾经反对的内部 Catalog 有：Hive，Hudi，AWS Glue。
ELT 反对
谈到数据仓库，肯定离不开应用 Extract-Transform-Load (ETL)或 Extract-Load-Transform (ELT)。将起源不同、格局各异的数据提取到数据仓库中，并进行解决加工。ByConity 从该版本开始反对 Extract-Load-Transform (ELT)的能力，从而使用户免于保护多套异构零碎。具体而言，用户能够将数据导入后，通过自定义的 SQL 语句，在 ByConity 外部进行数据转换，而无需依赖独立的 ETL 零碎及资源。
该版本反对 ELT 中的第一阶段的根本能力，包含异步执行，队列，基于磁盘的 Shuffle。
异步执行
面对查问量大、耗时长的工作时，同步执行的形式须要客户端期待服务端返回，容易呈现连贯超时、影响后续工作执行等问题，在长时工作中，用户不太关怀申请的相应工夫，只冀望能在特定工夫内实现，并对可靠性等要求较高，反对长时工作的异步执行，是反对混合负载的开始。
队列
离线加工面对大量申请时，当零碎超载，须要肯定的排队机制使 query 申请挂起，期待集群开释资源后再进行调度。
基于磁盘的 Shuffle
以后的 exchange 会在所有 segment 下发执行后进行注册动作。Stage by stage execution 要求上下游 stage 别离执行。exchange 以后的实现不满足要求。应实现基于磁盘的 shuffle 性能，在上游 task 运行结束后，上游 task 依然可能获取分区输出数据。
RBAC
该版本反对 RBAC 根本能力，其用法与 ClickHouse 统一，包含用户治理，角色治理，权限治理等。实现方面因为 ByConity 存算拆散的架构个性，采纳对立元数据的形式实现，RBAC 信息对立寄存在 ByConity 的 Metastore 当中，并且为了性能，由 Server 在镜像 RBAC 信息并播送所有更改。
问题修复
修复了 ByConity 0.1.0 版本中若干已知问题，进一步提高了零碎的稳定性。残缺的问题列表能够看这里：
https://github.com/ByConity/ByConity/releases
致谢
从 0.1.0 至今，咱们收到很多社区开发者的测试反馈和代码奉献，在此向所有参加 0.2.0 测试和反馈的开发者表示感谢（排名不分先后，均为 GitHub ID）：
juppylm，luffyhwl，Alima777，fky2015，AdityaC4，gaodayue，zeromem，SYaoJun，JackyWoo，fancyqlx，xiaomo728，hillbun，tianyouyangying，skyoct，xingcici，FourSpaces，inewzone，xiaohu-zhang
欢送退出社区，与咱们共建
