实时数仓ClickHouse学习小指南
点击上方蓝色字体，选择“设为星标”
回复”资源“获取更多惊喜
ClickHouse介绍
什么是ClickHouse
ClickHouse 是Yandex开源的一个用于实时数据分析的基于列存储的数据库，其处理数据的速度比传统方法快100-1000 倍。
ClickHouse的性能超过了目前市场上可比的面向列的 DBMS，每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。
ClickHouse基本介绍
ClickHouse作为新兴事物，特点有很多，很多大厂也在使用；关于其特点也不多说了，确切的说是为OLAP量身打造的数据库
ClickHouse使用场景
CLAP的特点
读多于写：不同于事务处理（OLTP）的场景，数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。
大宽表：读大量行但是少量列，结果集较小，在OLAP场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列。而聚合计算的结果集相比于动辄数十亿的原始数据，也明显小得多。
数据批量写入：OLTP类业务数据不更新或少更新，对于延时要求更高，要避免让客户等待造成业务损失；而OLAP类业务，由于数据量非常大，通常更加关注写入吞吐量。
无需事务，数据一致性要求低：OLAP类业务对于事务需求较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。
灵活多变，不适合预先建模：分析场景下，随着业务变化要及时调整分析维度、挖掘方法，以尽快发现数据价值、更新业务指标。
ClickHouse使用场景压根就是针对OLAP设计的，并且根据相关的特性做了优化。
ClickHouse核心特征
完备的DBMS功能
ClickHouse拥有完备的管理功能，作为一个DBMS，它具备了一些基本功能，如下所示。
DDL：可以动态地创建、修改或删除数据库、表和视图，而无须重启服务。
DML ：可以动态查询、插入、修改或删除数据。
权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
分布式管理：提供集群模式，能够自动管理多个数据库节点。
列式存储与数据压缩
一个非常流行的观点认为，如果你想让查询变得更快，最简单且有效的方法是减少数据扫描范围和数据传输时的大小，而列式存储和数据压缩就可以帮助我们实现上述两点。
列式存储和数据压缩通常是伴生的，因为一般来说列式存储是数据压缩的前提。
按列存储相比按行存储的另一个优势是对数据压缩的友好性。
ClickHouse就是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存。
向量化执行引擎
向量化执行就是这种方式的典型代表，这项寄存器硬件层面的特性，为上层应用程序的性能带来了指数级的提升。
为了实现向量化执行，需要利用CPU的SIMD指令，即用单条指令操作多条数据。
ClickHouse目前利用SSE4.2指令集实现向量执行引擎，对内存中的列式数据，一个batch调用一次SIMD指令，不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。
关系模型与SQL查询
相比HBase和Redis这类NoSQL数据库，ClickHouse使用关系模型描述数据并提供了传统数据库的概念，这使得它平易近人，容易理解和学习。
ClickHouse使用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的系统迁移到ClickHouse的成本会变得更低，可以直接沿用之前的经验成果。
多样化的表引擎
在ClickHouse的设计中，能够察觉到一些MySQL的影子，表引擎的设计就是其中之一。
与MySQL类似，ClickHouse也将存储部分进行了抽象，把存储引擎作为一层独立的接口。
多线程与分布式
ClickHouse几乎具备现代化高性能数据库的所有典型特征，对于多线程和分布式这类被广泛使用的技术，自然更是不在话下。
如果说向量化执行是通过数据级并行的方式提升了性能，那么多线程处理就是通过线程级并行的方式实现了性能的提升。
ClickHouse还提供了可线性拓展的分布式计算能力。ClickHouse会自动将查询拆解为多个task下发到集群中，然后进行多机并行处理，最后把结果汇聚到一起。
相比基于底层硬件实现的向量化执行SIMD，线程级并行通常由更高层次的软件层面控制。ClickHouse在数据存取方面，既支持分区 ( 纵向扩展，利用多线程原理 )，也支持分片 ( 横向扩展，利用分布式原理 )，可以说是将多线程和分布式的技术应用到了极致。
多主架构
HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。
而ClickHouse则采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多优势，例如对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。所以它天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。
数据分片与分布式查询
数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。
ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限取决于节点数量 ( 1个分片只能对应1个服务节点 )。
ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse提供了本地表 与分布式表的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
ClickHouse的存储
列式存储
相比于行式存储，列式存储在分析场景下有着许多优良的特性。
分析场景中往往需要读大量行但是少数几个列。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。
同一列中的数据属于同一类型，压缩效果显著，更小的数据意味着读取也就更快,意味着同等大小的内存能够存放更多数据，系统cache效果更好。
自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。
数据有序存储
ClickHouse支持在建表时，指定将数据按照某些列进行sort by。排序后，保证了相同sort key的数据在磁盘上连续存储，且有序摆放。
在进行等值、范围查询时，where条件命中的数据都紧密存储在一个或若干个连续的Block中，而不是分散的存储在任意多个Block， 大幅减少需要IO的block数量。
数据分片
ClickHouse支持单机模式，也支持分布式集群模式。在分布式模式下，ClickHouse会将数据分为多个分片，并且分布到不同节点上。不同的分片策略在应对不同的SQL Pattern时，各有优势。ClickHouse提供了丰富的sharding策略，让业务可以根据实际需求选用。
random随机分片：写入数据会被随机分发到分布式集群中的某个节点上。
constant固定分片：写入数据会被分发到固定一个节点上。
hash分片：按照某一列的值进行hash分片。
自定义表达式分片：指定任意合法表达式，根据表达式被计算后的值进行hash分片。数据分片，让ClickHouse可以充分利用整个集群的大规模并行计算能力，快速返回查询结果。
分片多样化好处也多多。
数据Partitioning
ClickHouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作，比如通过toYYYYMM()将数据按月进行分区、toMonday()将数据按照周几进行分区、对Enum类型的列直接每种取值作为一个分区等。
数据TTL
ClickHouse通过TTL提供了数据生命周期管理的能力。目前支持几种不同粒度的TTL：
列级别TTL：当一列中的部分数据过期后，会被替换成默认值；当全列数据都过期后，会删除该列。
行级别TTL：当某一行过期后，会直接删除该行。
分区级别TTL：当分区过期后，会直接删除该分区。
ClickHouse的计算
ClickHouse的架构设计
Column与Field
作为一款百分之百的列式存储数据库，ClickHouse按列存储数据，内存中的一列数据由一个Column对象表示。
Column和Field是ClickHouse数据最基础的映射单元。本质上Column和Field就是一个个的接口。IColumn是一个抽象接口，insertRangeFrom和insertFrom方法、用于分页的cut，以及用于过滤的filter方法等等都是接口里面的方法。
这些方法的具体实现对象则根据数据类型的不同，由相应的对象实现，例如ColumnString、ColumnArray和ColumnTuple等。
在大多数场合，ClickHouse都会以整列的方式操作数据。如果需要操作单个具体的数值，则需要使用Field对象，Field对象代表一个单值。
与Column对象的泛化设计思路不同，Field对象使用了聚合的设计模式。在Field对象内部聚合了Null、UInt64、String和Array等13种数据类型及相应的处理逻辑。
DataType
数据的序列化和反序列化工作由DataType负责。IDataType接口定义了许多正反序列化的方法涵盖了常用的二进制、文本、JSON、XML、CSV和Protobuf等多种格式类型。
IDataType也使用了泛化的设计模式，具体方法的实现逻辑由对应数据类型的实例承载。比如DataTypeString、DataTypeArray等等。
DataType虽然负责序列化相关工作，但它并不直接负责数据的读取，而是转由从Column或Field对象获取。在DataType的实现类中，聚合了相应数据类型的Column对象和Field对象。
例如DataTypeString会引用字符串类型的ColumnString，而DataTypeArray则会引用数组类型的ColumnArray，以此类推。
Block与Block流
ClickHouse内部的数据操作是面向Block对象进行的，并且采用了流的形式。虽然Column和Filed组成了数据的基本映射单元，但对应到实际操作，它们还缺少了一些必要的信息，比如数据的类型及列的名称。
于是ClickHouse设计了Block对象，Block对象可以看作数据表的子集。Block对象的本质是由数据对象、数据类型和列名称组成的三元组，即Column、DataType及列名称字符串。
Column提供了数据的读取能力，而DataType知道如何正反序列化，所以Block在这些对象的基础之上实现了进一步的抽象和封装，从而简化了整个使用的过程，仅通过Block对象就能完成一系列的数据操作。
有了Block对象这一层封装之后，对Block流的设计就是水到渠成的事情了。流操作有两组顶层接口：IBlockInputStream负责数据的读取和关系运算，IBlockOutputStream负责将数据输出到下一环节。Block流也使用了泛化的设计模式，对数据的各种操作最终都会转换成其中一种流的实现。IBlockInputStream接口定义了读取数据的若干个read虚方法，而具体的实现逻辑则交由它的实现类来填充。
Table
在数据表的底层设计中并没有所谓的Table对象，它直接使用IStorage接口指代数据表。表引擎是ClickHouse的一个显著特性，不同的表引擎由不同的子类实现，例如 系统表、合并树表引擎、日志表引擎 。
IStorage接口定义了DDL 、read和write方法，它们分别负责数据的定义、查询与写入。在数据查询时，IStorage负责根据AST查询语句的指示要求，返回指定列的原始数据。
对Table发起的一次操作通常都会经历这样的过程，接收AST查询语句，根据AST返回指定列的数据，之后再将数据交由Interpreter做进一步处理。
Parser与Interpreter
Parser和Interpreter是非常重要的两组接口：Parser分析器负责创建AST对象；而Interpreter解释器则负责解释AST，并进一步创建查询的执行管道。它们与IStorage一起，串联起了整个数据查询的过程。
Cluster与Replication
ClickHouse的集群由分片 ( Shard ) 组成，而每个分片又通过副本 (Replica ) 组成。
ClickHouse的某些设计总是显得独树一帜，而集群与分片就是其中之一。这里有几个与众不同的特性。
1.ClickHouse的1个节点只能拥有1个分片，也就是说如果要实现1分片、1副本，则至少需要部署2个服务节点。
2.分片只是一个逻辑概念，其物理承载还是由副本承担的。