ClickHouse（一）简介与架构

1.OLAP详解

1.1.OLAP的场景特征

1、读多于写

不同于事务处理（OLTP）的场景，比如电商场景中加购物车、下单、支付等需要在原地进行大量insert、update、delete操作，数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。

数据一次性写入后，分析师需要尝试从各个角度对数据做挖掘、分析，直到发现其中的商业价值、业务变化趋势等信息。这是一个需要反复试错、不断调整、持续优化的过程，其中数据的读取次数远多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。

2、大宽表，读大量行但是少量列，结果集较小

在OLAP场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列。而聚合计算的结果集相比于动辄数十亿的原始数据，也明显小得多。

3、数据批量写入，且数据不更新或少更新

OLTP类业务对于延时（Latency）要求更高，要避免让客户等待造成业务损失；而OLAP类业务，由于数据量非常大，通常更加关注写入吞吐（Throughput），要求海量数据能够尽快导入完成。一旦导入完成，历史数据往往作为存档，不会再做更新、删除操

4、无需事务，数据一致性要求低

OLAP类业务对于事务需求较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。多数OLAP系统都支持最终一致性。

5、灵活多变，不适合预先建模

分析场景下，随着业务变化要及时调整分析维度、挖掘方法，以尽快发现数据价值、更新业务指标。而数据仓库中通常存储着海量的历史数据，调整代价十分高昂。预先建模技术虽然可以在特定场景中加速计算，但是无法满足业务灵活多变的发展需求，维护成本过高。

1.1.1.技术选型

• 少量数据：单机程序
• 中级数据：ES、MySQL的分库分表
• 海量数据：druid，kylin，doris，clickhouse
• 海量数据做查询分析高效：列式数据库，写模式（保证同一列的数据类型是一样的：方便压缩）

1.2.ClickHouse官网解释

URL地址：https://clickhouse.tech/docs/zh/

1、绝大多数请求都是读请求
2、数据以相当大的批次（> 1000行）更新，而不是单行更新;或者它根本没有更新。
3、数据已添加到数据库，但不会进行修改。
4、对于读取，每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
5、表格“宽”，意味着它们包含大量列。
6、查询相对较少（通常每台服务器数百个查询或每秒更少）。
7、对于简单查询，允许延迟大约50毫秒。
8、列中的数据相对较小：一般来说，都是数字和短字符串(例如，每个URL 60个字节)
9、处理单个查询时需要高吞吐量（每个服务器每秒最多数十亿行）。
10、Transactions不是必需的。
11、对数据一致性要求低。
12、每个查询有一个大表。所有其他表都很小，除了这个大表。
13、查询结果明显小于源数据。换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中

2.ClickHouse

2.1.概述

源代码：C++

典型特点总结：ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、具有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用

简单的说，ClickHouse作为分析型数据库，有三大特点：一是跑分快， 二是功能多 ，三是文艺范

1.跑分快： ClickHouse跑分是Vertica的5倍快：

clickHouse性能超过了市面上大部分的列式存储数据库，相比传统的数据ClickHouse要快100-1000X，ClickHouse还是有非常大的优势：
100Million 数据集:ClickHouse比Vertica约快5倍，比Hive快279倍，比MySQL快801倍
1Billion 数据集:ClickHouse比Vertica约快5倍，MySQL和Hive已经无法完成任务了

2.功能多：ClickHouse支持数据统计分析各种场景

支持类SQL查询，
支持繁多库函数（例如IP转化，