当前位置：首页 > article >正文

clickhouse--本地表和分布式表，副本机制，分片集群

article 2025/2/25 11:31:18

1、本地表和分布式表

ck的表分为两种:

分布式表
一个逻辑上的表，可以理解为数据库中的视图，一般查询都查询分布式表。分布式表引擎会将我们的查询请求路由本地表进行查询，然后进行汇总最终返回给用户。
本地表
实际存储数据的表。

Distributed Table & Distributed Engine

ClickHouse分布式表的本质并不是一张表，而是一些本地物理表(分片)的分布式视图，本身并不存储数据。分布式表建表的引擎为Distributed。
Distrbuted_table

Copy Highlighter-hljs
CREATE TABLE IF NOT EXISTS {distributed_table} as {local_table} 
ENGINE = Distributed({cluster}, '{local_database}', '{local_table}', rand())

Distributed引擎需要以下几个参数：

集群标识符
本地表所在的数据库名称
本地表名称
分片键(sharding key) - 可选
该键与config.xml中配置的分片权重(weight)一同决定写入分布式表时的路由, 即数据最终落到哪个物理表上. 它可以是表中一列的原始数据(如site_id), 也可以是函数调用的结果, 如上面的SQL语句采用了随机值rand(). 注意该键要尽量保证数据均匀分布, 另外一个常用的操作是采用区分度较高的列的哈希值, 如intHash64(user_id).

数据查询的流程

在这里插入图片描述

各个实例之间会交换自己持有的分片的表数据；
汇总到同一个实例上返回给用户。

2、基于表的副本机制

① 特点

副本策略表级别
ClickHouse 的副本机制由表引擎（如 ReplicatedMergeTree）实现，用户可以为每张表单独配置副本数。
最终一致性
数据写入时，ClickHouse 异步复制到其他副本，可能存在短暂的数据不一致。
依赖 ZooKeeper
副本之间的协调通过 ZooKeeper 实现（如副本状态、任务分配）。

② 优点

灵活性高
用户可根据业务需求为不同表配置不同的副本策略。
存储成本可控
可以为重要表配置多副本，非重要表减少副本。
适合 OLAP 场景
高吞吐写入、实时查询。

③ 缺点

依赖外部组件（如 ZooKeeper），增加了系统复杂性。
数据一致性较弱（最终一致性）。

④ 与HDFS副本机制的区别

基于集群的副本机制（HDFS）

特点
- 副本策略全局化：HDFS 的副本机制是集群级别的，所有文件默认存储 3 个副本，用户无法针对单个文件或目录单独配置副本数。
- 强一致性：数据写入时，HDFS 会同步写入所有副本，确保数据强一致性。
- 数据块管理：HDFS 将文件切分为固定大小的数据块（如 128MB），每个块独立存储副本。
优点
- 简单易用，用户无需关心副本管理。
- 适合通用文件存储场景（如 Hadoop 生态）。
缺点
- 灵活性差，无法针对特定数据单独配置副本策略。
- 存储成本高（默认 3 副本）。

总结

在这里插入图片描述

3、分片集群

副本虽然能够提高数据的可用性，降低丢失风险，但是每台服务器实际上必须容纳全量数据，对数据的横向扩容没有解决。
要解决数据水平切分的问题，需要引入分片的概念。通过分片把一份完整的数据进行切分，不同的分片分布到不同的节点上，再通过 Distributed 表引擎把数据拼接起来一同使用。
Distributed 表引擎本身不存储数据，有点类似于 MyCat 之于 MySql，成为一种中间件，通过分布式逻辑表来写入、分发、路由来操作多台节点不同分片的分布式数据。
注意：ClickHouse 的集群是表级别的，实际企业中，大部分做了高可用，但是没有用分片，避免降低查询性能以及操作集群的复杂性。