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

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).

数据查询的流程

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

2、基于表的副本机制

① 特点

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

② 优点

• 灵活性高
    用户可根据业务需求为不同表配置不同的副本策略。

• 存储成本可控
    可以为重要表配置多副本，非重要表减少副本。

• 适合 OLAP 场景
    高吞吐写入、实时查询。

③ 缺点

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

④ 与HDFS副本机制的区别

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

• 特点

  • 副本策略全局化：HDFS 的副本机制是集群级别的，所有文件默认存储 3 个副本，用户无法针对单个文件或目录单独配置副本数。
  • 强一致性：数据写入时，HDFS 会同步写入所有副本，确保数据强一致性。
  • 数据块管理：HDFS 将文件切分为固定大小的数据块（如 128MB），每个块独立存储副本。

• 优点

  • 简单易用，用户无需关心副本管理。
  • 适合通用文件存储场景（如 Hadoop 生态）。

• 缺点

  • 灵活性差，无法针对特定数据单独配置副本策略。
  • 存储成本高（默认 3 副本）。

总结

3、分片集群

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

• 集群写入流程（3 分片 2 副本共 6 个节点）
  

• 集群读取流程（3 分片 2 副本共 6 个节点）
  
  详细配置参考