[Doc][Vectorized] Add vectorized execution engine docs

docs/.vuepress/sidebar/en.js

@@ -213,6 +213,7 @@ module.exports = [
       "broker",
       "colocation-join",
       "bucket-shuffle-join",
+      "vectorized-execution-engine",
       "dynamic-partition",
       "export-manual",
       "export_with_mysql_dump",

docs/.vuepress/sidebar/zh-CN.js

@@ -212,6 +212,7 @@ module.exports = [
       "broker",
       "colocation-join",
       "bucket-shuffle-join",
+      "vectorized-execution-engine",
       "dynamic-partition",
       "export-manual",
       "export_with_mysql_dump",

docs/en/administrator-guide/vectorized-execution-engine.md

@@ -0,0 +1,126 @@
+---
+{
+    "title": "[Experimental] Vectorized Execution Engine",
+    "language": "en"
+}
+---
+
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Vectorized Execution Engine
+
+Vectorized execution engine is an experimental feature added to the current version of Doris. The goal is to replace the current Doris row-based SQL execution engine, fully release the computing power of modern CPUs, and break through the performance shortcomings of Doris in the SQL execution engine.
+
+Its specific design, implementation and effects can be found in [ISSUE 6238](https://github.com/apache/incubator-doris/issues/6238).
+
+
+## Principle
+
+The current Doris SQL execution engine is based on the row-based memory format and is designed based on the traditional volcano model. There is a lot of unnecessary overhead when performing SQL operators and function operations:
+1. The virtual function call caused by the type loss, the function cannot be inline optimized.
+2. Cache affinity is poor, and the locality principle of code and data cache cannot be fully utilized.
+3. Inability to use the vectorization capabilities of modern CPU to SIMD  computations.
+4. CPU branch prediction, prefetch memory is not friendly.
+
+![image.png](/images/vectorized-execution-engine1.png)
+
+The resulting series of overheads makes the current Doris execution engine inefficient and does not adapt to the architecture of modern CPU.
+
+
+And as shown in the figure below (quoted from [Column-Oriented
+Database Systems](https://web.stanford.edu/class/cs346/2015/notes/old/column.pdf)）, the vectorized execution engine redesigns the SQL execution engine of the columnar storage system based on the characteristics of modern CPU and the execution characteristics of the volcano model:
+
+![image.png](/images/vectorized-execution-engine2.png)
+
+1. Reorganize the data structure of the memory, replace **Tuple** with **Column**, improve the Cache affinity during calculation, the friendliness of branch prediction and prefetch memory.
+2. Type judgment is performed in batches, and the determined type is used in this single batch. Allocate the virtual function overhead of each row type judgment to the batch level.
+3. Through batch-level type judgment, virtual function calls are eliminated, allowing the compiler to have the opportunity for function inlining and SIMD optimization.
+
+This greatly improves the efficiency of the CPU when executing SQL and improves the performance of SQL queries.
+
+## Usage
+
+### Set session variable
+
+#### enable_vectorized_engine
+Set the session variable `enable_vectorized_engine` to `true`, then FE will convert SQL operators and SQL expressions into vectorized execution plans by default when performing query planning.
+```
+set enable_vectorized_engine = true;
+```
+
+#### batch_size
+`batch_size` represents the number of rows that the SQL operator performs batch calculations on each time. The default configuration of Doris is `1024`. The number of lines in this configuration will affect the performance of the vectorized execution engine and the behavior of CPU cache prefetching. The recommended configuration here is `4096`.
+
+```
+set batch_size = 4096;
+```
+
+### NULL value
+Performance degradation due to NULL value ​​in the vectorized execution engine. Therefore, when creating a table, setting the corresponding column to NULL usually affects the performance of the vectorized execution engine. **It is recommended to use some special column values ​​to represent NULL values, and set the columns to NOT NULL when creating the table to give full play to the performance of the vectorized execution engine.**
+
+### View the type of SQL execution
+
+
+You can use the `explain` command to check whether the current SQL has the vectorized execution engine enabled:
+
+```
++-----------------------------+
+| Explain String              |
++-----------------------------+
+| PLAN FRAGMENT 0             |
+|  OUTPUT EXPRS:<slot 0> TRUE |
+|   PARTITION: UNPARTITIONED  |
+|                             |
+|   VRESULT SINK              |
+|                             |
+|   0:VUNION                  |
+|      constant exprs:        |
+|          TRUE               |
++-----------------------------+
+
+```
+
+After the vectorized execution engine is enabled,  `V` mark will be added before the SQL operator in the SQL execution plan.
+
+## Some differences from the row-store execution engine
+
+In most scenarios, users only need to turn on the seesion variable by default to transparently enable the vectorized execution engine and improve the performance of SQL execution. However, **the current vectorized execution engine is different from the original row-stored execution engine in the following minor details, which requires users to know**. This part of the difference is divided into two categories
+
+* **Type A** : functions that need to be deprecated and deprecated or depended on by the inline execution engine.
+* **Type B**: Not supported on the vectorized execution engine in the short term, but will be supported by development in the future.
+
+
+#### Type A
+
+1. Float and Double type calculations may cause precision errors, which only affect numbers after 5 decimal places. **If you have special requirements for calculation precision, please use Decimal type**.
+2. The DateTime type does not support various operations such as calculation or format below the second level, and the vectorization engine will directly discard the calculation results of milliseconds below the second level. At the same time, `microseconds_add` and other functions that calculate milliseconds are not supported.
+3. When encoded with a conforming type, `0` and `-0` are considered equal in SQL execution. This may affect the results of calculations like `distinct`, `group by`, etc.
+4. The bitmap/hll type is in the vectorized execution engine: if the input is all NULL, the output result is NULL instead of 0.
+
+#### Type B
+
+1. The `geolocation function` is not supported, including all functions starting with `ST_` in the function. For details, please refer to the section on SQL functions in the official documentation.
+2. The `UDF` and `UDAF` of the original row storage execution engine are not supported.
+3. It is not supported to rewrite the between statement into a compound judgment statement, which will result in the following error: `BetweenPredicate needs to be rewritten into a CompoundPredicate`.
+4. The `TupleIsNull` function is not supported, which may cause partial outer joins and expressions with non-Nullable functions to obtain the required NULL value.
+5. The maximum length of `string/text` type is 1MB instead of the default 2GB. That is, when the vectorization engine is turned on, it is impossible to query or import strings larger than 1MB. However, if you turn off the vectorization engine, you can still query and import normally.
+6. The export method of `select ... into outfile` is not supported.
+7. Lateral view is not supported.
+8. Extrenal broker appearance is not supported.

docs/zh-CN/administrator-guide/vectorized-execution-engine.md

@@ -0,0 +1,123 @@
+---
+{
+    "title": "[Experimental] 向量化执行引擎",
+    "language": "zh-CN"
+}
+---
+
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# 向量化执行引擎
+
+向量化执行引擎 是 Doris 当前版本加入的实验性功能。目标是为了替换当前Doris的行式的SQL执行引擎，充分释放现代CPU的计算能力，突破Doris在SQL执行引擎上的性能短板。
+
+它的具体设计、实现和效果可以参阅 [ISSUE 6238](https://github.com/apache/incubator-doris/issues/6238)。
+
+
+## 原理
+
+当前的Doris的SQL执行引擎是基于行式内存格式，基于传统的火山模型进行设计，在进行SQL算子与函数运算的时候存在大量的非必要的开销：
+1. 类型丢失导致的虚函数的调用，函数无法进行内联优化
+2. Cache亲和度差，代码和数据Cache的局部性原理无法得到充分利用
+3. 无法利用现代CPU的向量化能力将计算SIMD化
+4. CPU的分支预测，预取内存不友好 
+
+![image.png](/images/vectorized-execution-engine1.png)
+
+由此带来的一系列开销导致当前Doris执行引擎效率低下，并不适应现代CPU的体系结构。
+
+
+而如下图所示（引用自[Column-Oriented
+Database Systems](https://web.stanford.edu/class/cs346/2015/notes/old/column.pdf)），向量化执行引擎基于现代CPU的特点与火山模型的执行特点，重新设计列式存储系统的SQL执行引擎：
+
+![image.png](/images/vectorized-execution-engine2.png)
+
+1. 重新组织内存的数据结构，用**Column**替换**Tuple**，提高了计算时Cache亲和度，分支预测与预取内存的友好度
+2. 分批进行类型判断，这单批次内用确定的类型。将每一行类型判断的虚函数开销分摊到批量级别。
+3. 通过批级别的类型判断，消除了虚函数的调用，让编译器有函数内联以及SIMD优化的机会
+
+从而大大提高了CPU在SQL执行时的效率，提升了SQL查询的性能。
+
+## 使用方式
+
+### 设置Session变量
+
+#### enable_vectorized_engine
+将session变量`enable_vectorized_engine `设置为`true`，则FE在进行查询规划时就会默认将SQL算子与SQL表达式转换为向量化的执行计划。
+
+```
+set enable_vectorized_engine = true;
+```
+
+#### batch_size
+`batch_size`代表了SQL算子每次进行批量计算的行数。Doris默认的配置为`1024`,这个配置的行数会影响向量化执行引擎的性能与CPU缓存预取的行为。这里推荐配置为`4096`。
+
+```
+set batch_size = 4096;
+```
+
+### NULL值
+由于NULL值在向量化执行引擎中会导致性能劣化。所以在建表时，将对应的列设置为NULL通常会影响向量化执行引擎的性能。**这里推荐使用一些特殊的列值表示NULL值，并在建表时设置列为NOT NULL以充分发挥向量化执行引擎的性能。**
+
+### 查看SQL执行的类型
+
+可以通过`explain`命令来查看当前的SQL是否开启了向量化执行引擎：
+
+```
++-----------------------------+
+| Explain String              |
++-----------------------------+
+| PLAN FRAGMENT 0             |
+|  OUTPUT EXPRS:<slot 0> TRUE |
+|   PARTITION: UNPARTITIONED  |
+|                             |
+|   VRESULT SINK              |
+|                             |
+|   0:VUNION                  |
+|      constant exprs:        |
+|          TRUE               |
++-----------------------------+
+
+```
+开启了向量化执行引擎之后，在SQL的执行计划之中会在SQL算子前添加一个`V`的标识。
+
+## 与行存执行引擎的部分差异
+
+在绝大多数场景之中，用户只需要默认打开seesion变量的开关就可以透明的使向量化执行引擎并且得到SQL执行的性能提升。但是，**目前的向量化执行引擎在下面一些微小的细节上与原先的行存执行引擎存在不同，需要使用者知晓**。这部分区别分为两类
+
+* **a类** ：行存执行引擎需要被废弃和不推荐使用或依赖的功能
+* **b类**： 短期没有在向量化执行引擎上得到支持，但后续会得到开发支持的功能
+
+
+#### a类
+1. Float与Double类型计算可能产生精度误差，仅影响小数点后5位之后的数字。**如果对计算精度有特殊要求，请使用Decimal类型**。
+2. DateTime类型不支持秒级别以下的计算或format等各种操作，向量化引擎会直接丢弃秒级别以下毫秒的计算结果。同时也不支持`microseconds_add`等，对毫秒计算的函数。
+3. 有符合类型进行编码时，`0`与`-0`在SQL执行中被认为是相等的。这可能会影响`distinct`，`group by`等计算的结果。
+4. bitmap/hll 类型在向量化执行引擎中：输入均为NULL，则输出的结果为NULL而不是0。
+
+#### b类
+1. 不支持`地理位置函数` ，包含了函数中所有以`ST_`开头的函数。具体请参考官方文档SQL函数的部分。
+2. 不支持原有行存执行引擎的`UDF`与`UDAF`。
+3. 不支持将between语句改写为复合判断语句，会导致以下报错：`BetweenPredicate needs to be rewritten into a CompoundPredicate`。
+4. 不支持`TupleIsNull`函数，可能会导致部分外连接并带有非Nullable函数计算的表达式无法得到所需的NULL值。
+5. `string/text`类型最大长度支持为1MB，而不是默认的2GB。即当开启向量化引擎后，将无法查询或导入大于1MB的字符串。但如果关闭向量化引擎，则依然可以正常查询和导入。
+6. 不支持 `select ... into outfile` 的导出方式。
+7. 不支持lateral view。
+8. 不支持extrenal broker外表。