Skip to content

Commit 0d05f1d

Browse files
AI Translate 81-how-databend-works to Simplified-Chinese (#2415)
* [INIT] Start translation to Simplified-Chinese * 🌐 Translate _category_.json to Simplified-Chinese * 🌐 Translate _category_.json to Simplified-Chinese * 🌐 Translate _category_.json to Simplified-Chinese * 🌐 Translate _category_.json to Simplified-Chinese * 🌐 Translate _category_.json to Simplified-Chinese * 🌐 Translate _category_.json to Simplified-Chinese --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
1 parent 6bc8399 commit 0d05f1d

File tree

7 files changed

+360
-350
lines changed

7 files changed

+360
-350
lines changed

.translation-init

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
Translation initialization: 2025-06-07T11:38:44.688685
1+
Translation initialization: 2025-06-08T04:07:45.539834

docs/cn/guides/81-how-databend-works/01-how-databend-fuse-engine-works.md

Lines changed: 77 additions & 69 deletions
Large diffs are not rendered by default.

docs/cn/guides/81-how-databend-works/02-how-databend-optimizer-works.md

Lines changed: 138 additions & 138 deletions
Large diffs are not rendered by default.

docs/cn/guides/81-how-databend-works/03-how-databend-json-variant-works.md

Lines changed: 95 additions & 94 deletions
Large diffs are not rendered by default.
Lines changed: 47 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -1,134 +1,135 @@
1-
title: Databend 免拷贝数据共享 (Data Sharing) 工作原理
1+
---
2+
title: Databend 免拷贝数据共享(Copy-Free Data Sharing)的工作原理
23
---
34

4-
## 什么是数据共享 (Data Sharing)
5+
## 什么是数据共享Data Sharing
56

6-
不同团队通常需要访问同一份数据的不同部分。传统解决方案通过多次复制数据来满足需求,但这种方式成本高昂且难以维护
7+
不同团队需要相同数据的不同部分。传统解决方案会多次复制数据——成本高昂且难以维护
78

8-
Databend 的 **[ATTACH TABLE](/sql/sql-commands/ddl/table/attach-table)** 命令优雅地解决了这个问题:它能为同一份数据创建多个“视图”,而无需进行物理复制。这得益于 Databend **真正的存算分离**架构——无论是使用云存储还是本地对象存储,都能实现**一次存储,随处访问**
9+
Databend 的 **[ATTACH TABLE](/sql/sql-commands/ddl/table/attach-table)** 优雅地解决了这个问题:为相同数据创建多个"视图"(View)而无需复制。这利用了 Databend **真正计算存储分离**架构——无论使用云存储还是本地对象存储:**存储一次,随处访问**
910

10-
您可以将 `ATTACH TABLE` 理解为操作系统的快捷方式——它仅仅指向原始文件,并不会复制文件本身
11+
可以将 ATTACH TABLE 想象成计算机快捷方式——它们指向原始文件而不复制它
1112

1213
```
13-
对象存储 (Object Storage),如 S3、MinIOAzure
14+
对象存储Object Storage)(S3, MinIO, Azure, 等)
1415
┌─────────────┐
15-
原始数据
16+
您的数据
1617
└──────┬──────┘
1718
1819
┌───────────────────────┼───────────────────────┐
1920
│ │ │
2021
▼ ▼ ▼
2122
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
22-
│ 营销团队 │ │ 财务团队 │ │ 销售团队 │
23+
营销团队 │ │ 财务团队 │ │ 销售团队 │
2324
│ 视图 │ │ 视图 │ │ 视图 │
2425
└─────────────┘ └─────────────┘ └─────────────┘
2526
```
2627

2728
## 如何使用 ATTACH TABLE
2829

29-
**步骤 1:获取数据位置**
30+
**步骤 1:查找数据位置**
3031
```sql
3132
SELECT snapshot_location FROM FUSE_SNAPSHOT('default', 'company_sales');
32-
-- 结果: 1/23351/_ss/... → 数据位于 s3://your-bucket/1/23351/
33+
-- 结果1/23351/_ss/... → 数据位于 s3://your-bucket/1/23351/
3334
```
3435

35-
**步骤 2:为不同团队创建专属视图**
36+
**步骤 2:创建团队特定视图**
3637
```sql
37-
-- 营销团队:用于客户行为分析
38+
-- 营销:客户行为分析
3839
ATTACH TABLE marketing_view (customer_id, product, amount, order_date)
3940
's3://your-bucket/1/23351/' CONNECTION = (ACCESS_KEY_ID = 'xxx', SECRET_ACCESS_KEY = 'yyy');
4041

41-
-- 财务团队:用于收入跟踪
42+
-- 财务:收入跟踪
4243
ATTACH TABLE finance_view (order_id, amount, profit, order_date)
4344
's3://your-bucket/1/23351/' CONNECTION = (ACCESS_KEY_ID = 'xxx', SECRET_ACCESS_KEY = 'yyy');
4445

45-
-- 人力资源团队:仅含员工信息,不含薪资
46+
-- 人力资源:不包含薪资的员工信息
4647
ATTACH TABLE hr_employees (employee_id, name, department)
4748
's3://data/1/23351/' CONNECTION = (...);
4849

49-
-- 开发团队:访问生产环境表结构,但不含敏感数据
50+
-- 开发:不包含敏感数据的生产结构
5051
ATTACH TABLE dev_customers (customer_id, country, created_date)
5152
's3://data/1/23351/' CONNECTION = (...);
5253
```
5354

54-
**步骤 3:独立查询数据**
55+
**步骤 3:独立查询**
5556
```sql
56-
-- 营销团队分析消费趋势
57+
-- 营销分析趋势
5758
SELECT product, COUNT(*) FROM marketing_view GROUP BY product;
5859

59-
-- 财务团队跟踪利润
60+
-- 财务跟踪利润
6061
SELECT order_date, SUM(profit) FROM finance_view GROUP BY order_date;
6162
```
6263

63-
## 核心优势
64+
## 主要优势
6465

65-
**实时更新**源数据一旦变更,所有附加表都能即时感知。
66+
**实时更新**当源数据更改时,所有附加表立即看到变化
6667
```sql
6768
INSERT INTO company_sales VALUES (1001, 501, 'Laptop', 1299.99, 299.99, '[email protected]', '2025-01-20');
6869
SELECT COUNT(*) FROM marketing_view WHERE order_date = '2024-01-20'; -- 返回:1
6970
```
7071

71-
**列级安全性**各团队只能看到其所需的数据——例如,营销团队无法查看利润,财务团队也无法访问客户的电子邮件地址。
72+
**列级安全性**团队只能看到需要的内容——营销看不到利润,财务看不到客户邮箱
7273

73-
**强一致性**查询操作永远不会读取到部分更新的数据,确保看到的是完整的快照 (Snapshot)——这对于财务报告和合规性审计至关重要。
74+
**强一致性**永远不会读取部分更新,始终看到完整快照——非常适合财务报告和合规性
7475

75-
**完整性能**:所有索引 (Index) 自动生效,查询性能与操作常规表完全相同。
76+
**完整性能**:所有索引Index)自动工作,与常规表相同的速度
7677

77-
## 该功能为何如此重要
78+
## 为什么这很重要
7879

7980
| 传统方法 | Databend ATTACH TABLE |
80-
|---------------------|----------------------|
81-
| 存在多个数据副本 | 所有团队共享单一数据副本 |
82-
| 存在 ETL 延迟和同步问题 | 数据实时、始终保持最新 |
83-
| 维护工作复杂 | 零维护成本 |
84-
| 副本越多,安全风险越高 | 支持细粒度的列级访问控制 |
85-
| 因数据移动导致性能下降 | 基于原始数据进行全面优化 |
81+
|---------|----------------------|
82+
| 多个数据副本 | 所有人共享单个副本 |
83+
| ETL 延迟,同步问题 | 实时,始终最新 |
84+
| 复杂维护 | 零维护 |
85+
| 更多副本 = 更多安全风险 | 细粒度列访问 |
86+
| 由于数据移动而变慢 | 对原始数据进行完整优化 |
8687

8788
## 底层工作原理
8889

8990
```
90-
查询:SELECT product, SUM(amount) FROM marketing_view GROUP BY product
91+
查询(Query):SELECT product, SUM(amount) FROM marketing_view GROUP BY product
9192
9293
┌─────────────────────────────────────────────────────────────────┐
93-
查询执行流程
94+
查询执行流程
9495
└─────────────────────────────────────────────────────────────────┘
9596
9697
用户查询
9798
9899
99100
┌───────────────────┐ ┌─────────────────────────────────────┐
100-
│ 1. 读取快照元数据 │───►│ s3://bucket/1/23351/_ss/ │
101-
│ │ 获取表的当前状态
101+
│ 1. 读取快照 │───►│ s3://bucket/1/23351/_ss/ │
102+
(Snapshot) │ 获取当前表状态
102103
└───────────────────┘ └─────────────────────────────────────┘
103104
104105
105106
┌───────────────────┐ ┌─────────────────────────────────────┐
106-
│ 2. 应用列过滤器 │───►│ 筛选条件: customer_id, product, │
107-
│ │ amount, order_date │
107+
│ 2. 应用列 │───►│ 过滤器:customer_id, product,
108+
过滤器 │ │ amount, order_date
108109
└───────────────────┘ └─────────────────────────────────────┘
109110
110111
111112
┌───────────────────┐ ┌─────────────────────────────────────┐
112-
│ 3. 检查统计信息与 │───►│ • 段 (Segment) 的最小/最大值 │
113-
索引 │ │ • 布隆过滤器 (Bloom Filter)
114-
└───────────────────┘ │ • 聚合索引 (Aggregate Index)
113+
│ 3. 检查统计信息 │───►│ • 段最小/最大值
114+
和索引 │ │ • 布隆过滤器Bloom Filter
115+
└───────────────────┘ │ • 聚合索引Aggregate Index
115116
│ └─────────────────────────────────────┘
116117
117118
┌───────────────────┐ ┌─────────────────────────────────────┐
118-
│ 4. 智能数据获取 │───►│ 跳过不相关的数据块
119-
│ │ 仅从 _b/ 目录下载所需数据
119+
│ 4. 智能数据 │───►│ 跳过无关块
120+
获取 │ │ 仅从 _b/ 下载所需数据
120121
└───────────────────┘ └─────────────────────────────────────┘
121122
122123
123124
┌───────────────────┐ ┌─────────────────────────────────────┐
124-
│ 5. 本地执行 │───►│ 全面的查询优化与并行处理
125-
│ │ │ 利用所有可用索引进行数据处理
125+
│ 5. 本地 │───►│ 完整优化和并行处理
126+
执行 使用所有可用索引进行处理
126127
└───────────────────┘ └─────────────────────────────────────┘
127128
128129
129-
返回结果:产品销售摘要
130+
结果:产品销售摘要
130131
```
131132

132-
多个 Databend 集群可以同时执行此流程而无需相互协调,这正是存算分离架构强大能力的体现
133+
多个 Databend 集群可以同时执行此流程而无需协调——真正的计算存储分离在实际应用中
133134

134-
`ATTACH TABLE` 代表了一种根本性的转变**从“为每个用例复制一份数据”转向“一份数据,多个视图”**无论是在云端还是本地环境中,Databend 的架构都能实现强大、高效的数据共享 (Data Sharing),同时保持企业级的一致性与安全性
135+
ATTACH TABLE 代表了一个根本性转变**从为每个用例复制数据转向一个副本多个视图**无论在云环境还是本地环境中,Databend 的架构都能实现强大、高效的数据共享,同时保持企业级一致性和安全性
Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,3 @@
11
{
22
"label": "Databend 工作原理"
3-
}
3+
}

docs/cn/guides/81-how-databend-works/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
title: Databend 工作原理
33
---
44

5-
深入了解 Databend 的架构 (Architecture)、存储引擎 (Storage Engine) 和查询执行 (Query Execution)
5+
深入了解 Databend 的架构、存储引擎和查询执行的技术细节
66

77
import IndexOverviewList from '@site/src/components/IndexOverviewList';
88

0 commit comments

Comments
 (0)