ClickHouse学习：基础结构+储存结构_clickhouse存储结构

1. 使用场景

ClickHouse被广泛应用于OLAP领域，其使用场景通常具有以下特点：

1. 读多于写

ClickHouse应用的场景多发生在数据已经批量导入之后， 对数据进行多维度分析，挖掘等操作。对其中数据进行的读取操作远大于写入操作，且通常要求实时返回结果。

1. 宽表

ClickHouse中的表通常是大宽表，包含大量了columns。通常会对colunm进行大量读取，对row进行的操作极少，并且column的数据通常为短字符，并不会占用过多储存空间。另外，通常操作之后的结果集会限制小于原数据。

1. 数据稳定

一般不进行数据更新，如果需要更新，通常是大批量的数据导入，少有删除操作。

1. 少Transcation

基本上无transaction，通常会搭配一个OLTP数据库，两者相互链接来满足transaction需求。 数据一致性要求较低。

1. 不适合预先建模

由于OLAP的场景限制，数据的维度可能会被多次改变，所用方法难以固定，所以不合适进行预先建模。

2. 工作架构

根据ClickHouse的数据流流向将其工作架构分为四个层级

2.1数据接入层

这一层主要的工作是把外部数据输入到ClickHouse中， 在这一步中可以根据数据量和数据特性进行分类，采用不同的输入方法。

1. 应用层小表数据，通常有着数据量小，数据源较多等特点。适合用TaskPlus来进行数据导入；
2. 多维明细宽表，这类数据一般数据量庞大，一般通过spark进行高并发的写入。
3. 实时明细宽表，ClickHouse封装了相应的方法，可以通过flink接入，支持app,pc.m三端百亿级数据写入。

2.2 数据储存层

对于数据储存可以采用单机模式或分布式模式。 如果选择了分布式模式，则会采用双副本机制，同时用nginx代理clickhouse集群，通过域名的方式进行读写操作，实现了数据均衡及高可靠写入，且对于域名的响应时间及流量有对应的实时监控，一旦响应速度出现波动或异常会在第一时间发出告警。

nginx_one_replication：代理集群一半节点即一个完整副本，常用于写操作，在每次提交数据时由nginx均衡路由到对应的shard表，当某一个节点出现异常导致写入失败时，nginx会暂时剔除异常节点并报警，然后另选一台节点重新写入。

nginx_two_replication：代理集群所有节点，一般用作查询和无副本表数据写入，同时也会有对于异常节点的剔除和报警机制。

2.3 数据服务层

把集群封装为SCF服务（RPC），供外部调用；为内部数据分析师，开发人员提供了封装好的client工具。

2.4 数据应用层

埋点系统：对接实时clickhouse集群，提供秒级别的OLAP查询功能。

用户分析平台：通过标签筛选的方式，从用户访问总集合中根据特定的用户行为捕获所需用户集。

BI：提供数据应用层的可视化展示，对接单分片多副本Clickhouse集群，可横向扩展。

4. 特性分析

4.1 数据分片

ClickHouse的数据分片是将数据横向切分，如表所示