|
1 |
| -title: Databend 免拷贝数据共享 (Data Sharing) 工作原理 |
| 1 | +--- |
| 2 | +title: Databend 免拷贝数据共享(Copy-Free Data Sharing)的工作原理 |
2 | 3 | ---
|
3 | 4 |
|
4 |
| -## 什么是数据共享 (Data Sharing)? |
| 5 | +## 什么是数据共享(Data Sharing)? |
5 | 6 |
|
6 |
| -不同团队通常需要访问同一份数据的不同部分。传统解决方案通过多次复制数据来满足需求,但这种方式成本高昂且难以维护。 |
| 7 | +不同团队需要相同数据的不同部分。传统解决方案会多次复制数据——成本高昂且难以维护。 |
7 | 8 |
|
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 的**真正计算存储分离**架构——无论使用云存储还是本地对象存储:**存储一次,随处访问**。 |
9 | 10 |
|
10 |
| -您可以将 `ATTACH TABLE` 理解为操作系统的快捷方式——它仅仅指向原始文件,并不会复制文件本身。 |
| 11 | +可以将 ATTACH TABLE 想象成计算机快捷方式——它们指向原始文件而不复制它。 |
11 | 12 |
|
12 | 13 | ```
|
13 |
| - 对象存储 (Object Storage),如 S3、MinIO、Azure 等 |
| 14 | + 对象存储(Object Storage)(S3, MinIO, Azure, 等) |
14 | 15 | ┌─────────────┐
|
15 |
| - │ 原始数据 │ |
| 16 | + │ 您的数据 │ |
16 | 17 | └──────┬──────┘
|
17 | 18 | │
|
18 | 19 | ┌───────────────────────┼───────────────────────┐
|
19 | 20 | │ │ │
|
20 | 21 | ▼ ▼ ▼
|
21 | 22 | ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
22 |
| -│ 营销团队 │ │ 财务团队 │ │ 销售团队 │ |
| 23 | +│ 营销团队 │ │ 财务团队 │ │ 销售团队 │ |
23 | 24 | │ 视图 │ │ 视图 │ │ 视图 │
|
24 | 25 | └─────────────┘ └─────────────┘ └─────────────┘
|
25 | 26 | ```
|
26 | 27 |
|
27 | 28 | ## 如何使用 ATTACH TABLE
|
28 | 29 |
|
29 |
| -**步骤 1:获取数据位置** |
| 30 | +**步骤 1:查找数据位置** |
30 | 31 | ```sql
|
31 | 32 | 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/ |
33 | 34 | ```
|
34 | 35 |
|
35 |
| -**步骤 2:为不同团队创建专属视图** |
| 36 | +**步骤 2:创建团队特定视图** |
36 | 37 | ```sql
|
37 |
| --- 营销团队:用于客户行为分析 |
| 38 | +-- 营销:客户行为分析 |
38 | 39 | ATTACH TABLE marketing_view (customer_id, product, amount, order_date)
|
39 | 40 | 's3://your-bucket/1/23351/' CONNECTION = (ACCESS_KEY_ID = 'xxx', SECRET_ACCESS_KEY = 'yyy');
|
40 | 41 |
|
41 |
| --- 财务团队:用于收入跟踪 |
| 42 | +-- 财务:收入跟踪 |
42 | 43 | ATTACH TABLE finance_view (order_id, amount, profit, order_date)
|
43 | 44 | 's3://your-bucket/1/23351/' CONNECTION = (ACCESS_KEY_ID = 'xxx', SECRET_ACCESS_KEY = 'yyy');
|
44 | 45 |
|
45 |
| --- 人力资源团队:仅含员工信息,不含薪资 |
| 46 | +-- 人力资源:不包含薪资的员工信息 |
46 | 47 | ATTACH TABLE hr_employees (employee_id, name, department)
|
47 | 48 | 's3://data/1/23351/' CONNECTION = (...);
|
48 | 49 |
|
49 |
| --- 开发团队:访问生产环境表结构,但不含敏感数据 |
| 50 | +-- 开发:不包含敏感数据的生产结构 |
50 | 51 | ATTACH TABLE dev_customers (customer_id, country, created_date)
|
51 | 52 | 's3://data/1/23351/' CONNECTION = (...);
|
52 | 53 | ```
|
53 | 54 |
|
54 |
| -**步骤 3:独立查询数据** |
| 55 | +**步骤 3:独立查询** |
55 | 56 | ```sql
|
56 |
| --- 营销团队分析消费趋势 |
| 57 | +-- 营销分析趋势 |
57 | 58 | SELECT product, COUNT(*) FROM marketing_view GROUP BY product;
|
58 | 59 |
|
59 |
| --- 财务团队跟踪利润 |
| 60 | +-- 财务跟踪利润 |
60 | 61 | SELECT order_date, SUM(profit) FROM finance_view GROUP BY order_date;
|
61 | 62 | ```
|
62 | 63 |
|
63 |
| -## 核心优势 |
| 64 | +## 主要优势 |
64 | 65 |
|
65 |
| -**实时更新**:源数据一旦变更,所有附加表都能即时感知。 |
| 66 | +**实时更新**:当源数据更改时,所有附加表立即看到变化 |
66 | 67 | ```sql
|
67 | 68 | INSERT INTO company_sales VALUES ( 1001, 501, 'Laptop', 1299. 99, 299. 99, '[email protected]', '2025-01-20');
|
68 | 69 | SELECT COUNT(*) FROM marketing_view WHERE order_date = '2024-01-20'; -- 返回:1
|
69 | 70 | ```
|
70 | 71 |
|
71 |
| -**列级安全性**:各团队只能看到其所需的数据——例如,营销团队无法查看利润,财务团队也无法访问客户的电子邮件地址。 |
| 72 | +**列级安全性**:团队只能看到需要的内容——营销看不到利润,财务看不到客户邮箱 |
72 | 73 |
|
73 |
| -**强一致性**:查询操作永远不会读取到部分更新的数据,确保看到的是完整的快照 (Snapshot)——这对于财务报告和合规性审计至关重要。 |
| 74 | +**强一致性**:永远不会读取部分更新,始终看到完整快照——非常适合财务报告和合规性 |
74 | 75 |
|
75 |
| -**完整性能**:所有索引 (Index) 自动生效,查询性能与操作常规表完全相同。 |
| 76 | +**完整性能**:所有索引(Index)自动工作,与常规表相同的速度 |
76 | 77 |
|
77 |
| -## 该功能为何如此重要 |
| 78 | +## 为什么这很重要 |
78 | 79 |
|
79 | 80 | | 传统方法 | Databend ATTACH TABLE |
|
80 |
| -|---------------------|----------------------| |
81 |
| -| 存在多个数据副本 | 所有团队共享单一数据副本 | |
82 |
| -| 存在 ETL 延迟和同步问题 | 数据实时、始终保持最新 | |
83 |
| -| 维护工作复杂 | 零维护成本 | |
84 |
| -| 副本越多,安全风险越高 | 支持细粒度的列级访问控制 | |
85 |
| -| 因数据移动导致性能下降 | 基于原始数据进行全面优化 | |
| 81 | +|---------|----------------------| |
| 82 | +| 多个数据副本 | 所有人共享单个副本 | |
| 83 | +| ETL 延迟,同步问题 | 实时,始终最新 | |
| 84 | +| 复杂维护 | 零维护 | |
| 85 | +| 更多副本 = 更多安全风险 | 细粒度列访问 | |
| 86 | +| 由于数据移动而变慢 | 对原始数据进行完整优化 | |
86 | 87 |
|
87 | 88 | ## 底层工作原理
|
88 | 89 |
|
89 | 90 | ```
|
90 |
| -查询:SELECT product, SUM(amount) FROM marketing_view GROUP BY product |
| 91 | +查询(Query):SELECT product, SUM(amount) FROM marketing_view GROUP BY product |
91 | 92 |
|
92 | 93 | ┌─────────────────────────────────────────────────────────────────┐
|
93 |
| -│ 查询执行流程 │ |
| 94 | +│ 查询执行流程 │ |
94 | 95 | └─────────────────────────────────────────────────────────────────┘
|
95 | 96 |
|
96 | 97 | 用户查询
|
97 | 98 | │
|
98 | 99 | ▼
|
99 | 100 | ┌───────────────────┐ ┌─────────────────────────────────────┐
|
100 |
| -│ 1. 读取快照元数据 │───►│ s3://bucket/1/23351/_ss/ │ |
101 |
| -│ │ │ 获取表的当前状态 │ |
| 101 | +│ 1. 读取快照 │───►│ s3://bucket/1/23351/_ss/ │ |
| 102 | +│ (Snapshot) │ │ 获取当前表状态 │ |
102 | 103 | └───────────────────┘ └─────────────────────────────────────┘
|
103 | 104 | │
|
104 | 105 | ▼
|
105 | 106 | ┌───────────────────┐ ┌─────────────────────────────────────┐
|
106 |
| -│ 2. 应用列过滤器 │───►│ 筛选条件: customer_id, product, │ |
107 |
| -│ │ │ amount, order_date │ |
| 107 | +│ 2. 应用列 │───►│ 过滤器:customer_id, product, │ |
| 108 | +│ 过滤器 │ │ amount, order_date │ |
108 | 109 | └───────────────────┘ └─────────────────────────────────────┘
|
109 | 110 | │
|
110 | 111 | ▼
|
111 | 112 | ┌───────────────────┐ ┌─────────────────────────────────────┐
|
112 |
| -│ 3. 检查统计信息与 │───►│ • 段 (Segment) 的最小/最大值 │ |
113 |
| -│ 索引 │ │ • 布隆过滤器 (Bloom Filter) │ |
114 |
| -└───────────────────┘ │ • 聚合索引 (Aggregate Index) │ |
| 113 | +│ 3. 检查统计信息 │───►│ • 段最小/最大值 │ |
| 114 | +│ 和索引 │ │ • 布隆过滤器(Bloom Filter) │ |
| 115 | +└───────────────────┘ │ • 聚合索引(Aggregate Index) │ |
115 | 116 | │ └─────────────────────────────────────┘
|
116 | 117 | ▼
|
117 | 118 | ┌───────────────────┐ ┌─────────────────────────────────────┐
|
118 |
| -│ 4. 智能数据获取 │───►│ 跳过不相关的数据块 │ |
119 |
| -│ │ │ 仅从 _b/ 目录下载所需数据 │ |
| 119 | +│ 4. 智能数据 │───►│ 跳过无关块 │ |
| 120 | +│ 获取 │ │ 仅从 _b/ 下载所需数据 │ |
120 | 121 | └───────────────────┘ └─────────────────────────────────────┘
|
121 | 122 | │
|
122 | 123 | ▼
|
123 | 124 | ┌───────────────────┐ ┌─────────────────────────────────────┐
|
124 |
| -│ 5. 本地执行 │───►│ 全面的查询优化与并行处理 │ |
125 |
| -│ │ │ 利用所有可用索引进行数据处理 │ |
| 125 | +│ 5. 本地 │───►│ 完整优化和并行处理 │ |
| 126 | +│ 执行 │ │ 使用所有可用索引进行处理 │ |
126 | 127 | └───────────────────┘ └─────────────────────────────────────┘
|
127 | 128 | │
|
128 | 129 | ▼
|
129 |
| - 返回结果:产品销售摘要 |
| 130 | + 结果:产品销售摘要 |
130 | 131 | ```
|
131 | 132 |
|
132 |
| -多个 Databend 集群可以同时执行此流程而无需相互协调,这正是存算分离架构强大能力的体现。 |
| 133 | +多个 Databend 集群可以同时执行此流程而无需协调——真正的计算存储分离在实际应用中。 |
133 | 134 |
|
134 |
| -`ATTACH TABLE` 代表了一种根本性的转变:**从“为每个用例复制一份数据”转向“一份数据,多个视图”**。无论是在云端还是本地环境中,Databend 的架构都能实现强大、高效的数据共享 (Data Sharing),同时保持企业级的一致性与安全性。 |
| 135 | +ATTACH TABLE 代表了一个根本性转变:**从为每个用例复制数据转向一个副本多个视图**。无论在云环境还是本地环境中,Databend 的架构都能实现强大、高效的数据共享,同时保持企业级一致性和安全性。 |
0 commit comments