KassieZ commented on code in PR #1561:
URL: https://github.com/apache/doris-website/pull/1561#discussion_r1895558233


##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/colocation-join.md:
##########
@@ -0,0 +1,445 @@
+---
+{
+    "title": "Colocation Join",
+    "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.
+-->
+
+
+
+Colocation Join 旨在为某些 Join 查询提供本地性优化,来减少数据在节点间的传输耗时,加速查询。本文档主要介绍 Colocation 
Join 的原理、实现、使用方式和注意事项。  
+
+注意:这个属性不会被 CCR 同步,如果这个表是被 CCR 复制而来的,即 PROPERTIES 中包含`is_being_synced = 
true`时,这个属性将会在这个表中被擦除。
+
+## 名词解释
+
+- Colocation Group(CG):一个 CG 中会包含一张及以上的 Table。在同一个 Group 内的 Table 有着相同的 
Colocation Group Schema,并且有着相同的数据分片分布。
+
+- Colocation Group Schema(CGS):用于描述一个 CG 中的 Table,和 Colocation 相关的通用 Schema 
信息。包括分桶列类型,分桶数以及副本数等。
+
+## 原理
+
+Colocation Join 功能,是将一组拥有相同 CGS 的 Table 组成一个 CG。并保证这些 Table 对应的数据分片会落在同一个 BE 
节点上。使得当 CG 内的表进行分桶列上的 Join 操作时,可以通过直接进行本地数据 Join,减少数据在节点间的传输耗时。
+
+一个表的数据,最终会根据分桶列值 Hash、对桶数取模的后落在某一个分桶内。假设一个 Table 的分桶数为 8,则共有 `[0, 1, 2, 3, 4, 
5, 6, 7]` 8 个分桶(Bucket),我们称这样一个序列为一个 `BucketsSequence`。每个 Bucket 
内会有一个或多个数据分片(Tablet)。当表为单分区表时,一个 Bucket 内仅有一个 Tablet。如果是多分区表,则会有多个。
+
+为了使得 Table 能够有相同的数据分布,同一 CG 内的 Table 必须保证以下属性相同:
+
+1. 分桶列和分桶数
+
+   分桶列,即在建表语句中 `DISTRIBUTED BY HASH(col1, col2, ...)` 
中指定的列。分桶列决定了一张表的数据通过哪些列的值进行 Hash 划分到不同的 Tablet 中。同一 CG 内的 Table 
必须保证分桶列的类型和数量完全一致,并且桶数一致,才能保证多张表的数据分片能够一一对应的进行分布控制。
+
+2. 副本数
+
+   同一个 CG 内所有表的所有分区(Partition)的副本数必须一致。如果不一致,可能出现某一个 Tablet 的某一个副本,在同一个 BE 
上没有其他的表分片的副本对应。
+
+同一个 CG 内的表,分区的个数、范围以及分区列的类型不要求一致。
+
+在固定了分桶列和分桶数后,同一个 CG 内的表会拥有相同的 BucketsSequence。而副本数决定了每个分桶内的 Tablet 的多个副本,存放在哪些 
BE 上。假设 BucketsSequence 为 `[0, 1, 2, 3, 4, 5, 6, 7]`,BE 节点有 `[A, B, C, D]` 4 
个。则一个可能的数据分布如下:
+
+```text
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| A | | B | | C | | D | | A | | B | | C | | D |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| B | | C | | D | | A | | B | | C | | D | | A |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| C | | D | | A | | B | | C | | D | | A | | B |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+```
+
+CG 内所有表的数据都会按照上面的规则进行统一分布,这样就保证了,分桶列值相同的数据都在同一个 BE 节点上,可以进行本地数据 Join。
+
+## 使用方式
+
+### 建表
+
+建表时,可以在 `PROPERTIES` 中指定属性 `"colocate_with" = "group_name"`,表示这个表是一个 
Colocation Join 表,并且归属于一个指定的 Colocation Group。
+
+示例:
+
+```sql
+CREATE TABLE tbl (k1 int, v1 int sum)
+DISTRIBUTED BY HASH(k1)
+BUCKETS 8
+PROPERTIES(
+    "colocate_with" = "group1"
+);
+```
+
+如果指定的 Group 不存在,则 Doris 会自动创建一个只包含当前这张表的 Group。如果 Group 已存在,则 Doris 会检查当前表是否满足 
Colocation Group Schema。如果满足,则会创建该表,并将该表加入 Group。同时,表会根据已存在的 Group 
中的数据分布规则创建分片和副本。Group 归属于一个 Database,Group 的名字在一个 Database 内唯一。在内部存储是 Group 
的全名为 `dbId_groupName`,但用户只感知 groupName。
+
+
+
+:::tip
+2.0 版本中,Doris 支持了跨 Database 的 Group。
+:::
+
+在建表时,需使用关键词 `__global__` 作为 Group 名称的前缀。如:
+
+```

Review Comment:
   add sql



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/colocation-join.md:
##########
@@ -0,0 +1,445 @@
+---
+{
+    "title": "Colocation Join",
+    "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.
+-->
+
+
+
+Colocation Join 旨在为某些 Join 查询提供本地性优化,来减少数据在节点间的传输耗时,加速查询。本文档主要介绍 Colocation 
Join 的原理、实现、使用方式和注意事项。  
+
+注意:这个属性不会被 CCR 同步,如果这个表是被 CCR 复制而来的,即 PROPERTIES 中包含`is_being_synced = 
true`时,这个属性将会在这个表中被擦除。
+
+## 名词解释
+
+- Colocation Group(CG):一个 CG 中会包含一张及以上的 Table。在同一个 Group 内的 Table 有着相同的 
Colocation Group Schema,并且有着相同的数据分片分布。
+
+- Colocation Group Schema(CGS):用于描述一个 CG 中的 Table,和 Colocation 相关的通用 Schema 
信息。包括分桶列类型,分桶数以及副本数等。
+
+## 原理
+
+Colocation Join 功能,是将一组拥有相同 CGS 的 Table 组成一个 CG。并保证这些 Table 对应的数据分片会落在同一个 BE 
节点上。使得当 CG 内的表进行分桶列上的 Join 操作时,可以通过直接进行本地数据 Join,减少数据在节点间的传输耗时。
+
+一个表的数据,最终会根据分桶列值 Hash、对桶数取模的后落在某一个分桶内。假设一个 Table 的分桶数为 8,则共有 `[0, 1, 2, 3, 4, 
5, 6, 7]` 8 个分桶(Bucket),我们称这样一个序列为一个 `BucketsSequence`。每个 Bucket 
内会有一个或多个数据分片(Tablet)。当表为单分区表时,一个 Bucket 内仅有一个 Tablet。如果是多分区表,则会有多个。
+
+为了使得 Table 能够有相同的数据分布,同一 CG 内的 Table 必须保证以下属性相同:
+
+1. 分桶列和分桶数
+
+   分桶列,即在建表语句中 `DISTRIBUTED BY HASH(col1, col2, ...)` 
中指定的列。分桶列决定了一张表的数据通过哪些列的值进行 Hash 划分到不同的 Tablet 中。同一 CG 内的 Table 
必须保证分桶列的类型和数量完全一致,并且桶数一致,才能保证多张表的数据分片能够一一对应的进行分布控制。
+
+2. 副本数
+
+   同一个 CG 内所有表的所有分区(Partition)的副本数必须一致。如果不一致,可能出现某一个 Tablet 的某一个副本,在同一个 BE 
上没有其他的表分片的副本对应。
+
+同一个 CG 内的表,分区的个数、范围以及分区列的类型不要求一致。
+
+在固定了分桶列和分桶数后,同一个 CG 内的表会拥有相同的 BucketsSequence。而副本数决定了每个分桶内的 Tablet 的多个副本,存放在哪些 
BE 上。假设 BucketsSequence 为 `[0, 1, 2, 3, 4, 5, 6, 7]`,BE 节点有 `[A, B, C, D]` 4 
个。则一个可能的数据分布如下:
+
+```text
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| A | | B | | C | | D | | A | | B | | C | | D |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| B | | C | | D | | A | | B | | C | | D | | A |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| C | | D | | A | | B | | C | | D | | A | | B |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+```
+
+CG 内所有表的数据都会按照上面的规则进行统一分布,这样就保证了,分桶列值相同的数据都在同一个 BE 节点上,可以进行本地数据 Join。
+
+## 使用方式
+
+### 建表
+
+建表时,可以在 `PROPERTIES` 中指定属性 `"colocate_with" = "group_name"`,表示这个表是一个 
Colocation Join 表,并且归属于一个指定的 Colocation Group。
+
+示例:
+
+```sql
+CREATE TABLE tbl (k1 int, v1 int sum)
+DISTRIBUTED BY HASH(k1)
+BUCKETS 8
+PROPERTIES(
+    "colocate_with" = "group1"
+);
+```
+
+如果指定的 Group 不存在,则 Doris 会自动创建一个只包含当前这张表的 Group。如果 Group 已存在,则 Doris 会检查当前表是否满足 
Colocation Group Schema。如果满足,则会创建该表,并将该表加入 Group。同时,表会根据已存在的 Group 
中的数据分布规则创建分片和副本。Group 归属于一个 Database,Group 的名字在一个 Database 内唯一。在内部存储是 Group 
的全名为 `dbId_groupName`,但用户只感知 groupName。
+
+
+
+:::tip
+2.0 版本中,Doris 支持了跨 Database 的 Group。
+:::
+
+在建表时,需使用关键词 `__global__` 作为 Group 名称的前缀。如:
+
+```
+CREATE TABLE tbl (k1 int, v1 int sum)
+DISTRIBUTED BY HASH(k1)
+BUCKETS 8
+PROPERTIES(
+    "colocate_with" = "__global__group1"
+);
+```
+
+`__global__` 前缀的 Group 不再归属于一个 Database,其名称也是全局唯一的。
+
+通过创建 Global Group,可以实现跨 Database 的 Colocate Join。
+
+
+
+### 删表
+
+当 Group 中最后一张表彻底删除后(彻底删除是指从回收站中删除。通常,一张表通过 `DROP TABLE` 
命令删除后,会在回收站默认停留一天的时间后,再删除),该 Group 也会被自动删除。
+
+### 查看 Group
+
+以下命令可以查看集群内已存在的 Group 信息。
+
+```sql
+SHOW PROC '/colocation_group';
+
++-------------+--------------+--------------+------------+----------------+----------+----------+
+| GroupId     | GroupName    | TableIds     | BucketsNum | ReplicationNum | 
DistCols | IsStable |
++-------------+--------------+--------------+------------+----------------+----------+----------+
+| 10005.10008 | 10005_group1 | 10007, 10040 | 10         | 3              | 
int(11)  | true     |
++-------------+--------------+--------------+------------+----------------+----------+----------+
+```
+
+- GroupId:一个 Group 的全集群唯一标识,前半部分为 db id,后半部分为 group id。
+
+- GroupName:Group 的全名。
+
+- TabletIds:该 Group 包含的 Table 的 id 列表。
+
+- BucketsNum:分桶数。
+
+- ReplicationNum:副本数。
+
+- DistCols:Distribution columns,即分桶列类型。
+
+- IsStable:该 Group 是否稳定(稳定的定义,见 `Colocation 副本均衡和修复` 一节)。
+
+通过以下命令可以进一步查看一个 Group 的数据分布情况:
+
+```sql
+SHOW PROC '/colocation_group/10005.10008';
+
++-------------+---------------------+
+| BucketIndex | BackendIds          |
++-------------+---------------------+
+| 0           | 10004, 10002, 10001 |
+| 1           | 10003, 10002, 10004 |
+| 2           | 10002, 10004, 10001 |
+| 3           | 10003, 10002, 10004 |
+| 4           | 10002, 10004, 10003 |
+| 5           | 10003, 10002, 10001 |
+| 6           | 10003, 10004, 10001 |
+| 7           | 10003, 10004, 10002 |
++-------------+---------------------+
+```
+
+- BucketIndex:分桶序列的下标。
+
+- BackendIds:分桶中数据分片所在的 BE 节点 id 列表。
+
+:::note
+以上命令需要 ADMIN 权限。暂不支持普通用户查看。
+:::
+
+### 修改表 Colocate Group 属性
+
+可以对一个已经创建的表,修改其 Colocation Group 属性。示例:
+
+```sql
+ALTER TABLE tbl SET ("colocate_with" = "group2");
+```
+
+- 如果该表之前没有指定过 Group,则该命令检查 Schema,并将该表加入到该 Group(Group 不存在则会创建)。
+
+- 如果该表之前有指定其他 Group,则该命令会先将该表从原有 Group 中移除,并加入新 Group(Group 不存在则会创建)。
+
+也可以通过以下命令,删除一个表的 Colocation 属性:
+
+```sql
+ALTER TABLE tbl SET ("colocate_with" = "");
+```
+
+### 其他相关操作
+
+当对一个具有 Colocation 属性的表进行增加分区(ADD PARTITION)、修改副本数时,Doris 会检查修改是否会违反 Colocation 
Group Schema,如果违反则会拒绝。
+
+## Colocation 副本均衡和修复
+
+Colocation 表的副本分布需要遵循 Group 中指定的分布,所以在副本修复和均衡方面和普通分片有所区别。
+
+Group 自身有一个 Stable 属性,当 Stable 为 true 时,表示当前 Group 内的表的所有分片没有正在进行变动,Colocation 
特性可以正常使用。当 Stable 为 false 时(Unstable),表示当前 Group 内有部分表的分片正在做修复或迁移,此时,相关表的 
Colocation Join 将退化为普通 Join。
+
+### 副本修复
+
+副本只能存储在指定的 BE 节点上。所以当某个 BE 不可用时(宕机、Decommission 等),需要寻找一个新的 BE 进行替换。Doris 
会优先寻找负载最低的 BE 进行替换。替换后,该 Bucket 内的所有在旧 BE 上的数据分片都要做修复。迁移过程中,Group 被标记为 Unstable。
+
+### 副本均衡
+
+Doris 会尽力将 Colocation 表的分片均匀分布在所有 BE 节点上。对于普通表的副本均衡,是以单副本为粒度的,即单独为每一个副本寻找负载较低的 
BE 节点即可。而 Colocation 表的均衡是 Bucket 级别的,即一个 Bucket 
内的所有副本都会一起迁移。我们采用一个简单的均衡算法,即在不考虑副本实际大小,而只根据副本数量,将 BucketsSequence 均匀的分布在所有 BE 
上。具体算法可以参阅 `ColocateTableBalancer.java` 中的代码注释。
+
+:::caution

Review Comment:
   :::caution 注意



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-sync-mv.md:
##########
@@ -24,32 +24,28 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-## 工作原理
+## 概述
 
-单表物化视图 (Materialized View) 是一种特殊的表,它预先根据定义好的 SELECT 
语句计算并存储数据。其主要目的是满足用户对原始明细数据的任意维度分析需求,同时也能快速地进行固定维度的分析查询。
+[单表物化视图](https://selectdb.feishu.cn/wiki/KOOYwALDdiu5ACk1UdMcKS9Tn1c?open_in_browser=true)
 (Materialized View) 是一种特殊的表,它预先根据定义好的 SELECT 
语句计算并存储数据。其主要目的是满足用户对原始明细数据的任意维度分析需求,同时也能快速地进行固定维度的分析查询。

Review Comment:
   ../../query-acceleration/materialized-view/sync-materialized-view



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/reordering-join-with-leading-hint.md:
##########
@@ -24,174 +24,73 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-## Leading Hint 简介
+## 概述
 
-Leading Hint 是一种强大的查询优化技术,它允许用户指导 Doris 优化器确定查询计划中的表连接顺序。正确使用 Leading Hint 
可以显著提升复杂查询的性能。本文将详细介绍如何在 Doris 中使用 Leading Hint 来控制 Join 的顺序。
+Doris 支持使用 Hint 来调整 Join 操作中数据 Shuffle 的类型,从而优化查询性能。本节将详细介绍如何在 Doris 中利用 Hint 
来指定 Join Shuffle 的类型。
 
-:::info 备注
+目前,Doris 支持两种独立的 
[DistributeHint](https://selectdb.feishu.cn/wiki/BpBxwpu07iL4jjkeai1cfs24nrn?open_in_browser=true),`[shuffle]
 ` 和 `[broadcast]`,用来指定 Join 右表的 Distribute Type。Distribute Type 需置于 Join 
右表之前,采用中括号 `[]` 的方式。同时,Doris 也可以通过 LeadingHint 配合 DistributeHint 的方式,指定 shuffle 
方式(详见“使用 Leading Hint 控制 Join 顺序”章节相关介绍)。

Review Comment:
   ../../query-acceleration/hints/distribute-hint



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/performance-tuning-overview/diagnostic-tools.md:
##########
@@ -0,0 +1,109 @@
+---
+{
+    "title": "诊断工具",
+    "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.
+-->
+
+## 概述
+
+高效好用的性能诊断工具对于数据库系统的调优至关重要,因为这关系到是否能快速定位到存在性能问题的业务 SQL,继而快速定位和解决性能瓶颈,保证数据库系统服务的 
SLA。
+
+当前,Doris 系统默认将执行时间超过 5 秒的 SQL 认定为慢 SQL,此阈值可通过 `config.qe_slow_log_ms` 进行配置。目前 
Doris 提供了以下三种诊断渠道,能够帮助快速定位存在性能问题的慢 SQL,分别如下:
+
+## Doris Manager 日志
+
+Doris Manager 的日志模块提供了慢 SQL 筛选功能。用户可以通过选择特定 FE 节点上的 `fe.audit.log` 来查看慢 
SQL。只需在搜索框中输入“slow_query”,即可在页面上展示出当前系统的历史慢 SQL 信息,如下图所示:
+
+![](static/EbJobMOIso1vIgx5mYgcXTRrnYc.png)

Review Comment:
   src - static - images. link should be `![](/images/XX`



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/adjusting-join-shuffle.md:
##########
@@ -24,40 +24,28 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-## 工作原理
+## 概述
 
 Doris 支持使用 Hint 来调整 Join 操作中数据 Shuffle 的类型,从而优化查询性能。本节将详细介绍如何在 Doris 中利用 Hint 
来指定 Join Shuffle 的类型。
 
-目前,Doris 仅限于指定 Join 右表的 Distribute Type,并且仅提供两种类型供选择:`[shuffle] `和 
`[broadcast]`。Distribute Type 需置于 Join 右表之前,可采用中括号 `[]`的方式。
+目前,Doris 支持两种独立的 
[DistributeHint](https://selectdb.feishu.cn/wiki/BpBxwpu07iL4jjkeai1cfs24nrn?open_in_browser=true),`[shuffle]
 ` 和 `[broadcast]`,用来指定 Join 右表的 Distribute Type。Distribute Type 需置于 Join 
右表之前,采用中括号 `[]` 的方式。同时,Doris 也可以通过 LeadingHint 配合 DistributeHint 的方式,指定 shuffle 
方式(详见“使用 Leading Hint 控制 Join 顺序”章节相关介绍)。

Review Comment:
   (../../query-acceleration/hint/sql-cache-manual)



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/accelerating-queries-with-sql-cache.md:
##########
@@ -24,67 +24,14 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-## 工作原理
+## 概述
 
-关于 SQL Cache 详细实现原理,请参考 [查询缓存(SQL 
Cache)](../../../query-acceleration/sql-cache-manual)
+关于 SQL Cache 详细实现原理,请参考 [查询缓存(SQL 
Cache)](https://selectdb.feishu.cn/wiki/GhRhwLOXNi5muzkb5PacLR4Wn6e)

Review Comment:
   (../query-acceleration/sql-cache-manual)



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/dml-tuning-plan.md:
##########
@@ -24,100 +24,6 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-DML 计划调优包括导入部分(INSERT INTO SELECT)与查询部分(CREATE TABLE AS SELECT - 
CTAS)。本小节将分别介绍这两部分的工作原理与调优实践。
+DML 计划调优首先需要定位是导入引起的性能瓶颈,还是查询部分引起的性能瓶颈 。查询部分的性能瓶颈的排查和调优详见计划调优章节其他小节。
 
-## 导入部分
-
-### 工作原理
-
-Apache Doris 提供了多种灵活的数据导入方案,以满足不同场景下的数据接入需求。Doris 支持从以下数据源导入数据:
-
-1. 对象存储(S3)和 HDFS
-
-2. 本地文件
-
-3. Kafka
-
-4. 关系型数据库(如 MySQL、PostgreSQL、Oracle、SQLServer 等)
-
-5. 通过 JDBC 连接的数据源
-
-6. JSON 格式数据
-
-**Doris 提供了以下几种主要的数据导入方式:**
-
-1. Broker Load:通过 Broker 进程导入外部存储系统的数据
-
-2. Stream Load:流式导入本地文件或内存中的数据
-
-3. Routine Load:持续导入 Kafka 中的数据
-
-4. INSERT INTO:通过 SQL 插入语句导入数据
-
-5. S3 Load:直接从支持 S3 协议的对象存储导入数据
-
-6. MySQL Load:使用 MySQL 客户端导入本地数据
-
-**不同的导入方式所支持的数据格式略有差异:**
-
-1. Broker Load:支持 Parquet、ORC、CSV、GZip 格式
-
-2. Stream Load:支持 CSV、JSON、Parquet、ORC 格式
-
-3. Routine Load:支持 CSV、JSON 格式
-
-4. MySQL Load:支持 CSV 格式
-
-**数据的导入具备以下机制:**
-
-1. 原子性保证:每个导入作业都作为一个完整的事务,确保数据的原子性写入。
-
-2. 导入标识:每个导入作业都分配有唯一的 Label,用于确保 At-Most-Once 语义。
-
-3. 同步/异步模式:同步模式会立即返回结果,而异步模式则需要另行查询作业状态。
-
-4. Array 类型支持:可以通过 CAST 和数组函数来导入 Array 类型的数据。
-
-5. 执行引擎:可以根据配置选择是否使用 Pipeline 引擎来执行导入任务。
-
-**在实际应用中,需要注意以下事项:**
-
-1. 合理选择导入方式:针对不同的数据源,选择最合适的导入方法。
-
-2. 利用 Label 机制:实现 Exactly-Once 语义的保证。
-
-3. 适当配置并行度:根据集群资源,调整并行导入的数量。
-
-4. 监控导入状态:对于异步导入,及时查看作业的运行情况。
-
-:::tip 提示
-通过灵活运用 Doris 提供的多种导入功能,可以高效地将各种来源的数据导入到 Doris 
中进行分析。如需了解更多细节,请参考数据[导入概览](../../../data-operate/import/load-manual)
-:::
-
-### 导入优化
-
-Pipeline 引擎是 Doris 中一种新的查询执行引擎,旨在提高查询和数据处理的效率。在数据导入过程中,Pipeline 
引擎同样可以被启用,以提升整体性能。默认情况下,数据导入时 Pipeline 引擎是关闭状态,但用户可以通过相关配置来启用它。
-
-在数据导入中启用 Pipeline 引擎,需配置以下变量:
-
-**1. FE 配置项:enable_pipeline_load**
-
-- 位置:位于 FE(Frontend)的配置文件中
-
-- 作用:启用后,Stream Load 等导入任务将尝试使用 Pipeline 引擎执行
-
-**2. Session 变量:enable_nereids_dml_with_pipeline**
-
-- 位置:在会话级别进行设置
-
-- 作用:启用后,INSERT INTO 语句将尝试使用 Pipeline 引擎执行
-
-**3. Session 变量:enable_pipeline_engine**
-
-- 位置:在会话级别进行设置
-
-- 作用:控制是否实际启用 Pipeline 引擎
-
-## 查询部分
-
-详细请参考[计划调优 - 
其他章节](../../../query-acceleration/tuning/tuning-plan/optimizing-table-schema)
\ No newline at end of file
+Doris 支持从多种数据源导入数据,灵活运用 Doris 提供的多种导入功能,可以高效地将各种来源的数据导入到 Doris 
中进行分析。最佳实践详情请参考[导入概览](https://doris.apache.org/zh-CN/docs/dev/data-operate/import/load-manual/)。

Review Comment:
   ../../data-operate/import/load-manual



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/colocation-join.md:
##########
@@ -0,0 +1,445 @@
+---
+{
+    "title": "Colocation Join",
+    "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.
+-->
+
+
+
+Colocation Join 旨在为某些 Join 查询提供本地性优化,来减少数据在节点间的传输耗时,加速查询。本文档主要介绍 Colocation 
Join 的原理、实现、使用方式和注意事项。  
+
+注意:这个属性不会被 CCR 同步,如果这个表是被 CCR 复制而来的,即 PROPERTIES 中包含`is_being_synced = 
true`时,这个属性将会在这个表中被擦除。
+
+## 名词解释
+
+- Colocation Group(CG):一个 CG 中会包含一张及以上的 Table。在同一个 Group 内的 Table 有着相同的 
Colocation Group Schema,并且有着相同的数据分片分布。
+
+- Colocation Group Schema(CGS):用于描述一个 CG 中的 Table,和 Colocation 相关的通用 Schema 
信息。包括分桶列类型,分桶数以及副本数等。
+
+## 原理
+
+Colocation Join 功能,是将一组拥有相同 CGS 的 Table 组成一个 CG。并保证这些 Table 对应的数据分片会落在同一个 BE 
节点上。使得当 CG 内的表进行分桶列上的 Join 操作时,可以通过直接进行本地数据 Join,减少数据在节点间的传输耗时。
+
+一个表的数据,最终会根据分桶列值 Hash、对桶数取模的后落在某一个分桶内。假设一个 Table 的分桶数为 8,则共有 `[0, 1, 2, 3, 4, 
5, 6, 7]` 8 个分桶(Bucket),我们称这样一个序列为一个 `BucketsSequence`。每个 Bucket 
内会有一个或多个数据分片(Tablet)。当表为单分区表时,一个 Bucket 内仅有一个 Tablet。如果是多分区表,则会有多个。
+
+为了使得 Table 能够有相同的数据分布,同一 CG 内的 Table 必须保证以下属性相同:
+
+1. 分桶列和分桶数
+
+   分桶列,即在建表语句中 `DISTRIBUTED BY HASH(col1, col2, ...)` 
中指定的列。分桶列决定了一张表的数据通过哪些列的值进行 Hash 划分到不同的 Tablet 中。同一 CG 内的 Table 
必须保证分桶列的类型和数量完全一致,并且桶数一致,才能保证多张表的数据分片能够一一对应的进行分布控制。
+
+2. 副本数
+
+   同一个 CG 内所有表的所有分区(Partition)的副本数必须一致。如果不一致,可能出现某一个 Tablet 的某一个副本,在同一个 BE 
上没有其他的表分片的副本对应。
+
+同一个 CG 内的表,分区的个数、范围以及分区列的类型不要求一致。
+
+在固定了分桶列和分桶数后,同一个 CG 内的表会拥有相同的 BucketsSequence。而副本数决定了每个分桶内的 Tablet 的多个副本,存放在哪些 
BE 上。假设 BucketsSequence 为 `[0, 1, 2, 3, 4, 5, 6, 7]`,BE 节点有 `[A, B, C, D]` 4 
个。则一个可能的数据分布如下:
+
+```text
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| A | | B | | C | | D | | A | | B | | C | | D |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| B | | C | | D | | A | | B | | C | | D | | A |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| C | | D | | A | | B | | C | | D | | A | | B |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+```
+
+CG 内所有表的数据都会按照上面的规则进行统一分布,这样就保证了,分桶列值相同的数据都在同一个 BE 节点上,可以进行本地数据 Join。
+
+## 使用方式
+
+### 建表
+
+建表时,可以在 `PROPERTIES` 中指定属性 `"colocate_with" = "group_name"`,表示这个表是一个 
Colocation Join 表,并且归属于一个指定的 Colocation Group。
+
+示例:
+
+```sql
+CREATE TABLE tbl (k1 int, v1 int sum)
+DISTRIBUTED BY HASH(k1)
+BUCKETS 8
+PROPERTIES(
+    "colocate_with" = "group1"
+);
+```
+
+如果指定的 Group 不存在,则 Doris 会自动创建一个只包含当前这张表的 Group。如果 Group 已存在,则 Doris 会检查当前表是否满足 
Colocation Group Schema。如果满足,则会创建该表,并将该表加入 Group。同时,表会根据已存在的 Group 
中的数据分布规则创建分片和副本。Group 归属于一个 Database,Group 的名字在一个 Database 内唯一。在内部存储是 Group 
的全名为 `dbId_groupName`,但用户只感知 groupName。
+
+
+
+:::tip
+2.0 版本中,Doris 支持了跨 Database 的 Group。
+:::
+
+在建表时,需使用关键词 `__global__` 作为 Group 名称的前缀。如:
+
+```
+CREATE TABLE tbl (k1 int, v1 int sum)
+DISTRIBUTED BY HASH(k1)
+BUCKETS 8
+PROPERTIES(
+    "colocate_with" = "__global__group1"
+);
+```
+
+`__global__` 前缀的 Group 不再归属于一个 Database,其名称也是全局唯一的。
+
+通过创建 Global Group,可以实现跨 Database 的 Colocate Join。
+
+
+
+### 删表
+
+当 Group 中最后一张表彻底删除后(彻底删除是指从回收站中删除。通常,一张表通过 `DROP TABLE` 
命令删除后,会在回收站默认停留一天的时间后,再删除),该 Group 也会被自动删除。
+
+### 查看 Group
+
+以下命令可以查看集群内已存在的 Group 信息。
+
+```sql
+SHOW PROC '/colocation_group';
+
++-------------+--------------+--------------+------------+----------------+----------+----------+
+| GroupId     | GroupName    | TableIds     | BucketsNum | ReplicationNum | 
DistCols | IsStable |
++-------------+--------------+--------------+------------+----------------+----------+----------+
+| 10005.10008 | 10005_group1 | 10007, 10040 | 10         | 3              | 
int(11)  | true     |
++-------------+--------------+--------------+------------+----------------+----------+----------+
+```
+
+- GroupId:一个 Group 的全集群唯一标识,前半部分为 db id,后半部分为 group id。
+
+- GroupName:Group 的全名。
+
+- TabletIds:该 Group 包含的 Table 的 id 列表。
+
+- BucketsNum:分桶数。
+
+- ReplicationNum:副本数。
+
+- DistCols:Distribution columns,即分桶列类型。
+
+- IsStable:该 Group 是否稳定(稳定的定义,见 `Colocation 副本均衡和修复` 一节)。
+
+通过以下命令可以进一步查看一个 Group 的数据分布情况:
+
+```sql
+SHOW PROC '/colocation_group/10005.10008';
+
++-------------+---------------------+
+| BucketIndex | BackendIds          |
++-------------+---------------------+
+| 0           | 10004, 10002, 10001 |
+| 1           | 10003, 10002, 10004 |
+| 2           | 10002, 10004, 10001 |
+| 3           | 10003, 10002, 10004 |
+| 4           | 10002, 10004, 10003 |
+| 5           | 10003, 10002, 10001 |
+| 6           | 10003, 10004, 10001 |
+| 7           | 10003, 10004, 10002 |
++-------------+---------------------+
+```
+
+- BucketIndex:分桶序列的下标。
+
+- BackendIds:分桶中数据分片所在的 BE 节点 id 列表。
+
+:::note

Review Comment:
   :::info 备注



##########
i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/colocation-join.md:
##########
@@ -0,0 +1,445 @@
+---
+{
+    "title": "Colocation Join",
+    "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.
+-->
+
+
+
+Colocation Join 旨在为某些 Join 查询提供本地性优化,来减少数据在节点间的传输耗时,加速查询。本文档主要介绍 Colocation 
Join 的原理、实现、使用方式和注意事项。  
+
+注意:这个属性不会被 CCR 同步,如果这个表是被 CCR 复制而来的,即 PROPERTIES 中包含`is_being_synced = 
true`时,这个属性将会在这个表中被擦除。
+
+## 名词解释
+
+- Colocation Group(CG):一个 CG 中会包含一张及以上的 Table。在同一个 Group 内的 Table 有着相同的 
Colocation Group Schema,并且有着相同的数据分片分布。
+
+- Colocation Group Schema(CGS):用于描述一个 CG 中的 Table,和 Colocation 相关的通用 Schema 
信息。包括分桶列类型,分桶数以及副本数等。
+
+## 原理
+
+Colocation Join 功能,是将一组拥有相同 CGS 的 Table 组成一个 CG。并保证这些 Table 对应的数据分片会落在同一个 BE 
节点上。使得当 CG 内的表进行分桶列上的 Join 操作时,可以通过直接进行本地数据 Join,减少数据在节点间的传输耗时。
+
+一个表的数据,最终会根据分桶列值 Hash、对桶数取模的后落在某一个分桶内。假设一个 Table 的分桶数为 8,则共有 `[0, 1, 2, 3, 4, 
5, 6, 7]` 8 个分桶(Bucket),我们称这样一个序列为一个 `BucketsSequence`。每个 Bucket 
内会有一个或多个数据分片(Tablet)。当表为单分区表时,一个 Bucket 内仅有一个 Tablet。如果是多分区表,则会有多个。
+
+为了使得 Table 能够有相同的数据分布,同一 CG 内的 Table 必须保证以下属性相同:
+
+1. 分桶列和分桶数
+
+   分桶列,即在建表语句中 `DISTRIBUTED BY HASH(col1, col2, ...)` 
中指定的列。分桶列决定了一张表的数据通过哪些列的值进行 Hash 划分到不同的 Tablet 中。同一 CG 内的 Table 
必须保证分桶列的类型和数量完全一致,并且桶数一致,才能保证多张表的数据分片能够一一对应的进行分布控制。
+
+2. 副本数
+
+   同一个 CG 内所有表的所有分区(Partition)的副本数必须一致。如果不一致,可能出现某一个 Tablet 的某一个副本,在同一个 BE 
上没有其他的表分片的副本对应。
+
+同一个 CG 内的表,分区的个数、范围以及分区列的类型不要求一致。
+
+在固定了分桶列和分桶数后,同一个 CG 内的表会拥有相同的 BucketsSequence。而副本数决定了每个分桶内的 Tablet 的多个副本,存放在哪些 
BE 上。假设 BucketsSequence 为 `[0, 1, 2, 3, 4, 5, 6, 7]`,BE 节点有 `[A, B, C, D]` 4 
个。则一个可能的数据分布如下:
+
+```text
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+| A | | B | | C | | D | | A | | B | | C | | D |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| B | | C | | D | | A | | B | | C | | D | | A |
+|   | |   | |   | |   | |   | |   | |   | |   |
+| C | | D | | A | | B | | C | | D | | A | | B |
++---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
+```
+
+CG 内所有表的数据都会按照上面的规则进行统一分布,这样就保证了,分桶列值相同的数据都在同一个 BE 节点上,可以进行本地数据 Join。
+
+## 使用方式
+
+### 建表
+
+建表时,可以在 `PROPERTIES` 中指定属性 `"colocate_with" = "group_name"`,表示这个表是一个 
Colocation Join 表,并且归属于一个指定的 Colocation Group。
+
+示例:
+
+```sql
+CREATE TABLE tbl (k1 int, v1 int sum)
+DISTRIBUTED BY HASH(k1)
+BUCKETS 8
+PROPERTIES(
+    "colocate_with" = "group1"
+);
+```
+
+如果指定的 Group 不存在,则 Doris 会自动创建一个只包含当前这张表的 Group。如果 Group 已存在,则 Doris 会检查当前表是否满足 
Colocation Group Schema。如果满足,则会创建该表,并将该表加入 Group。同时,表会根据已存在的 Group 
中的数据分布规则创建分片和副本。Group 归属于一个 Database,Group 的名字在一个 Database 内唯一。在内部存储是 Group 
的全名为 `dbId_groupName`,但用户只感知 groupName。
+
+
+
+:::tip

Review Comment:
   :::tip 提示



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org


Reply via email to