ClickHouse深⼊浅出之（⼀）基础篇
1. 需求背景
1.1. 概述
随着数据科技的进步，数据分析师早已不再满⾜于传统的T+1式报表或需要提前设置好维度与指标的OLAP查询。数据分析师更希望使⽤可以⽀持任意指标、任意维度并秒级给出反馈的⼤数据Ad-hoc查询系统。这对⼤数据技术来说是⼀项⾮常⼤的挑战，传统的⼤数据查询引擎根本⽆法做到这⼀点。由俄罗斯的Yandex公司开源的ClickHouse脱颖⽽出。在第⼀届易观OLAP⼤赛中，在⽤户⾏为分析转化漏⽃场景⾥，ClickHouse⽐Spark快了近10倍。在随后⼏年的⼤赛中，⾯对各类新的⼤数据引擎的挑战，ClickHouse⼀直稳稳地坐在冠军宝座上。同时在各种OLAP查询引擎评测中，ClickHouse单表查询的速度⼒压现在流⾏的各⼤数据库引擎，尤其是Ad-hoc查询速度⼀直遥遥领先，因此被国内⼤量⽤户和爱好者⼴泛⽤在即席查询场景当中。 1.2. ⽤户轨迹⾏为分析
架构⽬标:
1. 海量数据
2. 实时导⼊
3. 实时查询
4. 多维聚合分析
1.3. 架构分析
1. 数据的实效性：中间过程经过Kafka、ETL、调度处理，报表的实效性不理想
2. 即席分析性能：Hive存储是hdfs⽂件系统，查询效率不⾼，不适合即席查询
3. 涉及Hadoop组件多：涉及Flume、Kafka、HDFS等等，数据冗余过多，同时需要深厚的知识储备
备长炭粉
4. 数据链路长：数据链路处理流程长，繁琐容错也不好
1.4. 美好愿望
2. OLAP详解
OLTP + OLAP： T：transaction 事务处理侧重于增删改 A ： analysis 分析 Select⼤批量数据的聚合查询事务处理作⽤：保证数据的⼀致性，如果涉及到事务操作，这个操作的执⾏效率必然不⾼
OLAP + OLTP =====> 同时满⾜，很难涉及
MySQL： insert update delete Hive ClickHouse: Select 查询分析的⾼效
读模式 + 写模式 OLAP⼀般都是读模式， OLTP 写模式 ClickHouse⼀出来，界限模糊了。 ClickHouse 写模式+ OLAP
海量数据做查询分析⾼效: 列式数据库, 写模式（保证同⼀列的数据类型是⼀样的: ⽅便压缩），排序
OLAP体系的重要三个特点：排序 + 写模式 + 列式数据库
ClickHouse 全部都具备！
2.1. OLAP的场景特征
1. 读多于写
不同于事务处理（OLTP）的场景，⽐如电商场景中加购物车、下单、⽀付等需要在原地进⾏⼤量insert、update、delete操作，数据分析（OLAP）场景通常是将数据批量导⼊后，进⾏任意维度的灵活探索、BI⼯具洞察、报表制作等。
数据⼀次性写⼊后，分析师需要尝试从各个⾓度对数据做挖掘、分析，直到发现其中的商业价值、业务变化趋势等信息。这是⼀个需要反复试错、不断调整、持续优化的过程，其中数据的读取次数远多于写⼊次数。这就要求底层数据库为这个 特点做专门设计，⽽不是盲⽬采⽤传统数据库的技术架构。
2.⼤宽表，读⼤量⾏但是少量列，结果集较⼩
在OLAP场景中，通常存在⼀张或是⼏张多列的⼤宽表，列数⾼达数百甚⾄数千列。对数据分析处理时，选择其中的少数⼏列作为维度列、其他少数⼏列作为指标列，然后对全表或某⼀个较⼤范围内的数据做聚合计算。这个过程会扫描⼤量的⾏数据，但是只⽤到了其中的少数列。⽽聚合计算的结果集相⽐于动辄数⼗亿的原始数据，也明显⼩得多。
例如：查询公司每个部门⼈有多少。
select department, count(id) as total from compant group by department;
3.数据批量写⼊，且数据不更新或少更新
OLTP类业务对于延时（Latency）要求更⾼，要避免让客户等待造成业务损失；⽽OLAP类业务，由于数据量⾮常⼤，通常更加关注写⼊吞吐（Throughput），要求海量数据能够尽快导⼊完成。⼀旦导⼊完成，历史数据往往作为存档，不会再做更新、删除操作
4.⽆需事务，数据⼀致性要求低
OLAP类业务对于事务需求较少，通常是导⼊历史⽇志数据，或搭配⼀款事务型数据库并实时从事务型数据库中进⾏数据同步。多
数OLAP系统都⽀持最终⼀致性。
5.灵活多变，不适合预先建模
分析场景下，随着业务变化要及时调整分析维度、挖掘⽅法，以尽快发现数据价值、更新业务指标。⽽数据仓库中通常存储着海量的历史数据，调整代价⼗分⾼昂。预先建模技术虽然可以在特定场景中加速计算，但是⽆法满⾜业务灵活多变的发展需求，维护成本过⾼。
2.2. 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数据库相⽐，性能会⾮常差。
1.列式数据库
1.2列式存储的特点
⾏式：
列式：
看到差别了么？下⾯将详细介绍为什么会发⽣这种情况。
输⼊/输出
1. 针对分析类查询，通常只需要读取表的⼀⼩部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5
列，这将帮助你最少减少20倍的I/O消耗。
2. 由于数据总是打包成批量读取的，所以压缩是⾮常容易的。同时数据按列分别存储这也更容易压缩。这进⼀步降低了I/O的体积。
3. 由于I/O的降低，这将帮助更多的数据被系统缓存。
例如，查询«统计每个⼴告平台的记录数量»需要读取«⼴告平台ID»这⼀列，它在未压缩的情况下需要1个字节进⾏存储。如果⼤部分流量不是来⾃⼴告平台，那么这⼀列⾄少可以以⼗倍的压缩率被压缩。当采⽤快速压缩算法，它的解压速度最少在⼗亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒⼤约⼏⼗亿⾏的速度进⾏处理。这实际上是当前实现的速度。
CPU
由于执⾏⼀个查询需要处理⼤量的⾏，因此在整个向量上执⾏所有操作将⽐在每⼀⾏上执⾏所有操作更加⾼效。同时这将有助于实现⼀个⼏乎没有调⽤成本的查询引擎。如果你不这样做，使⽤任何⼀个机械硬盘，查询引擎都不可避免的停⽌CPU进⾏等待。所以，在数据按列存储并且按列执⾏是很有意义的。
有两种⽅法可以做到这⼀点：
1. 向量引擎：所有的操作都是为向量⽽不是为单个值编写的。这意味着多个操作之间的不再需要频繁的调⽤，并且调⽤的成本基本可以
ilvs忽略不计。操作代码包含⼀个优化的内部循环。
2. 代码⽣成：⽣成⼀段代码，包含查询中的所有操作。
这是不应该在⼀个通⽤数据库中实现的，因为这在运⾏简单查询时是没有意义的。但是也有例外，例如，MemSQL使⽤代码⽣成来减少处理SQL查询的延迟(只是为了⽐较，分析型数据库通常需要优化的是吞吐⽽不是延迟)。
1.3ClickHouse概述
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.4ClickHouse使⽤场景
适⽤场景
1. web和app数据分析
2. ⼴告⽹络和RTB
3. 电信
4. 电⼦商务和⾦融碗公
5. 信息安全
6. 监测
7. 时序数据
8. 商业智能
9. 在线游戏
10. 物联⽹
不适⽤场景
1. 事务性⼯作(OLTP)
2. ⾼并发的键值访问
3. ⽂档存储
4. 超标准化的数据
1.5ClickHouse的优点
1. 真正的⾯向列的DBMS（ClickHouse是⼀个DBMS,⽽不是⼀个单⼀的数据库。它允许在运⾏时创建表和数据库、加载数据和运⾏查
询，⽽⽆需重新配置和重新启动服务器）
2. 数据压缩（⼀些⾯向列的DBMS（INFINIDB CE 和 MonetDB）不使⽤数据压缩。但是，数据压缩确实是提⾼了性能）
3. 磁盘存储的数据（许多⾯向列的DBMS(SPA HANA和GooglePowerDrill)）只能在内存中⼯作。但即使在数千台服务器上，内存也太
⼩了。）
4. 多核并⾏处理(多核多节点并⾏化⼤型查询)
5. 在多个服务器上分布式处理(在clickhouse中，数据可以驻留在不同的分⽚上。每个分⽚都可以⽤于容错的⼀组副本，查询会在所有分
⽚上并⾏处理)
6. SQL⽀持(ClickHouse sql 跟真正的sql有不⼀样的函数名称。不过语法基本跟SQL语法兼容，⽀持JOIN/FROM/IN 和JOIN⼦句及标
量⼦查询⽀持⼦查询)
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议