Skip to content

Commit 12f9063

Browse files
xiaomeng79xiaomeng79
committed
init
1 parent 1d9b9d8 commit 12f9063

File tree

6 files changed

+661
-34
lines changed

6 files changed

+661
-34
lines changed

‎02数据存取/10clickhouse.md‎

Lines changed: 181 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,159 @@
55
- [ClickHouse](https://github.com/ClickHouse/ClickHouse)
66
- [使用场景](https://zhuanlan.zhihu.com/p/98439924)
77

8+
# **ClickHouse 原理详细介绍**
9+
10+
ClickHouse 是一个开源的 **列式存储** 数据库管理系统，专为 **实时分析** 设计，具有 **高性能 OLAP（Online Analytical Processing）查询** 能力。它主要用于处理大规模数据的实时分析，如日志数据、金融交易、区块链数据等。
11+
12+
---
13+
14+
## **1️⃣ ClickHouse 体系架构**
15+
ClickHouse 采用 **Shared-Nothing 分布式架构**，每个节点都可以独立运行，并通过分片（Sharding）和副本（Replication）提升可用性和性能。
16+
17+
### **🔹 主要组件**
18+
- **MergeTree 存储引擎**：核心存储引擎，支持数据的列式存储和分区管理，适用于大规模数据处理。
19+
- **SQL 查询优化器**：支持 `ORDER BY`、`GROUP BY`、`bloom_filter` 等优化策略，提升查询效率。
20+
- **分布式计算**：通过 `Distributed` 表实现数据的水平扩展。
21+
- **高效索引机制**：包括 **主键索引（Primary Index）、稀疏索引（Sparse Index）、跳跃索引（Skip Index）**，减少 I/O 读取量。
22+
- **数据压缩**：ClickHouse 使用多种压缩算法（如 LZ4、ZSTD）减少存储占用，提高查询性能。
23+
24+
---
25+
26+
## **2️⃣ ClickHouse 的存储原理**
27+
ClickHouse 采用 **列式存储（Columnar Storage）**，与传统 **行存储（Row-Based Storage）** 不同：
28+
- **列存储**：仅存储查询所需的列，减少 I/O 读取，加速聚合查询。
29+
- **高效压缩**：相同类型的数据存储在一起，压缩率更高。
30+
- **批量处理**：优化 `GROUP BY`、`ORDER BY` 操作，提升计算效率。
31+
32+
### **🔹 MergeTree 存储引擎**
33+
`MergeTree` 是 ClickHouse 最常用的存储引擎，提供 **分区（Partitioning）、索引（Primary Index）、数据合并（Merge）** 等功能。
34+
35+
#### **🌟 MergeTree 关键特性**
36+
| **特性** | **描述** |
37+
|----------------------|--------|
38+
| **分区（Partitioning）** | 通过 `PARTITION BY` 定义数据存储分区，提升查询效率 |
39+
| **主键索引（Primary Index）** | 采用稀疏索引，仅存储部分数据，提高查询速度 |
40+
| **数据合并（Merge）** | 后台自动合并数据文件，提升存储效率 |
41+
| **TTL 过期删除（TTL Expiry）** | 自动清理历史数据，减少存储成本 |
42+
43+
---
44+
45+
## **3️⃣ ClickHouse 的查询优化**
46+
ClickHouse 针对大规模数据查询进行了深度优化：
47+
48+
### **🔹 索引机制**
49+
- **主键索引（Primary Index）**：基于 `ORDER BY` 维护的索引，加速范围查询。
50+
- **跳跃索引（Skip Index）**：跳过不必要的数据块，减少 I/O。
51+
- **bloom_filter**：加速 `WHERE` 过滤条件匹配。
52+
53+
### **🔹 查询优化策略**
54+
| **优化点** | **描述** |
55+
|------------------|--------|
56+
| **向量化执行** | 采用 SIMD 指令加速计算 |
57+
| **预计算（Materialized View）** | 通过物化视图存储聚合结果，提高查询性能 |
58+
| **分布式查询（Distributed Query）** | 通过分片加速大规模数据查询 |
59+
| **并行查询（Parallel Query）** | 多核并行处理 SQL，提高执行速度 |
60+
61+
---
62+
63+
64+
### **🔹 ClickHouse vs 其他数据库**
65+
| **对比项** | **ClickHouse** | **MySQL** | **StarRocks** |
66+
|---------------|-------------|----------|-------------|
67+
| **存储模型** | 列式存储 | 行式存储 | 列式存储 |
68+
| **查询性能** | 高并发、OLAP | 适用于 OLTP | 高并发、实时分析 |
69+
| **索引机制** | 主键索引、跳跃索引 | B+ 树索引 | 主键索引、物化视图 |
70+
| **实时性** | 主要用于批处理 | 事务处理 | 近实时分析 |
71+
| **适用场景** | 日志分析、BI、金融数据 | 事务处理 | 实时数据分析 |
72+
73+
---
74+
75+
## **5️⃣ ClickHouse 的优缺点**
76+
### **✅ 优势**
77+
- **超高查询性能**：列式存储 + 并行计算，查询速度远超传统数据库。
78+
- **高效数据压缩**：降低存储成本，提高查询效率。
79+
- **分布式架构**：支持海量数据存储 & 分布式计算。
80+
- **灵活的 SQL 支持**：兼容大部分 SQL 语法，易于迁移。
81+
82+
### **❌ 限制**
83+
- **不支持事务（ACID）**：适用于 OLAP 场景，不适用于高并发事务处理。
84+
- **数据更新较慢**：追加写入模式，不适用于频繁更新数据的场景。
85+
- **高内存占用**：需要大量内存优化查询。
86+
87+
---
88+
89+
## **6️⃣ 总结**
90+
ClickHouse 是 **高性能 OLAP 数据库**，专为 **大规模数据分析** 设计，采用 **列式存储、MergeTree 引擎、分布式计算** 提供超快的查询速度。适用于 **日志分析、金融交易、区块链数据** 等实时分析场景，但不适用于高并发 OLTP 事务处理。
91+
92+
93+
# **Shared-Nothing 分布式架构**
94+
95+
## **🔹 Shared-Nothing 架构概述**
96+
**Shared-Nothing（无共享）架构** 是一种分布式系统设计理念，其中 **每个节点都是独立的，不共享 CPU、内存、磁盘或网络资源**。每个节点自主存储和处理数据，并通过网络通信协作完成分布式计算。
97+
98+
---
99+
100+
## **🔹 Shared-Nothing vs. 其他架构**
101+
| **架构类型** | **描述** | **代表数据库** |
102+
|---------------------|--------|--------------|
103+
| **Shared-Nothing** | **每个节点独立**，无资源共享，横向扩展能力强 | ClickHouse、StarRocks、Hadoop、CitusDB |
104+
| **Shared-Disk** | 多个节点共享磁盘存储，计算独立 | Oracle RAC、IBM DB2 |
105+
| **Shared-Memory** | 多个计算节点共享内存和磁盘 | SAP HANA |
106+
107+
---
108+
109+
## **🔹 Shared-Nothing 架构的关键特性**
110+
1. **分布式存储**
111+
- 每个节点存储独立数据，避免磁盘 I/O 竞争，提高吞吐量。
112+
2. **分片（Sharding）**
113+
- 数据按照一定策略（如哈希、范围）分配到不同节点，提高查询并发能力。
114+
3. **无集中式瓶颈**
115+
- **没有共享存储或共享内存**，扩展时仅需增加新节点，支持 **水平扩展（Scale-Out）**。
116+
4. **高可用性 & 容错性**
117+
- 通过数据副本（Replication）和故障恢复（Failover）机制，保证高可用性。
118+
119+
---
120+
121+
## **🔹 Shared-Nothing 架构的优势**
122+
| **优势** | **描述** |
123+
|------------------|--------|
124+
| **高可扩展性** | 通过增加节点即可扩展存储 & 计算能力 |
125+
| **无共享瓶颈** | 每个节点独立工作，避免 I/O 或 CPU 竞争 |
126+
| **高容错能力** | 节点故障不会影响整个系统，副本机制可恢复数据 |
127+
| **并行计算** | 查询可在多个节点并发执行，提高吞吐量 |
128+
129+
---
130+
131+
## **🔹 Shared-Nothing 在 ClickHouse / StarRocks 中的应用**
132+
### **🚀 ClickHouse**
133+
- 采用 **分片（Sharding）+ 副本（Replication）** 机制。
134+
- `Distributed` 表用于分布式查询，数据存储在多个节点，无需共享磁盘。
135+
136+
### **🚀 StarRocks**
137+
- 通过 **存算分离（Storage & Compute Separation）** 提供高扩展性。
138+
- 使用 **Colocation Join** 技术优化分布式查询，减少跨节点数据传输。
139+
140+
---
141+
142+
143+
## **🔹 适用场景**
144+
✅ **Shared-Nothing 适用于**：
145+
- **大规模数据分析（OLAP）**：ClickHouse、StarRocks、Hadoop。
146+
- **高并发查询**：日志分析、广告分析、金融数据。
147+
- **分布式存储 & 计算**：海量数据场景。
148+
149+
🚫 **不适用于**：
150+
- **高频事务（OLTP）**：银行系统、订单处理（适合 Shared-Disk）。
151+
- **低延迟 JOIN 查询**：需要数据紧密存储的情况。
152+
153+
---
154+
155+
## **🔹 总结**
156+
Shared-Nothing **架构简单、可扩展、无共享瓶颈**，是 **大规模分布式数据库**（如 ClickHouse、StarRocks、Hadoop）广泛采用的设计。适用于 **大数据分析、高并发查询** 场景，但对于事务型应用（OLTP）可能不是最佳选择。
157+
158+
🚀 **如果你的业务需要处理 PB 级数据并进行高效分析，Shared-Nothing 是理想架构！**
159+
160+
8161
## 表引擎
9162

10163
### MergeTree
@@ -35,4 +188,31 @@
35188

36189
### Integration
37190

38-
该系统表引擎主要用于将外部数据导入到ClickHouse中，或者在ClickHouse中直接操作外部数据源。
191+
该系统表引擎主要用于将外部数据导入到ClickHouse中，或者在ClickHouse中直接操作外部数据源。
192+
193+
## **1. 交易数据（Transactions）表结构**
194+
存储区块链上的所有交易记录，包括普通转账和智能合约调用。
195+
196+
```sql
197+
CREATE TABLE transactions (
198+
tx_hash String, -- 交易哈希
199+
block_number UInt64, -- 区块号
200+
block_timestamp DateTime, -- 交易时间
201+
from_address String, -- 发送方地址
202+
to_address String, -- 接收方地址（可能为空）
203+
value Decimal(38,18), -- 交易金额（ETH）
204+
gas_price UInt64, -- Gas 价格（Wei）
205+
gas_used UInt64, -- 实际 Gas 消耗
206+
status UInt8, -- 交易状态（0:失败, 1:成功）
207+
method_id String, -- 调用的合约方法 ID
208+
contract_address String, -- 交易涉及的合约地址
209+
-- 物理存储引擎
210+
INDEX idx_tx_hash tx_hash TYPE bloom_filter() GRANULARITY 1,
211+
INDEX idx_from_address from_address TYPE bloom_filter() GRANULARITY 1,
212+
INDEX idx_to_address to_address TYPE bloom_filter() GRANULARITY 1
213+
) ENGINE = MergeTree()
214+
PARTITION BY toYYYYMM(block_timestamp)
215+
ORDER BY (block_number, tx_hash)
216+
SAMPLE BY block_number
217+
SETTINGS index_granularity = 8192;
218+
```

‎02数据存取/11starocks.md‎

Lines changed: 141 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,141 @@
1+
# Starocks
2+
3+
- [starocks存储区块链数据](./starocks_chain.md)
4+
5+
## **StarRocks 物化视图增量更新：是否基于时间？**
6+
7+
StarRocks 的 **物化视图增量更新** **不完全基于时间**，而是通过 **基于 Base + Delta 的增量计算** 进行刷新。它并不是简单按照时间字段（如 `timestamp`）进行更新，而是利用数据的变更（Insert / Update / Delete）来计算增量。
8+
9+
---
10+
11+
## **1. StarRocks 物化视图增量更新机制**
12+
StarRocks 的增量更新依赖于 **两部分数据**：
13+
1. **Base（已有的数据）**：物化视图构建时的初始数据快照。
14+
2. **Delta（增量数据）**：自上次刷新后，新写入或修改的部分。
15+
16+
### 📌 **关键点**
17+
- **增量计算是基于数据变更，而不是基于时间字段**。
18+
- **支持 INSERT、UPDATE、DELETE 类型的变更**，并根据不同的物化视图模型自动合并数据。
19+
- **自动增量更新（`REFRESH AUTO`）根据数据量大小和导入方式决定触发机制**，但仍会有一定的**时间延迟（秒级）**。
20+
21+
---
22+
23+
## **2. 增量更新的触发条件**
24+
StarRocks 物化视图的增量刷新基于 **数据变更**，触发方式如下：
25+
- **自动增量刷新（REFRESH AUTO）**
26+
- 当 StarRocks 检测到基础表数据变更后，会**周期性**地进行增量计算并刷新 MV。
27+
- 刷新间隔由系统内部调度决定，通常在 **秒级**，但不是严格的**实时更新**。
28+
- 适用于 **高频更新的数据流，如 Kafka Stream Load**。
29+
30+
- **手动刷新（REFRESH MANUAL）**
31+
- 需要用户**手动执行 `REFRESH MATERIALIZED VIEW`** 命令进行增量计算和更新。
32+
- 适用于 **离线批量计算、数据更新不频繁的场景**。
33+
34+
---
35+
36+
## StarRocks和ClickHouse 物化视图对比
37+
38+
| **对比项** | **StarRocks 物化视图** | **ClickHouse 物化视图** |
39+
|--------------|--------------------------|-------------------------|
40+
| **更新方式** | 增量刷新（可手动/自动） | 仅支持手动（`REFRESH`） |
41+
| **查询优化** | 自动命中（Query Rewrite） | 依赖 `POPULATE`（不自动刷新） |
42+
| **更新触发** | 自动 / 手动 | 手动（批量更新） |
43+
| **实时性** | 近实时（秒级） | 较慢（批处理） |
44+
| **适用场景** | 高并发查询，准实时聚合 | 历史数据 OLAP 聚合 |
45+
46+
47+
---
48+
49+
## **1. StarRocks vs. ClickHouse 对比**
50+
51+
| **对比项** | **StarRocks** | **ClickHouse** |
52+
|---------------|-------------------------------------------------|----------------------------------------------|
53+
| **数据模型** | **MPP（多节点分布式）+ 向量化执行** | **列式存储 + 向量化执行** |
54+
| **数据写入** | **支持高并发批量 & 流式导入**（Kafka / Stream Load） | **批量导入性能高，但流式导入较弱** |
55+
| **查询性能** | **自动索引 + 物化视图优化查询**（Query Rewrite） | **依赖手动创建索引 & 物化视图**（`POPULATE`） |
56+
| **实时性** | **近实时（秒级延迟）** | **准实时（分钟级）** |
57+
| **主键支持** | **支持更新（Primary Key 模型），适合账户余额等数据** | **写入后不可变更，需手动合并数据** |
58+
| **JOIN 计算** | **支持高效分布式 JOIN**，适合多表分析 | **JOIN 性能较弱**，不适合复杂关系查询 |
59+
| **扩展性** | **云原生架构，自动分区 & 动态扩展** | **手动分片，扩展较复杂** |
60+
| **适用场景** | **高并发 OLAP 查询，交易分析，账户数据更新** | **大规模日志分析，区块链全历史数据归档** |
61+
62+
---
63+
64+
## **2. 适用场景分析**
65+
✅ **StarRocks 更适合：**
66+
- **交易分析 & 账户余额计算**（高并发查询 + 低延迟更新）
67+
- **链上 DeFi & NFT 数据分析**（多维度交互查询）
68+
- **实时区块 & 交易监控**（Kafka 实时流数据）
69+
70+
✅ **ClickHouse 更适合：**
71+
- **链上全量历史数据存储 & 批量查询**（一次性分析大数据集）
72+
- **区块链日志分析**（合约日志 / 节点日志）
73+
- **长期归档 & 批处理分析**（低频查询但数据量大）
74+
75+
---
76+
77+
## StarRocks离线计算
78+
- 🔹 StarRocks 可以直接导入离线计算，并支持多种方式，如 OUTFILE、Spark Connector、Flink 等。
79+
- 🔹 最推荐的方式是 Spark / Flink 直接读取 StarRocks，避免额外的数据导出，提高效率。
80+
- 🔹 可以结合 StarRocks 物化视图进行预计算，减少离线计算负担，提高查询性能。 🚀
81+
82+
# **StarRocks 的 Query Rewrite（查询改写）**
83+
84+
**Query Rewrite（查询改写）** 是 StarRocks 提供的一种 **自动优化查询** 的机制，主要用于 **自动命中物化视图**，减少计算量，提高查询性能。
85+
86+
---
87+
88+
## **🔹 Query Rewrite 的工作原理**
89+
1. **创建物化视图（Materialized View, MV）**
90+
- 用户预计算 & 存储部分查询结果，提高查询效率。
91+
2. **执行查询时，StarRocks 自动匹配物化视图**
92+
- **查询改写（Query Rewrite）机制** 会自动 **重写 SQL 语句**，让查询直接从物化视图中获取数据，而不是扫描原始大表。
93+
3. **用户无需手动指定物化视图**
94+
- StarRocks 会**智能判断**是否可以使用物化视图，并自动改写 SQL，以加速查询。
95+
96+
---
97+
98+
99+
## **ClickHouse vs. StarRocks 适用场景对比**
100+
101+
| **对比项** | **ClickHouse** | **StarRocks** |
102+
|---------------|-------------------------------------------------|-----------------------------------|
103+
| **数据更新方式** | 追加写入 (`MergeTree`)，支持 `ReplacingMergeTree` | `DUPLICATE KEY`（支持更新）或 `PRIMARY KEY`（实时更新） |
104+
| **查询优化** | 适用于批量分析，高效 `ORDER BY` & `bloom_filter` | `Query Rewrite` + 物化视图优化 |
105+
| **实时性** | 主要适用于批处理 | 近实时数据分析 |
106+
| **适用场景** | 历史交易分析、大规模批量数据存储 | 高并发查询、实时数据分析 |
107+
108+
109+
# ClickHouse vs. StarRocks 数据均衡对比
110+
111+
| **对比项** | **ClickHouse** | **StarRocks** |
112+
|------------------|--------------------------------|-----------------------------|
113+
| **自动数据均衡** | ❌ 不支持（需手动迁移） | ✅ 自动均衡数据 |
114+
| **新节点拓展** | 需要手动迁移旧数据 | 自动平衡存储 & 计算 |
115+
| **负载均衡** | 通过 `Distributed` 表均衡查询 | 内部自动均衡数据分布 |
116+
117+
## kafka数据导入starocks
118+
| 方法 | 适用场景 | 优势 | 适用数据格式 |
119+
|------------------|---------------|----------------------------|---------------------|
120+
| **Routine Load** | 长期持续导入 | 自动化流式导入，稳定可靠 | JSON、CSV |
121+
| **Flink + StarRocks** | 大规模数据同步 | 可实时处理 ETL 逻辑 | JSON、Avro、Parquet |
122+
| **Stream Load** | 小规模批量导入 | 支持 HTTP 接口 | JSON、CSV |
123+
124+
### **推荐**
125+
- **如果是实时消费 Kafka 数据** → **Routine Load**
126+
- **如果需要数据清洗、转换** → **Flink + StarRocks**
127+
- **如果是批量数据** → **Stream Load**
128+
129+
### 查询优化
130+
StarRocks 中，索引的概念与传统数据库（如 MySQL、PostgreSQL）不同，它主要依靠 主键索引（Primary Key Index）、排序键（Sort Key） 和 前缀索引（Prefix Index） 来加速查询。StarRocks 通过 存储引擎优化和数据分布策略 来提高查询效率，而不支持显式的 CREATE INDEX 语法。
131+
132+
133+
| 索引类型 | 适用场景 | 查询优化 | 示例 |
134+
|------------------|-----------------------------|------------------------------|-----------------------------------------|
135+
| **主键索引（Primary Key）** | 交易唯一标识 (`tx_hash`) | `WHERE tx_hash = '0xabc...'` | `PRIMARY KEY(tx_hash)` |
136+
| **排序键（Sort Key）** | 和联合索引差不多 时间排序 (`block_time`) | `ORDER BY block_time DESC` | `DUPLICATE KEY(from_address, to_address, block_time)` |
137+
| **前缀索引（Prefix Index）** | 地址前缀匹配 (`0xabc%`) | `WHERE from_address LIKE '0xabc%'` | `BITMAP INDEX (from_address)` |
138+
139+
140+
141+

0 commit comments

Comments
 (0)