什么是 ClickHouse？
ClickHouse 是近年来备受关注的开源列式数据库管理系统，主要⽤于数据分析 （OLAP）领域。通过向量化执⾏以
及对 cpu 底层指令集（SIMD）的使⽤，它 可以对海量数据进⾏并⾏处理，从⽽加快数据的处理速度。 ClickHouse
从 OLAP 场景需求出发，定制开发了⼀套全新的⾼效列式存储引擎，并且实现了数据有序 存储、主键索引、稀疏
索引、数据 Sharding、数据 Partitioning、 TTL、主备复 制等丰富功能。
ClickHouse 有哪些应⽤场景？

1. 绝⼤多数请求都是⽤于读访问的；
2. 数据需要以⼤批次（⼤于 1000 ⾏）进⾏更新，⽽不是单⾏更新；
3. 数据只是添加到数据库，没有必要修改；
4. 读取数据时，会从数据库中提取出⼤量的⾏，但只⽤到⼀⼩部分列；
5. 表很“宽”，即表中包含⼤量的列；
6. 查询频率相对较低（通常每台服务器每秒查询数百次或更少）；
7. 对于简单查询，允许⼤约 50 毫秒的延迟；
8. 列的值是⽐较⼩的数值和短字符串（例如，每个 URL只有 60 个字节）；
9. 在处理单个查询时需要⾼吞吐量（每台服务器每秒⾼达数⼗亿⾏）；
10. 不需要事务；
11. 数据⼀致性要求较低；
12. 每次查询中只会查询⼀个⼤表。除了⼀个⼤表，其余都是⼩表；
13. 查询结果显著⼩于数据源。即数据有过滤或聚合。返回结果不超过单个服务 器内存。ClickHouse 列式存储的优点有哪些？
    当分析场景中往往需要读⼤量⾏但是少数⼏个列时，在⾏存模式下，数据按
    ⾏连续存储，所有列的数据都存储在⼀个 block 中，不参与计算的列在 IO 时也要全部读出，读取操作被严重放
    ⼤。⽽列存模式下，只需要读取参与计 算的列即可，极⼤的减低了 IO cost，加速了查询。
    同⼀列中的数据属于同⼀类型，压缩效果显著。列存往往有着⾼达⼗倍甚⾄
    更⾼的压缩⽐，节省了⼤量的存储空间，降低了存储成本。
    更⾼的压缩⽐意味着更⼩的 data size，从磁盘中读取相应数据耗时更短。 - ⾃由的压缩算法选择。不同列的
    数据具有不同的数据类型，适⽤的压缩算法
    也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。
    ⾼压缩⽐，意味着同等⼤⼩的内存能够存放更多数据，系统 cache 效果更好。
    ClickHouse 的缺点是是什么？
    不⽀持事务，不⽀持真正的删除/更新； - 不⽀持⼆级索引；
    join 实现与众不同；
    不⽀持窗⼝功能；
    元数据管理需要⼈为⼲预。
    ClickHouse 的架构是怎样的？
    ClickHouse 采⽤典型的分组式的分布式架构，其中：
    Shard。集群内划分为多个分⽚或分组（Shard 0 … Shard N），通过 Shard
    的线性扩展能⼒，⽀持海量数据的分布式存储计算。
    Node。每个 Shard 内包含⼀定数量的节点（Node，即进程），同⼀ Shard 内的节点互为副本，保障数据可
    靠。 ClickHouse 中副本数可按需建设，且逻
    辑上不同 Shard 内的副本数可不同。
    ZooKeeper Service。集群所有节点对等，节点间通过 ZooKeeper 服务进
    ⾏分布式协调。
    ClickHouse 的逻辑数据模型？
    从⽤户使⽤⻆度看， ClickHouse 的逻辑数据模型与关系型数据库有⼀定的相似： ⼀个集群包含多个数据库，⼀个
    数据库包含多张表，表⽤于实际存储数据。ClickHouse 的核⼼特性？
    列存储：列存储是指仅从存储系统中读取必要的列数据，⽆⽤列不读取，速
    度⾮常快。 ClickHouse 采⽤列存储，这对于分析型请求⾮常⾼效。⼀个典型 且真实的情况是，如果我们需要分析
    的数据有 50 列，⽽每次分析仅读取其 中的 5 列，那么通过列存储，我们仅需读取必要的列数据，相⽐于普通⾏
    存，可减少 10 倍左右的读取、解压、处理等开销，对性能会有质的影响。
    向量化执⾏：在⽀持列存的基础上， ClickHouse 实现了⼀套⾯向 向量化处
    理 的计算引擎，⼤量的处理操作都是向量化执⾏的。相⽐于传统⽕⼭模型中 的逐⾏处理模式，向量化执⾏引擎采
    ⽤批量处理模式，可以⼤幅减少函数调 ⽤开销，降低指令、数据的 Cache Miss，提升 CPU 利⽤效率。并且
    ClickHouse 可 利 ⽤ SIMD 指 令 进 ⼀ 步 加 速 执 ⾏ 效 率 。 这 部 分 是 ClickHouse 优于⼤量同类 OLAP 产品
    的重要因素。
    编码压缩：由于 ClickHouse 采⽤列存储，相同列的数据连续存储，且底层
    数据在存储时是经过排序的，这样数据的局部规律性⾮常强，有利于获得更 ⾼的数据压缩⽐。此外， ClickHouse
    除了⽀持 LZ### ZSTD 等通⽤压缩算 法外，还⽀持 Delta、 DoubleDelta、 Gorilla 等专⽤编码算法，⽤于进⼀
    步 提⾼数据压缩⽐。
    多索引：列存⽤于裁剪不必要的字段读取，⽽索引则⽤于裁剪不必要的记录
    读取。 ClickHouse ⽀持丰富的索引，从⽽在查询时尽可能的裁剪不必要的 记录读取，提⾼查询性能。
    使⽤ ClickHouse 时有哪些注意点？
    分区和索引 分区粒度根据业务特点决定，不宜过粗或过细。⼀般选择按天分区，也可指定为
    tuple()；以单表 1 亿数据为例，分区⼤⼩控制在 10-30 个为最佳。
    必须指定索引列， clickhouse 中的索引列即排序列，通过 order by 指定，⼀般 在查询条件中经常被⽤来充当筛选
    条件的属性被纳⼊进来；可以是单⼀维度，也 可以是组合维度的索引；通常需要满⾜⾼级列在前、查询频率⼤的在
    前原则；还 有基数特别⼤的不适合做索引列，如⽤户表的 userid 字段；通常筛选后的数据 满⾜在百万以内为最
    佳。
    数据采样策略 通过采⽤运算可极⼤提升数据分析的性能。
    数据量太⼤时应避免使⽤ select * 操作，查询的性能会与查询的字段⼤⼩和数 量成线性变换；字段越少，消耗的
    IO 资源就越少，性能就会越⾼。 千万以上数据集⽤ order by 查询时需要搭配 where 条件和 limit 语句⼀起使⽤。
    如⾮必须不要在结果集上构建虚拟列，虚拟列⾮常消耗资源浪费性能，可以考虑 在前端进⾏处理，或者在表中构造
    实际字段进⾏额外存储。 不建议在⾼基列上执⾏ distinct 去重查询，改为近似去重 uniqCombined。 多表 Join 时
    要满⾜⼩表在右的原则，右表关联时被加载到内存中与左表进⾏⽐ 较。
    存储
    ClickHouse 不⽀持设置多数据⽬录，为了提升数据 ⼀个券组绑定多块物理磁盘提升读写性能；多数查询场景 硬盘
    快 2-3 倍。
    io 性能，可以挂载虚拟券组，
    SSD 盘会⽐普通机械ClickHouse 的引擎有哪些？
    ClickHouse 提供了⼤量的数据引擎，分为数据库引擎、表引擎，根据数据特点 及使⽤场景选择合适的引擎⾄关重
    要。
    ClickHouse 引擎分类
    在以下⼏种情况下， ClickHouse 使⽤⾃⼰的数据库引擎：
    决定表存储在哪⾥以及以何种⽅式存储； - ⽀持哪些查询以及如何⽀持；
    并发数据访问；
    索引的使⽤；
    是否可以执⾏多线程请求；
    数据复制参数。
    在所有的表引擎中，最为核⼼的当属 MergeTree 系列表引擎，这些表引擎拥有 最为强⼤的性能和最⼴泛的使⽤场
    合。对于⾮ MergeTree 系列的其他引擎⽽⾔， 主要⽤于特殊⽤途，场景相对有限。⽽ MergeTree 系列表引擎是
    官⽅主推的存 储引擎，⽀持⼏乎所有 ClickHouse 核⼼功能。
    MergeTree 作为家族系列最基础的表引擎，主要有以下特点：
    存储的数据按照主键排序：允许创建稀疏索引，从⽽加快数据查询速度； - ⽀持分区，可以通过 PRIMARY
    KEY语句指定分区字段；
    ⽀持数据副本；
    ⽀持数据采样。