ClickHouse浅谈

21年笔记迁移

前置知识

什么是OLAP与OLTP

OLAP（OnLine Analytical Processing）联机分析系统；
OLTP（OnLine Transaction Processing）联机事务处理系统；

OLAP主要用来读取数据、分析数据，辅助运营决策分析。
数据一次性批量写入后，分析师需要从各种角度出发，对数据进行挖掘分析，以期发现其中的商业价值、业务变化趋势等；
OLAP主要用来做离线分析，对时效性要求不高。
OLAP主要的开源产品包括HDFS、HIVE和Impala等；目标应用场景就是一次写入，多次读取；

OLTP是进行事务的增删改查。
比如在电商系统中进行商品的购买、库存减少、购物车下单支付等。
OLTP是传统的关系型数据库的主要应用，也被称为是面向交易的处理系统，一般用于大数据在线业务系统中，要求有实时性。

OLAP：读 + 一次性的写入；
OLTP：实时的读 + 实时的写

如此理解：OLTP可变相视为是OLAP的数据源。
前期我们需要通过OLTP来进行数据的累积，当数据累积到一定的程度，我们需要对过去发生的事情做一个统计分析，来为公司的决策提供支持，这时候就是在做OLAP了。

综上，简单地说，OLAP是OLTP的延展，让数据发挥更大价值。

再加一点，传统的数据库，主要是面向OLTP，而数据仓库主要面对OLAP，侧重决策分析。
所谓数据仓库，是一个更好的支持企业或者组织的决策分析处理的面向主题的、集成的、不可更新的、随时间不断变化的数据集合。

行式数据库与列式数据库

什么是行式和列式？

行式数据库：以行相关的存储体系进行数据存储；
列式数据库：以列相关的存储体系进行数据存储；

假设现在我们有下图这样的数据：

行式存储，会将一行数据串成一串字符，一行一行存储，即：

列式存储，会将一列字符串成一串，一列一列做存储，即：

相比来讲，列式存储更适合查询，每一列都是索引。

行式和列式的优缺点

列式数据库：

• 每一列单独存储，意味着数据本身就是索引，查询快；
• 每一列数据类型一致，意味着更高效的压缩；
• 只将select集合中需要的列读入内存，极大降低系统的IO。

列式的优点就是行式的缺点。

行式数据库擅长随机读操作，列式数据库更擅长大批量数据的查询。
列式数据库本身就是面向大数据环境下的数据分析而生，适合大量数据而不是小批量数据，适合查询操作而不是增删改。
列式数据库在并行查询处理和压缩上更有优势，列式数据库的主要应用场景就是在99%的操作都是查询的应用。很适合OLAP。
列式数据库的代表包括：[HANA], [Sybase IQ]]，ParAccel, Sand/DNAAnalytics和 Vertica。

ClickHouse

什么是clickhouse？

俄罗斯第一大搜索引擎Yandex在2016年6月15日开源了一个数据分析的数据库，名字叫做ClickHouse，开源免费，圈内人戏称为“喀秋莎数据库。
其图标：

这个列式存储数据库的跑分要超过很多流行的商业数据库软件，例如Vertica；
受欢迎程度也比其他的高。

clickhouse的使用架构

腾讯的ClickHouse使用架构：

头条的一个基于Clickhouse集群的架构：

可以看到，围绕clickhouse集群，有很多数据源，包括离线的数据、实时的消息中间件数据，也有些业务的数据等，外围也提供一个数据ETL的Service，定期把数据迁移到clickhouse local storage上，最后再在clickhouse集群上架几个分析系统。

clickhouse的优点和缺点

clickhouse的三大特点：跑分快、功能多、限制多。
为什么说它跑分快？
一亿数据：
ClickHouse比Vertica约快5倍，比Hive快279倍，比My SQL快801倍；
十亿数据：
ClickHouse比Vertica约快5倍，MySQL和Hive已经无法完成任务了；

ClickHouse的快是因为采用了并行处理机制，在默认情况下，即使一个查询，也会占用服务器一半的CPU去执行，这也是ClickHouse不能支持高并发的原因。(当然，这个占用核数是可以配置的)
另外，它的压缩率高，目前clickhouse的数据压缩能够达到30%～40%。

为什么说限制多？
据说，clickhouse生来就是为小资服务的。

• 目前只支持Ubuntu系统。windows下需要Ubuntu虚拟环境；
• 不支持高并发，官方建议QBS(每秒查询率)为100；
• 不提供设计和架构文档，设计很神秘的样子，只有开源的C++源码；
• 不理睬Hadoop生态，采用 Local attached storage 作为存储，走自己的路，自我实现分布式部署。
• 不支持事务，不存在隔离级别；
• 写入慢；
• 上手存在难度，老毛子做的有些粗犷（所谓的喀秋莎数据库，有一部分是源于这里）；
• join性能欠佳，远不如其在单表上的表现，所以建议多使用宽表来代替join。(clickhouse支持列宽到一万列左右)

clickhouse的功能特性

计算层

多核并行、分布式计算、近似计算和复杂数据类型支持等；
多核并行：在clickhouse中数据被分成了多个分区，查询某条数据时通过多分区的数据，利用CPU的多核同时并行处理获取数据，降低了查询时长；
分布式计算：ClickHouse将查询任务拆分成多个子任务下发到多个集群中进行多机并行处理，最后汇聚结果给到用户，提供最近hostname规则（即将任务下发到机器最近的hostname节点）、inorder（即按顺序进行分发，当某个分片不可用时，下发到下一个分片）
近似计算：指的是牺牲一定的精确度获取数据，在海量数据的分析中，其实并不需要非常精准的数据，近似数据足以分析决策，ClickHouse提供了中位数、分位数（二分位数即中位数、四分位数等）等多种聚合函数，极大的提高了查询性能，减轻了计算压力。所谓的近似计算，实际上就是提供了一堆写好的聚合函数是吗，可提供迅速的近似计算。支持对数据进行抽样处理。
复杂数据类型支持：ClickHouse还提供了array、json、tuple、set等复合数据类型，也是极为有效的；

服务层

在存储层它实现了数据有序存储、主键索引、稀疏索引、数据分区分片、主备复制、有限支持delete和update等功能。

数据的有序存储指的是数据在建表时可以将数据按照某些列进行排序，排序之后，相同类型的数据在磁盘上有序的存储，在进行范围查询时所获取的数据都存储在一个或若干个连续的空间内，极大的减少了磁盘IO时间；
所谓数据分区分片，指的是在ClickHouse的部署模式上支持单机模式和分布式集群模式，在分布式中会把数据分为多个分片，并且分布到不同的节点上，它提供了丰富的分片策略，包含random随机分片（将写入数据随机分发到集群中的某个节点）、constant固定分片（将写入数据分发到某个固定节点）、columnvalue分片（将写入数据按某一列的值进行hash分片）、自定义表达式分片（将写入数据按照自定义的规则进行hash分片）
主备复制，可为一个主库配置多个副本，且默认配置下，任何副本都处于active模式，可以对外提供查询服务。

向量化引擎

ClickHouse实现了向量执行引擎（Vectorized execution engine），可以充分发挥CPU的性能。

对内存中的列式数据，一个batch调用一次SIMD(单指令多数据流)指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。

clickhouse提供了一个MySQL数据引擎，可以将MySQL中的表直接映射成自己的表（所以底层有时候会搞MySQL做底层），除此之外，clickhouse也有一个自己的数据引擎，可以执行正常的sql；

clickhouse的使用案例

今日头条用ClickHouse来做用户行为分析，内部一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。

腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。

携程内部从18年7月份开始 接入试用，目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询请求。

快手内部也在使用ClickHouse，存储总量大约10PB， 每天新增200TB， 90%查询小于3S。

在国外，Yandex内部有数百节点用于做用户点击行为分析，CloudFlare、Spotify等头部公司也在使用。Yandex有十几个项目在使用ClickHouse，它们包括：Yandex数据分析，电子邮件，广告数据分析，用户行为分析等等。

2012年，欧洲核子研究中心使用ClickHouse保存粒子对撞机产生的大量实验数据，每年的数据存储量都是PB级别，并支持统计分析查询。

与其他OLAP相比，clickhouse的优势

整体来讲：
相比商业的OLAP数据库，click house是开源免费的；
相比云解决方案，click house可以使用自己的机器部署，可不需要云付费；
相比Hadoop生态的DBMS们，click house不依赖Hadoop生态，自己就可以实现实时的高并发系统，也支持分布式机房的部署。
相比几个开源的OLAP数据库，clickhouse发展的更加成熟，稳定性更高，应用的场景更大。
相比非关系型数据库，ClickHouse可以支持从原始数据的直接查询，ClickHouse支持类SQL语言，提供了传统关系型数据的便利。

clickhouse与kylin的区别

• Kylin 适合高并发，固定模式查询场景
• ClickHouse 适合低并发，灵活即席查询场景

固定模式查询：
预先将客户的需求计算好以结果的形式存下来，当客户提出需求后，找到对应结果返回即可。
特点是当命中需求后返回非常快，同等资源下支持的数据体量更大，支持的并发更多；
不足则是当表的维度越多，越复杂，其所需的磁盘存储空间则越大，构建cube也需要一定的时间。

灵活即席查询：
实时根据用户提出的需求对数据进行计算后返回给用户，所以用户使用相对比较灵活，可以随意选择维度组合来进行实时计算。

另外，原理上，Kylin 是基于Hadoop平台,通过预计算, 定义cube模型的MOLAP分析（多维联机分析处理），即以空间换时间；
而clickhouse是关系型联机分析处理（ROLAP），主张通过极致使用CPU的性能达到高性能的OLAP分析。

相同点上， Kylin 和 ClickHouse 都能通过 SQL 的方式在 PB 数据量级下,亚秒级(绝多数查询 5s内返回)返回 OLAP(在线分析查询) 查询结果。

大数据技术的演变

一开始大家发现原生的MapReduce实在太难写了，大家迫切的需要一种高级语言层来描述数据的计算过程（这个过程就好比，你有了汇编之后，虽然什么都能干了，但是真的是太繁琐了，于是衍生了一堆C++和Java等高级语言）。

于是便有了pig和hive。

pig是以接近脚本的方式去描述MapReduce，而Hive用的是类SQL语言，即HQL。
pig和hive分别将脚本和HQL翻译成MapReduce程序，丢给计算引擎来计算，这使得开发人员从繁琐的MapReduce程序中解脱出来，降低了使用门槛。
而有了Hive之后，人们发现SQL是真的简单，于是Hive逐渐成长了大数据仓库的核心组件。

但是人们发现Hive在MapReduce上跑的太慢，于是诞生了Impala、Presto，Drill等交互SQL引擎，牺牲了通用性、稳定性来换取处理速度。（似乎，并没有完整替换MapReduce，只是做了一些优化）。
然后这些交互式引擎并没有完全符合人类的预期，于是大家决定用新一代通用的计算引擎Tez或者Spark（代替MapReduce）来跑SQL，于是诞生了Hive on Tez / Spark和SparkSQL。

上面的介绍，基本就是一个成型的数据仓库的框架了。
底层是HDFS，上面跑MapReduce/Tez/spark做计算，然后高级语言层跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。这解决了大部分中低速数据处理的需求。

参考文献

原稿遗失了。。所以参考文献这部分找不到了。。。