关于后端:Apache-Doris-20beta-版本发布盲测性能-10-倍提升更统一的多场景极速分析体验

敬爱的社区小伙伴们，咱们很快乐地向大家发表，Apache Doris 2.0-beta 版本已于 2023 年 7 月 3 日正式公布！在 2.0-beta 版本中有超过 255 位贡献者为 Apache Doris 提交了超过 3500 个优化与修复，欢送大家下载应用！

下载链接：https://doris.apache.org/download

GitHub 源码：https://github.com/apache/doris/tree/branch-2.0

在今年年初举办的 Doris Summit 年度峰会上，咱们曾公布了 Apache Doris 的 2023 年 Roadmap 并提出了新的愿景：

咱们心愿用户能够基于 Apache Doris 构建多种不同场景的数据分析服务、同时撑持在线与离线的业务负载、高吞吐的交互式剖析与高并发的点查问；通过一套架构实现湖和仓的对立、在数据湖和多种异构存储之上提供无缝且极速的剖析服务；也可通过对日志 / 文本等半结构化乃至非结构化的多模数据进行对立治理和剖析、来满足更多样化数据分析的需要。

这是咱们心愿 Apache Doris 可能带给用户的价值，不再让用户在多套零碎之间衡量，仅通过一个零碎解决绝大部分问题，升高简单技术栈带来的开发、运维和应用老本，最大化晋升生产力。

面对海量数据的实时剖析难题，这一愿景的实现无疑须要克服许多艰难，尤其是在应答理论业务场景的实在诉求中更是遭逢了许多挑战：

• 如何保障上游数据实时高频写入的同时保障用户的查问稳固；
• 如何在上游数据更新及表构造变更的同时保障在线服务的连续性；
• 如何实现结构化与半结构化数据的对立存储与高效剖析；
• 如何同时应答点查问、报表剖析、即席查问、ETL/ELT 等不同的查问负载且保障负载间互相隔离？
• 如何保障简单 SQL 语句执行的高效性、大查问的稳定性以及执行过程的可观测性？
• 如何更便捷地集成与拜访数据湖以及各种异构数据源？
• 如何在大幅升高数据存储和计算资源老本的同时兼顾高性能查问？
• ……

秉持着“将易用性留给用户、将复杂性留给本人”的准则，为了克服以上一系列挑战，从实践根底到工程实现、从现实业务场景到极其异样 Case、从内部测试通过到大规模生产可用，咱们消耗了更多的工夫与精力在性能的开发、验证、继续迭代与精益求精上。值得庆贺的是，在通过近半年的开发、测试与稳定性调优后，Apache Doris 终于迎来了 2.0-beta 版本的正式公布！而这一版本的胜利公布也使得咱们的愿景离事实更进一步！

盲测性能 10 倍以上晋升！

全新的查问优化器

高性能是 Apache Doris 一直谋求的指标。过来一年在 Clickbench、TPC-H 等公开测试数据集上的优异体现，曾经证实了其在执行层以及算子优化方面做到了业界当先，但从 Benchmark 到实在业务场景之间还存在肯定间隔：

• Benchmark 更多是实在业务场景的形象、提炼与简化，而事实场景往往可能面临更简单的查问语句，这是测试所无奈笼罩的；
• Benchmark 查问语句可枚举、可针对性进行调优，而实在业务场景的调优极度依赖工程师的心智老本、调优效率往往较为低下且过于耗费工程师人力；

基于此，咱们着手研发了古代架构的全新查问优化器，并在 Apache Doris 2.0-beta 版本全面启用。全新查问优化器采取了更先进的 Cascades 框架、应用了更丰盛的统计信息、实现了更智能化的自适应调优，在绝大多数场景无需任何调优和 SQL 改写即可实现极致的查问性能，同时对简单 SQL 反对得更加齐备、可残缺反对 TPC-DS 全副 99 个 SQL。

咱们对全新查问优化器的执行性能进行了盲测，仅以 TPC-H 22 个 SQL 为例，全新优化器在未进行任何手工调优和 SQL 改写的状况下 查问耗时，盲测性能晋升了超过 10 倍！而在数十个 2.0 版本用户的实在业务场景中，绝大多数原始 SQL 执行效率得以极大晋升，真正解决了人工调优的痛点！

参考文档：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/ne…

如何开启：SET enable_nereids_planner=true 在 Apache Doris 2.0-beta 版本中全新查问优化器曾经默认开启，通过调用 Analyze 命令收集统计信息。

自适应的 Pipeline 执行引擎

过来 Apache Doris 的执行引擎是基于传统的火山模型构建，为了更好利用多机多核的并发能力，过来咱们须要手动设置执行并发度（例如将 parallel_fragment_exec_instance_num 这一参数从默认值 1 手工设置为 8 或者 16），在存在大量查问工作时存在一系列问题：

• 大查问、小查问须要设置不同的 instance 并发度，零碎不能做到自适应调整；
• Instance 算子占用线程阻塞执行，大量查问工作将导致执行线程池被占满、无奈响应后续申请，甚至呈现逻辑死锁；
• Instance 线程间的调度依赖于系统调度机制，线程进行重复切换将产生额定的性能开销；
• 在不同剖析负载并存时，Instance 线程间可能呈现 CPU 资源争抢的状况，可能导致大小查问、不同租户之间互相受影响；

针对以上问题，Apache Doris 2.0 引入了 Pipeline 执行模型作为查问执行引擎。在 Pipeline 执行引擎中，查问的执行是由数据来驱动控制流变动的， 各个查问执行过程之中的阻塞算子被拆分成不同 Pipeline，各个 Pipeline 是否获取执行线程调度执行取决于前置数据是否就绪，因而实现了以下成果：

• Pipeline 执行模型通过阻塞逻辑将执行打算拆解成 Pipeline Task，将 Pipeline Task 分时调度到线程池中，实现了阻塞操作的异步化，解决了 Instance 长期占用繁多线程的问题。
• 能够采纳不同的调度策略，实现 CPU 资源在大小查问间、不同租户间的调配，从而更加灵便地管理系统资源。
• Pipeline 执行模型还采纳了数据池化技术，将单个数据分桶中的数据进行池化，从而解除分桶数对 Instance 数量的限度，进步 Apache Doris 对多核零碎的利用能力，同时防止了线程频繁创立和销毁的问题。

通过 Pipeline 执行引擎，Apache Doris 在混合负载场景中的查问性能和稳定性都得以进一步晋升。

参考文档：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/pi…

如何开启：Set enable_pipeline_engine = true该性能在 Apache Doris 2.0 版本中将默认开启，BE 在进行查问执行时默认将 SQL 的执行模型转变 Pipeline 的执行形式。parallel_pipeline_task_num代表了 SQL 查问进行查问并发的 Pipeline Task 数目。Apache Doris 默认配置为 0，此时 Apache Doris 会主动感知每个 BE 的 CPU 核数并把并发度设置为 CPU 核数的一半，用户也能够理论依据本人的理论状况进行调整。 对于从老版本升级的用户，倡议用户将该参数设置成老版本中 parallel_fragment_exec_instance_num 的值。

查问稳定性进一步晋升

多业务资源隔离

随着用户规模的极速扩张，越来越多的用户将 Apache Doris 用于构建企业外部的对立剖析平台。这一方面须要 Apache Doris 去承当更大规模的数据处理和剖析，另一方面也须要 Apache Doris 同时去应答更多剖析负载的挑战，而其中的关键在于如何保障不同负载可能在一个零碎中稳固运行。

Apache Doris 2.0 版本中基于 Pipeline 执行引擎减少了 Workload 管理器，通过对 Workload 进行分组治理，以保障内存和 CPU 资源的精细化管控。

在过来版本中 Apache Doris 通过资源标签的形式进行了多租户资源隔离，能够通过节点资源划分来防止不同业务间的互相烦扰，而 Workload Group 实现了更精细化的资源管控形式，通过将 Query 与 Workload Group 相关联，能够限度单个 Query 在 BE 节点上的 CPU 和内存资源的百分比，并能够配置开启资源组的内存软限度。当集群资源缓和时，将主动 Kill 组内占用内存最大的若干个查问工作以减缓集群压力。当集群资源闲暇时，一旦 Workload Group 应用资源超过预设值时，多个 Workload 将共享集群可用闲暇资源并主动冲破阙值，持续应用零碎内存以保障查问工作的稳固执行。

create workload group if not exists etl_group
properties (
  "cpu_share"="10",
  "memory_limit"="30%",
  "max_concurrency" = "10",
  "max_queue_size" = "20",
  "queue_timeout" = "3000"
);

能够通过 Show 命令来查看创立的 Workload Group，例如：

作业排队

同时在 Workload Group 中咱们还引入了查问排队的性能，在创立 Workload Group 时能够设置最大查问数，超出最大并发的查问将会进行队列中期待执行。

• max_concurrency 以后 Group 容许的最大查问数，超过最大并发的查问到来时会进入排队逻辑；
• max_queue_size查问排队的长度，当队列满了之后，新来的查问会被回绝；
• queue_timeout查问在队列中期待的工夫，如果查问等待时间超过等待时间查问将会被回绝，工夫单位为毫秒；

参考文档：https://doris.apache.org/zh-CN/docs/dev/admin-manual/workload…

彻底辞别 OOM

在内存短缺时内存治理通常对用户是无感的，但实在场景中往往面临着各式各样的极其 Case，这些都将为内存性能和稳定性带来挑战，尤其是在面临内存资源耗费微小的简单计算和大规模作业时，因为内存 OOM 导致查问失败甚至可能造成 BE 过程宕机。

因而咱们逐步对立内存数据结构、重构 MemTracker、开始反对查问内存软限，并引入过程内存超限后的 GC 机制，同时优化了高并发的查问性能等。在 2.0 版本中咱们引入了全新的内存治理框架，通过无效的内存调配、统计、管控，在 Benchmark、压力测试和实在用户业务场景的反馈中，根本打消了内存热点以及 OOM 导致 BE 宕机的问题，即便产生 OOM 通常也可根据日志定位内存地位并针对性调优，从而让集群复原稳固，对查问和导入的内存限度也更加灵便，在内存短缺时让用户无需感知内存应用。

通过以上一系列优化，Apache Doris 2.0 版本在应答简单计算以及大规模 ETL/ELT 操作时，内存资源得以无效管制，零碎稳定性体现更上一个台阶。

具体介绍：https://mp.weixin.qq.com/s/Z5N-uZrFE3Qhn5zTyEDomQ

高效稳固的数据写入

更高的实时数据写入效率

导入性能进一步晋升

聚焦于实时剖析，咱们在过来的几个版本中在一直加强实时剖析能力，其中端到端的数据实时写入能力是优化的重要方向，在 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%。

数据高频写入更稳固

在高频数据写入过程中，小文件合并和写放大问题以及随之而来的磁盘 I/ O 和 CPU 资源开销是制约零碎稳定性的要害，因而在 2.0 版本中咱们引入了 Vertical Compaction 以及 Segment Compaction，用以彻底解决 Compaction 内存问题以及写入过程中的 Segment 文件过多问题，资源耗费升高 90%，速度晋升 50%，内存占用仅为原先的 10%。

具体介绍：https://mp.weixin.qq.com/s/BqiMXRJ2sh4jxKdJyEgM4A

数据表构造主动同步

在过来版本中咱们引入了毫秒级别的 Schema Change，而在最新版本 Flink-Doris-Connector 中，咱们实现了从 MySQL 等关系型数据库到 Apache Doris 的一键整库同步。在理论测试中单个同步工作能够承载数千张表的实时并行写入，从此彻底辞别过来繁琐简单的同步流程，通过简略命令即可实现上游业务数据库的表构造及数据同步。同时当上游数据结构产生变更时，也能够主动捕捉 Schema 变更并将 DDL 动静同步到 Doris 中，保障业务的无缝运行。

具体介绍：https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw

主键模型反对局部列更新

在 Apache Doris 1.2 版本中咱们引入了 Unique Key 模型的 Merg-on-Write 写时合并模式，在上游数据高频写入和更新的同时能够保障上游业务的高效稳固查问，实现了 实时写入和极速查问的对立。 而 2.0 版本咱们对 Unique Key 模型进行了全面加强。在性能上，反对了新的局部列更新能力，在上游多个源表同时写入时无需提前解决成宽表，间接通过局部列更新在写时实现 Join，大幅简化了宽表的写入流程。

在性能上，2.0 版本大幅加强了 Unique Key 模型 Merge-on-Write 的大数据量写入性能和并发写入能力，大数据量导入较 1.2 版本有超过 50% 的性能晋升，高并发导入有超过 10 倍的性能晋升，并通过高效的并发解决机制来彻底解决了 publish timeout(Error -3115) 问题，同时因为 Doris 2.0 高效的 Compaction 机制，也不会呈现 too many versions (Error-235) 问题。这使得 Merge-on-Write 可能在更宽泛的场景下代替 Merge-on-Read 实现，同时咱们还利用局部列更新能力来升高 UPDATE 语句和 DELETE 语句的计算成本，整体性能晋升约 50%。

局部列更新的应用示例（Stream Load）：

例如有表构造如下

mysql> desc user_profile;
+------------------+-----------------+------+-------+---------+-------+
| Field           | Type           | Null | Key   | Default | Extra |
+------------------+-----------------+------+-------+---------+-------+
| id               | INT             | Yes | true | NULL   |       |
| name             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| age             | INT             | Yes | false | NULL   | NONE |
| city             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| balance         | DECIMALV3(9, 0) | Yes | false | NULL   | NONE |
| last_access_time | DATETIME       | Yes | false | NULL   | NONE |
+------------------+-----------------+------+-------+---------+-------+

用户心愿批量更新最近 10s 发生变化的用户的余额和拜访工夫，能够把数据组织在如下 csv 文件中

1,500,2023-07-03 12:00:01
3,23,2023-07-03 12:00:02
18,9999999,2023-07-03 12:00:03

而后通过 Stream Load，减少 Header partial_columns:true，并指定要导入的列名即可实现更新

curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H 
"columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

极致弹性与存算拆散

过来 Apache Doris 凭借在易用性方面的诸多设计帮忙用户大幅节约了计算与存储资源老本，而面向未来的云原生架构，咱们曾经走出了松软的一步。

从降本增效的趋势登程，用户对于计算和存储资源的需要能够概括为以下几方面：

• 计算资源弹性：面对业务计算顶峰时能够疾速进行资源扩大晋升效率，在计算低谷时能够疾速缩容以降低成本；
• 存储老本更低：面对海量数据能够引入更为便宜的存储介质以降低成本，同时存储与计算独自设置、互相不干涉；
• 业务负载隔离：不同的业务负载能够应用独立的计算资源，防止互相资源抢占；
• 数据管控对立：对立 Catalog、对立治理数据，能够更加便捷地剖析数据。

存算一体的架构在弹性需要不强的场景具备简略和易于保护的劣势，然而在弹性需要较强的场景有肯定的局限。而存算拆散的架构实质是解决资源弹性的技术手段，在资源弹性方面有着更为显著的劣势，但对于存储具备更高的稳定性要求，而存储的稳定性又会进一步影响到 OLAP 的稳定性以及业务的存续性，因而也引入了 Cache 治理、计算资源管理、垃圾数据回收等一系列机制。

而在与 Apache Doris 社区宽广用户的交换中，咱们发现用户对于存算拆散的需要能够分为以下三类：

• 目前抉择简略易用的存算一体架构，临时没有资源弹性的需要；
• 欠缺稳固的大规模存储，要求在 Apache Doris 原有根底上提供弹性、负载隔离以及低成本；
• 有稳固的大规模存储，要求极致弹性架构、解决资源疾速伸缩的问题，因而也须要更为彻底的存算拆散架构；

为了满足前两类用户的需要，Apache Doris 2.0 版本中提供了能够兼容降级的存算拆散计划：

第一种，计算节点。2.0 版本中咱们引入了无状态的计算节点 Compute Node，专门用于数据湖剖析。绝对于本来存储计算一体的混合节点，Compute Node 不保留任何数据，在集群扩缩容时无需进行数据分片的负载平衡，因而在数据湖剖析这种具备显著顶峰的场景中能够灵便扩容、疾速退出集群摊派计算压力。同时因为用户数据往往存储在 HDFS/S3 等远端存储中，执行查问时查问工作会优先调度到 Compute Node 执行，以防止内表与表面查问之间的计算资源抢占。

参考文档：https://doris.apache.org/zh-CN/docs/dev/advanced/compute_node

第二种，冷热分层。在存储方面，冷热数据数据往往面临不同频次的查问和响应速度要求，因而通常能够将冷数据存储在老本更低的存储介质中。在过来版本中 Apache Doris 反对对表分区进行生命周期治理，通过后台任务将热数据从 SSD 主动冷却到 HDD，但 HDD 上的数据是以多正本的形式存储的，并没有做到最大水平的老本节约，因而对于冷数据存储老本依然有较大的优化空间。在 Apache Doris 2.0 版本中推出了冷热数据分层性能，冷热数据分层性能使 Apache Doris 能够将冷数据下沉到存储老本更加低廉的对象存储中，同时冷数据在对象存储上的保留形式也从多正本变为单正本，存储老本进一步降至原先的三分之一，同时也缩小了因存储附加的计算资源老本和网络开销老本。通过理论测算，存储老本最高能够升高超过 70%！

参考文档：https://doris.apache.org/zh-CN/docs/dev/advanced/cold_hot_sep…

后续计算节点会反对查问冷数据和存储节点的数据，从而实现能兼容降级的存算拆散计划。

而为了满足第三类用户的需要，咱们还将把 SelectDB Cloud 存算拆散计划奉献回社区。这一计划在性能、性能成熟度、零碎稳定性等方面经验了上百家企业生产环境的考验，后续性能合入的理论停顿咱们也将及时同步。

10 倍以上性价比的日志剖析计划

从过来的实时报表和 Ad-hoc 等典型 OLAP 场景到 ELT/ETL、日志检索与剖析等更多业务场景，Apache Doris 正在一直拓展利用场景的边界，而日志数据的对立存储与剖析正是咱们在 2.0 版本的重要冲破。

过来业界典型的日志存储剖析架构难以同时兼顾 高吞吐实时写入、低成本大规模存储与高性能文本检索剖析，只能在某一方面或某几方面做衡量取舍。而在 Apache Doris 2.0 版本中，咱们引入了全新倒排索引、以满足字符串类型的全文检索和一般数值 / 日期等类型的等值、范畴检索，同时进一步优化倒排索引的查问性能、使其更加符合日志数据分析的场景需要，同时联合过来在大规模数据写入和低成本存储等方面的劣势，实现了更高性价比的日志剖析计划。

在雷同硬件配置和数据集的测试体现上，Apache Doris 绝对于 ElasticSearch 实现了日志数据写入速度晋升 4 倍、存储空间升高 80%、查问性能晋升 2 倍，再联合 Apache Doris 2.0 版本引入的冷热数据分层个性，整体性价比晋升 10 倍以上。

除了日志剖析场景的优化以外，在简单数据类型方面，咱们减少了全新的数据类型 Map/Struct，包含反对以上类型的高效写入、存储、剖析函数以及类型之间的互相嵌套，以更好满足多模态数据分析的反对。

具体介绍：https://mp.weixin.qq.com/s/WJXKyudW8CJPqlUiAro_KQ

更全面、更高性能的数据湖剖析能力

在 Apache Doris 1.2 版本中，咱们公布了 Multi-Catalog 性能，反对了多种异构数据源的元数据主动映射与同步，实现了数据湖的无缝对接。依赖 数据读取、执行引擎、查问优化器方面的诸多优化，在规范测试集场景下，Apache Doris 在湖上数据的查问性能，较 Presto/Trino 有 3-5 倍的晋升。

在 2.0 版本中，咱们进一步对数据湖剖析能力进行了增强，岂但反对了更多的数据源，同时针对用户的理论生产环境做了诸多优化，相较于 1.2 版本，可能在实在工作负载状况下显著晋升性能。

更多数据源反对

• 反对 Hudi Copy-on-Write 表的 Snapshot Query 以及 Merge-on-Read 表的 Read Optimized Query，后续将反对 Incremental Query 和 Time Trival。参考文档：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catal…
• JDBC Catalog 新增反对 Oceanbase，目前反对包含 MySQL、PostgreSQL、Oracle、SQLServer、Doris、Clickhouse、SAP HANA、Trino/Presto、Oceanbase 等近十种关系型数据库。参考文档：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catal…

数据权限管控

• 反对通过 Apache Range 对 Hive Catalog 进行鉴权，能够无缝对接用户现有的权限零碎。同时还反对可扩大的鉴权插件，为任意 Catalog 实现自定义的鉴权形式。参考文档：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catal…

性能进一步优化，最高晋升数十倍

• 优化了大量小文件场景以及宽表场景的读取性能。通过小文件全量加载、小 IO 合并、数据预读等技术，显著升高远端存储的读取开销，在此类场景下，查问性能最高晋升数十倍。
• 优化了 ORC/Parquet 文件的读取性能，相较于 1.2 版本查问性能晋升一倍。

• 反对湖上数据的本地文件缓存。能够利用本地磁盘缓存 HDFS 或对象存储等远端存储系统上的数据，通过缓存减速拜访雷同数据的查问。在命中本地文件缓存的状况下，通过 Apache Doris 查问湖上数据的性能可与 Apache Doris 外部表持平，该性能能够极大晋升湖上热数据的查问性能。参考文档：https://doris.apache.org/zh-CN/docs/dev/lakehouse/filecache
• 反对表面的统计信息收集。和 Apache Doris 内表一样，用户能够通过 Analyze 语句剖析并收集指定表面的统计信息，联合 Nereids 全新查问优化器，可能更精确更智能地对简单 SQL 进行查问打算的调优。以 TPC-H 规范测试数据集为例，无需手动改写 SQL 即可取得最优的查问打算并取得更好的性能体现。参考文档：https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/
• 优化了 JDBC Catalog 的数据写回性能。通过 PrepareStmt 和批量形式，用户通过 INSERT INTO 命令、通过 JDBC Catalog 将数据写回到 MySQL、Oracle 等关系型数据库的性能晋升数十倍。

高并发数据服务反对

与简单 SQL 和大规模 ETL 作业不同，在诸如银行交易流水单号查问、保险代理人保单查问、电商历史订单查问、快递运单号查问等 Data Serving 场景，会面临大量一线业务人员及 C 端用户基于主键 ID 检索整行数据的需要，在过来此类需要往往须要引入 Apache HBase 等 KV 零碎来应答点查问、Redis 作为缓存层来分担高并发带来的零碎压力。

对于基于列式存储引擎构建的 Apache Doris 而言，此类的点查问在数百列宽表上将会放大随机读取 IO，并且执行引擎对于此类简略 SQL 的解析、散发也将带来不必要的额定开销，往往须要更高效简洁的执行形式。因而在新版本中咱们引入了全新的行列混合存储以及行级 Cache，使得单次读取整行数据时效率更高、大大减少磁盘拜访次数，同时引入了点查问短门路优化、跳过执行引擎并间接应用疾速高效的读门路来检索所需的数据，并引入了预处理语句复用执行 SQL 解析来缩小 FE 开销。

通过以上一系列优化，Apache Doris 2.0 版本在并发能力上实现了数量级的晋升！在规范 YCSB 基准测试中，单台 16 Core 64G 内存 4*1T 硬盘规格的云服务器上实现了单节点 30000 QPS 的并发体现，较过来版本点查问并发能力晋升超 20 倍！基于以上能力，Apache Doris 能够更好应答高并发数据服务场景的需要，代替 HBase 在此类场景中的能力，缩小简单技术栈带来的保护老本以及数据的冗余存储。

参考文档：https://doris.apache.org/zh-CN/docs/dev/query-acceleration/hi…

具体介绍：https://mp.weixin.qq.com/s/Ow77-kFMWXFxugFXjOPHhg

CCR 跨集群数据同步

为了满足用户多集群之间数据同步的需要，在过来须要定期通过 Backup/Restore 命令进行数据备份和复原，操作较为简单、数据同步时延高并且还须要两头存储。为了满足用户多集群的数据库表主动同步需要，在 2.0-beta 版本中咱们减少了 CCR 跨集群数据同步的性能，可能在库 / 表级别将源集群的数据变更同步到指标集群、以晋升在线服务的数据可用性并更好地实现了读写负载拆散以及多机房备份。

反对 Kubernetes 容器化部署

在过来 Apache Doris 是基于 IP 通信的，在 K8s 环境部署时因为宿主机故障产生 Pod IP 漂移将导致集群不可用，在 2.0 版本中咱们反对了 FQDN，使得 Apache Doris 能够在无需人工干预的状况下实现节点自愈，因而能够更好应答 K8s 环境部署以及灵便扩缩容。

参考文档：https://doris.apache.org/zh-CN/docs/dev/install/k8s-deploy/

其余降级注意事项

• 1.2-lts 能够滚动降级到 2.0-beta，2.0-alpha 能够停机降级到 2.0-beta；
• 查问优化器开关默认开启 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 之旅

间隔 Apache Doris 2.0-alpha 版本公布曾经有一个半月之久，这一段时间内咱们在减速外围性能个性开发的同时、还播种到了数百家企业对于新版本的切身体验与实在反馈，这些来自实在业务场景的反馈对于性能的打磨与进一步欠缺有着极大的帮忙。因而 2.0-beta 版本无论在性能的残缺度还是零碎稳定性上，都曾经具备了更佳的应用体验，欢送所有对于 2.0 版本新个性有需要的用户部署降级。

如果您在调研、测试以及部署降级 2.0 版本的过程中有任何问题，欢送提交问卷信息，届时将由社区外围贡献者提供 1-1 专项反对。咱们也期待 2.0 版本为更多社区用户提供实时对立的剖析体验，置信 Apache Doris 2.0 版本会成为您在实时剖析场景中的最现实抉择。