大数据东风下,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都做不了的东西，真的有资格叫大数据系统吗？

这坨屎有够清新脱俗的。