ClickHouse 基础介绍
一、ClickHouse 是什么？
ClickHouse 是 Yandex（俄罗斯最大的搜索引擎）开源的一个用于实时数据分析的基于列存储的数据库，其处理数据的速度比传统方法快 100-1000 倍。ClickHouse 的性能超过了目前市场上可比的面向列的 DBMS，每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。
ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用：
- 今日头条 内部用ClickHouse来做用户行为分析，内部一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。
- 腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。
- 携程内部从18年7月份开始接入试用，目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询请求。
- 快手内部也在使用ClickHouse，存储总量大约10PB， 每天新增200TB， 90%查询小于3S。
在国外，Yandex内部有数百节点用于做用户点击行为分析，CloudFlare、Spotify等头部公司也在使用。
特别值得一提的是：国内云计算的领导厂商 阿里云 率先推出了自己的ClickHouse托管产品，产品首页地址为 云数据库ClickHouse，可以点击链接申请参加免费公测，一睹为快！
二、ClickHouse 特性
- 快速：ClickHouse 会充分利用所有可用的硬件，以尽可能快地处理每个查询。单个查询的峰值处理性能超过每秒 2 TB（解压缩后，仅使用的列）。在分布式设置中，读取是在健康副本之间自动平衡的，以避免增加延迟。
- 容错：ClickHouse 支持多主机异步复制，并且可以跨多个数据中心进行部署。所有节点都相等，这可以避免出现单点故障。单个节点或整个数据中心的停机时间不会影响系统的读写可用性。
- 可伸缩：ClickHouse 可以在垂直和水平方向上很好地缩放。ClickHouse 易于调整以在具有数百或数千个节点的群集上或在单个服务器上，甚至在小型虚拟机上执行。当前，每个单节点安装的数据量超过数万亿行或数百兆兆字节。
- 易用：ClickHouse 简单易用，开箱即用。它简化了所有数据处理：将所有结构化数据吸收到系统中，并且立即可用于构建报告。SQL 允许表达期望的结果，而无需涉及某些 DBMS 中可以找到的任何自定义非标准 API。
- 充分利用硬件：ClickHouse 与具有相同的可用 I/O 吞吐量和 CPU 容量的传统的面向行的系统相比，其处理典型的分析查询要快两到三个数量级。列式存储格式允许在 RAM 中容纳更多热数据，从而缩短了响应时间。
- 提高 CPU 效率：向量化查询执行涉及相关的 SIMD 处理器指令和运行时代码生成。处理列中的数据会提高 CPU 行缓存的命中率。
- 优化磁盘访问：ClickHouse 可以最大程度地减少范围查询的次数，从而提高了使用旋转磁盘驱动器的效率，因为它可以保持连续存储数据。
- 最小化数据传输：ClickHouse 使公司无需使用专门针对高性能计算的专用网络即可管理其数据。
三、为什么 ClickHouse 速度这么快？
ClickHouse 是一个用于联机分析（OLAP）的列式数据库管理系统（DBMS）。
我们首先理清一些基础概念：
-
OLTP：是传统的关系型数据库，主要操作增删改查，强调事务一致性，比如银行系统、电商系统。
-
OLAP：是仓库型数据库，主要是读取数据，做复杂数据分析，侧重技术决策支持，提供直观简单的结果。
ClickHouse OLAP场景的特点
读多于写
不同于事务处理（OLTP）的场景，比如电商场景中加购物车、下单、支付等需要在原地进行大量insert、update、delete操作，数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。数据一次性写入后，分析师需要尝试从各个角度对数据做挖掘、分析，直到发现其中的商业价值、业务变化趋势等信息。这是一个需要反复试错、不断调整、持续优化的过程，其中数据的读取次数远多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。
大宽表，读大量行但是少量列，结果集较小
在OLAP场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列。而聚合计算的结果集相比于动辄数十亿的原始数据，也明显小得多。
数据批量写入，且数据不更新或少更新
OLTP类业务对于延时（Latency）要求更高，要避免让客户等待造成业务损失；而OLAP类业务，由于数据量非常大，通常更加关注写入吞吐（Throughput），要求海量数据能够尽快导入完成。一旦导入完成，历史数据往往作为存档，不会再做更新、删除操作。
无需事务，数据一致性要求低
OLAP类业务对于事务需求较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。多数OLAP系统都支持最终一致性。
灵活多变，不适合预先建模
分析场景下，随着业务变化要及时调整分析维度、挖掘方法，以尽快发现数据价值、更新业务指标。而数据仓库中通常存储着海量的历史数据，调整代价十分高昂。预先建模技术虽然可以在特定场景中加速计算，但是无法满足业务灵活多变的发展需求，维护成本过高。
ClickHouse 从 OLAP 场景需求出发，定制开发了一套全新的高效列式存储引擎
column-oriented 图片来源见水印
- 如前所述，分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个 block 中，不参与计算的列在 IO 时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了 IO cost，加速了查询。
- 同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。
- 更高的压缩比意味着更小的 data size，从磁盘中读取相应数据耗时更短。
- 自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。
- 高压缩比，意味着同等大小的内存能够存放更多数据，系统 cache 效果更好。
四、和其他列式存储的对比
没有银弹，各种数据存储类型还是要结合具体的场景使用。
