ClickHouse-简谈OLAP与ClickHouse

ClickHouse-简谈OLAP与ClickHouse
ClickHouse简述
架构和选型分析
OLAP及场景特征比较
列式数据库特点及更适合OLAP系统的原因
ClickHouse简述
俄罗斯的Yandex公司（被誉为俄罗斯的google）在2016年开源了ClickHouse（C++）。
在第一届易观OLAP大赛中，在用户行为分析转化漏斗场景里，ClickHouse比Spark快了近10倍。在随后几年的大赛中，面对各类新的大数据引擎的挑战， ClickHouse一直稳稳地坐在冠军宝座上。同时在各种OLAP查询引擎评测中，ClickHouse单表查询的速度力压现在流行的各大数据库引擎，尤其是Ad-hoc查询速度一直遥遥领先，因此被国内大量用户和爱好者广泛用在即席查询场景当中。

我们可以在以下网址看到clickhouse与其他常用查询分析引擎的benchmark性能测试
ClickHouse的性能测试https://clickhouse.tech/benchmark/dbms/

clickhouse 是OLAP的列式数据库，vertica是商业的数据仓库，greenplum 是用来做MPP数据分析。

架构和选型分析
随着数据科技的进步，数据分析师早已不再满足于传统的T+1式报表或需要提前设置好维度与指标的 OLAP查询。数据分析师更希望使用可以支持任意指标、任意维度并秒级给出反馈的大数据Ad-hoc查询 系统。这对大数据技术来说是一项非常大的挑战，传统的大数据查询引擎根本无法做到这一点。

在使用hadoop生态构建海量数据下用户行为轨迹分析场景时，常用到以下架构：

架构目标:
1、海量数据
2、实时导入
3、实时查询
4、多维聚合分析

架构缺点：
1、数据的实效性:中间过程经过Kafka、ETL、调度处理，报表的实效性不理想
2、即席分析性能:Hive存储是hdfs文件系统，hdfs不支持随机读写，查询效率不高，不适合即席查询
3、涉及Hadoop组件多:涉及Flume、Kafka、HDFS等等，数据冗余过多，同时需要深厚的知识储备
4、数据链路长:数据链路处理流程长，繁琐容错也不好

针对不同数据量的选型建议：
少量数据:单机程序
中级数据:ES MySQL的分库分表
海量数据:druid, kylin, doris, clickhouse, kudu等

OLAP及场景特征比较
OLTP + OLAP:
T:transaction 事务处理 侧重于增删改
A : analysis 分析 Select大批量数据的聚合查询

目前常用的技术中OLAP和OLTP同时满足又能做到高效处理的很少很少，一般都是偏向于事务处理或者数据分析。

mysql和Hive、ClickHouse的设计目的是不同的
MySQL: insert update delete
Hive ClickHouse: Select 查询分析的高效

读模式和写模式 ：
OLAP一般都是读模式(例如hive，写数据不校验，读数据会校验报错)， OLTP是写模式 （写入时校验格式）。

海量数据做查询分析高效的特点:
1、列式数据库
2、写模式(保证同一列的数据类型是一样的: 方便压缩)
3、排序

OLAP场景特征：

1、读多于写
不同于事务处理(OLTP)的场景，比如电商场景中加购物车、下单、支付等需要在原地进行大量 insert、update、delete操作，数据分析(OLAP)场景通常是将数据批量导入后，进行任意维度的灵 活探索、BI工具洞察、报表制作等。
数据一次性写入后，分析师需要尝试从各个角度对数据做挖掘、分析，直到发现其中的商业价值、业务 变化趋势等信息。这是一个需要反复试错、不断调整、持续优化的过程，其中数据的读取次数远多于写 入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。

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

select department, count(id) as total from student group by department;

3、数据批量写入，且数据不更新或少更新
OLTP类业务对于延时(Latency)要求更高，要避免让客户等待造成业务损失;而OLAP类业务，由于 数据量非常大，通常更加关注写入吞吐(Throughput)，要求海量数据能够尽快导入完成。一旦导入 完成，历史数据往往作为存档，不会再做更新、删除操作。
更新:修改 和 删除
批量:导入 和 导出
mysql: insert update delete , source
clickouse: 单条记录的增删改 批量导入导出 多

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

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

大宽表:100个字段，用户使用其中的任意多个字段作为组合条件进行查询分析
kylin: 做预聚合! clichouse 也能实现这个功能:预聚合 (在数据聚合上的预)
hive: 离线分析:预聚合(在时间上的预)

在ClickHouse官网中给出的场景特征（https://clickhouse.tech/docs/zh/#olapchang-jing-de-guan-jian-te-zheng）：

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

很容易看出OLAP 场景与其他流行场景(例如OLTP或键值访问)非常不同。 因此，如果希望获得不错 的性能，尝试使用 OLTP 或 键值DB 来处理分析查询是没有意义的。 例如，如果尝试使用 MongoDB 或 Redis 进行分析，则与OLAP数据库相比，性能会非常差。

比较：
mysql:少量结构化数据的针对单条记录的增删改查
hbase:针对海量数据的key-value增删改查
redis:基于内存的针对key-value类型的增删改查，热数据的缓存
mongodb:文档数据库
elasticsearch: 针对文件做全文检索的(倒排索引)
clickhouse: 针对海量数据的大量行少量列的聚合查询分析的请求

列式数据库特点及更适合OLAP系统的原因
行式和列式数据库结构：
行式存储:一行数据接着一行数据做存储，一行数据中的多个字段的值都是物理相邻的。
列式存储:一列数据单独存储，多行数据的相同列的值，在物理存储上是相邻的

与行存将每一行的数据连续存储不同，列存将每一列的数据连续存储。示例图如下:

列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)：

行式：

列式：

输入/输出 ：ClickHouse官网阐述:https://clickhouse.tech/docs/zh/#inputoutput
针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
由于I/O的降低，这将帮助更多的数据被系统缓存。

例如，查询«统计每个广告平台的记录数量»需要读取«广告平台ID»这一列，它在未压缩的情况下需要1个字节进行存储。如果大部分流量不是来自广告平台，那么这一列至少可以以十倍的压缩率被压缩。当采用快速压缩算法，它的解压速度最少在十亿字节(未压缩数据)每秒。换句话说，这个查询可以在单个服务器上以每秒大约几十亿行的速度进行处理。这实际上是当前实现的速度。

相比于行式存储，列式存储在分析场景下有着许多优良的特性。

1、分析类场景：在行存模式下，数据按行连续存储，所有列的 数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取操作被严重放大。而列存模式下，只 需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。

2、同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的 存储空间，降低了存储成本。

3、更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。

4、自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同
列类型，选择最合适的压缩算法。

5、高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。

分析类查询，通常只需要读取表的一小部分列。在列式数据库中可以只读取需要的数据。数据总是打包 成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O 的体积。由于I/O的降低，这将帮助更多的数据被系统缓存。
————————————————