ClickHouse数据库的起源

21-05-17 banq

ClickHouse最初是Yandex Metrica中用于Web分析的解决方案,Metrica是一项用于分析网站流量的流行服务,目前在Google Analytics(分析)之后排名第二。

2008年,Metrica团队的工程师Alexey Milovidov正在寻找一个数据库,该数据库可以创建有关指标的报告,例如每天的页面浏览量,唯一身份访问者和跳出率,而无需预先汇总数据。该想法是提供广泛的度量标准数据,并让用户提出有关它们的任何问题,这是数据仓库的经典问题。

但是,Alexey找不到满足Yandex要求的程序,特别是大型数据集,线性缩放,高效和与SQL工具的兼容性。简而言之:类似于MySQL,但用于分析应用程序OLAP。

于是Alexey 写了一个这样原型,它最初是做GROUP BY操作的原型。该原型演变成一个完整的解决方案,名称为ClickHouse,简称“ Clickstream Data Warehouse”。

Alexey添加了其他功能,包括SQL支持和MergeTree引擎。SQL方言从表面上类似于MySQL,后者也在Metrica中使用,但是如果没有复杂的预聚合就无法处理查询工作负载。

到2011年,ClickHouse已在Metrica中投入生产。在接下来的5年中,Alexey和不断壮大的开发人员团队将ClickHouse扩展到了新的用例。

到2016年,ClickHouse已成为Metrica的核心后端服务。它也已根深蒂固地成为Yandex内的数据仓库,并扩展到诸如服务监视,网络流日志和事件管理之类的用例。

ClickHouse已由最初的一个人项目演变为业务关键软件,由Alexey领导的十多名工程师组成的完整团队。

到2016年,ClickHouse已有8年的历史,并准备成为大型开源项目。

 

ClickHouse是什么?

它是一个面向列的数据库。这意味着,在内部,它会将列存储在一起而不是将行存储在一起。实际上,这意味着它已针对在大型数据集上计算分析进行了优化。

它可以很好地替代时间序列数据库,即使从技术上讲它不是时间序列数据库。有人将数据从InfluxDB迁移到ClickHouse,性能得到显着提高。

 

黑客网友评论:

我们的DevOp讨厌它,并抱怨它多“脆弱”。

让zookeeper正常运行似乎非常痛苦。出于某种原因,获得一致的复制似乎很困难,并且多个副本存在一些问题。如果你有3个副本,1个副本死了,当这个死去的副本恢复回来时,它竟然不同步,并拒绝自动重新同步自己。所以必须有人去戳它,让它再次工作。

在实践中,这些都不是问题,这种情况只有在进行“混沌工程”测试时才出现,但这让DevOps非常紧张。

另一方面,每当我们试图在同样硬件上进行基准测试时,它比使用AWS Redshift/Apache Drill/PostgreSQL快几个数量级,所以我们坚持使用下去。

 

我们在生产中运行了一个非一般规模的Clickhouse服务器,用于存储和查询应用程序日志(半结构化JSON文档)。

在我们的案例中,我们从一个作为真相源泉的kafka主题中消费,因此我们选择不使用Clickhouse的内置写复制机制,而是手动分片并独立写入每个副本(这意味着复制并不总是对全新数据进行完美同步,但在实践中这是可以接受的)。

尽管设置很奇怪,但分布式查询方仍然工作得很好,即使我们出于这样或那样的原因正在做一些奇怪的事情,比如重新分片或删除一些副本。

我们不和其内部备份打交道,因为我们已经将卡夫卡流视为真相的来源,而不是clickhouse数据存储。我们以更适合长期存档而不是实时查询的格式将数据直接从kafka归档。

我使用Clickhouse的经验是,核心原语是坚如磐石的,但在使用更多功能时,你经常处于不稳定的状态——例如,我们在尝试使用bloom过滤器进行文本搜索时遇到崩溃。

Clickhouse的表演绝对让我大吃一惊。它可以像基础磁盘提供数据一样快速读取、过滤和聚合结果。不过,我要指出,虽然Clickhouse非常擅长它的作用,但它给设计模式和编写查询的人带来了很大工作,以确保它以正确的方式做到这一点。在我们的情况下,这很好用,因为我们只需要服务少量的查询“形态”,并且我们有一个CLI工具,可以将用户用简单的DSL(实际上只是一个键匹配值过滤器表达式)编写的查询转换为SQL,这将导致clickhouse的有效查询。但对于要求更灵活的工作负载来说,这可能是一个主要问题,因为您需要非常了解系统才能编写好的查询。

 

1
猜你喜欢