Clikhouse产生背景以及概述（一）

1、需求背景

1.1 概述

随着数据科技的进步，数据分析师早已不在满足于传统的T+1的报表或者类似于MOLAP这种类型提前设置好维度和指标的OLAP也就是Cube，类似Kylin。数据分析师更希望使用可以支持 任意指标、任意维度并且可以秒级反馈的大数据量下的Ad-hoc查询 。

这个需求对大数据领域来说 是一项非常大的挑战，传统的大数据查询引擎根本无法做到这一点。由俄罗斯的Yandex公司开源的ClickHouse脱颖而出。在第一届易观OLAP大赛中，在用户行为分析转化漏斗场景里，Clickhouse比Spark快了将近10倍。在随后的几年大赛里面，面对各类的大数据引擎的挑战， Clickhouse一直稳坐冠军宝座。同时在各种OLAP查询引擎评测中，Clickhouse单表查询的速度力压现在流行的各大数据库引擎，尤其是Ad-hoc查询速度是一直遥遥领先的，因此被国内大量用户和爱好者广泛用在即席查询场景中。

1.2 Clickhouse的性能测试

平均消耗时间

SQL

Clickhouse性能测试：

https://clickhouse.tech/benchmark/dbms

1.3 架构目标

1、海量数据的存储

2、实时导入

3、实时查询

4、可以进行多维度聚合分析

2、选型分析

2.1 我们先来看看OLAP的场景都有哪些特征

1、读多写少

不同于事务处理（OLTP）的场景，比如电商汇总加购，下单，支付等需要在原地进行大量的update、delete、insert的操作。数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。

数据一性写入后，分析书需要尝试从各个角度对数据做挖掘、分析，直到发现其中的商业价值、业务变化趋势等信息。这是一个需要反复试错、不断调整、持续优化的一个过程，其中数据的读取次数远多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。

2、大宽表，读取大量的行但是少量的列，结果集比较小

在OLAP场景中， 通常存在一张或者是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中少数的几个列作为维度列，其他少数几列作为指标列，然后对全表或者某一个较大范围内的数据做聚合计算，例如月度，这个过程会扫描大量的行数据，但是可能只用到了其中的少数几个列。聚合计算的结果集也比动辄数十亿的原始数据，也明显小得多。

3、数据批量写入，且数据不更新或者少更新

OLTP类业务对于延时（Latency）要求更高，要避免给客户等待造成业务损失；而OLAP类业务，由于数据量非常大。通产个更加关注写入和吞吐，要求海量数据能够尽快导入完成。一旦完成，历史数据往往作为存档，不会做更新和删除操作。其实也有这种需求，哈哈，有些人叫刷数小王子 不是白叫的，对数皇帝，嘿嘿。

4、无需事务，数据一致性要求低

OLAP类业务对于事务需求较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。多数OLAP系统都支持最终一致性。

5、灵活多变，不适合预先建模

分析场景下，随着业务变化要及时调整分析维度、挖掘方法，以尽快发现数据价值、更新业务指标。而数据仓库中通常存储着海量的历史数据，调整代价十分高昂。预先建模技术虽然可以在特定场景中加速计算，但是无法满足业务灵活多变的发展需求，维护成本过高。

2.2 选型思考

1、Kylin 明显不适合

2、Greenplum 对于大数据量下的表现并不是很好

3、kudu和impala对于开发人员有着一些挑战，玩的好了很厉害，不好了会很难受

4、Druid 是一个预聚合的系统，对于广告来讲是很棒的，但是明细可能并不是那么优秀，数据导入也比较复杂

5、Doris是一个不错的选择，百度开源的，但是经过我们的测试和clickhouse比较还是有些慢的。

6、Clickhouse是一个很棒的选择，但是支持他的bi工具是比较少的，但是我们只是用来做实时分析，BI工具是比较好找的，但是DBMS是不好找的，经过测试我们被clickhouse的速度惊吓到了

所以最后我们就选择采用ClickHouse，我们再来看看Clickhouse的官网解释

1、绝大多数请求都是读请求 2、数据以相当大的批次（> 1000行）更新，而不是单行更新;或者它根本没有更新。 3、数据已添加到数据库，但不会进行修改。 4、对于读取，每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列 5、表格“宽”，意味着它们包含大量列。 6、查询相对较少（通常每台服务器数百个查询或每秒更少）。 7、对于简单查询，允许延迟大约50毫秒。 8、列中的数据相对较小：一般来说，都是数字和短字符串(例如，每个URL 60个字节) 9、处理单个查询时需要高吞吐量（每个服务器每秒最多数十亿行）。 10、Transactions不是必需的。 11、对数据一致性要求低。 12、每个查询有一个大表。所有其他表都很小，除了这个大表。 13、查询结果明显小于源数据。换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中

很容易看出OLAP场景与其他流行场景（例如OLTP或键值访问）非常不同。 因此，如果希望获得不错的性能，尝试使用 OLTP 或 键值DB 来处理分析查询是没有意义的。 例如，如果尝试使用MongoDB 或Redis 进行分析，则与OLAP数据库相比，性能会非常差。

3、ClickHouse概述

3.1 列式数据库结构

行式数据库

列式数据库

1. 对于分析查询，只需要读取少量的表列。在面向列的数据库中，您可以只读取所需的数据。例如，如果您需要100列中的5列，则可以预期I/O将减少20倍。
2. 由于数据是以数据包的形式读取的，因此更容易压缩。列中的数据也更容易压缩。这进一步减少了I/O容量。
3. 由于减少了I/O，系统缓存中可以容纳更多的数据。

3.2 列式存储的特点

相比于行式存储，列式存储在分析场景下有着许多优良的特性。

1、如前所述，分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的 数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取操作被严重放大。而列存模式下，只 需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。 

2、同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的 存储空间，降低了存储成本。 

3、更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。

4、自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同 列类型，选择最合适的压缩算法。

5、高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。

3.3 ClickHouse概述

ClickHouse 是俄罗斯搜索巨头 Yandex 公司早 2016年 开源的一个极具 " 战斗力 " 的实时数据分析数据库，是一个用于联机分析 (OLAP:Online Analytical Processing) 的列式数据库管理系统(DBMS:Database Management System)，简称 CK，工作速度比传统方法快100-1000倍，ClickHouse的性能超过了目前市场上可比的面向列的DBMS。 每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。它允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器，支持线性扩展，简单方便，高可靠性，容错。

ClickHouse 作为一个高性能 OLAP 数据库，虽然OLAP能力逆天但也不应该把它用于任何OLTP事务性操作的场景，相比OLTP：不支持事务、不擅长根据主键按行粒度的查询、不擅长按行删除数据，目前市场上的其他同类高性能 OLAP 数据库同样也不擅长这些方面。因为对于一款OLAP数据库而言，OLTP能力并不是重点。

ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。这些功能共同为ClickHouse极速的分析性能奠定了基础。

ClickHouse适合流式或批次入库的时序数据。ClickHouse不应该被用作通用数据库，而是作为超高性能的海量数据快速查询的分布式实时处理平台，在数据汇总查询方面(如GROUP BY)，ClickHouse的查询速度非常快。

典型特点总结： ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、具有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用

简单的说，ClickHouse作为分析型数据库，有三大特点：一是跑分快， 二是功能多 ，三是文艺范

1、跑分快

ClickHouse性能超过了市面上大部分的列式存储数据库，相比传统的数据ClickHouse要快100-1000X，

ClickHouse还是有非常大的优势：

100Million 数据集:ClickHouse比Vertica约快5倍，比Hive快279倍，比MySQL快801倍

1Billion 数据集:ClickHouse比Vertica约快5倍，MySQL和Hive已经无法完成任务了

2、功能多

支持类SQL查询，

支持繁多库函数（例如IP转化，URL分析等，预估计算/HyperLoglog等）

支持数组(Array)和嵌套数据结构(Nested Data Structure)

支持数据库异地复制部署

3、文艺范

相对较缺乏的文档，社区刚开始活跃，只有开源的C++源码

不理睬Hadoop生态，走自己的路

3.4 Clickhouse的适用场景

适合 ：用于结构良好清晰且不可变的事件或日志流分析。

1、Web和App数据分析 
2、广告网络和RTB 
3、电信 
4、电子商务和金融 
5、信息安全
6、监测和遥测 
7、时序数据
8、商业智能 
9、在线游戏
10、物联网

不适合 ：事务性工作(OLTP)，高请求率的键值访问，低延迟的修改或删除已存在数据，Blob或文档存储，超标准化数据。

1、事物性工作（OLTP） 
2、高并发的键值访问 
3、Blob或者文档存储 
4、超标准化的数据