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的有效查询。但对于要求更灵活的工作负载来说，这可能是一个主要问题，因为您需要非常了解系统才能编写好的查询。