我们很高兴宣布Apache Doris 2.0 Beta的发布。感谢255个Apache Doris贡献者，我们要竭尽全力，他们完全对3500多个错误修复和优化。您是所有新功能和性能飞跃背后的推动力！
在2023年中期，我们沿着路线图上的一半，并且在Doris Summit 2022中提出的视野更近。
：我们希望将Apache Doris构建到一个多合一平台中，该平台可以满足我们大多数用户的需求，以最大程度地提高其生产率，同时促进最低的发展和维护成本。具体来说，它应该能够在多种情况下进行数据分析，支持在线和离线工作负载，并在高通量交互式分析和高急及点查询中提供闪电性能。此外，为了响应行业趋势，它应该能够在异质数据源提供无缝的分析服务，并为半结构化和非结构化数据提供统一的管理服务。
采用这些伟大的视野意味着一条充满障碍的道路。我们需要找出所有这些困难问题的答案：
- 如何在不损害查询服务稳定性的情况下确保实时数据编写？
- 如何确保在数据更新和表模式更改期间的在线服务连续性？
- 如何在一个地方有效地存储和分析结构化和半结构的数据？
- 如何同时处理多个工作负载（点查询，报告，临时查询，ETL/ELT等）并保证隔离它们？
- 如何有效地执行复杂的SQL，大查询的稳定性以及执行的可观察性？
- 如何更轻松地整合和访问数据湖和许多异源数据源？
- 如何在很大程度上降低存储和计算成本的同时改善查询性能？
我们认为，对于开发人员或用户来说，生活都是痛苦的，因此我们决定应对更多的挑战，以使我们的用户遭受更少的痛苦。现在，我们很高兴宣布Apache Doris 2.0 Beta的进度。这些是您从这个新版本中可以期望的：
性能提高了10倍
高性能是我们的用户所识别的。在过去的一年中，Apache Doris在ClickBench和TPC-H基准测试中的测试结果反复证明了这一点。但是，基准测试和现实生活应用之间仍然存在一些差异：
- 基准测试简化和摘要实际情况，因此它可能无法涵盖数据分析中经常看到的复杂查询语句。
- 基准测试中的查询陈述通常是微调的，但是在现实生活中，微调太苛刻，疲惫和耗时。
这就是为什么我们引入了全新的查询优化器：Nereids。凭借更丰富的统计基础和高级Cascades框架，Nereids在大多数查询场景中都可以进行自我调整，因此用户可以期待高性能而无需进行任何微调或SQL重写。更重要的是，它支持TPC-DS中的所有99 SQL。
对22个TPC-H SQL的测试表明，与旧查询优化器相比，没有人类干预， 。在业务方案中尝试了Apache Doris 2.0 Alpha的数十名用户报告了类似的结果。它确实使工程师免于微调的负担。
文档：https://doris.apache.org/docs/dev/query-acceleration/nereids/
nereids在apache doris 2.0 beta：SET enable_nereids_planner=true中默认启用。 Nereids通过调用分析命令来收集统计数据。
支持更广泛的分析场景
具有成本效益的日志分析解决方案的10倍
从简单的OLAP引擎进行实时报告到能够具有ETL/ELT的数据仓库，而Apache Doris一直在推动其边界。使用版本2.0，我们在日志分析中取得突破。
行业内的常见日志分析解决方案在高写入吞吐量，低存储成本和快速文本检索之间基本上是不同的权衡。但是Apache Doris 2.0允许您全部拥有它们。它具有倒置索引，可在数字/dateTime上进行全文搜索以及字符串和等效/范围查询。在同一硬件环境中，与相同数据集的比较测试表明，Apache Doris在日志数据编写中比Elasticsearch快4倍，日志查询速度快2倍，而Elasticsearch使用的存储空间的20％。
。
我们还在多模型数据分析中取得进步。 Apache Doris 2.0支持两种新的数据类型：地图和结构，以及它们的快速写作，功能分析和嵌套。
阅读更多：https://doris.apache.org/blog/Inverted%20Index
高频率数据服务
在诸如电子商务订单查询和快速跟踪之类的方案中，将同时提供大量的数据用户对一小部分数据的查询。这些是高电位的查询，可以对系统造成巨大压力。一种传统的解决方案是在此类查询中引入诸如Apache HBase之类的密钥值商店，而Redis作为缓存层来减轻负担，但这意味着冗余存储和更高的维护成本。
对于以Apache Doris等为导向的DBMS，将乘以点查询的I/O使用。我们需要更整洁的执行。因此，我们引入了行存储格式和行缓存，以提高行阅读效率，短路计划以加快数据检索和准备的语句以减少前端开销。
在这些优化之后，Apache Doris 2.0在16 Core 64g云服务器上的YCSB上的每个节点 30,000 Qps的并发级别，具有4不驱动器，代表 20的改进与较旧版本相比，时代。这使Apache Doris在高急性方案中成为HBase的好替代品。
doc：https://doris.apache.org/blog/High_concurrency
增强的数据湖屋功能
在Apache Doris 1.2中，我们引入了多毒素，以支持来自异质源数据的自动映射和自动同步。在数据读数，执行引擎和查询优化器进行了优化之后，Doris 1.2在标准测试中提供了比Presto/Trino快的3〜5倍。
在Apache Doris 2.0中，我们根据用户的实际生产环境扩展了支持和进行优化的数据源列表。
-
更多支持的数据源
- 在hudi复制表上支持的快照查询，并在hudi合并中读取优化查询；在计划中合并表上的增量查询和快照查询的支持正在计划。
- 通过JDBC目录支持与Oceanbase的连接，延长了支持的关系数据库列表，其中包括MySQL，Postgresql，Oracle，SQLServer，Doris，Doris，Clickhouse，Sap Hana，Sap Hana和Trino/Presto。
-
数据特权控制
- 支持Hive目录通过Apache范围的授权；支持的可扩展特权授权插件允许在任何目录上使用用户定义的授权方法。
-
绩效改进
- 加速读取平面桌和大量小文件；提高查询速度数十次；通过诸如小文件的完全加载，I/O合并和数据预取用的技术来减少读取开销。
- 与版本1.2相比，ORC/Parquet文件上的查询速度提高了100％。
- 支持Lakehouse数据的本地缓存。用户可以从HDFS缓存数据或本地磁盘中的对象存储，以加快涉及相同数据的查询。在缓存命中，查询Lakehouse数据将与查询Apache Doris中的内部数据一样快。
- Doc: https://doris.apache.org/docs/dev/lakehouse/filecache/
- 支持外部表统计的收集。用户可以通过分析声明获得有关其指定外部表的统计信息，以便更有效地对复杂的SQL进行查询计划。
- Doc: https://doris.apache.org/docs/dev/lakehouse/multi-catalog/
- 提高了JDBC目录的数据写入速度。通过PreparestMT和其他批处理方法，用户可以通过插入命令将数据写回MySQL和Oracle等关系数据库。
多个分析工作负载的统一平台
自适应平行执行模型
随着用户群的扩展，Apache Doris在处理越来越多的数据尺寸的同时，进行了越来越多的分析工作负载。一个巨大的挑战是确保所有这些工作负载的高执行效率并避免资源抢占。
Apache Doris的较旧版本具有基于火山的执行引擎。为了使所有计算机和内核进行全面播放，用户必须设置执行并发本身（例如，将parallel_fragment_exec_instance_num从默认值1更改为1到8或16）。但是当多丽丝不得不同时处理多个查询时，存在问题：
- 实例操作员占用了线程，并且查询任务没有被执行。逻辑僵局发生了。
- 实例线程是通过系统调度机制安排的，线程之间的切换带来了额外的开销。
- 处理各种分析工作负载时，实例线程可能会为CPU资源而战，因此查询和租户可能会相互打断。
apache 2.0引入了管道执行引擎来解决这些问题。在此引擎中，查询的执行是由数据驱动的。所有查询执行过程中的阻止运算符分为管道。管道是否获得执行线程取决于其数据是否准备就绪。结果：
- 管道执行模型将查询执行计划根据阻塞逻辑和同步封锁操作将查询执行计划分配到管道任务中，因此很长一段时间以来都不会占用一个线程。
- 它允许用户更灵活地管理系统资源。他们可以采取不同的调度策略将CPU资源分配给各种查询和租户。
- 它还从所有存储桶中汇总数据，因此实例的数量不会受到存储桶数的限制，并且系统不必经常创建和破坏线程。
使用管道执行引擎，Apache Doris将提供更快的查询和更高的混合工作负载方案。
。doc：https://doris.apache.org/docs/dev/query-acceleration/pipeline-execution-engine/
默认情况下，apache doris 2.0：Set enable_pipeline_engine = true启用管道执行引擎。 parallel_pipeline_task_num表示在SQL查询中执行的管道任务的数量。它的默认值是0，用户可以根据需要更改值。 对于那些从较旧版本升级到Apache Doris 2.0的人，建议将parallel_pipeline_task_num的值设置为旧版本中的parallel_fragment_exec_instance_num的值。
工作负载管理
基于管道执行引擎，Apache Doris 2.0将工作负载分为工作负载组，以进行内存和CPU资源的细化管理。
通过将查询与工作负载组联系起来，用户可以限制一个查询在后端节点上使用的内存和CPU资源的百分比，并为资源组配置内存软限制。当存在集群资源短缺时，系统将杀死最大的内存任务。当有足够的群集资源时，一旦工作负载组使用比预期的更多资源，闲置集群资源将在多个工作负载组之间共享，并且系统内存仍将用于确保查询的稳定执行。
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命令检查现有的工作负载组：
查询队列
创建工作负载组时，用户可以为其设置最大查询号。超出该限制的查询将等待在查询队列中执行。
-
max_concurrency：当前工作负载组允许的最大查询数 -
max_queue_size：查询队列的长度。填补了所有点后，任何新的查询都将被拒绝。 -
queue_timeout：以miliseconds测量的队列中查询的等待时间。如果队列的等待时间比此限制更长，则将被拒绝。
doc：https://doris.apache.org/docs/dev/admin-manual/workload-group/
弹性缩放和存储计算分离
在计算和存储资源方面，用户想要什么？
- 计算资源的弹性缩放：在高峰时期迅速扩大资源以提高效率和降低山谷时的规模以降低成本。
- 较低的存储成本：使用低成本存储介质并与计算分开存储。
- 工作负载的分离：隔离不同工作负载的计算资源以避免先发制人。
- 数据的统一管理：只需在一个地方管理目录和数据。
分开存储和计算是实现资源弹性缩放的一种方式，但是它需要更多的努力来维持存储稳定性，这决定了OLAP服务的稳定性和连续性。为了确保存储稳定性，我们引入了包括缓存管理，计算资源管理和垃圾收集在内的机制。
在这方面，我们在调查后将用户分为三组：
1.不需要资源缩放的用户
2.需要资源缩放，低存储成本和与Apache Doris分离的用户
3.已经具有稳定的大规模存储系统的用户，因此需要高级计算存储分隔的体系结构，以进行有效的资源缩放
Apache Doris 2.0提供了两种解决方案来满足前两种用户的需求。
1.compute节点。我们在2.0版中介绍了无状态计算节点。与混合节点不同，计算节点不能保存任何数据，也不参与集群缩放期间数据平板电脑的工作负载平衡。因此，他们能够快速加入群集并在高峰时段共享计算压力。此外，在数据Lakehouse分析中，这些节点将是第一个在远程存储（HDFS/S3）上执行查询的节点，因此内部表和外部表之间将没有资源竞争。
doc：https://doris.apache.org/docs/dev/advanced/compute_node/
2.热冷数据分离。热/冷数据分别是指经常/很少访问的数据。通常，将冷数据存储在低成本存储中更有意义。 Apache Doris的较旧版本支持表分区的生命周期管理：随着热数据的冷却，它将从SSD转移到HDD。但是，数据存储在HDD上的多个复制品，这仍然是浪费。现在，在Apache Doris 2.0中，可以将冷数据存储在对象存储中，该对象存储甚至更便宜，可以允许单复制存储。这将存储成本降低了70％，并降低了存储随附的计算和网络开销。
doc：https://doris.apache.org/docs/dev/advanced/cold_hot_separation/
阅读更多：https://doris.apache.org/blog/HCDS/
对于第三种类型的用户，SelectDB团队将为Apache Doris项目贡献SelectDB Cloud Compute-Storage-Storage-Storage-Storage-Storage-Separation解决方案。该解决方案的性能和稳定性已经对其生产环境中数百家公司进行了考验。解决方案的Apache Doris的合并正在进行中。
更快，稳定器和智能数据编写
数据编写速度更高
作为我们持续努力增强Apache Doris的实时分析能力的一部分，我们改善了2.0版的端到端实时数据编写。这是TPC-H基准测试结果：
- 流载荷，TPC-H 144G lineItem表，48-bucket副本表，三重修复写作：吞吐量增加了100％
- 流载荷，TPC-H 144G线路表，48-Bucket独特的钥匙表，三重修复写作：吞吐量增加了200％
- 插入Select，TPC-H 144G LineItem表，48-Bucket副本表：吞吐量增加了50％
- 插入选择，tpc-h 144g lineItem表，48-bucket独特的钥匙表：吞吐量增加了150％
高频率数据编写的稳定性更大
小文件的合并，写放大以及相应的磁盘I/O和CPU开销通常是系统不稳定性的来源。因此，我们在2.0版中引入了垂直压实和段压实，以消除压实中的OOM错误，并避免在数据编写过程中生成太多的细分文件。经过此类改进，Apache Doris可以使用以前使用的10％的内存。
阅读更多：https://doris.apache.org/blog/Compaction
表模式的自动同步
最新的Flink-Doris-Connector允许用户通过一个简单的步骤将整个数据库（例如MySQL）同步到Apache Doris。根据我们的测试结果，一个单一的同步任务可以执行数千个表的实时同时撰写。 Apache Doris已经自动化了上游表模式和数据的更新，因此用户不再需要通过复杂的同步过程。此外，上游数据架构的更改将自动捕获，并以无缝的方式动态更新为Apache Doris。
支持唯一密钥模型中部分列更新
apache doris 1.2在独特的密钥模型中使用合并机制同时实现了实时写作和快速查询执行。现在，在2.0版中，我们进一步改善了唯一的关键模型。它支持部分列更新，因此在摄入多个源表时，用户不必提前将它们合并到一张平台中。
在此基础上，我们还增强了合并后的能力。在大数据编写中，Apache Doris 2.0比Apache Doris 1.2快50％，在高频率数据编写中的速度快10倍。可以使用并行处理机制来避免“发布超时”（E-3115），并且有更有效的压实机制可以防止“太多版本”（E-235）。所有这些都允许用户在更多情况下用合并后的合并来替换合并阅读。另外，部分列更新使执行更新和删除语句的成本降低。
部分列更新的执行很简单。
示例（流负载）：
假设您有下表模式：
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 |
+------------------+-----------------+------+-------+---------+-------+
如果您需要批处理更新最近10秒的“余额”和“最后访问时间”字段，则可以将更新放入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
然后，添加一个标题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
告别OOM
内存管理可能不在用户的优先列表中，直到存在内存问题。但是，现实生活中的分析充满了极端的情况，这些案例挑战了内存稳定性。在大型计算任务中，OOM错误通常会导致查询失败甚至导致后端停机时间。
为了解决这个问题，我们改进了内存数据结构，重建了孟形式器，并引入了查询的软内存限制和GC Mechansim来应对过程内存溢出。新的内存管理机制可以更有效地分配，插入和监视内存。根据基准测试，压力测试和用户反馈，它消除了大多数内存热点和后端停机时间。即使存在OOM错误，用户也可以根据日志找到问题点并采取相应的操作。
在一个单词中，Apache Doris 2.0能够处理复杂的计算和具有更大系统稳定性的大型ETL/ELT操作。
阅读更多：https://doris.apache.org/blog/Memory_Management/
支持Kubernetes部署
Apache Doris的较旧版本基于IP进行通信，因此导致POD IP漂移的Kubernetes部署中的任何主机故障都会导致群集无法可用。现在，版本2.0支持FQDN。这意味着失败的多丽丝节点可以在没有人干预的情况下自动恢复，这为Kubernetes部署和弹性缩放奠定了基础。
doc：https://doris.apache.org/docs/dev/install/k8s-deploy/
支持跨集群复制
对于跨多个群集的数据同步，Apache Doris过去曾需要通过备份/还原命令进行常规数据备份和恢复。该过程需要中间存储，并且具有很高的潜伏期。 Apache Doris 2.0 Beta支持跨集群复制（CCR），该复制（CCR）自动化此过程。源群集中数据库/表级别的数据更改将同步到目标群集。此功能允许更高的数据可用性，读/写工作负载分离和跨数据中心复制。
行为改变
- 使用从1.2-ITS滚动升级到2.0-beta，然后从2.0-alpha重新升级到2.0-beta;
- 默认情况下启用了新的查询优化器（NEREIDS）：
enable_nereids_planner=true; - 所有非矢量化代码已从系统中删除，因此
enable_vectorized_engine参数无长效; - 添加了一个新的参数
enable_single_replica_compaction; - datev2，dateTimev2和decimalv3是表创建中的默认数据类型； Datav1，DateTimeV1和DecimalV2在表创建中不支持;
- decimalv3是JDBC和Iceberg目录的默认数据类型;
- 已经添加了一种新的数据类型
AGG_STATE; - 群集列已从后端表中删除；
- 为了更好地与BI工具的兼容性，DateV2和DateTimeV2在
show create table; 时显示为日期和dateTime
- max_openfiles和交换检查被添加到后端启动脚本中，因此不适当的系统配置可能会导致后端故障;
- 不允许在Localhost上访问前端的无密码登录;
- 如果系统中有一个多毒素，则默认情况下，仅在查询信息架构时才显示内部目录的数据；
- 对表达树的深度施加了一个极限。默认值为200;
- 数组字符串的返回值中的单个报价已更改为double Quote;
- 多丽丝过程被重命名为Dorisfe和Dorisbe。
Apache Doris 2.0 GA即将来临！
在Apache Doris 2.0 Alpha发行后的最近一个半月中，根据数百名企业用户的测试反馈，我们一直在磨练主要功能和完美的Doris。现在，Apache Doris 2.0 beta更成熟和稳定，肯定会提供更好的用户体验。
如果您在调查，测试和部署Apache Doris时有任何疑问，请在Slack上找到我们。我们的开发人员将很乐意提供有针对性的支持。
除了上述功能外，一些新功能还进行了最终调试，并且将在Apache Doris 2.0.0 GA中使用，并且随后的版本，包括多台式物质化的视图，单台可观的视图中的表达支持，动态模式表和Doris Binlog。我们会让您了解我们的进度。