专栏首页飞总聊IT大数据东风下,Clickhouse这坨屎是怎么上天的

大数据东风下,Clickhouse这坨屎是怎么上天的

网上有很多讲大数据的文章会告诉你,Clickhouse是来自俄罗斯的“大数据”查询引擎。这个由Yandex主导的大数据引擎,非常的牛逼,速度超级快。然后这个传说就在不断的传播中越传越遥远。

我本来对Clickhouse知道的非常少,记忆中有两件事情能扯上关系。第一件事是2015年VLDB在印度开。开完会以后我报了个团,慕名去泰姬陵。那天一辆小巴车接了我,又在半路接了另外一个酒店接了几个俄罗斯人。

去泰姬陵要开3个半小时的车,路上几个俄罗斯人就介绍说,我们正在开发一个大数据系统,叫Clickhouse。后面其中有个俄罗斯人就经常在各种Clickhouse的meetup里面频频出现了。当时我也就一听,呵呵了。后面就忘记了这回事。直到后来别人再提起Clickhouse

另外一件事情是2020年VLDB的时候,TiDB的HTAP论文,里面提到了它们的AP部分,是拿Clickhouse的代码来魔改得到的。

最近因为一些原因,需要了解一下Clickhouse到底是个什么东西,但是没什么文章能把这事情说清楚的,所以就自己去看源代码了。打开一看,吓我一跳,好大一坨屎。

当然,哪里都有屎,HIVE里面就有很多屎。不能仅仅因为屎代码,就直接否认了一个系统。问题吧,Clickhouse的屎,和别的系统还不太一样,很有特点。

看Clickhouse的代码,最重要的不要把这个系统当成是个大数据的系统。把它当成一个单机数据库来看,就比较好理解。一个单机数据库,怎么变成了大数据系统,这就是我觉得屎的别样的地方。

下面的东西比较技术一点,会涉及数据库系统的比较核心的东西。讲真,我很久没有那么干巴巴的聊纯技术的东西了。可能90%我的读者不一定看得懂了。见谅。

数据库系统来说,除去外围的东西,我们一般会注意Compiler, Optimizer, Runtime, Storage有时候也要看一下Catalog,或者叫Metadata service。我习惯了用英文,就不一一翻译成中文了,大家自行翻译吧。我本人对Compiler Optimizer,Runtime都还比较熟,Runtime经常也叫做query execution,metadata service也还行,storage相对来说差点。

Clickhouse的compiler和optimizer有种一塌糊涂的感觉。在一个正规的数据库产品里,Compiler一般是Parse, Syntax check, Binding, Semantic check.

Parse会用Parser generator比如说YACC或者ANTLR来通过文法产生,得到一棵AST(Abstract Syntax Tree),之后的Syntax check检查语法,Binding解决每个词到底是什么,是column name, table name 还是function name等等。Semantic Check会做语义检查,最后AST被转化成Logical Operator Tree。

我说了那么多,算科普了。Clickhouse的compiler,Parser是手写的,Parser干了很多活,后面接一个Interpreter。后者干了一半Compiler一半Optimizer的活。

Optimizer在一个数据库系统里面是大头,一般要么是SystemR那样自底向上的要么是Volcano那样自顶向下的。前者以DB2为代表,后者SQL Server为代表。比较新一点的Optimizer都自称自己是Volcano style,但是每个还是有点不一样。

Clickhouse这种鼻子眉毛胡子一起的,倒是真的吓着我了,见过差的,没见过这样离谱的,连Parser generator都不用的。

Rumtime是亮点。Clickhouse的Runtime有种熟悉感。仔细看看是Vectorwise的做法。关于这个可以去看Marcin Zukowski的博士论文。这篇论文绝对是值得一读的,上百页满满的干货。

链接给出来了在下面。

https://dare.uva.nl/search?identifier=5ccbb60a-38b8-4eeb-858a-e7735dd37487

这位叫Marcin的人,毕业后就开了公司Vectowise,做的是MonetDB里面这个vectorization引擎的创业,擅长跑TPCH。2010年公司卖给Ingres以后跑美国来二次创业,开了一家叫Snowflake的公司。现在当然已经是亿万富翁了。Snowflake的故事可以看这篇文章Snowflake:价值200亿美元的云端数据库厂商

Clickhouse的Runtime就很有这篇论文里面讲述的风格了。我看过几个抄vectorwise代码的查询引擎,总是有种说不出来的感觉。

Clickhouse的代码里面还有一个很不舒服的地方,什么东西都给你搞一堆,Hash Table也有几十种做法。往好了说,是为了提高性能,极致。往不好了说,脑袋有点被驴踢了。是不是需要这样优化,值得商榷,起码在compiler和optimizer一坨屎的情况下,是不是要这样优化。

最神奇的地方来了,这个系统是怎么样实现分布式查询的呢?它的存储层是通过IStorage这个接口来做的。所以它搞了一个Distributed Table来硬生生的扩展出一片天地来。

Distributed Table是为了在单机引擎上实现分布式处理的一种Hack,堂而皇之的就越做越大,最后把自己吹成了一个分布式引擎。

Distributed Table你可以认为是在不同节点上的单机Table的一个UNION ALL。对这样一个表如果做单表查询的话,相当于我可以对每个表单独先查询,再把结果UNION ALL起来。

如果说再扩展一下的话,我还可以把Aggregte做push down,采用local aggregate和global aggregate两层。我知道说到这里,大概撑死了1%读我这篇文章的人能看懂我说什么。

这当然不是真的分布式引擎。最多只能处理一下单表查询,要是给它塞两张distributed table做个join,这个系统就原形毕露了。

科普一下,分布式系统,在数据库里面是通过exchange opertor来实现对数据的shuffle的,这需要从optimizer到runtime都有支持。有一些投机取巧的地方可以做,但整体来说,是个大活。

没有exchange operator,不能够做data shuffling的东西,没资格自称是大数据系统。

这其实解释了一个最本质的问题:Clickhouse建议大家把数据做成一张又大又长的单表来存。为什么啊,它就没办法处理两张分布式的表,只能让大家存成一张表了。

我不是说存成一张表就是问题,某些应用,比如说日志查询,一张表也就够了。但是李鬼,哪怕是个很快的李鬼,你不能把自己硬吹成李逵。没有exchange operator,不能做data shuffle的系统好意思叫自己是个大数据系统?

除了这个分布式查询的设计很扯淡以外,Clickhouse的replication也很扯淡。Replication的办法是建立一张新的表,名字完全不一样,然后和老的表共享同一个ZooKeeper的path。这样你们两张表以后就同生共死,是兄弟了。对我的操作一定会复制给你,对你的操作也反之亦然。问题是,我如果是个新用户的话,我鬼知道原来李逵就是李鬼,李鬼也是李逵。这产品经理要在我手下干活,早就领盒饭了。

扯了这么多,我就觉得很扯淡的,有那么多的人在吹Clickhouse这个大数据系统。我也不否认在特定应用场景下,Clickhouse可以跑的很快,但是一个连分布式join都做不了的东西,真的有资格叫大数据系统吗?

这坨屎有够清新脱俗的。

本文分享自微信公众号 - 飞总聊IT(feiitworld),作者:努力赚钱的小作者

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

原始发表时间:2021-04-06

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 那些牛叉无比的评审风格

    我们可以见到许多有意思的编程风格,又没有精神为之一振的感觉,仿佛里面的例子就在自己身上,或者离自己很近。其实,对于文档、代码的评审,也是有诸多风格可言的,我这里...

    MavenTalker
  • 如何写出优秀的代码

    写了太多屎一样的代码,终于不臭了!更多精彩文章请关注公众号『Pythonnote』或者『全栈技术精选』

    小闫同学啊
  • 掏了一把祖传代码,屎山!

    凑近了一看,在不净的框架中,乱码般的语句在运转,像生了麻风病的蛞蝓一样在喷吐,粘稠的水在流动,而穿着格子衫的人群则在焰柱旁围成了一个半圆,这就是码农的仪式。他们...

    程序员小浩
  • 项目中Dao,Service,Controller,Util,Model是什么意思,为什么划分?

    对的,这种感受是绝对不会错的。而我们要做的就是把这团毛线,变成像瑞士军刀一样的清晰。

    Rookie
  • 自己动手写一个PHP组件

    许杨淼淼
  • 程序员请改掉影响你升职加薪的36个坏习惯!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    Java后端技术
  • 这36个坏习惯,影响着程序员是否能升职加薪!

    IT行业的科技公司们一直苦苦追寻传说中以一当十的超级程序员,最新的研究表明确实存在这样一小撮效率奇高的“程序金刚”,但是一位普通程序猿如何能够蜕变成代码金刚呢?

    用户5224393
  • 看了很多技术书,为啥仍然写不出项目?

    这大概是还在读书的同学最大的困惑了。自己明明看了很多书,感觉不到自己的进步,很有挫败感。计算机科学是一门实践的科学,你发现你看了《现代操作系统》,《CSAPP》...

    Leetcode名企之路
  • 未来已来——iphone X 开启时代大门(附官方设计规范下载)

    另外iphone8的设计尺寸要出了,所以老板马上会给你配iphone8的,不要着急

    宇相

扫码关注云+社区

领取腾讯云代金券