查看: 324|回复: 5

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

[复制链接]
论坛徽章:
523
奥运会纪念徽章:垒球
日期:2008-09-15 01:28:12生肖徽章2007版:鸡
日期:2008-11-17 23:40:58生肖徽章2007版:马
日期:2008-11-18 05:09:48数据库板块每日发贴之星
日期:2008-11-29 01:01:02数据库板块每日发贴之星
日期:2008-12-05 01:01:03生肖徽章2007版:虎
日期:2008-12-10 07:47:462009新春纪念徽章
日期:2009-01-04 14:52:28数据库板块每日发贴之星
日期:2009-02-08 01:01:03生肖徽章2007版:蛇
日期:2009-03-09 22:18:532009日食纪念
日期:2009-07-22 09:30:00
发表于 2021-4-7 22:33 | 显示全部楼层 |阅读模式
https://mp.weixin.qq.com/s/7xxikscq5pUrqP59_fQUJA
大数据东风下,Clickhouse这坨屎是怎么上天的[color=rgba(0, 0, 0, 0.3)]Original [color=rgba(0, 0, 0, 0.3)]努力赚钱的小作者 [url=]飞总聊IT[/url] [color=rgba(0, 0, 0, 0.3)]2 days ago
[color=rgba(0, 0, 0, 0.5)]收录于话题
#互联网和企业分析

[color=rgba(0, 0, 0, 0.5)]158个



网上有很多讲大数据的文章会告诉你,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都做不了的东西,真的有资格叫大数据系统吗?

这坨屎有够清新脱俗的。


[color=rgba(0, 0, 0, 0.9)][color=rgba(0, 0, 0, 0.5)]收录于话题 #互联网和企业分析
[color=rgba(0, 0, 0, 0.5)]158个

下一篇八卦AWS新CEO Adam Selipsky不为人知的故事













论坛徽章:
403
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
发表于 2021-4-8 05:44 来自手机 | 显示全部楼层
vectorwise很久以前就用过,后来改名叫vector,雪花以前没注意,前天看doris db的人刚发的文章提到他们要做中国的雪花,也要争取clickhouse 的用户和工程师

使用道具 举报

回复
论坛徽章:
0
发表于 2021-4-8 09:53 | 显示全部楼层
clickhouse在单机上做查询应该比其它数据库更快吧?咱不和分布式比,就比单机。

使用道具 举报

回复
论坛徽章:
0
发表于 2021-4-9 16:27 | 显示全部楼层
嘻嘻嘻

使用道具 举报

回复
论坛徽章:
403
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
发表于 2021-4-10 05:49 来自手机 | 显示全部楼层
与雪花比较 https://db-engines.com/en/system/ClickHouse%3BSnowflake

使用道具 举报

回复
论坛徽章:
403
紫蛋头
日期:2012-05-21 10:19:41迷宫蛋
日期:2012-06-06 16:02:49奥运会纪念徽章:足球
日期:2012-06-29 15:30:06奥运会纪念徽章:排球
日期:2012-07-10 21:24:24鲜花蛋
日期:2012-07-16 15:24:59奥运会纪念徽章:拳击
日期:2012-08-07 10:54:50奥运会纪念徽章:羽毛球
日期:2012-08-21 15:55:33奥运会纪念徽章:蹦床
日期:2012-08-21 21:09:51奥运会纪念徽章:篮球
日期:2012-08-24 10:29:11奥运会纪念徽章:体操
日期:2012-09-07 16:40:00
发表于 2021-4-10 05:57 来自手机 | 显示全部楼层
雪花有connect by语句  https://docs.snowflake.com/en/sql-reference/constructs/connect-by.html

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表