ClickHouse要点小记

最新推荐文章于 2024-05-08 14:55:39 发布

冰川_

最新推荐文章于 2024-05-08 14:55:39 发布

阅读量1.7k

点赞数 1

分类专栏： ClickHouse

本文链接：https://blog.csdn.net/wenyichuan/article/details/113883973

版权

ClickHouse 专栏收录该内容

15 篇文章 7 订阅

订阅专栏

关于分片，副本，节点

ck存在严格的限制，如果是单副本的情况下，停用一个分片会导致分布式表不可用
4分片1副本需要4个ck节点，而3分片2副本需要6个CK节点，CK节点数为分片数乘副本数，不推荐一个节点上存在两个副本，若需要一节点两副本则新建两个数据库，动态传入数据库值
节点扩容不会自动同步旧数据，有两种方式解决，以下两种方式均需要在新节点上重新创建表
（1）创建一个新集群，select remote（）函数查询A集群输入插入B集群，将原表重命名，在所有节点上建立与原表schema相同的新表，将实时数据写入新表，同时用clickhouse-copier工具将历史数据整体迁移到新表上来，再删除原表。当然在迁移期间，被重平衡的表是无法提供服务的，仍然不那么优雅。
（2）调整weight权重，使数据前期优先存入新节点上,后续再重新调整weight。但是这会造成明显的热点问题，并且仅对直接写入分布式表才有效，并不可取。
2021.2.22新增
58采用的是单分片多副本，原因如下：https://xie.infoq.cn/article/ebfe0a6b0d6bdbbb4eae642ff
- BI对接数仓应用层数据，总体来说量级较小，同时clickhouse有着高效的数据压缩比，采用单节点能存储当前BI的全量数据，且能满足未来几年的数据存储需求。
- Clickhouse默认并发数为100，采用单分片每个节点都拥有全量数据，当qps过高时可横向增加节点来增大并发数。
- clickhouse对Distributed 表的join支持较差，单分片不走网络，能提高join查询速度。

关于分区

那些有相同分区表达式值的数据片段才会合并。这意味着你不应该用太精细的分区方案（超过一千个分区）。否则，会因为文件系统中的文件数量过多和需要打开的文件描述符过多，导致 SELECT 查询效率不佳。

关于副本同步机制

复制是多主异步的。
INSERT语句（以及ALTER）可在任意可用的服务器上执行。数据首先插入到本地的服务器（即运行查询的服务器），然后数据被复制到其他服务器。

由于复制是异步的，所以最近插入的数据出现在其他副本上会有一定的延迟。

如果部分副本不可用，则在它们可用时写入数据。

如果副本可用，则等待的时间是通过网络传输压缩数据块所耗费的时间。

默认情况下， INSERT操作只需等待一个副本写入成功后返回。如果仅将数据成功写入一个副本，并且该副本的服务器不再存在，则存储的数据将丢失。要启动来自多个副本的写入确认机制，使用insert_quorum选项。

insert_quorum：启用仲裁写入，写入多少个副本才算成功。默认0。insert_quorum <2，则禁用仲裁写入；insert_quorum> = 2，则启用仲裁写入。
当在insert_quorum_timeout期间将数据正确写入副本的insert_quorum时，INSERT才能成功。如果由于任何原因而成功写入的副本数量未达到insert_quorum，则认为写入失败，并将从已写入数据的所有副本中删除插入的块。读取从insert_quorum写入的数据时，可以使用select_sequential_consistency选项。查询时可用副本的数量小于insert_quorum则会报错。
insert_quorum_timeout：仲裁写入超时（秒），默认60s。如果超时时间内没有写完，则将生成一个异常，并且客户端必须重复查询才能将同一块写入相同或任何其他副本。

关于分布式表查询负载均衡调用副本

执行分布式查询时，首先计算分片的每个副本的错误数，然后将查询发送至最少错误的副本。如果没有错误或者错误数相同，则按如下的策略查询数据：
1.random(默认) ：将查询发送至任意一个副本。
2.nearest_hostname : 将查询发送至主机名最相似的副本。
3.in_order : 将查询按配置文件中的配置顺序发送至副本。
4.first_or_random : 选择第一个副本，如果第一个副本不可用，随机选择一个可用的副本。

关于建表

建表时添加on cluster 可以只操作一次在多个节点上同时新建本地表

关于分布式表

直接在分布式表中插入数据数据落地规则：建分布式表时会有一个参数选择分片，一般是rand或者是hash，根据这个参数，还有weight权重这两个属性，决定数据落地那个分片
写数据到分布式表
优点：clickhouse控制数据到分片的路由
缺点：
（1）数据是先写到一个分布式表的实例中并缓存起来，再逐渐分发到各个分片上去，实际是双写了数据（写入放大），浪费资源
（2）数据写入默认是异步的，短时间内可能造成不一致
（3）目标表中会产生较多的小parts，使merge（即compaction）过程压力增大
相对而言，直接写本地表是同步操作，更快，parts的大小也比较合适，但是就要求应用层额外实现sharding和路由逻辑，如轮询或者随机等，在生产环境中推荐写本地表、读分布式表，可以引入第三方负载均衡工具，由第三方工具决定插入到那个表中，例如chproxy，或者Flink-ClickHouse Sink中实现随机路由，此处只是简单的随机分配，并未考虑集群负载占用的情况。https://www.jianshu.com/p/ab811cceb856
2021.2.22新增
- 负载均衡可以采用BalancedClickhouseDataSource轮询多个节点，druid已经有对应支持https://github.com/alibaba/druid/issues/3984使用简单；但是内部随机方式，可能会导致负载不均匀，虽然有定时检测机制，但是经测试，节点挂掉，请求直接报错；这种无法实现故障转移
- nginx实现SLB，既可以轮询，也可以做故障转移，国内大厂采用此方案
  
  （1）没有配置副本，非复制表（MergeTree），每个节点为一个shard的情况：数据只被插入到一个本地表中。当一个节点挂了之后查询分布表会报错。
  （2）配置副本，非复制表（MergeTree）：数据只被插入到一个本地表中，虽然做了副本，但是MergeTree 引擎的表并不会自动复制数据，所有数据还是只在一个节点上。当一个节点挂了之后查询分布表不会报错，但是挂了的节点的数据会丢失。
  （3）配置副本，复制表（ReplicatedMergeTree）：插入到分布式表中的数据仅插入到其中一个本地表中，但通过复制机制传输到另一个节点的表中，因此两个本地表上的数据保持同步。一个节点挂了之后可以正常提供服务，查询分布式表不会报错，数据未丢失。

private Request buildRequest(ClickhouseRequestBlank requestBlank) {
        String resultCSV = String.join(" , ", requestBlank.getValues());
        String query = String.format("INSERT INTO %s VALUES %s", requestBlank.getTargetTable(), resultCSV);
        String host = sinkSettings.getClickhouseClusterSettings().getRandomHostUrl();

        BoundRequestBuilder builder = asyncHttpClient
                .preparePost(host)
                .setHeader(HttpHeaders.Names.CONTENT_TYPE, "text/plain; charset=utf-8")
                .setBody(query);

        if (sinkSettings.getClickhouseClusterSettings().isAuthorizationRequired()) {
            builder.setHeader(HttpHeaders.Names.AUTHORIZATION, "Basic " + sinkSettings.getClickhouseClusterSettings().getCredentials());
        }

        return builder.build();
    }

    public String getRandomHostUrl() {
        currentHostId = ThreadLocalRandom.current().nextInt(hostsWithPorts.size());
        return hostsWithPorts.get(currentHostId);
    }

关于本地表引擎选择

推荐使用复制表而不是非复制表，普通mergetree会存在数据同步的问题，新建复制表时可以在配置文件中添加全局变量<macros>标签，指定分片名和副本名
internal_replication参数非复制表设置为false 复制表设置为true
值为true则由表自动同步数据，若为false则由集群自动同步数据

关于集群监控

没有直接提供QPS等类似数据，需要根据日志计算
如果用grafana直连，指标高频查询会影响集群性能
如果采用clickhouse-exporter+prometheus+grafana的组合，prometheus监控flink会有小毛病

搭建的本地监控环境

Tabix用于查询sql，监控信息

http://172.16.10.128:8080/#!/login

在这里插入图片描述

在这里插入图片描述

Grafana专业监控

http://172.16.10.128:23000/login

账号密码均为admin
在这里插入图片描述
登入后进入此处可看到新建的三个仪表盘

Json标签号13606，模板地址https://grafana.com/grafana/dashboards/13606

在这里插入图片描述

在这里插入图片描述
Json标签号2515，模板地址https://grafana.com/grafana/dashboards/2515

冰川_

关注

1
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
ClickHouse要点小记

节点扩容不会自动同步旧数据有两种方式解决前置条件，在新节点上重新创建表（1）创建一个新集群，select remote（）函数查询A集群输入插入B集群（2）调整weight权重，使数据前期优先存入新节点上直接在分布式表中插入数据数据落地规则：建分布式表时会有一个参数选择分片，一般是rand或者是hash，根据这个参数，还有weight权重两个属性，决定数据落地那个分片建表时添加on cluster 可以一下在多个节点上同时新建本地表推荐使用复制表而不是非复制表，普通merget..
复制链接

扫一扫