1. ClickHouse 介绍
ClickHouse是一个面向列的数据库管理系统（DBMS），用于在线分析处理查询（OLAP）。
ClickHouse官网：https://clickhouse.tech/
ClickHouse中文社区：http://www.clickhouse.com.cn
clickhouse 发展历程：
1.1. ClickHouse概述
ClickHouse 是俄罗斯搜索巨头 Yandex 公司早 2016年 开源的一个极具 “ 战斗力 “ 的实时数据分析数据库，是一个用于联机分析 (OLAP:Online Analytical Processing) 的列式数据库管理系统。
ClickHouse 简称 CK，工作速度比传统方法快100-1000倍，ClickHouse 的性能超过了目前市场上可比的面向列的DBMS。 每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。
ClickHouse 是一个完全的列式数据库管理系统，允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器，支持线性扩展，简单方便，高可靠性，高容错。
ClickHouse 从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。这些功能共同为ClickHouse极速的分析性能奠定了基础。
ClickHouse 不应该被用作通用数据库，而是作为超高性能的海量数据快速查询的分布式实时处理平台，在数据汇总查询方面(如GROUP BY)，ClickHouse的查询速度非常快。
ClickHouse 适合流式或批次入库的时序数据。
ClickHouse 在大数据领域没有走 Hadoop 生态，而是采用 Local attached storage 作为存储，这样整个 IO 可能就没有 Hadoop 那一套的局限。
ClickHouse 的系统在生产环境中可以应用到比较大的规模，因为它的线性扩展能力和可靠性保障能够原生支持 shard + replication 这种解决方案。它还提供了一些 SQL 直接接口，有比较丰富的原生 client。
1.2 ClickHouse使用场景
Clickhouse 适用于结构良好清晰且不可变的事件或日志流实时查询分析。 如物联网，在线游戏，电子商务，金融数据等场景。
1.3 ClickHouse 的不足
ClickHouse作为一款高性能OLAP数据库，虽然足够优秀，但也不是万能的。我们不应该把它用于任何OLTP事务性操作的场景，因为它有以下几点不足。
- 不支持事务。
- 不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作KeyValue数据库使用。
- 不擅长按行删除数据（虽然支持）。
这些弱点并不能视为ClickHouse的缺点，事实上其他同类高性能的OLAP数据库同样也不擅长上述的这些方面。因为对于一款OLAP数据库而言，上述这些能力并不是重点，只能说这是为了极致查询性能所做的权衡。
2. ClickHouse 核心特性
2.1 完备的DBMS功能
ClickHouse拥有完备的管理功能，所以它称得上是一个DBMS（DatabaseManagementSystem，数据库管理系统），而不仅是一个数据库。作为一个DBMS，它具备了如下功能：
- DDL（数据定义语言）：可以动态地创建、修改或删除数据库、表和视图而无须重启服务
- DML（数据操作语言）：可以动态查询、插入、修改或删除数据。
- 权限控制：可以按照用户设置的权限粒度, 对数据库或者表的操作设置权限，保障数据的安全性。
- 数据备份与恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
- 分布式管理：提供集群模式，能够自动管理多个数据库节点。
2.2 列式存储与数据压缩
ClickHouse 是使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会分别由不同的文件保存。
列式存储除了降低IO和存储的压力之外，还为向量化执行做好了铺垫。
默认使用LZ4算法压缩，在Yandex.Metrica的生产环境中，数据总体的压缩比可以达到8:1。
2.3 向量化执行引擎
- 向量化执行，可以简单地看作一项消除程序中循环的优化。
- 现代计算机系统概念中，向量化执行是通过数据并行以提高性能的一种实现方式（其他的还有指令级并行和线程级并行），它的原理是在CPU寄存器层面实现数据的并行操作。如下图所示存储媒介距离CPU越近，则访问数据的速度越快。
- 为了实现向量化执行，需要利用CPU的SIMD指令。
- SIMD的全称是Single Instruction Multiple Data，即用单条指令操作多条数据。
- ClickHouse目前利用SSE4.2指令集实现向量化执行。
2.4 关系模型与SQL查询
- SQL 查询
ClickHouse完全使用SQL作为查询语言（支持GROUPBY、ORDERBY、JOIN、IN等大部分标准SQL），使得现有的第三方分析可视化系统可以轻松与它集成对接。
在SQL解析方面，ClickHouse是大小写敏感的
- 关系模型
- ClickHouse使用关系模型描述数据并提供了传统数据库的概念（数据库、表、视图和函数等）。
- 关系模型相比文档和键值对等其他模型，拥有更好的描述能力，也能够更加清晰地表述实体间的关系。
- ClickHouse使用了关系模型，所以将构建在传统关系型数据库或数据仓库之上的系统迁移到ClickHouse的成本会变得更低。
2.5 多样化的表引擎
ClickHouse也将存储部分进行了抽象，把存储引擎作为一层独立的接口。
ClickHouse共拥有合并树、内存、文件、接口和其他6大类20多种表引擎。
每一种表引擎都有着各自的特点，用户可以根据实际业务场景的要求，选择合适的表引擎使用。
将表引擎独立设计的好处是显而易见的，通过特定的表引擎支撑特定的场景，十分灵活。
对于简单的场景，可直接使用简单的引擎降低成本，而复杂的场景也有合适的选择。
2.6 多线程与分布式
- 多线程
如果说向量化执行是通过数据级并行的方式提升了性能，那么多线程处理就是通过线程级并行的方式实现了性能的提升。
由于SIMD不适合用于带有较多分支判断的场景，ClickHouse也大量使用了多线程技术以实现提速，以此和向量化执行形成互补。
- 分布式
在分布式领域，计算移动比数据移动更加划算，已经成为基本共识。
在各服务器之间，通过网络传输数据的成本是高昂的，所以相比移动数据，更为聪明的做法是预先将数据分布到各台服务器，将数据的计算查询直接下推到数据所在的服务器。
ClickHouse在数据存取方面，既支持分区也支持分片，可以说是将多线程和分布式的技术应用到了极致。
2.7 多主架构
ClickHouse 采用了 Multi Master 多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。
多主架构中每个节点对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。
多主架构天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。
2.8 在线查询
只有Clickouse在成本与性能之间做到了良好平衡，即又快又开源。
ClickHouse在复杂查询的场景下，它也能够做到极快响应，且无须对数据进行任何预处理加工。
2.9 数据分片与分布式查询
数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。
ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点，分片的数量上限取决于节点数量 。
ClickHouse提供了本地表（LocalTable）与分布式表（DistributedTable）的概念。
- 本地表等同于一份数据的分片。
- 分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。
3. ClickHouse与其他 OLAP对比
| 组件 | 说明 |
|---|---|
| Druid | 分布式的、支持实时多维OLAP分析的数据处理系统。 |
| Kylin | 开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据。 |
| Presto | 分布式的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto擅长对海量数据进行复杂的分析。 |
| ClickHouse | 面向 OLAP 的分布式列式数据库，能够使用 SQL 查询生成实时数据报告。 |
| Doris | PB 级联机分析处理引擎，为客户提供稳定、高效、低成本的在线报表和多维分析服务。 |
具体对比：
| OLAP产品 | 数据摄入 | 存储方式 | 查询性能 | 用户友好程度 | 场景 |
|---|---|---|---|---|---|
| Druid | 支持离线 Hdfs 数据摄入和实时 Kafka 数据摄入 | LSM 变种，采用 一层全维度的 roll up 进行预计算，不存储明细 | 查询时在 broker 层面进行更加深层的 聚合计算，毫 秒级到秒级 | 组件繁多，有多种组件和进 程，依赖 ZK 和 MySQL， 运维相对复 杂，维度度量修改支持在线修改，对用户友好，需要时间字段 。 | iot、实时监控指 标产出、实时渠道聚合分析等 |
| Kylin | 支持 Hive 和 Kafka 摄入，由于使用基于 mr 和 spark的计 算引擎进行 cube构建，难以达到分钟级延迟，延迟至少在 十分钟至半小时级别 | 全维度预计算构建 cube，支持 一些策略的剪枝，减少无用计算量，开源版本依赖 HBase 作 为 Storage | 基于全量预计算产 出、亚 秒级 | 依赖 Hadoop 生态，适合维度、度量相对 稳定的 cube 分析，一旦需 要修改维度、 度量需要重新配置，重新构建，不一定需要时间字段 | 维度、度量明确的场景、分析聚合维度多样化，维度 尽量不要 超过 20 维，否则将产生维度爆炸 |
| ClickHouse | 支持离线在线数据录入，但是由于存储设计实时数据摄入千万不 能单条频繁摄入，一定要做 batch 汇总 | 与 kylin、druid 不同，不做预计算，完全是通过索引、列式存储、压缩、向量化、code gen 等充分压榨 cpu 等计算资源达到 快速计算的目的 | 毫秒级至秒级不等 | 单一组件、 sql 支持良 好、分析函数丰富，易上 手，需要时间短 | 渠道漏斗 分析、 app 点 击路径事 件分析 |
