专栏首页ClickHouse的秘密基地这会是ClickHouse解决数据一致性的新法宝吗?

这会是ClickHouse解决数据一致性的新法宝吗?

大家都知道,由于 MergeTree 的实现原理导致它只能支持数据的最终一致性。什么?你不知道?请进传送门。这导致我们在使用 ReplacingMergeTree、SummingMergeTree 这类表引擎的时候,会出现短暂数据不一致的情况。

在某些对一致性非常敏感的场景,通常有这么几种解决方案。

一种是在写入数据后,立刻通过

OPTIMIZE TABLE PARTITION part FINAL

强制触发新写入分区的合并动作。

一种是通过 GROUP BY 查询 + 过滤实现,可以参考我先前的文章 传送门2号

还有一种是通过 FINAL 查询实现,即在查询语句后增加 FINAL 修饰符,这样在查询的过程中将会执行 Merge 的特殊逻辑(例如数据去重,预聚合等)。

但是这种方法基本没有人使用,因为在增加 FINAL 之后,我们的查询将会变成一个单线程的执行过程,查询速度非常慢。

但是在最新的 MaterializeMySQL 中,消费同步 binlog 的表使用了 ReplacingMergeTree,而它实现数据去重的方法就是使用了 FINAL 查询,难道不怕慢吗?不知道 MaterializeMySQL ? 请进传送门3号

原来在 v20.5.2.7-stable 版本中,FINAL 查询进行了优化,现在已经支持多线程执行了,并且可以通过 max_final_threads 参数控制单个查询的线程数。https://github.com/ClickHouse/ClickHouse/pull/10463

支持了多线程的 FINAL 查询到底性能如何呢? 我们就来试试看吧。

这里直接使用 Yandex 提供的测试数据集 hits_100m_obfuscated,它拥有 1亿 行数据,105个字段,DDL示意如下:

ATTACH TABLE hits_100m_obfuscated(    
`WatchID` UInt64,     
`JavaEnable` UInt8,     
`Title` String,     
`GoodEvent` Int16,     
`EventTime` DateTime,     
... 
)ENGINE = ReplacingMergeTree()
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID), EventTime)
SAMPLE BY intHash32(UserID)

我使用了两台 8c 16g 的虚拟机,分别安装了19.17.4.11 和 20.6.3.28 两个版本的 CH 进行对比。

首先在 19.17.4.11 中执行普通的语句:

select * from hits_100m_obfuscated WHERE EventDate = '2013-07-15' limit 100

100 rows in set. Elapsed: 0.595 sec.

接近0.6秒返回,它的执行日志如下所示:

Expression
 Expression
  ParallelAggregating
   Expression × 8
    MergeTreeThread

可以看到这个查询有8个线程并行查询。

接下来换 FINAL 查询:

select * from hits_100m_obfuscated FINAL WHERE EventDate = '2013-07-15' limit 100

100 rows in set. Elapsed: 1.406 sec.

时间慢了接近3倍,然后看看 FINAL 查询的执行日志:

Expression
 Expression
  Aggregating
   Concat
    Expression
     SourceFromInputStream

先前的并行查询变成了单线程,所以速度变慢也是情理之中的事情了。

现在我们换到 20.6.3.28 版本执行同样的对比查询

首先执行普通的不带 FINAL 的查询:

select * from hits_100m_obfuscated WHERE EventDate = '2013-07-15' limit 100 settings max_threads = 8

100 rows in set. Elapsed: 0.497 sec.

返回时间很快,在 CH 新版本中已经实现了 EXPLAIN 查询,所以查看这条 SQL 的执行计划就很方便了:

explain pipeline select * from hits_100m_obfuscated  WHERE EventDate = '2013-07-15' limit 100  settings max_threads = 8

(Union)
Converting × 8
  (Expression)
  ExpressionTransform × 8
    (Limit)
    Limit 8 → 8
      (Expression)
      ExpressionTransform × 8
        (ReadFromStorage)
        MergeTreeThread × 8 0 → 1

很明显的,该SQL将由8个线程并行读取 part 查询。

现在换 FINAL 查询:

select * from hits_100m_obfuscated final WHERE EventDate = '2013-07-15' limit 100  settings max_final_threads = 8

100 rows in set. Elapsed: 0.825 sec.

查询速度没有普通的查询快,但是相比之前已经有了一些提升了,我们看看新版本 FINAL 查询的执行计划:

explain pipeline select * from hits_100m_obfuscated final WHERE EventDate = '2013-07-15' limit 100  settings max_final_threads = 8

(Union)
Converting × 8
  (Expression)
  ExpressionTransform × 8
    (Limit)
    Limit 8 → 8
      (Expression)
      ExpressionTransform × 8
        (Filter)
        FilterTransform × 8
          (ReadFromStorage)
          ExpressionTransform × 8
            ReplacingSorted × 8 6 → 1
              Copy × 6 1 → 8
                AddingSelector × 6
                  ExpressionTransform
                    MergeTree 0 → 1
                      ExpressionTransform
                        MergeTree 0 → 1
                          ExpressionTransform
                            MergeTree 0 → 1
                              ExpressionTransform
                                MergeTree 0 → 1
                                  ExpressionTransform
                                    MergeTree 0 → 1
                                      ExpressionTransform
                                        MergeTree 0 → 1

可以看到新版本 FINAL 查询的执行计划有了很大的变化。 在这条 SQL 中,从ReplacingSorted 这一步开始已经是多线程执行了。

不过比较遗憾的是,目前读取 part 部分的动作还是串行的。在这里例子中可以看到,这张表有6个分区被依次加载了。

好了,现在总结一下:

  1. 从 v20.5.2.7-stable 版本开始,FINAL 查询执行并行执行了
  2. 目前读取 part 部分的动作依然是串行的
  3. 总的来说,目前的 FINAL 相比之前还是有了一些性能的提升

最后的最后,FINAL 查询最终的性能和很多因素相关,列字段的大小、分区的数量等等都会影响到最终的查询时间, 所以大家还是需要基于自己的业务数据多加测试。

本文分享自微信公众号 - ClickHouse的秘密基地(chcave),作者:凯朱

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-08-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 认识 ClickHouse-3306π 深圳站

    1. 爱可生目前是否已经对 ClickHouse 研发特有产品? 2. 如何看待 ClickHouse 的未来趋势? 3. ClickHouse 作为列式存储 ...

    爱可生开源社区
  • PB级数据实时分析,ClickHouse到底有多彪悍?

    腾讯公司内部有很多业务使用 ClickHouse,比较典型的就是QQ音乐。QQ音乐在使用 ClickHouse 之前,用的是基于 Hive 构建的离线数仓,当时...

    腾小云
  • 在DB-Engines的排名不高,ClickHouse还值得关注吗?

    我回答道:"其实很简单啊,你看看周边的人,都是在怎么学ClickHouse,不就明白了吗?" 接着,我拿出手机,给他看了下面这张照片。

    Nauu
  • ClickHouse 在日志存储与分析方面作为 ElasticSearch 和 MySQL 的替代方案

    2018年,我写过一篇关于Clickhouse的文章,这段内容在互联网上仍然很流行,甚至被多次翻译。现在已经过去两年多,同时 Clickhouse 的开发节奏仍...

    zhisheng
  • 《这么多MergeTree 表引擎,我该怎么选?》- part 1

    第一性原理这个概念大家应该不会陌生,它原本是由古希腊哲学家亚里士多德提出的,意指“在系统中会存在一个最基本的命题,它不能被违背或者删除”。

    Nauu
  • Elasticsearch 聚合数据结果不精确,怎么破?

    请教一个问题,ES 在聚合的时候发生了一个奇怪的现象聚合的语句里面size设置为10和大于10导致聚合的数量不一致,这个size不就是返回的条数吗?会影响统计结...

    铭毅天下
  • 干货 | 携程ClickHouse日志分析实践

    Gavin Zhu,携程软件技术专家,负责监控系统运维开发、ES系统运维及Clickhouse技术应用推广及运维工作。

    携程技术
  • ClickHouse高性能列存核心原理

    ClickHouse是近年来备受关注的开源列式数据库,主要用于数据分析(OLAP)领域。目前国内各个大厂纷纷跟进大规模使用:

    大鹅
  • ClickHouse为何如此之快?

    作为一个拥有ClickHouse信仰标签的忠实粉丝,我自然也是追寻谜底的一份子。在我苦苦寻觅许久之后,今天,终于被我找到了答案。所以特地拿来与各位分享,谜底就在...

    Nauu
  • [业界方案] ClickHouse业界解决方案学习笔记

    本文通过分析总结几篇文章来看目前工业界可能偏好的解决方案。学习目的是:大致知道其应用领域,技术特点和未来方向,看看目前工作中是否可以用到,或者当以后选型时候能够...

    罗西的思考
  • 干货 | 性能提升400%,ClickHouse在携程酒店数仓的实践

    随着时间推移和业务的快速发展,携程酒店数据累积越来越多。目前流量日数据在3T左右,再加上各种订单、价、量、态等数据更是庞大。现有Hive(Spark引擎)执行速...

    携程技术
  • 查询提升 200 倍,ClickHouse 你值得拥有!

    来源:https://juejin.im/post/6863283398727860238

    Java技术栈
  • Clickhouse 系列 - 番外 - LSM 算法

    在本系列的第三章中介绍了 clickhouse 通过 block 和 lsm 来减少磁盘读取的数据量。严谨的逻辑应该时 clickhouse 通过 lsm 算法...

    不会飞的小鸟
  • 一个比传统数据库快 100-1000 倍的数据库

    来源 | https://juejin.im/post/6863283398727860238

    程序猿DD
  • 交互式分析领域,为何ClickHouse能够杀出重围?

    导语 | 在百花齐放的交互式分析领域,ClickHouse 绝对是后起之秀,它虽然年轻,却有非常大的发展空间。本文将分享 PB 级分析型数据库 ClickHou...

    Spark学习技巧
  • 赠书 | Redis数据库学习必备书籍!

    DB-Engines最近发布了2021年4月份的数据库排名。该网站根据数据库管理系统的受欢迎程度对其进行排名,实时统计了370种数据库的排名指数。前20名的排行...

    小F
  • ClickHouse大数据领域企业级应用实践和探索总结

    2020年下半年在OLAP领域有一匹黑马以席卷之势进入大数据开发者的领域,它就是ClickHouse。在2019年小编也曾介绍过ClickHouse,大家可以参...

    王知无-import_bigdata
  • 重磅来袭:腾讯云ClickHouse支持数据均衡服务

    ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。它于2016年以apache 2.0协议开源,以优秀的查询性能,深受广大大数...

    腾讯云大数据
  • 重磅来袭:腾讯云ClickHouse支持数据均衡服务

    ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。它于2016年以apache 2.0协议开源,以优秀的查询性能,深受广大大数...

    fastio

扫码关注云+社区

领取腾讯云代金券