ClickHouse 在网易的实践

Posted 过往记忆大数据

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ClickHouse 在网易的实践相关的知识,希望对你有一定的参考价值。


databases;\' | curl \'http://10.200.161.49:9009/?user=writeuser&password=xxxx\' --data-binary @-

关于chroxy参数配置可参照如下文档:

https://github.com/ContentSquare/chproxy

 

5

客户端工具选择

1. DBeave

DBeaver是免费和开源(GPL)为开发人员和数据库管理员通用数据库工具。易用性是该项目的主要目标,是经过精心设计和开发的数据库管理工具。免费、跨平台、基于开源框架和允许各种扩展写作(插件)。

2. Superse

Superset 是一款由 Airbnb 开源的“现代化的企业级 BI(商业智能) Web 应用程序”,其通过创建和分享 dashboard,为数据分析提供了轻量级的数据查询和可视化方案。

3. Tabi

功能和部署方式与Superset相似,可参考如下文档:

https://github.com/smi2/tabix.ui/releases

6

可用性说明

根据选择的集群架构不同, clickhouse集群表现出的可用性也不同。

(1)数据的读写高可用就是依赖复制表引擎创建多副本机制保证。如果Clickhouse集群使用是多分片多副本架构,当一个副本所在的机器宕机后,chproxy层会自动路由到可用的副本读写数据;

(2)如果Clickhouse集群只用了sharding分片,没有用到复制表作为数据副本,那么单台机器宕机只会影响到单个数据分片的读写;

(3)当zk集群不可用时,整个集群的写入会都会受影响,不管有没有使用复制表。

总结:

数据可用性要求越高,意味着投入更多的资源,单台机器的资源利用率越低,业务可根据数据重要程度灵活选择,不过Clickhouse的定位是在线分析olap系统,建议业务方将ck里的数据也定义为二级数据,数据丢失后是可以再生成的,从而控制整体架构的成本,提高单台机器的资源利用率。同时强烈建议业务不要强依赖Clickhouse,要有一定的兜底和熔断机制。


7

集群配置参数调

1. max_concurrent_querie

最大并发处理的请求数(包含select,insert等),默认值100,推荐150(不够再加),在我们的集群中出现过”max concurrent queries”的问题。


2. max_bytes_before_external_sor

当order by已使用max_bytes_before_external_sort内存就进行溢写磁盘(基于磁盘排序),如果不设置该值,那么当内存不够时直接抛错,设置了该值order by可以正常完成,但是速度相对内存来说肯定要慢点(实测慢的非常多,无法接受)。


3. background_pool_size

后台线程池的大小,merge线程就是在该线程池中执行,当然该线程池不仅仅是给merge线程用的,默认值16,推荐32提升merge的速度(CPU允许的前提下)。


4. max_memory_usag

单个SQL在单台机器最大内存使用量,该值可以设置的比较大,这样可以提升集群查询的上限。


5. max_memory_usage_for_all_querie

单机最大的内存使用量可以设置略小于机器的物理内存(留一点内操作系统)。

 

6. max_bytes_before_external_group_b

在进行group by的时候,内存使用量已经达到了max_bytes_before_external_group_by的时候就进行写磁盘(基于磁盘的group by相对于基于磁盘的order by性能损耗要好很多的),一般max_bytes_before_external_group_by设置为max_memory_usage / 2,原因是在clickhouse中聚合分两个阶段:

  • 查询并且建立中间数据;

  • 合并中间数据 写磁盘在第一个阶段,如果无须写磁盘,clickhouse在第一个和第二个阶段需要使用相同的内存。

  • 这些内存参数强烈推荐配置上,增强集群的稳定性避免在使用过程中出现莫名其妙的异常。

    学习资料:

  • 官网  

    https://clickhouse.com/docs/en/engines/table-engines/integrations/

  • 中文社区  

    http://clickhouse.com.cn/


  • 作者简介

    刘彦鹏,网易杭州研究院数据库工程师。


    极客星球|Clickhouse在数据智能公司的应用与实践

    前言:Clickhouse数据库作为OLAP领域内的一匹黑马,目前在众多大厂已经广泛的被使用。MobTech在2020年开始尝试使用Clickhouse,并且具有一定的数据规模,目前线上Clickhouse集群数据规模为100亿左右。

    Clickhouse是什么?
    Clickhouse(https://Clickhouse.tech/)是俄...
    1.数据量比较大,亿级别以上;
    2.数据不需要更新;
    3.没有事务要求;
    4.查询并发要求不高。

    Clickhouse为什么这么快?主要是以下两个原因:
    1.对于OLAP数据库,每次查询并不需要访问所有的列。使用列存储能够极大减少IO,提升数据查询速度。另外使用列式存储也便于进行压缩,减少数据体积;
    2.Clickhouse 执行引擎使用CPU向量执行模型,能够极大提高计算速度。

    Clickhouse与其他OLAP系统的优劣势对比?
    目前在OLAP领域内使用比较多的系统主要有:Presto、Druid、Kylin、Doris和Clickhouse等其他。整个OLAP系统主要分为两大类型:预聚合和实时聚合,这两种类型都有各自的优缺点。

    预聚合数据库特点:
    1.查询速度比较快,由于已经预聚合部分数据,整体的数据集会相对减少;
    2.数据经过预聚合会导致明细数据丢失,这也是一大问题;
    3.数据需要预先聚合,查询灵活性比较低,也会导致维度膨胀整体数据量偏大。

    实时聚合数据库特点:
    1.存储所有明细数据,查询响应时间会稍微偏大;
    2.不需要预聚合,查询灵活度比较高。

    上述数据库Druid,Kylin属于预聚合类型,而Presto,Doris,Clickhouse属于实时聚合类型。MobTech主流使用的OLAP系统为Presto,下面介绍下Presto的特点:

    Presto是一个计算和存储分离的OLAP系统,支持标准SQL查询,完全基于内存运行,动态编译执行计划。Presto查询引擎是主从架构,由一个协调节点,一个发现节点,多个工作节点组成。通常情况下,发现节点和协调节点运行在同一个进程内,协调节点负责SQL解析,生成执行计划,分发任务到工作节点,工作节点负责实际的查询任务执行。

    MobTech在使用Presto过程中存在不少问题,如:
    1.无法控制资源使用量,导致不同业务线之间资源抢占比较严重;
    2.查询速度比较慢;
    3.Presto是纯内存计算,对资源消耗比较大。

    Clickhouse核心之MergeTree表引擎

    MergeTree系列表引擎,是Clickhouse最核心的表引擎。存储的数据顺序按主键排序,可以使用数据分区,支持数据副本特性和数据抽样。官方提供了包括MergeTree、ReplacingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree、VersionCollapsingMergeTree、GraphiteMergeTree等7种引擎。以下为每种表引擎的简单介绍:

    1. ReplacingMergeTree:该引擎会在后台数据合并时移除具有相同排序键的记录;
    2. SummingMergeTree:在合并数据时,会把具有相同主键的记录合并为一条记录。并根据主键进行数据聚合;
      3.AggregatingMergeTree:在合并数据时,把具有相同主键的记录根据指定的聚合函数进行聚合;
      4.CollapsingMergeTree:在合并数据时,把具有相同主键的记录进行折叠。折叠规则根据设定的sign字段,该字段值为1时保留,-1时删除;
      5.VersionCollapsingMergeTree: 在合并数据时,把具有相同主键的记录合并,合并规则是根据指定的version字段。

    这些表引擎在处理数据聚合和合并时,都只在同一个分区内。在使用MergeTree表引擎有一点需要注意,Clickhouse的主键并不唯一,意味着数据可能重复。另外MergeTree表引擎数据分区,每个分区都是一个单独的物理文件目录。在查询时指定分区,要比不指定分区查询快数倍。

    ReplicatedMergeTree表引擎可以设定数据副本存储。在线上使用时,我们是要求必须使用 ReplicatedMergeTree引擎,防止单点问题。

    Clickhouse在MobTech的应用与实践

    业务需求场景:
    每天大数据会离线跑出一批数据,每天数据量最多达到2亿,业务需要能够实时查询这些数据明细,并进行相关数据统计,每天新导入的数据是一个新的分区。由于大数据任务会出现延迟的情况,在这样的情况下需要能够查询前一天的数据。针对这样的情况,我们在每次查询数据前会查出该表最新的分区,然后在具体查询SQL中指定最新分区进行查询。最开始我们选择了Elasticsearch作为存储系统,由于大数据任务在导入数据时会导致Elasticsearch大量磁盘读写,甚至导致Elasticsearch宕机情况出现。

    在这样的情况下,我们急需要一种新的数据库来支撑业务。在了解到Clickhouse的特性和综合业务相关情况,我们最终选择了Clickhouse。经过对比各种表引擎后,选择了ReplicatedMergeTree引擎,将常用的查询字段作为主键索引。另外由于业务需要每天还会有少量的在线数据入库,使用Kafka表引擎接收在线实时数据。通过物化视图的方式,将Kafka表数据写入到目标表。Clickhouse既能够支撑离线数据的导入,也支持实时数据写入,并且具有良好的查询性能。
    实践总结:
    目前线上Clickhouse单表最大记录数为20亿左右,只使用了2台8核16G的机器就完成了TP99 1s内查询响应。目前线上使用的是单分片加数据副本的模式,能够充分利用Clickhouse单机强大的能力,又能保障线上数据安全。Clickhouse也有一些缺点,比如:数据更新比较麻烦,大规模集群没有较好的管理工具等问题存在。总的来说,Clickhouse能够以较低的成本完成大量数据查询和分析需求,并且保持稳定。

    以上是关于ClickHouse 在网易的实践的主要内容,如果未能解决你的问题,请参考以下文章

    如何在ClickHouse中实现资源隔离?火山引擎实践经验分享

    如何在ClickHouse中实现资源隔离?火山引擎实践经验分享

    HBase最佳实践 - 集群规划

    数据治理实践 | 网易某业务线的计算资源治理

    ClickHouse 读写分离方案

    回到网易8个月测试团队转型实践