大数据-142 - ClickHouse 集群 副本和分片 Distributed 附带案例演示

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
云原生网关 MSE Higress,422元/月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据-142 - ClickHouse 集群 副本和分片 Distributed 附带案例演示

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(已更完)

Spark(已更完)

Flink(已更完)

ClickHouse(正在更新···)

章节内容

上节我们完成了如下的内容:


副本和分片,上节主要是副本的部分

Zk 的配置

Replicated MergeTree原理详解

分片部分

副本(Replica)

概念:副本是指在多个节点之间复制相同的数据,确保即使某个节点发生故障,数据仍然可以从其他节点访问。副本提升了数据的高可用性和容错能力。

目的:如果某个节点宕机,查询可以从其他副本节点读取数据,保证系统的高可用性。同时,副本还可以均衡负载,在高并发查询时,副本节点可以分担查询压力。

实现:每个分片的副本节点存储相同的数据,ClickHouse 提供自动的副本同步机制,在节点恢复或新增副本时,数据会自动同步。

副本节点使用 ZooKeeper 进行协调,确保数据的写入在副本之间一致,并自动管理副本间的同步操作。

配置:副本通常通过 ReplicatedMergeTree 表引擎来实现,表的路径和副本 ID 由 ZooKeeper 进行管理。

Distributed 表

概念:Distributed 表是一种特殊的表类型,它不直接存储数据,而是将查询转发到多个分片或副本表中。这使得用户可以对多个节点执行统一的查询。

目的:通过 Distributed 表,可以将查询透明地分发到各个分片和副本上,最大化利用集群的并行处理能力。它简化了跨节点、跨分片查询的复杂性。

实现:在定义 Distributed 表时,需要指定目标集群、数据库和底层存储表的名字。

查询 Distributed 表时,ClickHouse 会根据分片键(如果存在)将查询转发到各个分片执行,并将各分片的结果汇总返回。

Distributed 表可以自动处理分片和副本的负载均衡。


分片、副本与 Distributed 表的组合

分片与副本的组合:通过分片,集群可以水平扩展,而通过副本,集群能够实现高可用性。当一个集群有多个分片和副本时,ClickHouse 会首先将数据分片,确保每个分片在不同的服务器上;每个分片的数据会有多个副本,副本分布在不同的节点上。

查询策略:查询通常会通过 Distributed 表执行。ClickHouse 会自动选择一个副本来读取数据,如果某个副本不可用,它会自动切换到其他可用副本上。查询时,可以利用并行处理,在多个分片上同时进行查询计算,提升整体查询性能。

副本一致性:当数据写入到副本时,ClickHouse 使用强一致性协议,确保每个副本在写入时数据是相同的。通过 ZooKeeper 管理副本的同步和协调,副本在恢复后可以从其他节点拉取丢失的数据。

优点与挑战

优点

高可用性:通过副本机制,即使某个节点宕机,查询和数据仍然可用。

可扩展性:分片机制允许系统在大规模数据场景下水平扩展。

高性能:Distributed 表的并行查询处理机制大大提升了查询速度,尤其在多分片、多节点的环境下。

挑战

管理复杂性:集群、分片、副本、ZooKeeper 之间的协调关系比较复杂,配置和维护需要较高的技术能力。

数据延迟:虽然副本同步机制较为强大,但在某些极端情况下,副本之间可能存在数据延迟。

配置文件

我们配置集群的时候,已经配置过了。

这里我把配置文件在粘贴到这里一次:(记得端口的事情)

<yandex>
  <remote_servers>
    <perftest_3shards_1replicas>
      <shard>
        <internal_replication>true</internal_replication>
        <replica>
          <host>h121.wzk.icu</host>
          <port>9000</port>
          <user>default</user>
          <password>clickhouse@wzk.icu</password>
        </replica>
      </shard>
      <shard>
        <internal_replication>true</internal_replication>
        <replica>
          <host>h122.wzk.icu</host>
          <port>9000</port>
          <user>default</user>
          <password>clickhouse@wzk.icu</password>
        </replica>
      </shard>
      <shard>
        <internal_replication>true</internal_replication>
        <replica>
          <host>h123.wzk.icu</host>
          <port>9000</port>
          <user>default</user>
          <password>clickhouse@wzk.icu</password>
        </replica>
      </shard>
    </perftest_3shards_1replicas>
  </remote_servers>
  <zookeeper-servers>
    <node index="1">
      <host>h121.wzk.icu</host>
      <port>2181</port>
    </node>
    <node index="2">
      <host>h122.wzk.icu</host>
      <port>2181</port>
    </node>
    <node index="3">
      <host>h123.wzk.icu</host>
      <port>2181</port>
    </node>
  </zookeeper-servers>
  <macros>
    <shard>01</shard>
    <replica>h121.wzk.icu</replica>
  </macros>
  <networks>
    <ip>::/0</ip>
  </networks>
  <clickhouse_compression>
    <case>
      <min_part_size>10000000000</min_part_size>
      <min_part_size_ratio>0.01</min_part_size_ratio>
      <method>lz4</method>
    </case>
  </clickhouse_compression>
</yandex>

Distributed用法

Distributed表引擎

  • all 全局查询
  • local 真正的保存数据的表

Distributed

分布式引擎,本身不存储数据,但可以在多个服务器上进行分布式查询。

读是自动并行的,读取时,远程服务器表的索引(如果有的话)会被使用。

指令是:

Distributed(cluster_name, database, table [, sharding_key])

参数解析:

  • cluster_name 服务器配置文件中的集群名,在我们配置的metrika.xml中
  • database 数据库名
  • table 表名
  • sharding_key 数据分片键

案例演示

创建新表

在3台节点上的t表插入新建表

注意:是三台节点都要!!!

CREATE TABLE test_tiny_log(
  id UInt16,
  name String
) ENGINE = TinyLog;

执行结果如下图所示:

插入数据

在3台节点上的t表插入一些数据

注意:是三台节点都要!!!

INSERT INTO test_tiny_log VALUES (1, 'wzk');
INSERT INTO test_tiny_log VALUES (2, 'icu');

SELECT
  *
FROM
  test_tiny_log

执行结果如下图所示:

分布式表

CREATE TABLE dis_table(
  id UInt16,
  name String
) ENGINE = Distributed(perftest_3shards_1replicas, default, test_tiny_log, id);

执行代码如下:

插入数据

INSERT INTO dis_table SELECT * FROM test_tiny_log;
• 1

插入我们刚才准备的数据:

查询数据

select count() from dis_table;
• 1

运行结束后,对应的截图如下所示:

查看每台节点的数据:

SELECT COUNT() FROM test_tiny_log;
• 1

执行结果如下图:

h121节点的返回:

h122节点的返回:

h123节点的返回:

可以看到三台的总数量(2 + 3 + 3)等于我们的分布式表dis_table(8)的数量,每个节点大约有 1/3 的数据。

相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
5月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
zdl
|
10月前
|
消息中间件 运维 大数据
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
421 56
|
9月前
|
存储 数据采集 监控
阿里云DTS踩坑经验分享系列|SLS同步至ClickHouse集群
作为强大的日志服务引擎,SLS 积累了用户海量的数据。为了实现数据的自由流通,DTS 开发了以 SLS 为源的数据同步插件。目前,该插件已经支持将数据从 SLS 同步到 ClickHouse。通过这条高效的同步链路,客户不仅能够利用 SLS 卓越的数据采集和处理能力,还能够充分发挥 ClickHouse 在数据分析和查询性能方面的优势,帮助企业显著提高数据查询速度,同时有效降低存储成本,从而在数据驱动决策和资源优化配置上取得更大成效。
352 9
|
10月前
|
存储 监控 数据挖掘
【Clikhouse 探秘】ClickHouse 物化视图:加速大数据分析的新利器
ClickHouse 的物化视图是一种特殊表,通过预先计算并存储查询结果,显著提高查询性能,减少资源消耗,适用于实时报表、日志分析、用户行为分析、金融数据分析和物联网数据分析等场景。物化视图的创建、数据插入、更新和一致性保证通过事务机制实现。
1057 14
|
10月前
|
SQL 存储 大数据
单机顶集群的大数据技术来了
大数据时代,分布式数仓如MPP成为热门技术,但其高昂的成本让人望而却步。对于多数任务,数据量并未达到PB级,单体数据库即可胜任。然而,由于SQL语法的局限性和计算任务的复杂性,分布式解决方案显得更为必要。esProc SPL作为一种开源轻量级计算引擎,通过高效的算法和存储机制,实现了单机性能超越集群的效果,为低成本、高效能的数据处理提供了新选择。
|
9月前
|
存储 负载均衡 监控
揭秘 Elasticsearch 集群架构,解锁大数据处理神器
Elasticsearch 是一个强大的分布式搜索和分析引擎,广泛应用于大数据处理、实时搜索和分析。本文深入探讨了 Elasticsearch 集群的架构和特性,包括高可用性和负载均衡,以及主节点、数据节点、协调节点和 Ingest 节点的角色和功能。
387 0
|
10月前
|
分布式计算 大数据 BI
ClickHouse与大数据生态整合:从ETL到BI报表
【10月更文挑战第27天】在这个数据驱动的时代,企业越来越依赖于数据来做出关键决策。而高效的数据处理和分析能力则是支撑这一需求的基础。作为一位数据工程师,我有幸参与到一个项目中,该项目旨在利用ClickHouse与Hadoop、Spark、Flink等大数据处理框架的整合,构建一个从数据提取(Extract)、转换(Transform)、加载(Load)到最终生成商业智能(BI)报表的全流程解决方案。以下是我在这个项目中的经验和思考。
442 1
|
10月前
|
存储 Prometheus 监控
构建高可用性ClickHouse集群:从理论到实践
【10月更文挑战第27天】在数据驱动的时代,构建一个稳定、高效的数据库系统对于企业的业务发展至关重要。作为一名数据工程师,我深知数据库系统的高可用性和可扩展性对于支撑企业应用的重要性。在这篇文章中,我将分享如何构建一个高可用性的ClickHouse集群,从分布式表的设计到数据复制与分片,再到故障恢复机制,确保系统在大规模数据处理中的稳定性和可靠性。
361 0
|
1月前
|
机器学习/深度学习 运维 监控
运维不怕事多,就怕没数据——用大数据喂饱你的运维策略
运维不怕事多,就怕没数据——用大数据喂饱你的运维策略
63 0

热门文章

最新文章

推荐镜像

更多