Apache Doris版本更新录(202x)
2023-08-16 21:27:27 
阿炯
本文是从Apache Doris的产品主页分离出来的，专门用于该发行版本的更新记录，截止到2030年之前。
最新版本：0.14
Palo 0.14.13 版本于2021年9月上旬正式发布。百度智能云 Doris 团队在维护 Apache Doris 社区的同时，也会定期发布基于 Apache Doris 官方 Release 的百度发行版本 Palo。快速迭代版本不仅包含了 Apache Doris 所有的新增功能、功能改进和 Bug 修复，同时也包含 Palo 的一些独占功能。
注意：这并不是 Apache 官方 Release 版本，但为了便于用户理解，我们沿用了社区版本的版本号格式，并且完全和社区版本兼容，以方便用户平滑升级。
升级注意事项
1. 升级步骤
0).14.12.x 版本包含了一个不兼容的 Thrift RPC 定义。如果用户是从 0.14.7(含)之前的版本升级到 0.14.12(含)之后的版本。需按照如下方式进行升级：
1). 执行 set global enable_bucket_shuffle_join =false; 全局关闭 Bucket Shuffle 功能。
2). 升级所有 BE 节点。
3). 升级所有 FE 节点。
4). 执行 set global enable_bucket_shuffle_join =true; 全局开启 Bucket Shuffle 功能。
即在升级过程中，禁止 Bucket Shuffle 功能，以避免升级过程中，BE 节点频繁宕机。
2. GCC 升级
从0.14.12版本开始，BE 端的 C++代码的编译器版本要求从 gcc7 升级为 gcc10。如需源码编译，需使用 Doris 编译镜像 v1.3 版本。如果用户在之前的版本中使用了 UDF(用户自定义函数)，这些将 UDF 不能在新版本中正常运行，请勿升级。我们将在后续迭代版本中给出解决方案。
新增功能
Doris Manager [*]
增加 Doris Manager 相关接口，可以通过 Doris Manager 组件查看和管理部分集群信息。
Routine load 相关
1. 获取例行导入作业的创建命令
支持通过 show create routine load 语句获取指定例行导入作业的创建语句。该功能方便用户在重新创建例行导入作业时，获取包含offset信息在内的完整作业创建语句。
2. 支持一次性暂停或重启所有例行导入作业
在某些情况下，用户可能需要批量暂停(Pause)或重启(Resume)所有例行导入作业。此时可以通过 pause(resume) all routine load 语句来一次性完成这个操作。
3. 支持修改 Kafka Broker List 和 Topic
可以通过 alter routine load 语句修改更多的作业属性，方便应对 Broker 信息变更等场景。
其他
1. 查看表的数据倾斜情况：支持通过 admin show data skew 命令查看表的各个数据分片大小，也确定数据是否产生倾斜。
2. 修改表和列的注释：支持通过 alter table 语句修改表或列的注释信息(Comment)。
3. 查看表的数据更新时间：支持通过 show table status 命令查看表的最近一次数据更新时间。
功能优化
1. 优化 Bloom Filter 的过滤性能，进一步提升索引的过滤效果和 Runtime Filter 的过滤性能。
2. 通过 SIMD 指令优化存储层的数据读取效率。
功能优化
1. 解决通过 apache http client 调用 Strem Load 时，可能出现的 Broken Pipe 等错误。
2. 支持在 show proc "/statistic" 中查看已损坏分片的情况，方便定位问题。
3. 优化 B E端 Compaction 的逻辑，避免在创建物化视图或表结构变更操作过程中，数据版本堆积的问题。
4. Flink-Doris-Connector 支持设置写入端 Stream Load 的提交频率和其他导入参数。
重要Bug修复
元数据相关问题
1. 修复部分情况下，在回放元数据操作日志时可能出现空指针的问题。
查询相关问题
1. 修复部分情况下，Bucket Shuffle 和 Left Semi Join(Exist) 查询结果不正确的问题。
2. 修复 Runtime Filter 处理 null 值不正确的问题。
其他
1. 修复在某些大内存机器上，BE 内存可能一直上涨，不受 mem_limit 参数限制的问题。
2. 修复在动态分区功能中，创建历史分区的若干已知问题。
3. 修复 Spark Load 中对于部分分桶列值计算错误的问题。
最新版本：2.0
Doris 2.0.0 版本已于 2023 年 8 月 11 日正式发布，有超过 275 位贡献者为 Apache Doris 提交了超过 4100 个优化与修复。在本版本中，Doris 在标准 Benchmark 数据集上盲测查询性能得到超过 10 倍的提升、在日志分析和数据湖联邦分析场景能力得到全面加强、数据更新效率和写入效率都更加高效稳定、支持了更加完善的多租户和资源隔离机制、在资源弹性与存算分离方向踏上了新的台阶、增加了一系列面向企业用户的易用性特性。在经过近半年的开发、测试与稳定性调优后，这一版本已经正式稳定可用，欢迎大家下载使用。
在 Doris 2.0 版本中引入了全新查询优化器和自适应的并行执行模型，结合存储层、执行层以及执行算子上的一系列性能优化手段，实现了盲测性能 10 倍以上的提升。以 SSB-Flat 和 TPC-H 标准测试数据集为例，在相同的集群和机器配置下，新版本宽表场景盲测较之前版本性能提升 10 倍、多表关联场景盲测提升了 13 倍，实现了巨大的性能飞跃。
1、更智能的全新查询优化器
全新查询优化器采取了更先进的 Cascades 框架、使用了更丰富的统计信息、实现了更智能化的自适应调优，在绝大多数场景无需任何调优和 SQL 改写即可实现极致的查询性能，同时对复杂 SQL 支持得更加完备、可完整支持 TPC-DS 全部 99 个 SQL。通过全新查询优化器，我们可以胜任更多真实业务场景的挑战，减少因人工调优带来的人力消耗，真正助力业务提效。
以 TPC-H 为例，全新优化器在未进行任何手工调优和 SQL 改写的情况下，绝大多数 SQL 仍领先于旧优化器手工调优后的性能表现！而在超过百家 2.0 版本提前体验用户的真实业务场景中，绝大多数原始 SQL 执行效率得以极大提升。
参考文档详见此处。
如何开启：SET enable_nereids_planner=true 在 2.0.0 版本中全新查询优化器已经默认开启
2、倒排索引支持
在 2.0 版本中对现有的索引结构进行了丰富，引入了倒排索引来应对多维度快速检索的需求，在关键字模糊查询、等值查询和范围查询等场景中均取得了显著的查询性能和并发能力提升。在此以某头部手机厂商的用户行为分析场景为例，在之前的版本中，随着并发量的上升、查询耗时逐步提升，性能下降趋势比较明显。而在 2.0.0 版本开启倒排索引后，随着并发量的提升查询性能始终保持在毫秒级。在同等查询并发量的情况下，2.0.0 版本在该用户行为分析场景中并发查询性能提升了 5-90 倍！
3、点查询并发能力提升 20 倍
在银行交易流水单号查询、保险代理人保单查询、电商历史订单查询、快递运单号查询等 Data Serving 场景，会面临大量一线业务人员及 C 端用户基于主键 ID 检索整行数据的需求，同时在用户画像、实时风控等场景中还会面对机器大规模的程序化查询，在过去此类需求往往需要引入 Apache HBase 等 KV 系统来应对点查询、Redis 作为缓存层来分担高并发带来的系统压力。
对于基于列式存储引擎构建的 Apache Doris 而言，此类的点查询在数百列宽表上将会放大随机读取 IO，并且查询优化器和执行引擎对于此类简单 SQL 的解析、分发也将带来不必要的额外开销，负责 SQL 解析的 FE 模块往往会成为限制并发的瓶颈，因此需要更高效简洁的执行方式。
在 Apache Doris 2.0.0 版本，我们引入了全新的行列混合存储以及行级 Cache，使得单次读取整行数据时效率更高、大大减少磁盘访问次数，同时引入了点查询短路径优化、跳过执行引擎并直接使用快速高效的读路径来检索所需的数据，并引入了预处理语句复用执行 SQL 解析来减少 FE 开销。
通过以上一系列优化，Apache Doris 2.0.0 版本在并发能力上实现了数量级的提升，实现了单节点 30000 QPS 的并发表现，较过去版本点查询并发能力提升超 20 倍！
基于以上能力，Apache Doris 可以更好应对高并发数据服务场景的需求，替代 HBase 在此类场景中的能力，减少复杂技术栈带来的维护成本以及数据的冗余存储。
4、自适应的并行执行模型
在实现极速分析体验的同时，为了保证多个混合分析负载的执行效率以及查询的稳定性，在 2.0.0 版本中我们引入了 Pipeline 执行模型作为查询执行引擎。在 Pipeline 执行引擎中，查询的执行是由数据来驱动控制流变化的，各个查询执行过程之中的阻塞算子被拆分成不同 Pipeline，各个 Pipeline 能否获取执行线程调度执行取决于前置数据是否就绪，实现了阻塞操作的异步化、可以更加灵活地管理系统资源，同时减少了线程频繁创建和销毁带来的开销，并提升了 Apache Doris 对于 CPU 的利用效率。因此 Apache Doris 在混合负载场景中的查询性能和稳定性都得到了全面提升。参考文档可见此处。
如何开启 Set enable_pipeline_engine = true
1.该功能在 Apache Doris 2.0.0 版本中将默认开启，BE 在进行查询执行时默认将 SQL 的执行模型转变 Pipeline 的执行方式。
2.parallel_pipeline_task_num 代表了 SQL 查询进行查询并发的 Pipeline Task 数目。Apache Doris 默认配置为 0，此时 Apache Doris 会自动感知每个 BE 的 CPU 核数并把并发度设置为 CPU 核数的一半，用户也可以实际根据自己的实际情况进行调整。
3.对于从老版本升级的用户，会自动将该参数设置成老版本中 parallel_fragment_exec_instance_num 的值。
更统一多样的分析场景
作为最初诞生于报表分析场景的 OLAP 系统，Apache Doris 在这一擅长领域中做到了极致，凭借自身优异的分析性能和极简的使用体验收获到了众多用户的认可，在诸如实时看板（Dashboard）、实时大屏、业务报表、管理驾驶舱等实时报表场景以及自助 BI 平台、用户行为分析等即席查询场景获得了极为广泛的运用。
而随着用户规模的极速扩张，越来越多用户开始希望通过 Apache Doris 来简化现有的繁重大数据技术栈，减少多套系统带来的使用及运维成本。因此 Apache Doris 也在不断拓展应用场景的边界，从过去的实时报表和 Ad-hoc 等典型 OLAP 场景到湖仓一体、ELT/ETL、日志检索与分析、高并发 Data Serving 等更多业务场景，而日志检索分析、湖仓一体也是我们在 Apache Doris 最新版本中的重要突破。
1.10倍以上性价比的日志检索分析平台
在 Apache Doris 2.0.0 版本中，我们提供了原生的半结构化数据支持，在已有的 JSON、Array 基础之上增加了复杂类型 Map，并基于 Light Schema Change 功能实现了 Schema Evolution。与此同时，2.0.0 版本新引入的倒排索引和高性能文本分析算法全面加强了 Apache Doris 在日志检索分析场景的能力，可以支持更高效的任意维度分析和全文检索。结合过去在大规模数据写入和低成本存储等方面的优势，相对于业内常见的日志分析解决方案，基于 Apache Doris 构建的新一代日志检索分析平台实现了 10 倍以上的性价比提升。
2.湖仓一体
在 Doris 1.2 版本中引入了 Multi-Catalog 功能，支持了多种异构数据源的元数据自动映射与同步，实现了便捷的元数据和数据打通。在 2.0.0 版本中进一步对数据联邦分析能力进行了加强，引入了更多数据源，并针对用户的实际生产环境做了诸多性能优化，在真实工作负载情况下查询性能得到大幅提升。
在数据源方面，Apache Doris 2.0.0 版本支持了 Hudi Copy-on-Write 表的 Snapshot Query 以及 Merge-on-Read 表的 Read Optimized Query，截止目前已经支持了 Hive、Hudi、Iceberg、Paimon、MaxCompute、Elasticsearch、Trino、ClickHouse 等数十种数据源，几乎支持了所有开放湖仓格式和 Metastore。同时还支持通过 Apache Range 对 Hive Catalog 进行鉴权，可以无缝对接用户现有的权限系统。同时还支持可扩展的鉴权插件，为任意 Catalog 实现自定义的鉴权方式。
在性能方面，利用 Doris 自身高效的分布式执行框架、向量化执行引擎以及查询优化器，结合 2.0 版本中对于小文件和宽表的读取优化、本地文件 Cache、ORC/Parquet 文件读取效率优化、弹性计算节点以及外表的统计信息收集，其在 TPC-H 场景下查询 Hive 外部表相较于 Presto/Trino 性能提升 3-5 倍。
通过这一系列优化，Apache Doris 湖仓一体的能力得到极大拓展，在如下场景可以更好发挥其优异的分析能力：
1）.湖仓查询加速：为数据湖、Elasticsearch 以及各类关系型数据库提供优秀的查询加速能力，相比 Hive、Presto、Spark 等查询引擎实现数倍的性能提升。
2）.数据导入与集成：基于可扩展的连接框架，增强 Doris 在数据集成方面的能力，让数据更便捷的被消费和处理。用户可以通过 Doris 对上游的多种数据源进行统一的增量、全量同步，并利用其的数据处理能力对数据进行加工和展示，也可以将加工后的数据写回到数据源，或提供给下游系统进行消费。
3）.统一数据分析网关：利用 Doris 构建完善可扩展的数据源连接框架，便于快速接入多类数据源。提供基于各种异构数据源的快速查询和写入能力，将其打造成统一的数据分析网关。
高效的数据更新
在实时分析场景中，数据更新是非常普遍的需求。用户不仅希望能够实时查询最新数据，也希望能够对数据进行灵活的实时更新。典型场景如电商订单分析、物流运单分析、用户画像等，需要支持数据更新类型包括整行更新、部分列更新、按条件进行批量更新或删除以及整表或者整个分区的重写（inser overwrite）。
高效的数据更新一直是大数据分析领域的痛点，离线数据仓库 Hive 通常只支持分区级别的数据更新，而 Hudi 和 Iceberg 等数据湖，虽然支持 Record 级别更新，但是通常采用 Merge-on-Read 或 Copy-on-Write 的方式，仅适合低频批量更新而不适合实时高频更新。
在 Apache Doris 1.2 版本，我们在 Unique Key 主键模型实现了 Merge-on-Write 的数据更新模式，数据在写入阶段就能完成所有的数据合并工作，因此查询性能得到 5-10 倍的提升。在 Apache Doris 2.0 版本我们进一步加强了数据更新能力，主要包括：
1）.对写入性能进行了大幅优化，高并发写入和混合负载写入场景的稳定性也显著提升。例如在单 Tablet 7GB 的重复导入测试中，数据导入的耗时从约 30 分钟缩短到了 90s，写入效率提升 20 倍；以某头部支付产品的场景压测为例，在 20 个并行写入任务下可以达到 30 万条每秒的写入吞吐，并且持续写入十几个小时后仍然表现非常稳定。
2）.支持部分列更新功能。在 2.0.0 版本之前 Apache Doris 仅支持通过 Aggregate Key 聚合模型的 Replace_if_not_null 进行部分列更新，在 2.0.0 版本中我们增加了 Unique Key 主键模型的部分列更新，在多张上游源表同时写入一张宽表时，无需由 Flink 进行多流 Join 打宽，直接写入宽表即可，减少了计算资源的消耗并大幅降低了数据处理链路的复杂性。同时在面对画像场景的实时标签列更新、订单场景的状态更新时，直接更新指定的列即可，较过去更为便捷。
3）.支持复杂条件更新和条件删除。在 2.0.0 版本之前 Unique Key 主键模型仅支持简单 Update 和 Delete 操作，在 2.0.0 版本中我们基于 Merge-on-Write 实现了复杂条件的数据更新和删除，并且执行效率更加高效。基于以上优化，Apache Doris 对于各类数据更新需求都有完备的能力支持！
更加高效稳定的数据写入
1、导入性能进一步提升
聚焦于实时分析，我们在过去的几个版本中在不断增强实时分析能力，其中端到端的数据实时写入能力是优化的重要方向，在 Apache Doris 2.0 版本中，我们进一步强化了这一能力。通过 Memtable 不使用 Skiplist、并行下刷、单副本导入等优化，使得导入性能有了大幅提升：
使用 Stream Load 对 TPC-H 144G lineitem 表原始数据进行三副本导入 48 buckets Duplicate 表，吞吐量提升 100%。
使用 Stream Load 对 TPC-H 144G lineitem 表原始数据进行三副本导入 48 buckets Unique Key 表，吞吐量提升 200%。
使用 insert into select 对 TPC-H 144G lineitem 表进行导入 48 buckets Duplicate 表，吞吐量提升 50%。
使用 insert into select 对 TPC-H 144G lineitem 表进行导入 48 buckets Unique Key 表，吞吐提升 150%。
2、数据高频写入更稳定
在高频数据写入过程中，小文件合并和写放大问题以及随之而来的磁盘 I/O 和 CPU 资源开销是制约系统稳定性的关键，因此在 2.0 版本中我们引入了 Vertical Compaction 以及 Segment Compaction，用以彻底解决 Compaction 内存问题以及写入过程中的 Segment 文件过多问题，资源消耗降低 90%，速度提升 50%，内存占用仅为原先的 10% 。详细介绍见此处。
3、数据表结构自动同步
在过去版本中引入了毫秒级别的 Schema Change，而在最新版本 Flink-Doris-Connector 中实现了从 MySQL 等关系型数据库到 Doris 的一键整库同步。在实际测试中单个同步任务可以承载数千张表的实时并行写入，从此彻底告别过去繁琐复杂的同步流程，通过简单命令即可实现上游业务数据库的表结构及数据同步。同时当上游数据结构发生变更时，也可以自动捕获 Schema 变更并将 DDL 动态同步到 Doris 中，保证业务的无缝运行。详细介绍见此处。
更加完善的多租户资源隔离
多租户与资源隔离的主要目的是为了保证高负载时避免相互发生资源抢占，Doris 在过去版本中推出了资源组（Resource Group）的硬隔离方案，通过对同一个集群内部的 BE 打上标签，标签相同的 BE 会组成一个资源组。数据入库时会按照资源组配置将数据副本写入到不同的资源组中，查询时按照资源组的划分使用对应资源组上的计算资源进行计算，例如将读、写流量放在不同的副本上从而实现读写分离，或者将在线与离线业务划分在不同的资源组、避免在离线分析任务之间的资源抢占。
资源组这一硬隔离方案可以有效避免多业务间的资源抢占，但在实际业务场景中可能会存在某些资源组紧张而某些资源组空闲的情况发生，这时需要有更加灵活的方式进行空闲资源的共享，以降低资源空置率。因此在 2.0.0 版本中我们增加了 Workload Group 资源软限制的方案，通过对 Workload 进行分组管理，以保证内存和 CPU 资源的灵活调配和管控。
通过将 Query 与 Workload Group 相关联，可以限制单个 Query 在 BE 节点上的 CPU 和内存资源的百分比，并可以配置开启资源组的内存软限制。当集群资源紧张时，将自动 Kill 组内占用内存最大的若干个查询任务以减缓集群压力。当集群资源空闲时，一旦 Workload Group 使用资源超过预设值时，多个 Workload 将共享集群可用空闲资源并自动突破阈值，继续使用系统内存以保证查询任务的稳定执行。Workload Group 还支持设置优先级，通过预先设置的优先级进行资源分配管理，来确定哪些任务可正常获得资源，哪些任务只能获取少量或没有资源。
与此同时，在 Workload Group 中还引入了查询排队的功能，在创建 Workload Group 时可以设置最大查询数，超出最大并发的查询将会进行队列中等待执行，以此来缓解高负载下系统的压力。
极致弹性与存算分离
过去 Doris 凭借在易用性方面的诸多设计帮助用户大幅节约了计算与存储资源成本，而面向未来的云原生架构已经走出了坚实的一步。从降本增效的趋势出发，用户对于计算和存储资源的需求可以概括为以下几方面：
1）.计算资源弹性：面对业务计算高峰时可以快速进行资源扩展提升效率，在计算低谷时可以快速缩容以降低成本；
2）.存储成本更低：面对海量数据可以引入更为廉价的存储介质以降低成本，同时存储与计算单独设置、相互不干预；
3）.业务负载隔离：不同的业务负载可以使用独立的计算资源，避免相互资源抢占；
4）.数据管控统一：统一 Catalog、统一管理数据，可以更加便捷地分析数据。
存算一体的架构在弹性需求不强的场景具有简单和易于维护的优势，但是在弹性需求较强的场景有一定的局限。而存算分离的架构本质是解决资源弹性的技术手段，在资源弹性方面有着更为明显的优势，但对于存储具有更高的稳定性要求，而存储的稳定性又会进一步影响到 OLAP 的稳定性以及业务的存续性，因此也引入了 Cache 管理、计算资源管理、垃圾数据回收等一系列机制。而在与 Doris 社区广大用户的交流中，我们发现用户对于存算分离的需求可以分为以下三类：
1）.目前选择简单易用的存算一体架构，暂时没有资源弹性的需求；
2）.欠缺稳定的大规模存储，要求在 Apache Doris 原有基础上提供弹性、负载隔离以及低成本；
3）.有稳定的大规模存储，要求极致弹性架构、解决资源快速伸缩的问题，因此也需要更为彻底的存算分离架构；
为了满足前两类用户的需求，Doris 2.0 版本中提供了可以兼容升级的存算分离方案：
第一种，计算节点。2.0 版本中我们引入了无状态的计算节点 Compute Node，专门用于数据湖分析。相对于原本存储计算一体的混合节点，Compute Node 不保存任何数据，在集群扩缩容时无需进行数据分片的负载均衡，因此在数据湖分析这种具有明显高峰的场景中可以灵活扩容、快速加入集群分摊计算压力。同时由于用户数据往往存储在 HDFS/S3 等远端存储中，执行查询时查询任务会优先调度到 Compute Node 执行，以避免内表与外表查询之间的计算资源抢占。参考文档详见此处。
第二种，冷热数据分层。在存储方面，冷热数据往往面临不同频次的查询和响应速度要求，因此通常可以将冷数据存储在成本更低的存储介质中。在过去版本中 Doris 支持对表分区进行生命周期管理，通过后台任务将热数据从 SSD 自动冷却到 HDD，但 HDD 上的数据是以多副本的方式存储的，并没有做到最大程度的成本节约，因此对于冷数据存储成本仍然有较大的优化空间。在 Apache Doris 2.0 版本中推出了冷热数据分层功能，冷热数据分层功能使 Doris 可以将冷数据下沉到存储成本更加低廉的对象存储中，同时冷数据在对象存储上的保存方式也从多副本变为单副本，存储成本进一步降至原先的三分之一，同时也减少了因存储附加的计算资源成本和网络开销成本。通过实际测算，存储成本最高可以降低超过 70%！参考文档可见此处。
面对更加彻底的存储计算分离需求，飞轮科技（SelectDB）技术团队设计并实现了全新的云原生存算分离架构（SelectDB Cloud），近一年来经历了大量企业客户的大规模使用，在性能、功能成熟度、系统稳定性等方面经受了真实生产环境的考验。在 Doris 2.0 版本发布之际，飞轮科技宣布将这一经过大规模打磨后的成熟架构贡献至 Apache Doris 社区。这一工作预计将于 2023 年 10 月前后完成，届时全部存算分离的代码都将会提交到 Apache Doris 社区主干分支中，预计在 2023 年 9 月广大社区用户就可以提前体验到基于存算分离架构的预览版本。
易用性进一步提升
除了以上功能需求外，在 Apache Doris 还增加了许多面向企业级特性的体验改进。
1、支持 Kubernetes 容器化部署
在过去 Doris 是基于 IP 通信的，在 K8s 环境部署时由于宿主机故障发生 Pod IP 漂移将导致集群不可用，在 2.0 版本中支持了 FQDN，使得其可以在无需人工干预的情况下实现节点自愈，因此可以更好应对 K8s 环境部署以及灵活扩缩容。
2、跨集群数据复制
在 Doris 2.0.0 版本中可以通过 CCR 的功能在库/表级别将源集群的数据变更同步到目标集群，可根据场景精细控制同步范围；用户也可以根据需求灵活选择全量或者增量同步，有效提升了数据同步的灵活性和效率；此外 Dors CCR 还支持 DDL 同步，源集群执行的 DDL 语句可以自动同步到目标集群，从而保证了数据的一致性。Doris CCR 配置和使用也非常简单，简单操作即可快速完成跨集群数据复制。基于 Doris CCR 优异的能力，可以更好实现读写负载分离以及多机房备份，并可以更好支持不同场景的跨集群复制需求。
3、其他升级注意事项
1.2-lts 需要停机升级到 2.0.0，2.0-alpha 需要停机升级到 2.0.0
查询优化器开关默认开启 enable_nereids_planner=true ；
系统中移除了非向量化代码，所以 enable_vectorized_engine 参数将不再生效；
新增参数 enable_single_replica_compaction ；
默认使用 datev2, datetimev2, decimalv3 来创建表，不支持 datev1，datetimev1， decimalv2 创建表；
在 JDBC 和 Iceberg Catalog 中默认使用 decimalv3；
date type 新增 AGG_STATE；
backend 表去掉 cluster 列；
为了与 BI 工具更好兼容，在 show create table 时，将 datev2 和 datetimev2 显示为 date 和 datetime。
在 BE 启动脚本中增加了 max_openfiles 和 swap 的检查，所以如果系统配置不合理，be 有可能会启动失败；
禁止在 localhost 访问 FE 时无密码登录；
当系统中存在 Multi-Catalog 时，查询 information schema 的数据默认只显示 internal catalog 的数据；
限制了表达式树的深度，默认为 200；
array string 返回值 单引号变双引号；
对 Doris 的进程名重命名为 DorisFE 和 DorisBE；
正式踏上 2.0 之旅
在 Doris 2.0.0 版本发布过程中，邀请了数百家企业参与新版本的打磨，力求为所有用户提供性能更佳、稳定性更高、易用性更好的数据分析体验。后续我们将会持续敏捷发版来响应所有用户对功能和稳定性的更高追求，预计 2.0 系列的第一个迭代版本 2.0.1 将于 8 月下旬发布，9 月会进一步发布 2.0.2 版本。在快速 Bugfix 的同时，也会不断将一些最新特性加入到新版本中。9 月份还将发布 2.1 版本的尝鲜版本，会增加一系列呼声已久的新能力，包括 Variant 可变数据类型更好满足半结构化数据 Schema Free 的分析需求，多表物化视图在实现查询加速的同时也能简化数据调度和处理链路，在导入性能方面持续优化、增加新的更加简洁的数据导入方式，通过自动攒批实现更加实时的数据写入，复合数据类型的嵌套能力等。
期待 Doris 2.0 版本的正式发布为更多社区用户提供实时统一的分析体验，也相信 Doris 2.0 版本会成为实时分析场景中的最理想选择。最后，Apache Doris 社区年度峰会 Doris Summit 2023 已经启程，我们期待将有更多关于 2.0 版本的最佳应用实践在 Doris Summit 2023 被所有用户所看到。
最新版本：3
v3.0.3 版本已于 2024 年 12 月上旬正式发布，该版本进一步提升了系统的性能及稳定性。
----------------
行为变更
禁止在具有同步物化视图的 MOW 表上进行列更新。
调整 RoutineLoad 的默认参数以提升导入效率。
当 StreamLoad 失败时，LoadedRows 的返回值调整为 0。
将 Segment cache 的默认内存限制调整为 5%。
----------------
新特性
引入 enable_cooldown_replica_affinity 会话变量，用以控制冷热分层副本的亲和性。
Lakehouse
新增 table$partition 语法，用于查询 Hive 表的分区信息。
支持创建 Text 格式的 Hive 表。
异步物化视图
引入新的物化视图属性 use_for_rewrite。当 use_for_rewrite 设置为 false 时，物化视图不参与透明改写。
查询优化器
支持关联非聚合子查询。
查询执行
增加了 ngram_search、 normal_cdf、 to_iso8601、 from_iso8601_date、 SESSION_USER()、 last_query_id 函数。
aes_encrypt 和 aes_decrypt 函数支持 GCM 模式。
Profile 中输出变更的会话变量值。
半结构化数据管理
新增数组函数 array_match_all 和 array_match_any。
数组函数 array_agg 支持在 ARRAY 中嵌套 ARRAY/MAP/STRUCT。
新增近似聚合统计函数 approx_top_k 和 approx_top_sum。
----------------
改进与优化
存储
支持将 bitmap_empty 作为默认值。
引入 insert_timeout 会话变量，用以控制 DELETE 语句的超时时间。
改进部分错误提示信息。
改进副本修复的优先级调度。
提高了建表时对时区处理的鲁棒性。
在创建表时检查分区表达式的合法性。
在 DELETE 操作时支持 Unicode 编码的列名。
存算分离
存算分离模式支持 ARM 架构部署。
优化文件缓存的淘汰策略和锁竞争，提高命中率及高并发点查性能。
S3 storage vault 支持 use_path_style，解决对象存储使用自定义域名的问题。
优化存算分离配置及部署，预防不同模式下的误操作。
优化可观测性，并提供删除指定 segment file cache 的接口。
优化 Meta-service 运维接口：RPC 限速及修复 tablet 元数据修正。
Lakehouse
Paimon Catalog 支持阿里云 DLF 和 OSS-HDFS 存储。 查看文档
支持读取 OpenCSV 格式的 Hive 表。
优化了访问 External Catalog 中 information_schema.columns 表的性能。
使用新的 Max Compute 开放存储 API 访问 Max Compute 数据源。
优化了 Paimon 表 JNI 部分的调度策略，使得扫描任务更加均衡。
优化了 ORC 小文件的读取性能。
支持读取 brotli 压缩格式的 parquet 文件。
在 information_schema 库下新增 file_cache_statistics 表，用于查看元数据缓存统计信息。
查询优化器
优化：当查询仅注释不同时，可以复用同一个 SQL Cache。
优化：提升了在数据频繁更新时统计信息的稳定性。
优化：提升常量折叠的稳定性。
优化：列裁剪可以生成更优的执行计划。
查询执行
优化了 sort 算子的内存使用。
优化了 ARM 下运算的性能。
优化了一系列函数的计算性能。
使用 SSE 指令优化 match_ipv6_subnet 函数的性能。
在 insert overwrite 时支持自动创建新的分区。
在 Profile 中增加了每个 PipelineTask 的状态。
IP 类型支持 runtime filter。
半结构化数据管理
审计日志中输出 prepared statement 的真实 SQL。
filebeat doris output plugin 支持容错、进度报告等。
倒排索引查询性能优化。
数组函数 array overlaps 支持使用倒排索引加速。
IP 函数 is_ip_address_in_range 支持使用倒排索引加速。
优化 VARIANT 数据类型的 CAST 性能。
优化 Variant 数据类型的 CPU 资源消耗。
优化 Variant 数据类型的元数据和执行内存资源消耗。
权限
LDAP 新增配置项 ldap_group_filter 用于自定义过滤 group。
其他
FE 监控项中的连接数信息支持按用户分别显示。
----------------
问题修复
存储
修复 IPv6 hostname 使用问题。
修复 broker/s3 load 进度展示不准确问题。
修复查询从 FE 可能卡住的问题。
修复异常情况下自增 id 重复的问题。
修复 groupcommit 偶发 NPE 问题。
修复 auto bucket 计算不准确的问题。
修复 FE 重启时流控多表不能正确规划的问题。
存算分离
修复 MOW 主键表 delete bitmap 过大可能导致 coredump 的问题。
修复 segment 文件为 5MB 整数倍时上传对象失败的问题。
修复 aws sdk 默认重试策略不生效的问题。
修复 alter storage vault 时指定错误 type 也能继续执行的问题。
修复大事务延迟提交过程中 tablet_id 可能为 0 的问题。
修复常量折叠 RCP 以及 FE 转发 SQL 可能不在预期的计算组执行的问题。
修复 meta-service 接收到 RPC 时不严格检查 instance_id 的问题。
修复 FE follower information_schema version 没有及时更新的问题。
修复 file cache rename 原子性以及指标不准确的问题。
Lakehouse
禁止带有隐式转换的谓词条件下推给 JDBC 数据源，避免不一致的查询结果。
修复 Hive 高版本事务表的一些读取问题。
修复 Export 命令可能导致死锁的问题。
修复无法查询 Spark 创建的 Hive 视图的问题。
修复 Hive 分区路径中包含特殊字符导致分区裁剪有误的问题。
修复 Iceberg Catalog 无法使用 AWS Glue 的问题。
异步物化视图
修复基表重建后，异步物化视图可能无法刷新的问题。
查询优化器
修复使用多列 range 分区时，分区裁剪结果可能有误的问题。
修复部分 limit offset 场景下计算结果错误的问题。
查询执行
修复 hash join 时 array 类型的大小超过 4G 导致 BE Core 的问题。
修复 is null 谓词运算部分场景下结果不正确的问题。
修复 bitmap 类型在 hash join 时输出结果不正确的问题。
修复一些函数结果计算错误的问题。
修复一些 JSON 类型解析的问题。
修复 varchar 和 char 类型在 runtime filter 运算时的问题。
修复一些 decimal256 在标量函数和聚合函数里使用的问题。
修复 arrow flight 在连接时报 Reach limit of connections 错误的问题。
修复 k8s 环境下，BE 可用内存统计不正确的问题。
半结构化数据管理
调整 segment_cache_fd_percentage 和 inverted_index_fd_number_limit_percent 的默认值。
logstash 支持 group_commit。
修复 build index 时 coredump 的问题。
修复 variant index 的问题。
修复后台 compaction 异常情况下可能出现的 fd 和内存泄漏。
倒排索引 match null 正确返回 null 而不是 false。
修复 ngram bloomfilter 索引 bf_size 设置为 65536 时 coredump 的问题。
修复复杂数据类型 JOIN 可能出 coredump 的问题。
修复 TVF JSON 数据 coredump 的问题。
修复 bloom filter 计算日期和时间的精度问题。
修复 IPv6 类型行存 coredump 的问题。
修复关闭 light_schema_change 时使用 VARIANT 类型 coredump 的问题。
提升高并发点查的 cache 性能。
修复删除列时 bloom filter 索引没有同步更新的问题。
修复 es catalog 在数组和标量混合数据等特殊情况下的不稳定问题。
修复异常正则匹配导致的 coredump 问题。
权限
修复若干权限授权之后无法正常限制的问题。
加强若干权限校验。
其他
补充了审计日志表和文件中缺失的审计日志字段。
最新版本：4
2025年10月下旬迎来了 Apache Doris 4.0 版本的正式发布，本次发布围绕 “AI 驱动、搜索增强、离线提效” 三大核心方向，新增向量索引、AI 函数等关键特性，完善搜索功能矩阵，优化离线计算稳定性与资源利用率，并通过多项底层改进提升查询性能与数据质量，为用户构建更高效、更灵活的企业级数据分析平台。通过 AI 与搜索能力的深度融合、离线计算的稳定性提升、性能与易用性的双重优化，进一步拓宽了数据库的应用边界，可更好地支撑企业从传统 BI 分析到 AI 智能检索、从实时查询到大规模离线批处理的全场景数据分析需求。无论是互联网、金融、零售等行业的实时报表、用户行为分析，还是政务、医疗领域的文档检索、大规模数据批处理，新版本 Doris 都将为用户提供更高效、更可靠的数据分析体验。
在 4.0 版本的研发过程中，有超过 200 名贡献者为 Apache Doris 提交了 9000+ 个优化与修复。
一、AI 能力深度集成，开启智能分析新范式
随着大模型与向量检索技术在企业级场景的加速落地与深度渗透，本次 Doris 版本迭代将重点强化 AI 原生支持能力。通过向量索引技术，高效融合企业的结构化与非结构化数据，Doris 将突破传统数据库的功能边界，直接升级为企业核心的 “AI 分析中枢”，为业务端的智能化决策与创新实践提供稳定、高效的底层数据支撑。
向量索引（Vector Index）
正式引入向量索引功能，支持对高维向量数据（如文本嵌入、图像特征等）进行高效存储与检索。结合 Doris 原生的 SQL 分析能力，用户可直接在数据库内完成 “结构化数据查询 + 向量相似性搜索” 的一体化分析，无需跨系统整合，大幅降低 AI 应用（如智能推荐、语义搜索、图像检索）的开发与部署成本。
AI Functions 函数库
让数据分析师能够直接通过简单的 SQL 语句，调用大语言模型进行文本处理。无论是提取特定重要信息、对评论进行情感分类，还是生成简短的文本摘要，现在都能在数据库内部无缝完成：
AI_CLASSIFY：在给定的标签中提取与文本内容匹配度最高的单个标签字符串。
AI_EXTRACT：根据文本内容，为每个给定标签提取相关信息。
AI_FILTER：判断文本内容是否正确，返回值为 bool 类型。
AI_FIXGRAMMAR：修复文本中的语法、拼写错误。
AI_GENERATE：基于参数内容生成内容。
AI_MASK：根据标签，将原文中的敏感信息用 [MASKED] 进行替换处理。
AI_SENTIMENT：分析文本情感倾向，返回值为 positive、negative、neutral、mixed 其中之一。
AI_SIMILARITY：判断两文本的语义相似度，返回值为 0 - 10 之间的浮点数，值越大代表语义越相似。
AI_SUMMARIZE：对文本进行高度总结概括。
AI_TRANSLATE：将文本翻译为指定语言。
AI_AGG: 对多条文本进行跨行聚合分析。
目前支持的大模型包括：OpenAI、Anthropic、Gemini、DeepSeek、Local、MoonShot、MiniMax、Zhipu、Qwen、Baichuan。例如：模拟一个简历筛选的需求，通过以下 SQL 在语义层进行筛选。
二、搜索功能全面升级，赋能全文检索
针对企业级搜索场景的多样化需求，本次版本完善搜索能力矩阵，提供更精准、更灵活的文本检索体验：
新增 Search 函数：统一入口的轻量 DSL 全文检索
核心亮点
一个函数搞定全文检索：将复杂文本检索算子收拢到 SEARCH() 统一入口，语法贴近 Elasticsearch Query String，极大降低 SQL 拼接复杂度与迁移成本。
多条件索引下推：复杂检索条件直接下推至倒排索引执行，避免 “解析一次、拼接一次” 的重复开销，显著提升性能。
DSL 语法支持简介
当前版本支持的语法功能：
词项查询（Term）：field:value
ANY / ALL 多值匹配：field:ANY(v1 v2 ...) / field:ALL(v1 v2 ...)
布尔组合：AND / OR / NOT 与括号分组
多字段搜索：在一个 search() 中对多个字段做布尔组合
后续版本会持续迭代以支持以下语法功能：短语、前缀、通配符、正则、范围、列表
文本检索打分
为了更好的支持混合检索场景，Doris4.0 版本引入业界主流的 BM25 相关性评分算法，替代传统的 TF-IDF 算法。BM25 可根据文档长度动态调整词频权重，在长文本、多字段检索场景下（如日志分析、文档检索），显著提升结果相关性与检索准确性。
倒排索引分词能力增强
Doris 在 3.1 版本初步提供了分词能力，在 4.0 版本中对分词能力进一步增强，能够满足用户在不同场景下的分词和文本检索需求。
增加三种内置分词器
ICU（International Components for Unicode）分词器
适用场景：包含复杂文字系统的国际化文本，特别适合多语言混合文档。
IK 分词器
适用场景：对分词质量要求较高的中文文本处理。
ik_smart：智能模式，词少且更长，语义集中，适合精确搜索。
ik_max_word：最细粒度模式，更多短词，覆盖更全面，适合召回搜索。
Basic 分词器
适用场景：简单场景、对性能要求极高的场景，可以作为日志场景中 unicode 分词器的平替。
新增自定义分词能力
管道化组合：通过 char filter、tokenizer 与多个 token filter 的链式配置，构建自定义文本处理流程。
组件复用：常用的 tokenizer 和 filter 可在多个 analyzer 中共享，减少重复定义，降低维护成本。
用户可以通过 Doris 提供的自定义分词机制，支持灵活组合 char filter、tokenizer 和 token filter，从而为不同字段定制合适的分词流程，满足复杂场景下的个性化文本检索需求。
三、离线计算能力强化，保障大规模任务稳定运行
当前越来越多的用户将 ETL 数据加工，多表物化视图处理等离线计算任务迁移到 Doris 上运行，针对离线批处理场景的资源消耗大、任务易溢出等痛点，4.0 新增 Spill Disk 功能，当离线计算任务的内存占用超出阈值时，自动将部分中间数据写入磁盘，避免因内存不足导致任务失败，大幅提升大规模离线任务的稳定性与容错能力。目前支持落盘的算子有：Hash Join 算子、聚合算子、排序算子、CTE 算子。
四、数据质量全链路保障，筑牢分析结果可信基石
数据正确性是企业制定决策的核心前提与关键基石。为进一步夯实这一基础，4.0 版本对大量函数的运行行为进行了系统性梳理与规范，从数据导入环节到计算分析环节构建全链路校验机制，全面保障数据处理结果的准确性与可靠性，为企业决策提供坚实的数据支撑。
注：数据质量问题的梳理会导致一些行为跟过去产生差异，升级之前请务必仔细阅读文档并提前做好环境测试。
Cast
CAST 是 SQL 中逻辑最复杂的函数之一，其核心作用是实现不同数据类型间的转换 —— 这一过程不仅需处理大量细碎的格式规则与边界场景，更因涉及类型语义的精准映射，成为实际使用中极易出错的环节。尤其在数据导入场景中，本质是将外部字符串转换为数据库内部类型的 CAST 操作，因此 CAST 的行为直接决定了导入逻辑的准确性与稳定性。同时，我们可以预见未来的数据库将大量的被 AI 来操作，而 AI 需要对数据库的行为有明确的定义，为此，我们引入了 BNF 范式，希望通过范式定义的方式，为开发者和 AI Agent 提供清晰的操作依据。
严格模式、非严格模式、TRY_CAST
在 v4.0 中，对 CAST 操作增加了严格模式、非严格模式（通过 enable_strict_cast 来控制）以及 TRY_CAST 函数，以更好地处理数据类型转换时的各种情况。具体如下：
严格模式：系统会依据预定义的 BNF（语法规则，对输入数据的格式、类型、取值范围进行严格校验：若数据不符合规则（如字段类型应为 “数值型” 却传入字符串、日期格式不符合 “YYYY-MM-DD” 规范），系统会直接终止数据处理流程并抛出明确报错（含具体不符合规则的字段与原因），杜绝不合法数据进入存储或计算环节。这种 “零容忍” 的校验逻辑，与 PostgreSQL 数据库的严格数据校验行为高度一致，能从源头保障数据质量的准确性与一致性，因此在对数据可靠性要求极高的场景中不可或缺 —— 例如金融行业的交易对账、财务领域的账单核算、政务系统的信息登记等场景，一旦出现不合法数据（如交易金额为负数、账单日期格式错误），可能引发资金损失、合规风险或业务流程混乱。
非严格模式：系统同样会依据 BNF 规则校验数据，但采用 “容错式” 处理逻辑：若数据不符合规则，不会终止流程或报错，而是自动将不合法数据转换为 NULL 值后继续执行 SQL（例如将字符串 “xyz” 转换为数值型 NULL），确保 SQL 任务能正常完成，优先保障业务流程的连续性与执行效率。这种模式更适用于对 “数据完整性要求较低、但对 SQL 执行成功率要求高” 的场景 —— 例如日志数据处理、用户行为数据清洗、临时数据分析等场景，此类场景中数据量庞大且来源复杂（如 APP 日志可能因设备异常产生格式错乱字段），若因少量不合法数据中断整个 SQL 任务，会大幅降低处理效率，且少量 NULL 值对整体分析结果（如统计活跃用户数、点击量）影响极小。
enable_strict_cast 是在一个语句级别控制 cast 的行为的方式，但是可能会出现，在一个 SQL 中有多个 cast 函数，有一部分函数用户希望用严格模式，另外一部分函数使用非严格模式，所以我们引入了 TRY_CAST 函数。
TRY_CAST 函数的作用是将一个表达式转换为指定的数据类型，如果转换成功则返回转换后的值，如果转换失败则返回 NULL。其语法为 TRY_CAST(source_expr AS target_type)，其中 source_expr 是要转换的表达式，target_type 是目标数据类型。例如，TRY_CAST('123' AS INT) 会返回 123，而 TRY_CAST('abc' AS INT) 会返回 NULL。TRY_CAST 函数提供了一种更灵活的类型转换方式，在不需要严格保证转换成功的场景下，可以使用该函数来避免因转换失败而导致的错误。
浮点类型计算
Doris 提供了两种浮点数据类型：FLOAT 和 DOUBLE，但是在有 INF 或者 NaN 的时候由于行为不确定，导致 Order BY 或者 Group BY 时结果可能错误，在这个版本中我们规范并且明确了这个行为。
算术运算
Doris 的浮点数支持常见的加减乘除等算术运算。需要特别注意的是，Doris 在处理浮点数除以 0 的情况时，并不完全遵循 IEEE 754 标准。Doris 在这方面参考了 PostgreSQL 的实现，当除以 0 时不会生成特殊值，而是返回 SQL NULL。
比较运算
IEEE 标准定义的浮点数比较与通常的整数比较有一些重要区别。例如，负零和正零被视为相等，而任何 NaN 值与任何其他值（包括它自身）比较时都不相等。所有有限浮点数都严格小于 +∞，严格大于 -∞。
为了确保结果的一致性和可预测性，Doris 对 NaN 的处理与 IEEE 标准有所不同。 在 Doris 中，NaN 被视为大于所有其他值（包括 Infinity），NaN 等于 NaN。
日期函数
本次优化围绕日期函数与时区支持两大维度展开，进一步提升了数据处理的准确性与适用性：
统一日期溢出行为：针对众多日期函数在日期溢出场景（如日期小于 0000-01-01 或大于 9999-12-31）下的行为进行标准化修正，此前不同函数处理溢出时结果不一致的问题被解决，当前所有相关函数在触发日期溢出时均统一返回报错，避免因异常结果导致的数据计算偏差。
扩展日期函数支持范围：将部分日期类型函数的参数签名从 int32 升级为 int64。这一调整突破了原 int32 类型对日期范围的限制，使相关函数能够支持更大跨度的日期计算。
优化时区支持描述：结合 Doris 时区管理的实际逻辑，明确了 system_time_zone 与 time_zone 两大核心参数的作用、修改方式，以及时区对日期函数（如FROM_UNIXTIME、UNIX_TIMESTAMP）、数据导入转换的具体影响，为用户配置与使用时区功能提供更清晰的指引。
为构建真正 Agent-Friendly 的数据库生态，并帮助大模型更精准、深度地理解 Doris，我们对 Doris 的 SQL Reference 进行了系统性完善，具体涵盖数据类型定义、函数定义、数据变换规则等核心内容，为 AI 与数据库的协同交互奠定清晰、可靠的技术基础。这项工作得到了很多社区小伙伴的支持，他们的智慧与力量为项目注入了关键活力。我们也热切期待更多社区同仁加入进来，与我们携手共建，在技术探索与生态完善的道路上凝聚更多力量，共创更大价值。
五、性能优化
TopN 延迟物化
SELECT * FROM tableX ORDER BY columnA ASC/DESC LIMIT N 作为典型的 TopN 查询模式，广泛应用于日志分析、向量检索、数据探查等高频场景。由于此类查询未携带过滤条件，当数据规模庞大时，传统执行方式需对全表数据进行扫描并排序，这会导致大量不必要的数据读取，引发严重的读放大问题。尤其在高并发请求或大数据量存储场景中，该类查询的性能瓶颈更为显著，用户对其优化需求极为迫切。
为攻克这一痛点，我们引入了「延迟物化」优化机制，将 TopN 查询拆解为两阶段高效执行：第一阶段仅读取排序字段（columnA）与用于定位数据的主键 / 行标识，通过排序快速筛选出符合 LIMIT N 条件的目标行；第二阶段再基于行标识精准读取目标行的所有列数据。
在 v4.0 上对这个能力做出了更进一步的扩展：
支持在多表关联的时候也进行 TopN 的延迟物化
支持在外表查询时进行 TopN 的延迟物化
在这两个新的场景之中，这个方案能大幅削减非必要列的读取量，从根源上降低读放大效应，在宽表小 LIMIT 场景下 TopN 查询的执行效率有几十倍的提升。
SQL Cache 缓存
SQL Cache 是 Doris 在早期版本中提供的功能，受限于很多条件，默认处于关闭状态，在这个版本中，我们系统的梳理了可能影响 SQL Cache 结果的问题，例如 Catalog、DB、Table、Column、Row 查询权限变更，Session variables 发生变更，出现常量折叠规则不能化简的非确定函数等，为了确保 SQL Cache 结果的正确性，该功能现已默认开启。
同时我们对优化器解析 SQL 的性能做了巨大的改进提升，具体而言，SQL 解析性能提升了 100 倍。例如以下 SQL，其中 big_view 是一个包含嵌套视图的大型视图，里面有嵌套的 view，共计 163 个 join 和 17 个 union，我们将 SQL 解析的性能从 400ms 提升到了 2ms。这个优化不仅对 SQL Cache 帮助很大，在 Doris 的高并发查询场景中也有明显提升。
JSON 性能优化
JSON 是半结构化数据常见的一种存储方式，在 4.0 版本我们对 JSONB 也进行了升级。一方面，新增对 Decimal 类型的支持，完善了 JSON 中 Number 类型与 Doris 内部类型的映射体系（此前已覆盖 Int8/Int16/Int32/Int64/Int128/Float/Double 等），进一步满足高精度数值场景的存储与处理需求，避免大数值或高精度数据在 JSON 转换中因类型适配问题导致的精度损失，这有助于 Variant 类型的推导；另一方面，对 JSONB 相关的全量函数（如 json_extract 系列、json_exists_path、json_type 等）进行系统性性能优化，优化后函数执行效率普遍提升 30% 以上，显著加快了 JSON 字段提取、类型判断、路径校验等高频操作的处理速度，为半结构化数据的高效分析提供更强支撑。
六、更易用的资源管控
4.0 版本对 Workload Group 的使用机制进行了优化：统一了 CPU 与内存的软限、硬限定义方式，无需再通过各类配置项单独开启软限或硬限功能，并且同时支持在同一 Workload Group 中并存使用软限与硬限。优化后不仅简化了参数配置流程，还增强了 Workload Group 的使用灵活性，能更精准地满足多样化的资源管控需求。
MIN_CPU_PERCENT 和 MAX_CPU_PERCENT 定义了在出现 CPU 争用时，Workload Group 中所有请求的最低和最高保证 CPU 资源。
1.MAX_CPU_PERCENT（最大 CPU 百分比）是该池中 CPU 带宽的最大限制，不论当前 CPU 使用率是多少， 当前 Workload Group 的 CPU 使用率超过都不会超过 MAX_CPU_PERCENT。
2.MIN_CPU_PERCENT（最小 CPU 百分比）是为该 Workload 预留的 CPU 带宽，在存在争用时，其他池无法使用这部分带宽， 但是当资源空闲时可以使用超过 MIN_CPU_PERCENT 的带宽。
假设某公司的销售部门和市场部门共享同一个 Doris 实例。销售部门的工作负载是 CPU 密集型的，且包含高优先级查询；市场部门的工作负载同样是 CPU 密集型，但查询优先级较低。通过为每个部门创建单独的 Workload Group，可以为销售 Workload Group 分配 40% 的最小 CPU 百分比，为市场 Workload Group 分配 30% 的最大 CPU 百分比。这种配置能确保销售工作负载获得所需的 CPU 资源，同时市场工作负载不会影响销售工作负载对 CPU 的需求。
MIN_MEMORY_PERCENT 和 MAX_MEMORY_PERCENT 是 Workload Group 可以使用的最小和最大内存量。
1.MAX_MEMORY_PERCENT，意味着当请求在该池中运行时，它们占用的内存绝不会超过总内存的这一百分比，一旦超过那么 Query 将会触发落盘或者被 Kill。
2.MIN_MEMORY_PERCENT，为某个池设置最小内存值，当资源空闲时，可以使用超过 MIN_MEMORY_PERCENT 的内存，但是当内存不足时，系统将按照 MIN_MEMORY_PERCENT（最小内存百分比）分配内存，可能会选取一些 Query Kill，将 Workload Group 的内存使用量降低到 MIN_MEMORY_PERCENT，以确保其他 Workload Group 有足够的内存可用。
与落盘相结合
在这个版本中将 Workload Group 的内存管理能力与落盘功能进行融合，用户不仅可以通过为每一个 query 设置内存大小来控制落盘，还可以通过 Workload Group 的 Slot 机制来实现动态落盘，在 Workload Group 之上实现了以下策略：
1.none，默认值，表示不启用；在这种方式下，query 就尽量的使用内存，但是一旦达到 Workload Group 的上限，就会触发落盘；此时不会根据查询的大小选择。
2.fixed，每个 query 可以使用的的内存 = workload group的mem_limit * query_slot_count/ max_concurrency；这种内存分配策略实际是按照并发，给每个 query 分配固定的内存。
3.dynamic，每个 query 可以使用的的内存 = workload group的mem_limit * query_slot_count/ sum(running query slots)，该参数克服了 fixed 模式下存在的 Slot 未使用的情况；实际是把大的查询先落盘。
fixed 或者 dynamic 设置的都是 query 的硬限，一旦超过就会落盘或者 kill，并且覆盖用户设置的静态内存分配的参数。因此设置 slot_memory_policy 时，一定要注意 Workload Group 的 max_concurrency，否则会出现内存不足的问题。
最新版本：0.14
Palo 0.14.13 版本于2021年9月上旬正式发布。百度智能云 Doris 团队在维护 Apache Doris 社区的同时，也会定期发布基于 Apache Doris 官方 Release 的百度发行版本 Palo。快速迭代版本不仅包含了 Apache Doris 所有的新增功能、功能改进和 Bug 修复，同时也包含 Palo 的一些独占功能。
注意：这并不是 Apache 官方 Release 版本，但为了便于用户理解，我们沿用了社区版本的版本号格式，并且完全和社区版本兼容，以方便用户平滑升级。
升级注意事项
1. 升级步骤
0).14.12.x 版本包含了一个不兼容的 Thrift RPC 定义。如果用户是从 0.14.7(含)之前的版本升级到 0.14.12(含)之后的版本。需按照如下方式进行升级：
1). 执行 set global enable_bucket_shuffle_join =false; 全局关闭 Bucket Shuffle 功能。
2). 升级所有 BE 节点。
3). 升级所有 FE 节点。
4). 执行 set global enable_bucket_shuffle_join =true; 全局开启 Bucket Shuffle 功能。
即在升级过程中，禁止 Bucket Shuffle 功能，以避免升级过程中，BE 节点频繁宕机。
2. GCC 升级
从0.14.12版本开始，BE 端的 C++代码的编译器版本要求从 gcc7 升级为 gcc10。如需源码编译，需使用 Doris 编译镜像 v1.3 版本。如果用户在之前的版本中使用了 UDF(用户自定义函数)，这些将 UDF 不能在新版本中正常运行，请勿升级。我们将在后续迭代版本中给出解决方案。
新增功能
Doris Manager [*]
增加 Doris Manager 相关接口，可以通过 Doris Manager 组件查看和管理部分集群信息。
Routine load 相关
1. 获取例行导入作业的创建命令
支持通过 show create routine load 语句获取指定例行导入作业的创建语句。该功能方便用户在重新创建例行导入作业时，获取包含offset信息在内的完整作业创建语句。
2. 支持一次性暂停或重启所有例行导入作业
在某些情况下，用户可能需要批量暂停(Pause)或重启(Resume)所有例行导入作业。此时可以通过 pause(resume) all routine load 语句来一次性完成这个操作。
3. 支持修改 Kafka Broker List 和 Topic
可以通过 alter routine load 语句修改更多的作业属性，方便应对 Broker 信息变更等场景。
其他
1. 查看表的数据倾斜情况：支持通过 admin show data skew 命令查看表的各个数据分片大小，也确定数据是否产生倾斜。
2. 修改表和列的注释：支持通过 alter table 语句修改表或列的注释信息(Comment)。
3. 查看表的数据更新时间：支持通过 show table status 命令查看表的最近一次数据更新时间。
功能优化
1. 优化 Bloom Filter 的过滤性能，进一步提升索引的过滤效果和 Runtime Filter 的过滤性能。
2. 通过 SIMD 指令优化存储层的数据读取效率。
功能优化
1. 解决通过 apache http client 调用 Strem Load 时，可能出现的 Broken Pipe 等错误。
2. 支持在 show proc "/statistic" 中查看已损坏分片的情况，方便定位问题。
3. 优化 B E端 Compaction 的逻辑，避免在创建物化视图或表结构变更操作过程中，数据版本堆积的问题。
4. Flink-Doris-Connector 支持设置写入端 Stream Load 的提交频率和其他导入参数。
重要Bug修复
元数据相关问题
1. 修复部分情况下，在回放元数据操作日志时可能出现空指针的问题。
查询相关问题
1. 修复部分情况下，Bucket Shuffle 和 Left Semi Join(Exist) 查询结果不正确的问题。
2. 修复 Runtime Filter 处理 null 值不正确的问题。
其他
1. 修复在某些大内存机器上，BE 内存可能一直上涨，不受 mem_limit 参数限制的问题。
2. 修复在动态分区功能中，创建历史分区的若干已知问题。
3. 修复 Spark Load 中对于部分分桶列值计算错误的问题。
最新版本：2.0
Doris 2.0.0 版本已于 2023 年 8 月 11 日正式发布，有超过 275 位贡献者为 Apache Doris 提交了超过 4100 个优化与修复。在本版本中，Doris 在标准 Benchmark 数据集上盲测查询性能得到超过 10 倍的提升、在日志分析和数据湖联邦分析场景能力得到全面加强、数据更新效率和写入效率都更加高效稳定、支持了更加完善的多租户和资源隔离机制、在资源弹性与存算分离方向踏上了新的台阶、增加了一系列面向企业用户的易用性特性。在经过近半年的开发、测试与稳定性调优后，这一版本已经正式稳定可用，欢迎大家下载使用。
在 Doris 2.0 版本中引入了全新查询优化器和自适应的并行执行模型，结合存储层、执行层以及执行算子上的一系列性能优化手段，实现了盲测性能 10 倍以上的提升。以 SSB-Flat 和 TPC-H 标准测试数据集为例，在相同的集群和机器配置下，新版本宽表场景盲测较之前版本性能提升 10 倍、多表关联场景盲测提升了 13 倍，实现了巨大的性能飞跃。
1、更智能的全新查询优化器
全新查询优化器采取了更先进的 Cascades 框架、使用了更丰富的统计信息、实现了更智能化的自适应调优，在绝大多数场景无需任何调优和 SQL 改写即可实现极致的查询性能，同时对复杂 SQL 支持得更加完备、可完整支持 TPC-DS 全部 99 个 SQL。通过全新查询优化器，我们可以胜任更多真实业务场景的挑战，减少因人工调优带来的人力消耗，真正助力业务提效。
以 TPC-H 为例，全新优化器在未进行任何手工调优和 SQL 改写的情况下，绝大多数 SQL 仍领先于旧优化器手工调优后的性能表现！而在超过百家 2.0 版本提前体验用户的真实业务场景中，绝大多数原始 SQL 执行效率得以极大提升。
参考文档详见此处。
如何开启：SET enable_nereids_planner=true 在 2.0.0 版本中全新查询优化器已经默认开启
2、倒排索引支持
在 2.0 版本中对现有的索引结构进行了丰富，引入了倒排索引来应对多维度快速检索的需求，在关键字模糊查询、等值查询和范围查询等场景中均取得了显著的查询性能和并发能力提升。在此以某头部手机厂商的用户行为分析场景为例，在之前的版本中，随着并发量的上升、查询耗时逐步提升，性能下降趋势比较明显。而在 2.0.0 版本开启倒排索引后，随着并发量的提升查询性能始终保持在毫秒级。在同等查询并发量的情况下，2.0.0 版本在该用户行为分析场景中并发查询性能提升了 5-90 倍！
3、点查询并发能力提升 20 倍
在银行交易流水单号查询、保险代理人保单查询、电商历史订单查询、快递运单号查询等 Data Serving 场景，会面临大量一线业务人员及 C 端用户基于主键 ID 检索整行数据的需求，同时在用户画像、实时风控等场景中还会面对机器大规模的程序化查询，在过去此类需求往往需要引入 Apache HBase 等 KV 系统来应对点查询、Redis 作为缓存层来分担高并发带来的系统压力。
对于基于列式存储引擎构建的 Apache Doris 而言，此类的点查询在数百列宽表上将会放大随机读取 IO，并且查询优化器和执行引擎对于此类简单 SQL 的解析、分发也将带来不必要的额外开销，负责 SQL 解析的 FE 模块往往会成为限制并发的瓶颈，因此需要更高效简洁的执行方式。
在 Apache Doris 2.0.0 版本，我们引入了全新的行列混合存储以及行级 Cache，使得单次读取整行数据时效率更高、大大减少磁盘访问次数，同时引入了点查询短路径优化、跳过执行引擎并直接使用快速高效的读路径来检索所需的数据，并引入了预处理语句复用执行 SQL 解析来减少 FE 开销。
通过以上一系列优化，Apache Doris 2.0.0 版本在并发能力上实现了数量级的提升，实现了单节点 30000 QPS 的并发表现，较过去版本点查询并发能力提升超 20 倍！
基于以上能力，Apache Doris 可以更好应对高并发数据服务场景的需求，替代 HBase 在此类场景中的能力，减少复杂技术栈带来的维护成本以及数据的冗余存储。
4、自适应的并行执行模型
在实现极速分析体验的同时，为了保证多个混合分析负载的执行效率以及查询的稳定性，在 2.0.0 版本中我们引入了 Pipeline 执行模型作为查询执行引擎。在 Pipeline 执行引擎中，查询的执行是由数据来驱动控制流变化的，各个查询执行过程之中的阻塞算子被拆分成不同 Pipeline，各个 Pipeline 能否获取执行线程调度执行取决于前置数据是否就绪，实现了阻塞操作的异步化、可以更加灵活地管理系统资源，同时减少了线程频繁创建和销毁带来的开销，并提升了 Apache Doris 对于 CPU 的利用效率。因此 Apache Doris 在混合负载场景中的查询性能和稳定性都得到了全面提升。参考文档可见此处。
如何开启 Set enable_pipeline_engine = true
1.该功能在 Apache Doris 2.0.0 版本中将默认开启，BE 在进行查询执行时默认将 SQL 的执行模型转变 Pipeline 的执行方式。
2.parallel_pipeline_task_num 代表了 SQL 查询进行查询并发的 Pipeline Task 数目。Apache Doris 默认配置为 0，此时 Apache Doris 会自动感知每个 BE 的 CPU 核数并把并发度设置为 CPU 核数的一半，用户也可以实际根据自己的实际情况进行调整。
3.对于从老版本升级的用户，会自动将该参数设置成老版本中 parallel_fragment_exec_instance_num 的值。
更统一多样的分析场景
作为最初诞生于报表分析场景的 OLAP 系统，Apache Doris 在这一擅长领域中做到了极致，凭借自身优异的分析性能和极简的使用体验收获到了众多用户的认可，在诸如实时看板（Dashboard）、实时大屏、业务报表、管理驾驶舱等实时报表场景以及自助 BI 平台、用户行为分析等即席查询场景获得了极为广泛的运用。
而随着用户规模的极速扩张，越来越多用户开始希望通过 Apache Doris 来简化现有的繁重大数据技术栈，减少多套系统带来的使用及运维成本。因此 Apache Doris 也在不断拓展应用场景的边界，从过去的实时报表和 Ad-hoc 等典型 OLAP 场景到湖仓一体、ELT/ETL、日志检索与分析、高并发 Data Serving 等更多业务场景，而日志检索分析、湖仓一体也是我们在 Apache Doris 最新版本中的重要突破。
1.10倍以上性价比的日志检索分析平台
在 Apache Doris 2.0.0 版本中，我们提供了原生的半结构化数据支持，在已有的 JSON、Array 基础之上增加了复杂类型 Map，并基于 Light Schema Change 功能实现了 Schema Evolution。与此同时，2.0.0 版本新引入的倒排索引和高性能文本分析算法全面加强了 Apache Doris 在日志检索分析场景的能力，可以支持更高效的任意维度分析和全文检索。结合过去在大规模数据写入和低成本存储等方面的优势，相对于业内常见的日志分析解决方案，基于 Apache Doris 构建的新一代日志检索分析平台实现了 10 倍以上的性价比提升。
2.湖仓一体
在 Doris 1.2 版本中引入了 Multi-Catalog 功能，支持了多种异构数据源的元数据自动映射与同步，实现了便捷的元数据和数据打通。在 2.0.0 版本中进一步对数据联邦分析能力进行了加强，引入了更多数据源，并针对用户的实际生产环境做了诸多性能优化，在真实工作负载情况下查询性能得到大幅提升。
在数据源方面，Apache Doris 2.0.0 版本支持了 Hudi Copy-on-Write 表的 Snapshot Query 以及 Merge-on-Read 表的 Read Optimized Query，截止目前已经支持了 Hive、Hudi、Iceberg、Paimon、MaxCompute、Elasticsearch、Trino、ClickHouse 等数十种数据源，几乎支持了所有开放湖仓格式和 Metastore。同时还支持通过 Apache Range 对 Hive Catalog 进行鉴权，可以无缝对接用户现有的权限系统。同时还支持可扩展的鉴权插件，为任意 Catalog 实现自定义的鉴权方式。
在性能方面，利用 Doris 自身高效的分布式执行框架、向量化执行引擎以及查询优化器，结合 2.0 版本中对于小文件和宽表的读取优化、本地文件 Cache、ORC/Parquet 文件读取效率优化、弹性计算节点以及外表的统计信息收集，其在 TPC-H 场景下查询 Hive 外部表相较于 Presto/Trino 性能提升 3-5 倍。
通过这一系列优化，Apache Doris 湖仓一体的能力得到极大拓展，在如下场景可以更好发挥其优异的分析能力：
1）.湖仓查询加速：为数据湖、Elasticsearch 以及各类关系型数据库提供优秀的查询加速能力，相比 Hive、Presto、Spark 等查询引擎实现数倍的性能提升。
2）.数据导入与集成：基于可扩展的连接框架，增强 Doris 在数据集成方面的能力，让数据更便捷的被消费和处理。用户可以通过 Doris 对上游的多种数据源进行统一的增量、全量同步，并利用其的数据处理能力对数据进行加工和展示，也可以将加工后的数据写回到数据源，或提供给下游系统进行消费。
3）.统一数据分析网关：利用 Doris 构建完善可扩展的数据源连接框架，便于快速接入多类数据源。提供基于各种异构数据源的快速查询和写入能力，将其打造成统一的数据分析网关。
高效的数据更新
在实时分析场景中，数据更新是非常普遍的需求。用户不仅希望能够实时查询最新数据，也希望能够对数据进行灵活的实时更新。典型场景如电商订单分析、物流运单分析、用户画像等，需要支持数据更新类型包括整行更新、部分列更新、按条件进行批量更新或删除以及整表或者整个分区的重写（inser overwrite）。
高效的数据更新一直是大数据分析领域的痛点，离线数据仓库 Hive 通常只支持分区级别的数据更新，而 Hudi 和 Iceberg 等数据湖，虽然支持 Record 级别更新，但是通常采用 Merge-on-Read 或 Copy-on-Write 的方式，仅适合低频批量更新而不适合实时高频更新。
在 Apache Doris 1.2 版本，我们在 Unique Key 主键模型实现了 Merge-on-Write 的数据更新模式，数据在写入阶段就能完成所有的数据合并工作，因此查询性能得到 5-10 倍的提升。在 Apache Doris 2.0 版本我们进一步加强了数据更新能力，主要包括：
1）.对写入性能进行了大幅优化，高并发写入和混合负载写入场景的稳定性也显著提升。例如在单 Tablet 7GB 的重复导入测试中，数据导入的耗时从约 30 分钟缩短到了 90s，写入效率提升 20 倍；以某头部支付产品的场景压测为例，在 20 个并行写入任务下可以达到 30 万条每秒的写入吞吐，并且持续写入十几个小时后仍然表现非常稳定。
2）.支持部分列更新功能。在 2.0.0 版本之前 Apache Doris 仅支持通过 Aggregate Key 聚合模型的 Replace_if_not_null 进行部分列更新，在 2.0.0 版本中我们增加了 Unique Key 主键模型的部分列更新，在多张上游源表同时写入一张宽表时，无需由 Flink 进行多流 Join 打宽，直接写入宽表即可，减少了计算资源的消耗并大幅降低了数据处理链路的复杂性。同时在面对画像场景的实时标签列更新、订单场景的状态更新时，直接更新指定的列即可，较过去更为便捷。
3）.支持复杂条件更新和条件删除。在 2.0.0 版本之前 Unique Key 主键模型仅支持简单 Update 和 Delete 操作，在 2.0.0 版本中我们基于 Merge-on-Write 实现了复杂条件的数据更新和删除，并且执行效率更加高效。基于以上优化，Apache Doris 对于各类数据更新需求都有完备的能力支持！
更加高效稳定的数据写入
1、导入性能进一步提升
聚焦于实时分析，我们在过去的几个版本中在不断增强实时分析能力，其中端到端的数据实时写入能力是优化的重要方向，在 Apache Doris 2.0 版本中，我们进一步强化了这一能力。通过 Memtable 不使用 Skiplist、并行下刷、单副本导入等优化，使得导入性能有了大幅提升：
使用 Stream Load 对 TPC-H 144G lineitem 表原始数据进行三副本导入 48 buckets Duplicate 表，吞吐量提升 100%。
使用 Stream Load 对 TPC-H 144G lineitem 表原始数据进行三副本导入 48 buckets Unique Key 表，吞吐量提升 200%。
使用 insert into select 对 TPC-H 144G lineitem 表进行导入 48 buckets Duplicate 表，吞吐量提升 50%。
使用 insert into select 对 TPC-H 144G lineitem 表进行导入 48 buckets Unique Key 表，吞吐提升 150%。
2、数据高频写入更稳定
在高频数据写入过程中，小文件合并和写放大问题以及随之而来的磁盘 I/O 和 CPU 资源开销是制约系统稳定性的关键，因此在 2.0 版本中我们引入了 Vertical Compaction 以及 Segment Compaction，用以彻底解决 Compaction 内存问题以及写入过程中的 Segment 文件过多问题，资源消耗降低 90%，速度提升 50%，内存占用仅为原先的 10% 。详细介绍见此处。
3、数据表结构自动同步
在过去版本中引入了毫秒级别的 Schema Change，而在最新版本 Flink-Doris-Connector 中实现了从 MySQL 等关系型数据库到 Doris 的一键整库同步。在实际测试中单个同步任务可以承载数千张表的实时并行写入，从此彻底告别过去繁琐复杂的同步流程，通过简单命令即可实现上游业务数据库的表结构及数据同步。同时当上游数据结构发生变更时，也可以自动捕获 Schema 变更并将 DDL 动态同步到 Doris 中，保证业务的无缝运行。详细介绍见此处。
更加完善的多租户资源隔离
多租户与资源隔离的主要目的是为了保证高负载时避免相互发生资源抢占，Doris 在过去版本中推出了资源组（Resource Group）的硬隔离方案，通过对同一个集群内部的 BE 打上标签，标签相同的 BE 会组成一个资源组。数据入库时会按照资源组配置将数据副本写入到不同的资源组中，查询时按照资源组的划分使用对应资源组上的计算资源进行计算，例如将读、写流量放在不同的副本上从而实现读写分离，或者将在线与离线业务划分在不同的资源组、避免在离线分析任务之间的资源抢占。
资源组这一硬隔离方案可以有效避免多业务间的资源抢占，但在实际业务场景中可能会存在某些资源组紧张而某些资源组空闲的情况发生，这时需要有更加灵活的方式进行空闲资源的共享，以降低资源空置率。因此在 2.0.0 版本中我们增加了 Workload Group 资源软限制的方案，通过对 Workload 进行分组管理，以保证内存和 CPU 资源的灵活调配和管控。
通过将 Query 与 Workload Group 相关联，可以限制单个 Query 在 BE 节点上的 CPU 和内存资源的百分比，并可以配置开启资源组的内存软限制。当集群资源紧张时，将自动 Kill 组内占用内存最大的若干个查询任务以减缓集群压力。当集群资源空闲时，一旦 Workload Group 使用资源超过预设值时，多个 Workload 将共享集群可用空闲资源并自动突破阈值，继续使用系统内存以保证查询任务的稳定执行。Workload Group 还支持设置优先级，通过预先设置的优先级进行资源分配管理，来确定哪些任务可正常获得资源，哪些任务只能获取少量或没有资源。
与此同时，在 Workload Group 中还引入了查询排队的功能，在创建 Workload Group 时可以设置最大查询数，超出最大并发的查询将会进行队列中等待执行，以此来缓解高负载下系统的压力。
极致弹性与存算分离
过去 Doris 凭借在易用性方面的诸多设计帮助用户大幅节约了计算与存储资源成本，而面向未来的云原生架构已经走出了坚实的一步。从降本增效的趋势出发，用户对于计算和存储资源的需求可以概括为以下几方面：
1）.计算资源弹性：面对业务计算高峰时可以快速进行资源扩展提升效率，在计算低谷时可以快速缩容以降低成本；
2）.存储成本更低：面对海量数据可以引入更为廉价的存储介质以降低成本，同时存储与计算单独设置、相互不干预；
3）.业务负载隔离：不同的业务负载可以使用独立的计算资源，避免相互资源抢占；
4）.数据管控统一：统一 Catalog、统一管理数据，可以更加便捷地分析数据。
存算一体的架构在弹性需求不强的场景具有简单和易于维护的优势，但是在弹性需求较强的场景有一定的局限。而存算分离的架构本质是解决资源弹性的技术手段，在资源弹性方面有着更为明显的优势，但对于存储具有更高的稳定性要求，而存储的稳定性又会进一步影响到 OLAP 的稳定性以及业务的存续性，因此也引入了 Cache 管理、计算资源管理、垃圾数据回收等一系列机制。而在与 Doris 社区广大用户的交流中，我们发现用户对于存算分离的需求可以分为以下三类：
1）.目前选择简单易用的存算一体架构，暂时没有资源弹性的需求；
2）.欠缺稳定的大规模存储，要求在 Apache Doris 原有基础上提供弹性、负载隔离以及低成本；
3）.有稳定的大规模存储，要求极致弹性架构、解决资源快速伸缩的问题，因此也需要更为彻底的存算分离架构；
为了满足前两类用户的需求，Doris 2.0 版本中提供了可以兼容升级的存算分离方案：
第一种，计算节点。2.0 版本中我们引入了无状态的计算节点 Compute Node，专门用于数据湖分析。相对于原本存储计算一体的混合节点，Compute Node 不保存任何数据，在集群扩缩容时无需进行数据分片的负载均衡，因此在数据湖分析这种具有明显高峰的场景中可以灵活扩容、快速加入集群分摊计算压力。同时由于用户数据往往存储在 HDFS/S3 等远端存储中，执行查询时查询任务会优先调度到 Compute Node 执行，以避免内表与外表查询之间的计算资源抢占。参考文档详见此处。
第二种，冷热数据分层。在存储方面，冷热数据往往面临不同频次的查询和响应速度要求，因此通常可以将冷数据存储在成本更低的存储介质中。在过去版本中 Doris 支持对表分区进行生命周期管理，通过后台任务将热数据从 SSD 自动冷却到 HDD，但 HDD 上的数据是以多副本的方式存储的，并没有做到最大程度的成本节约，因此对于冷数据存储成本仍然有较大的优化空间。在 Apache Doris 2.0 版本中推出了冷热数据分层功能，冷热数据分层功能使 Doris 可以将冷数据下沉到存储成本更加低廉的对象存储中，同时冷数据在对象存储上的保存方式也从多副本变为单副本，存储成本进一步降至原先的三分之一，同时也减少了因存储附加的计算资源成本和网络开销成本。通过实际测算，存储成本最高可以降低超过 70%！参考文档可见此处。
面对更加彻底的存储计算分离需求，飞轮科技（SelectDB）技术团队设计并实现了全新的云原生存算分离架构（SelectDB Cloud），近一年来经历了大量企业客户的大规模使用，在性能、功能成熟度、系统稳定性等方面经受了真实生产环境的考验。在 Doris 2.0 版本发布之际，飞轮科技宣布将这一经过大规模打磨后的成熟架构贡献至 Apache Doris 社区。这一工作预计将于 2023 年 10 月前后完成，届时全部存算分离的代码都将会提交到 Apache Doris 社区主干分支中，预计在 2023 年 9 月广大社区用户就可以提前体验到基于存算分离架构的预览版本。
易用性进一步提升
除了以上功能需求外，在 Apache Doris 还增加了许多面向企业级特性的体验改进。
1、支持 Kubernetes 容器化部署
在过去 Doris 是基于 IP 通信的，在 K8s 环境部署时由于宿主机故障发生 Pod IP 漂移将导致集群不可用，在 2.0 版本中支持了 FQDN，使得其可以在无需人工干预的情况下实现节点自愈，因此可以更好应对 K8s 环境部署以及灵活扩缩容。
2、跨集群数据复制
在 Doris 2.0.0 版本中可以通过 CCR 的功能在库/表级别将源集群的数据变更同步到目标集群，可根据场景精细控制同步范围；用户也可以根据需求灵活选择全量或者增量同步，有效提升了数据同步的灵活性和效率；此外 Dors CCR 还支持 DDL 同步，源集群执行的 DDL 语句可以自动同步到目标集群，从而保证了数据的一致性。Doris CCR 配置和使用也非常简单，简单操作即可快速完成跨集群数据复制。基于 Doris CCR 优异的能力，可以更好实现读写负载分离以及多机房备份，并可以更好支持不同场景的跨集群复制需求。
3、其他升级注意事项
1.2-lts 需要停机升级到 2.0.0，2.0-alpha 需要停机升级到 2.0.0
查询优化器开关默认开启 enable_nereids_planner=true ；
系统中移除了非向量化代码，所以 enable_vectorized_engine 参数将不再生效；
新增参数 enable_single_replica_compaction ；
默认使用 datev2, datetimev2, decimalv3 来创建表，不支持 datev1，datetimev1， decimalv2 创建表；
在 JDBC 和 Iceberg Catalog 中默认使用 decimalv3；
date type 新增 AGG_STATE；
backend 表去掉 cluster 列；
为了与 BI 工具更好兼容，在 show create table 时，将 datev2 和 datetimev2 显示为 date 和 datetime。
在 BE 启动脚本中增加了 max_openfiles 和 swap 的检查，所以如果系统配置不合理，be 有可能会启动失败；
禁止在 localhost 访问 FE 时无密码登录；
当系统中存在 Multi-Catalog 时，查询 information schema 的数据默认只显示 internal catalog 的数据；
限制了表达式树的深度，默认为 200；
array string 返回值 单引号变双引号；
对 Doris 的进程名重命名为 DorisFE 和 DorisBE；
正式踏上 2.0 之旅
在 Doris 2.0.0 版本发布过程中，邀请了数百家企业参与新版本的打磨，力求为所有用户提供性能更佳、稳定性更高、易用性更好的数据分析体验。后续我们将会持续敏捷发版来响应所有用户对功能和稳定性的更高追求，预计 2.0 系列的第一个迭代版本 2.0.1 将于 8 月下旬发布，9 月会进一步发布 2.0.2 版本。在快速 Bugfix 的同时，也会不断将一些最新特性加入到新版本中。9 月份还将发布 2.1 版本的尝鲜版本，会增加一系列呼声已久的新能力，包括 Variant 可变数据类型更好满足半结构化数据 Schema Free 的分析需求，多表物化视图在实现查询加速的同时也能简化数据调度和处理链路，在导入性能方面持续优化、增加新的更加简洁的数据导入方式，通过自动攒批实现更加实时的数据写入，复合数据类型的嵌套能力等。
期待 Doris 2.0 版本的正式发布为更多社区用户提供实时统一的分析体验，也相信 Doris 2.0 版本会成为实时分析场景中的最理想选择。最后，Apache Doris 社区年度峰会 Doris Summit 2023 已经启程，我们期待将有更多关于 2.0 版本的最佳应用实践在 Doris Summit 2023 被所有用户所看到。
最新版本：3
v3.0.3 版本已于 2024 年 12 月上旬正式发布，该版本进一步提升了系统的性能及稳定性。
----------------
行为变更
禁止在具有同步物化视图的 MOW 表上进行列更新。
调整 RoutineLoad 的默认参数以提升导入效率。
当 StreamLoad 失败时，LoadedRows 的返回值调整为 0。
将 Segment cache 的默认内存限制调整为 5%。
----------------
新特性
引入 enable_cooldown_replica_affinity 会话变量，用以控制冷热分层副本的亲和性。
Lakehouse
新增 table$partition 语法，用于查询 Hive 表的分区信息。
支持创建 Text 格式的 Hive 表。
异步物化视图
引入新的物化视图属性 use_for_rewrite。当 use_for_rewrite 设置为 false 时，物化视图不参与透明改写。
查询优化器
支持关联非聚合子查询。
查询执行
增加了 ngram_search、 normal_cdf、 to_iso8601、 from_iso8601_date、 SESSION_USER()、 last_query_id 函数。
aes_encrypt 和 aes_decrypt 函数支持 GCM 模式。
Profile 中输出变更的会话变量值。
半结构化数据管理
新增数组函数 array_match_all 和 array_match_any。
数组函数 array_agg 支持在 ARRAY 中嵌套 ARRAY/MAP/STRUCT。
新增近似聚合统计函数 approx_top_k 和 approx_top_sum。
----------------
改进与优化
存储
支持将 bitmap_empty 作为默认值。
引入 insert_timeout 会话变量，用以控制 DELETE 语句的超时时间。
改进部分错误提示信息。
改进副本修复的优先级调度。
提高了建表时对时区处理的鲁棒性。
在创建表时检查分区表达式的合法性。
在 DELETE 操作时支持 Unicode 编码的列名。
存算分离
存算分离模式支持 ARM 架构部署。
优化文件缓存的淘汰策略和锁竞争，提高命中率及高并发点查性能。
S3 storage vault 支持 use_path_style，解决对象存储使用自定义域名的问题。
优化存算分离配置及部署，预防不同模式下的误操作。
优化可观测性，并提供删除指定 segment file cache 的接口。
优化 Meta-service 运维接口：RPC 限速及修复 tablet 元数据修正。
Lakehouse
Paimon Catalog 支持阿里云 DLF 和 OSS-HDFS 存储。 查看文档
支持读取 OpenCSV 格式的 Hive 表。
优化了访问 External Catalog 中 information_schema.columns 表的性能。
使用新的 Max Compute 开放存储 API 访问 Max Compute 数据源。
优化了 Paimon 表 JNI 部分的调度策略，使得扫描任务更加均衡。
优化了 ORC 小文件的读取性能。
支持读取 brotli 压缩格式的 parquet 文件。
在 information_schema 库下新增 file_cache_statistics 表，用于查看元数据缓存统计信息。
查询优化器
优化：当查询仅注释不同时，可以复用同一个 SQL Cache。
优化：提升了在数据频繁更新时统计信息的稳定性。
优化：提升常量折叠的稳定性。
优化：列裁剪可以生成更优的执行计划。
查询执行
优化了 sort 算子的内存使用。
优化了 ARM 下运算的性能。
优化了一系列函数的计算性能。
使用 SSE 指令优化 match_ipv6_subnet 函数的性能。
在 insert overwrite 时支持自动创建新的分区。
在 Profile 中增加了每个 PipelineTask 的状态。
IP 类型支持 runtime filter。
半结构化数据管理
审计日志中输出 prepared statement 的真实 SQL。
filebeat doris output plugin 支持容错、进度报告等。
倒排索引查询性能优化。
数组函数 array overlaps 支持使用倒排索引加速。
IP 函数 is_ip_address_in_range 支持使用倒排索引加速。
优化 VARIANT 数据类型的 CAST 性能。
优化 Variant 数据类型的 CPU 资源消耗。
优化 Variant 数据类型的元数据和执行内存资源消耗。
权限
LDAP 新增配置项 ldap_group_filter 用于自定义过滤 group。
其他
FE 监控项中的连接数信息支持按用户分别显示。
----------------
问题修复
存储
修复 IPv6 hostname 使用问题。
修复 broker/s3 load 进度展示不准确问题。
修复查询从 FE 可能卡住的问题。
修复异常情况下自增 id 重复的问题。
修复 groupcommit 偶发 NPE 问题。
修复 auto bucket 计算不准确的问题。
修复 FE 重启时流控多表不能正确规划的问题。
存算分离
修复 MOW 主键表 delete bitmap 过大可能导致 coredump 的问题。
修复 segment 文件为 5MB 整数倍时上传对象失败的问题。
修复 aws sdk 默认重试策略不生效的问题。
修复 alter storage vault 时指定错误 type 也能继续执行的问题。
修复大事务延迟提交过程中 tablet_id 可能为 0 的问题。
修复常量折叠 RCP 以及 FE 转发 SQL 可能不在预期的计算组执行的问题。
修复 meta-service 接收到 RPC 时不严格检查 instance_id 的问题。
修复 FE follower information_schema version 没有及时更新的问题。
修复 file cache rename 原子性以及指标不准确的问题。
Lakehouse
禁止带有隐式转换的谓词条件下推给 JDBC 数据源，避免不一致的查询结果。
修复 Hive 高版本事务表的一些读取问题。
修复 Export 命令可能导致死锁的问题。
修复无法查询 Spark 创建的 Hive 视图的问题。
修复 Hive 分区路径中包含特殊字符导致分区裁剪有误的问题。
修复 Iceberg Catalog 无法使用 AWS Glue 的问题。
异步物化视图
修复基表重建后，异步物化视图可能无法刷新的问题。
查询优化器
修复使用多列 range 分区时，分区裁剪结果可能有误的问题。
修复部分 limit offset 场景下计算结果错误的问题。
查询执行
修复 hash join 时 array 类型的大小超过 4G 导致 BE Core 的问题。
修复 is null 谓词运算部分场景下结果不正确的问题。
修复 bitmap 类型在 hash join 时输出结果不正确的问题。
修复一些函数结果计算错误的问题。
修复一些 JSON 类型解析的问题。
修复 varchar 和 char 类型在 runtime filter 运算时的问题。
修复一些 decimal256 在标量函数和聚合函数里使用的问题。
修复 arrow flight 在连接时报 Reach limit of connections 错误的问题。
修复 k8s 环境下，BE 可用内存统计不正确的问题。
半结构化数据管理
调整 segment_cache_fd_percentage 和 inverted_index_fd_number_limit_percent 的默认值。
logstash 支持 group_commit。
修复 build index 时 coredump 的问题。
修复 variant index 的问题。
修复后台 compaction 异常情况下可能出现的 fd 和内存泄漏。
倒排索引 match null 正确返回 null 而不是 false。
修复 ngram bloomfilter 索引 bf_size 设置为 65536 时 coredump 的问题。
修复复杂数据类型 JOIN 可能出 coredump 的问题。
修复 TVF JSON 数据 coredump 的问题。
修复 bloom filter 计算日期和时间的精度问题。
修复 IPv6 类型行存 coredump 的问题。
修复关闭 light_schema_change 时使用 VARIANT 类型 coredump 的问题。
提升高并发点查的 cache 性能。
修复删除列时 bloom filter 索引没有同步更新的问题。
修复 es catalog 在数组和标量混合数据等特殊情况下的不稳定问题。
修复异常正则匹配导致的 coredump 问题。
权限
修复若干权限授权之后无法正常限制的问题。
加强若干权限校验。
其他
补充了审计日志表和文件中缺失的审计日志字段。
最新版本：4
2025年10月下旬迎来了 Apache Doris 4.0 版本的正式发布，本次发布围绕 “AI 驱动、搜索增强、离线提效” 三大核心方向，新增向量索引、AI 函数等关键特性，完善搜索功能矩阵，优化离线计算稳定性与资源利用率，并通过多项底层改进提升查询性能与数据质量，为用户构建更高效、更灵活的企业级数据分析平台。通过 AI 与搜索能力的深度融合、离线计算的稳定性提升、性能与易用性的双重优化，进一步拓宽了数据库的应用边界，可更好地支撑企业从传统 BI 分析到 AI 智能检索、从实时查询到大规模离线批处理的全场景数据分析需求。无论是互联网、金融、零售等行业的实时报表、用户行为分析，还是政务、医疗领域的文档检索、大规模数据批处理，新版本 Doris 都将为用户提供更高效、更可靠的数据分析体验。
在 4.0 版本的研发过程中，有超过 200 名贡献者为 Apache Doris 提交了 9000+ 个优化与修复。
一、AI 能力深度集成，开启智能分析新范式
随着大模型与向量检索技术在企业级场景的加速落地与深度渗透，本次 Doris 版本迭代将重点强化 AI 原生支持能力。通过向量索引技术，高效融合企业的结构化与非结构化数据，Doris 将突破传统数据库的功能边界，直接升级为企业核心的 “AI 分析中枢”，为业务端的智能化决策与创新实践提供稳定、高效的底层数据支撑。
向量索引（Vector Index）
正式引入向量索引功能，支持对高维向量数据（如文本嵌入、图像特征等）进行高效存储与检索。结合 Doris 原生的 SQL 分析能力，用户可直接在数据库内完成 “结构化数据查询 + 向量相似性搜索” 的一体化分析，无需跨系统整合，大幅降低 AI 应用（如智能推荐、语义搜索、图像检索）的开发与部署成本。
AI Functions 函数库
让数据分析师能够直接通过简单的 SQL 语句，调用大语言模型进行文本处理。无论是提取特定重要信息、对评论进行情感分类，还是生成简短的文本摘要，现在都能在数据库内部无缝完成：
AI_CLASSIFY：在给定的标签中提取与文本内容匹配度最高的单个标签字符串。
AI_EXTRACT：根据文本内容，为每个给定标签提取相关信息。
AI_FILTER：判断文本内容是否正确，返回值为 bool 类型。
AI_FIXGRAMMAR：修复文本中的语法、拼写错误。
AI_GENERATE：基于参数内容生成内容。
AI_MASK：根据标签，将原文中的敏感信息用 [MASKED] 进行替换处理。
AI_SENTIMENT：分析文本情感倾向，返回值为 positive、negative、neutral、mixed 其中之一。
AI_SIMILARITY：判断两文本的语义相似度，返回值为 0 - 10 之间的浮点数，值越大代表语义越相似。
AI_SUMMARIZE：对文本进行高度总结概括。
AI_TRANSLATE：将文本翻译为指定语言。
AI_AGG: 对多条文本进行跨行聚合分析。
目前支持的大模型包括：OpenAI、Anthropic、Gemini、DeepSeek、Local、MoonShot、MiniMax、Zhipu、Qwen、Baichuan。例如：模拟一个简历筛选的需求，通过以下 SQL 在语义层进行筛选。
二、搜索功能全面升级，赋能全文检索
针对企业级搜索场景的多样化需求，本次版本完善搜索能力矩阵，提供更精准、更灵活的文本检索体验：
新增 Search 函数：统一入口的轻量 DSL 全文检索
核心亮点
一个函数搞定全文检索：将复杂文本检索算子收拢到 SEARCH() 统一入口，语法贴近 Elasticsearch Query String，极大降低 SQL 拼接复杂度与迁移成本。
多条件索引下推：复杂检索条件直接下推至倒排索引执行，避免 “解析一次、拼接一次” 的重复开销，显著提升性能。
DSL 语法支持简介
当前版本支持的语法功能：
词项查询（Term）：field:value
ANY / ALL 多值匹配：field:ANY(v1 v2 ...) / field:ALL(v1 v2 ...)
布尔组合：AND / OR / NOT 与括号分组
多字段搜索：在一个 search() 中对多个字段做布尔组合
后续版本会持续迭代以支持以下语法功能：短语、前缀、通配符、正则、范围、列表
文本检索打分
为了更好的支持混合检索场景，Doris4.0 版本引入业界主流的 BM25 相关性评分算法，替代传统的 TF-IDF 算法。BM25 可根据文档长度动态调整词频权重，在长文本、多字段检索场景下（如日志分析、文档检索），显著提升结果相关性与检索准确性。
倒排索引分词能力增强
Doris 在 3.1 版本初步提供了分词能力，在 4.0 版本中对分词能力进一步增强，能够满足用户在不同场景下的分词和文本检索需求。
增加三种内置分词器
ICU（International Components for Unicode）分词器
适用场景：包含复杂文字系统的国际化文本，特别适合多语言混合文档。
IK 分词器
适用场景：对分词质量要求较高的中文文本处理。
ik_smart：智能模式，词少且更长，语义集中，适合精确搜索。
ik_max_word：最细粒度模式，更多短词，覆盖更全面，适合召回搜索。
Basic 分词器
适用场景：简单场景、对性能要求极高的场景，可以作为日志场景中 unicode 分词器的平替。
新增自定义分词能力
管道化组合：通过 char filter、tokenizer 与多个 token filter 的链式配置，构建自定义文本处理流程。
组件复用：常用的 tokenizer 和 filter 可在多个 analyzer 中共享，减少重复定义，降低维护成本。
用户可以通过 Doris 提供的自定义分词机制，支持灵活组合 char filter、tokenizer 和 token filter，从而为不同字段定制合适的分词流程，满足复杂场景下的个性化文本检索需求。
三、离线计算能力强化，保障大规模任务稳定运行
当前越来越多的用户将 ETL 数据加工，多表物化视图处理等离线计算任务迁移到 Doris 上运行，针对离线批处理场景的资源消耗大、任务易溢出等痛点，4.0 新增 Spill Disk 功能，当离线计算任务的内存占用超出阈值时，自动将部分中间数据写入磁盘，避免因内存不足导致任务失败，大幅提升大规模离线任务的稳定性与容错能力。目前支持落盘的算子有：Hash Join 算子、聚合算子、排序算子、CTE 算子。
四、数据质量全链路保障，筑牢分析结果可信基石
数据正确性是企业制定决策的核心前提与关键基石。为进一步夯实这一基础，4.0 版本对大量函数的运行行为进行了系统性梳理与规范，从数据导入环节到计算分析环节构建全链路校验机制，全面保障数据处理结果的准确性与可靠性，为企业决策提供坚实的数据支撑。
注：数据质量问题的梳理会导致一些行为跟过去产生差异，升级之前请务必仔细阅读文档并提前做好环境测试。
Cast
CAST 是 SQL 中逻辑最复杂的函数之一，其核心作用是实现不同数据类型间的转换 —— 这一过程不仅需处理大量细碎的格式规则与边界场景，更因涉及类型语义的精准映射，成为实际使用中极易出错的环节。尤其在数据导入场景中，本质是将外部字符串转换为数据库内部类型的 CAST 操作，因此 CAST 的行为直接决定了导入逻辑的准确性与稳定性。同时，我们可以预见未来的数据库将大量的被 AI 来操作，而 AI 需要对数据库的行为有明确的定义，为此，我们引入了 BNF 范式，希望通过范式定义的方式，为开发者和 AI Agent 提供清晰的操作依据。
严格模式、非严格模式、TRY_CAST
在 v4.0 中，对 CAST 操作增加了严格模式、非严格模式（通过 enable_strict_cast 来控制）以及 TRY_CAST 函数，以更好地处理数据类型转换时的各种情况。具体如下：
严格模式：系统会依据预定义的 BNF（语法规则，对输入数据的格式、类型、取值范围进行严格校验：若数据不符合规则（如字段类型应为 “数值型” 却传入字符串、日期格式不符合 “YYYY-MM-DD” 规范），系统会直接终止数据处理流程并抛出明确报错（含具体不符合规则的字段与原因），杜绝不合法数据进入存储或计算环节。这种 “零容忍” 的校验逻辑，与 PostgreSQL 数据库的严格数据校验行为高度一致，能从源头保障数据质量的准确性与一致性，因此在对数据可靠性要求极高的场景中不可或缺 —— 例如金融行业的交易对账、财务领域的账单核算、政务系统的信息登记等场景，一旦出现不合法数据（如交易金额为负数、账单日期格式错误），可能引发资金损失、合规风险或业务流程混乱。
非严格模式：系统同样会依据 BNF 规则校验数据，但采用 “容错式” 处理逻辑：若数据不符合规则，不会终止流程或报错，而是自动将不合法数据转换为 NULL 值后继续执行 SQL（例如将字符串 “xyz” 转换为数值型 NULL），确保 SQL 任务能正常完成，优先保障业务流程的连续性与执行效率。这种模式更适用于对 “数据完整性要求较低、但对 SQL 执行成功率要求高” 的场景 —— 例如日志数据处理、用户行为数据清洗、临时数据分析等场景，此类场景中数据量庞大且来源复杂（如 APP 日志可能因设备异常产生格式错乱字段），若因少量不合法数据中断整个 SQL 任务，会大幅降低处理效率，且少量 NULL 值对整体分析结果（如统计活跃用户数、点击量）影响极小。
enable_strict_cast 是在一个语句级别控制 cast 的行为的方式，但是可能会出现，在一个 SQL 中有多个 cast 函数，有一部分函数用户希望用严格模式，另外一部分函数使用非严格模式，所以我们引入了 TRY_CAST 函数。
TRY_CAST 函数的作用是将一个表达式转换为指定的数据类型，如果转换成功则返回转换后的值，如果转换失败则返回 NULL。其语法为 TRY_CAST(source_expr AS target_type)，其中 source_expr 是要转换的表达式，target_type 是目标数据类型。例如，TRY_CAST('123' AS INT) 会返回 123，而 TRY_CAST('abc' AS INT) 会返回 NULL。TRY_CAST 函数提供了一种更灵活的类型转换方式，在不需要严格保证转换成功的场景下，可以使用该函数来避免因转换失败而导致的错误。
浮点类型计算
Doris 提供了两种浮点数据类型：FLOAT 和 DOUBLE，但是在有 INF 或者 NaN 的时候由于行为不确定，导致 Order BY 或者 Group BY 时结果可能错误，在这个版本中我们规范并且明确了这个行为。
算术运算
Doris 的浮点数支持常见的加减乘除等算术运算。需要特别注意的是，Doris 在处理浮点数除以 0 的情况时，并不完全遵循 IEEE 754 标准。Doris 在这方面参考了 PostgreSQL 的实现，当除以 0 时不会生成特殊值，而是返回 SQL NULL。
比较运算
IEEE 标准定义的浮点数比较与通常的整数比较有一些重要区别。例如，负零和正零被视为相等，而任何 NaN 值与任何其他值（包括它自身）比较时都不相等。所有有限浮点数都严格小于 +∞，严格大于 -∞。
为了确保结果的一致性和可预测性，Doris 对 NaN 的处理与 IEEE 标准有所不同。 在 Doris 中，NaN 被视为大于所有其他值（包括 Infinity），NaN 等于 NaN。
日期函数
本次优化围绕日期函数与时区支持两大维度展开，进一步提升了数据处理的准确性与适用性：
统一日期溢出行为：针对众多日期函数在日期溢出场景（如日期小于 0000-01-01 或大于 9999-12-31）下的行为进行标准化修正，此前不同函数处理溢出时结果不一致的问题被解决，当前所有相关函数在触发日期溢出时均统一返回报错，避免因异常结果导致的数据计算偏差。
扩展日期函数支持范围：将部分日期类型函数的参数签名从 int32 升级为 int64。这一调整突破了原 int32 类型对日期范围的限制，使相关函数能够支持更大跨度的日期计算。
优化时区支持描述：结合 Doris 时区管理的实际逻辑，明确了 system_time_zone 与 time_zone 两大核心参数的作用、修改方式，以及时区对日期函数（如FROM_UNIXTIME、UNIX_TIMESTAMP）、数据导入转换的具体影响，为用户配置与使用时区功能提供更清晰的指引。
为构建真正 Agent-Friendly 的数据库生态，并帮助大模型更精准、深度地理解 Doris，我们对 Doris 的 SQL Reference 进行了系统性完善，具体涵盖数据类型定义、函数定义、数据变换规则等核心内容，为 AI 与数据库的协同交互奠定清晰、可靠的技术基础。这项工作得到了很多社区小伙伴的支持，他们的智慧与力量为项目注入了关键活力。我们也热切期待更多社区同仁加入进来，与我们携手共建，在技术探索与生态完善的道路上凝聚更多力量，共创更大价值。
五、性能优化
TopN 延迟物化
SELECT * FROM tableX ORDER BY columnA ASC/DESC LIMIT N 作为典型的 TopN 查询模式，广泛应用于日志分析、向量检索、数据探查等高频场景。由于此类查询未携带过滤条件，当数据规模庞大时，传统执行方式需对全表数据进行扫描并排序，这会导致大量不必要的数据读取，引发严重的读放大问题。尤其在高并发请求或大数据量存储场景中，该类查询的性能瓶颈更为显著，用户对其优化需求极为迫切。
为攻克这一痛点，我们引入了「延迟物化」优化机制，将 TopN 查询拆解为两阶段高效执行：第一阶段仅读取排序字段（columnA）与用于定位数据的主键 / 行标识，通过排序快速筛选出符合 LIMIT N 条件的目标行；第二阶段再基于行标识精准读取目标行的所有列数据。
在 v4.0 上对这个能力做出了更进一步的扩展：
支持在多表关联的时候也进行 TopN 的延迟物化
支持在外表查询时进行 TopN 的延迟物化
在这两个新的场景之中，这个方案能大幅削减非必要列的读取量，从根源上降低读放大效应，在宽表小 LIMIT 场景下 TopN 查询的执行效率有几十倍的提升。
SQL Cache 缓存
SQL Cache 是 Doris 在早期版本中提供的功能，受限于很多条件，默认处于关闭状态，在这个版本中，我们系统的梳理了可能影响 SQL Cache 结果的问题，例如 Catalog、DB、Table、Column、Row 查询权限变更，Session variables 发生变更，出现常量折叠规则不能化简的非确定函数等，为了确保 SQL Cache 结果的正确性，该功能现已默认开启。
同时我们对优化器解析 SQL 的性能做了巨大的改进提升，具体而言，SQL 解析性能提升了 100 倍。例如以下 SQL，其中 big_view 是一个包含嵌套视图的大型视图，里面有嵌套的 view，共计 163 个 join 和 17 个 union，我们将 SQL 解析的性能从 400ms 提升到了 2ms。这个优化不仅对 SQL Cache 帮助很大，在 Doris 的高并发查询场景中也有明显提升。
JSON 性能优化
JSON 是半结构化数据常见的一种存储方式，在 4.0 版本我们对 JSONB 也进行了升级。一方面，新增对 Decimal 类型的支持，完善了 JSON 中 Number 类型与 Doris 内部类型的映射体系（此前已覆盖 Int8/Int16/Int32/Int64/Int128/Float/Double 等），进一步满足高精度数值场景的存储与处理需求，避免大数值或高精度数据在 JSON 转换中因类型适配问题导致的精度损失，这有助于 Variant 类型的推导；另一方面，对 JSONB 相关的全量函数（如 json_extract 系列、json_exists_path、json_type 等）进行系统性性能优化，优化后函数执行效率普遍提升 30% 以上，显著加快了 JSON 字段提取、类型判断、路径校验等高频操作的处理速度，为半结构化数据的高效分析提供更强支撑。
六、更易用的资源管控
4.0 版本对 Workload Group 的使用机制进行了优化：统一了 CPU 与内存的软限、硬限定义方式，无需再通过各类配置项单独开启软限或硬限功能，并且同时支持在同一 Workload Group 中并存使用软限与硬限。优化后不仅简化了参数配置流程，还增强了 Workload Group 的使用灵活性，能更精准地满足多样化的资源管控需求。
MIN_CPU_PERCENT 和 MAX_CPU_PERCENT 定义了在出现 CPU 争用时，Workload Group 中所有请求的最低和最高保证 CPU 资源。
1.MAX_CPU_PERCENT（最大 CPU 百分比）是该池中 CPU 带宽的最大限制，不论当前 CPU 使用率是多少， 当前 Workload Group 的 CPU 使用率超过都不会超过 MAX_CPU_PERCENT。
2.MIN_CPU_PERCENT（最小 CPU 百分比）是为该 Workload 预留的 CPU 带宽，在存在争用时，其他池无法使用这部分带宽， 但是当资源空闲时可以使用超过 MIN_CPU_PERCENT 的带宽。
假设某公司的销售部门和市场部门共享同一个 Doris 实例。销售部门的工作负载是 CPU 密集型的，且包含高优先级查询；市场部门的工作负载同样是 CPU 密集型，但查询优先级较低。通过为每个部门创建单独的 Workload Group，可以为销售 Workload Group 分配 40% 的最小 CPU 百分比，为市场 Workload Group 分配 30% 的最大 CPU 百分比。这种配置能确保销售工作负载获得所需的 CPU 资源，同时市场工作负载不会影响销售工作负载对 CPU 的需求。
MIN_MEMORY_PERCENT 和 MAX_MEMORY_PERCENT 是 Workload Group 可以使用的最小和最大内存量。
1.MAX_MEMORY_PERCENT，意味着当请求在该池中运行时，它们占用的内存绝不会超过总内存的这一百分比，一旦超过那么 Query 将会触发落盘或者被 Kill。
2.MIN_MEMORY_PERCENT，为某个池设置最小内存值，当资源空闲时，可以使用超过 MIN_MEMORY_PERCENT 的内存，但是当内存不足时，系统将按照 MIN_MEMORY_PERCENT（最小内存百分比）分配内存，可能会选取一些 Query Kill，将 Workload Group 的内存使用量降低到 MIN_MEMORY_PERCENT，以确保其他 Workload Group 有足够的内存可用。
与落盘相结合
在这个版本中将 Workload Group 的内存管理能力与落盘功能进行融合，用户不仅可以通过为每一个 query 设置内存大小来控制落盘，还可以通过 Workload Group 的 Slot 机制来实现动态落盘，在 Workload Group 之上实现了以下策略：
1.none，默认值，表示不启用；在这种方式下，query 就尽量的使用内存，但是一旦达到 Workload Group 的上限，就会触发落盘；此时不会根据查询的大小选择。
2.fixed，每个 query 可以使用的的内存 = workload group的mem_limit * query_slot_count/ max_concurrency；这种内存分配策略实际是按照并发，给每个 query 分配固定的内存。
3.dynamic，每个 query 可以使用的的内存 = workload group的mem_limit * query_slot_count/ sum(running query slots)，该参数克服了 fixed 模式下存在的 Slot 未使用的情况；实际是把大的查询先落盘。
fixed 或者 dynamic 设置的都是 query 的硬限，一旦超过就会落盘或者 kill，并且覆盖用户设置的静态内存分配的参数。因此设置 slot_memory_policy 时，一定要注意 Workload Group 的 max_concurrency，否则会出现内存不足的问题。