Hbase的核心思想设计
1、内存 + 磁盘：保证处理效率，也保证数据安全
2、内存：必须经过设计，内存具备优秀的数据结构，保证基本的读写高效，甚至为了不同的需求，可以让读写效率倾斜。
3、磁盘：数据必须存放在磁盘，保证数据安全。磁盘数据文件必须经过精心设计，保证扫描磁盘数据文件的高效率
4、数据排序：在海量数据中要想保证低延时的随机读写操作，数据最好是排序的
5、范围分区：当数据排序之后，可以进行范围分区，来平摊负载，让多台服务器联合起来对外提供服务
6、跳表：基于数据排序+范围分区构建索引表，形成跳表的拓扑结构，方便用户操作时快速定位数据分区的位置
7、LSM-Tree存储引擎：把随机写变成顺序追加，在通过定期合并的方式来合并数据，去除无效数据，从而实现数据的删除和修改。
海量数据中，如果进行高效率的查询的核心思想：设计一种架构，能够快速把待搜寻的数据范围降低到原来的 1/n，然后再结合索引或者热点数据放在内
存等思路，就能实现高效率的查询了。
OLAP 分析的存储引擎设计方案
1、列式存储 + 字段类型统一
2、列裁剪
3、数据排序
4、数据分区分片 + 分布式查询
5、预聚合
6、利用CPU特性：向量化引擎，操作系统必须支持
7、主键索引+二级索引+位图索引+布隆索引等
8、支持近似计算 pv
9、定制引擎：多样化的存储引擎满足不同场景的特定需要
10、多样化算法选择：Volnitsky高效字符串搜索算法 和 HyperLogLog基于概率高效去重算法
对于单条记录的增删改等操作，通过数据的横向划分，做到数据操作的快速定位，在海量数据查询分析中，一般就是针对某些列做分析，既然并不
是全部列，那么把数据做纵向切分把表中的数据按照列来单独存储，那么在做分析的时候，同样可以快速把待查询分析的数据总量降低到原来表的1/n，
同样提高效率。
提到预聚合，大家会想到 Kylin，但是 Kylin 也有它的缺点：
1、预聚合只支持固定的分析场景，无法满足自定义分析场景，所以预聚合只能作为一种可选方案
2、维度组合爆炸会导致数据膨胀，这样会造成不必要的计算和存储开销。无必要的维度组合的计算就属于浪费资源
3、大概率数据都是增量生成，预聚合不能进行数据更新。所以会产生大量的重算。
ClickHouse 表引擎介绍
表引擎在 ClickHouse 中的作用十分关键，直接决定了数据如何存储和读取、并发读写、 索引、支持的查询种类、主备复制等。
关于库引擎，简单总结一下：ClickHouse 也支持在创建库的时候，指定库引擎，目前支持5种
1、Ordinary引擎：默认引擎，如果不指定数据库引擎创建的就是 Ordinary 数据库
2、Dictionary引擎：此数据库会自动为所有数据字典创建表
3、Memory引擎：所有数据只会保存在内存中，服务重启数据消失，该数据库引擎只能够创建 Memory 引擎表
4、MySQL引擎：改引擎会自动拉取远端 MySQL 中的数据，并在该库下创建 MySQL 表引擎的数据表
5、Lazy延时引擎：在距最近一次访问间隔 expiration_time_in_seconds 时间段内，将表保存在内存中，仅适用于 Log 引擎表
ClickHouse 的表引擎提供了四个系列（Log、MergeTree、Integration、Special）大约 28 种表引擎，各有各的用途。比如 Log 系列用来做小表数据分
析，MergeTree 系列用来做大数据量分析，而 Integration 系列则多用于外表数据集成。Log、Special、Integration 系列的表引擎相对来说，应用场景
有限，功能简单，应用特殊用途，MergeTree 系列表引擎又和两种特殊表引擎（Replicated，Distributed）正交形成多种具备不同功能的 MergeTree 表
引擎。
MergeTree 作为家族中最基础的表引擎，提供了主键索引、数据分区、数据副本和数据采样等基本能力，而家族中其他的表引擎则在 MergeTree 的基础
之上各有所长
关于MergeTree表引擎类型：
第一：MergeTree 表引擎主要用于海量数据分析，支持数据分区、存储有序、主键索引、稀疏索引、数据 TTL 等。MergeTree 支持所有 ClickHouse
SQL 语法，但是有些功能与 MySQL 并不一致，比如在 MergeTree 中主键并不用于去重。
第二：为了解决 MergeTree 相同主键无法去重的问题，ClickHouse 提供了 ReplacingMergeTree 引擎，用来做去重。ReplacingMergeTree 确保数据
最终被去重，但是无法保证查询过程中主键不重复。因为相同主键的数据可能被 shard 到不同的节点，但是 compaction 只能在一个节点中进行，而且
optimize 的时机也不确定。
第三：CollapsingMergeTree 引擎要求在建表语句中指定一个标记列 Sign（插入的时候指定为 1，删除的时候指定为 -1），后台 Compaction 时会将主
键相同、Sign 相反的行进行折叠，也即删除。来消除 ReplacingMergeTree 的限制。
第四：为了解决 CollapsingMergeTree 乱序写入情况下无法正常折叠问题，VersionedCollapsingMergeTree 表引擎在建表语句中新增了一列
Version，用于在乱序情况下记录状态行与取消行的对应关系。主键相同，且 Version 相同、Sign 相反的行，在 Compaction 时会被删除。
第五：ClickHouse 通过 SummingMergeTree 来支持对主键列进行预先聚合。在后台 Compaction 时，会将主键相同的多行进行 sum 求和，然后使用
一行数据取而代之，从而大幅度降低存储空间占用，提升聚合计算性能。
第六：AggregatingMergeTree 也是预先聚合引擎的一种，用于提升聚合计算的性能。与 SummingMergeTree 的区别在于：SummingMergeTree 对
非主键列进行 sum 聚合，而 AggregatingMergeTree 则可以指定各种聚合函数。
建表关键选择项：
1、PARTITION BY：分区键。指定表数据以何种标准进行分区。分区键既可以是单个列字段，也可以通过元组的形式使用多个列字段，同时它也支持使用列表达 式。
2、ORDER BY：排序键，用于指定在一个数据片段内，数据以何种标准排序。默认情况下主键(PRIMARY KEY)与排序键相同。
3、PRIMARY KEY：主键。声明后会依照主键字段生成一级索引。默认情况下，主键与排序键(ORDER BY)相同，所以通常直接使用 ORDER BY 代为指定主键。
4、SETTINGS：index_granularity 选项表示索引的粒度，默认值为 8192。MergeTree 索引在默认情况下，每间隔 8192 行数据才生成一条索引。
5、SAMPLE BY：抽样表达式，用于声明数据以何种标准进行采样。
ClickHouse 从 OLAP 场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据
Partitioning、TTL、主备复制等丰富功能。
存储信息：
1、分区目录：一个分区可能会有多个不同的目录，该目录下存储该分区的数据及其他各种形式的数据。后台会执行合并，把相同分 区的多个目录合并到一个分区。
2、checksums.txt：校验文件。使用二进制格式存储。它保存了余下各类文件(primary.id
x、count.txt等)的 size 大小及 size 的哈希值，用于快速校 验文件的完整性和正确性。
3、columns.txt：列信息文件，使用明文格式存储。用于保存此数据分区下的列字段信息
4、count.txt：计数文件，使用明文格式存储。用于记录当前数据分区目录下数据的总行数
5、primary.idx：一级索引文件，主键索引文件
6、xxx.bin：数据文件，使用压缩格式存储，默认为 LZ4 压缩格式，用于存储某一列的数据，每一列都对应一个该文件，如列 date 为 date.bin
7、xxx.mrk2：列字段标记文件，如果使用了自适应大小的索引间隔，则标记文件以 .mrk2 命名，否则以 .mrk 命名。它建立 primary.idx 稀疏索引与 xxx.bin 数据文件之间的映射关系，先通过主键索引找到数据的偏移量，然后去 xxx.bin 数据文件中找到真实数据
8、… 还有二级索引 和 分区键相关信息文件等等
列式存储
相比于行式存储，列式存储在分析场景下有着许多优良的特性。
分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个block中，不参与计算的列在IO时也
要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。
同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。
更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。
自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。
高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。
一级索引
关于一级索引：MergeTree 的主键使用 PRIMARY KEY 定义，待主键定义之后，MergeTree 会依据 index_granularity 间隔（默认 8192 行），为数据表
生成一级索引并保存至 primary.idx 文件内。一级索引是稀疏索引，意思就是说：每一段数据生成一条索引记录，而不是每一条数据都生成索引，如果是
每一条数据都生成索引，则是稠密索引。稀疏索引的好处，就是少量的索引标记，就能记录大量的数据区间位置信息，比如不到 24414 条标记信息，就
能为 2E 条数据提供索引。在 ClickHouse 中，一级索引常驻内存。总的来说：一级索引和标记文件一一对齐，两个索引标
记之间的数据，就是一个数据区间，在数据文件中，这个数据区间的所有数据，生成一个压缩数据块。
需要注意的是：ClickHouse 的主键索引与 MySQL 等数据库不同，它并不用于去重，即便 primary key 相同的行，也可以同时存在于数据库中。要想实
现去重效果，需要结合具体的表引擎 ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree 实现。这个在之前的表引擎介绍
中讲过。
二级索引
关于二级索引
又称之为跳数索引。目的和一级索引一样，是为了减少待搜寻的数据的范围。跳数索引的默认是关闭的
索引生成粒度由 granularity 控制，如果生成了二级索引，则会在分区目录下生成额外idx和mrk文件，
跳数索引的生成规则：按照特定规则每隔 granularity 个 index_granularity 条数据，就会
生成一条跳数索引。比如 minmax 跳数索引，生成的是：granularity 个 index_granularity 条数据内的最大值最小值生成一条索引，如果将来需要针对
构建二级索引的这个字段求最大值最小值，则可以帮助提高效率。跳数索引一共支持四种类型：minmax（最大最小）、set（去重集合）、
ngrambf_v1（ngram分词布隆索引） 和 tokenbf_v1（标点符号分词布隆索引），一张数据表支持同时声明多个跳数索引。
关于跳数索引支持的多种类型的区别：
1、minmax：以 index_granularity 为单位，存储指定表达式计算后的 min、max 值；在等值和范围查询中能够帮助快速跳过不满足要求的块，减少IO
2、set(max_rows)：以index granularity为单位，存储指定表达式的 distinct value 集合，用于快速判断等值查询是否命中该块，减少IO
3、ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)：将 string 进行 ngram 分词后，构建 bloom filter，能够优化 等值、like、in 等查询条件
4、tokenbf_v1(size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)：与 ngrambf_v1 类似，区别是不使用 ngram 进行分词，而是通过标点符号进行词语分割
5、bloom_filter([false_positive])：对指定列构建 bloom filter，用于加速 等值、like、in 等查询条件的执行。
关于数据压缩：ClickHouse 的数据存储文件 column.bin 中存储是一列的数据，由于一列是相同类型的数据，所以方便高效压缩。在进行压缩的时候，请
注意：一个压缩数据块由头信息和压缩数据两部分组成，头信息固定使用 9 位字节表示，具体由 1 个 UInt8（1字节）整型和 2 个 UInt32（4字节）整型
组成，分别代表使用的压缩算法类型、压缩后的数据大小和压缩前的数据大小。每个压缩数据块的体积，按照其压缩前的数据字节大小，都被严格控制在
64KB～1MB，其上下限分别由 min_compress_block_size（默认65536=64KB）与 max_compress_block_size（默认1048576=1M）参数指定。具体压
缩规则：
原理的说法：每 8192 条记录，其实就是一条一级索引 一个索引区间 压缩成一个数据块。自适应压缩
关于数据标记：数据标记文件也与 .bin 文件一一对应。即每一个列字段 [Column].bin 文件都有一个与之对应的 [Column].mrk2 数据标记文件，用于记
录数据在 .bin 文件中的偏移量信息。一行标记数据使用一个元组表示，元组内包含两个整型数值的偏移量信息。它们分别表示在此段数据区间内，在对
应的 .bin 压缩文件中，压缩数据块的起始偏移量；以及将该数据压缩块解压后，其未压缩数据的起始偏移量。每一行标记数据都表示了一个片段的数据
（默认8192行）在 .bin 压缩文件中的读取位置信息。标记数据与一级索引数据不同，它并不能常驻内存，而是使用 LRU（最近最少使用）缓存策略加快
其取用速度。
如果： a = 10kb b = 你的一个8192条数据的大小 c = 1M 1、单个批次数据 size < 64KB：如果单个批次数据小于 64KB，则继续获取下一批数据，直至累积到size >= 64KB时，生成下一个压缩数据块。如果平均每条 记录小于8byte，多个数据批次压缩成一个数据块 2、单个批次数据 64KB<= size <=1MB：如果单个批次数据大小恰好在 64KB 与 1MB 之间，则直接生成下一个压缩数据块。 3、单个批次数据 size > 1MB：如果单个批次数据直接超过 1MB，则首先按照 1MB大小截断并生成下一个压缩数据块。剩余数据继续依照上述规则执行。此时， 会出现一个批次数据生成多个压缩数据块的情况。如果平均每条记录的大小超过 128byte,则会把当前这一个批次的数据压缩成多个数据块
总结数据读取流程：先根据一级索引，找到标记文件中的对应数据压缩块信息（压缩块在 .bin 文件中的起始偏移量和未压缩之前该条数据的是偏移量）
然后从 .bin 文件中，把压缩块加载到内存，解压缩之后，执行读取。
建立了 主键索引 到 数据文件的 映射！
在一个 xxx.bin 字段存储文件中，并不是一个压缩块对应到一条一级索引！
一个 [Column].bin 其实是由一个个的压缩数据块组成的。每个压缩块的大小在：64kb - 1M 之间。
查询过程：
指定分区 > 指定字段（xxx.bin ）> 根据一级索引(primary.idx)定位到 标记文件(name.mrk2)中的那一条记录 ==> 扫描对应字段的 mark 标记文件
获取两个偏移量信息（当前要查找的数据，处于这个 .bin 数据文件中的那个 压缩数据块，这个压缩数据块在 .bin 文件的偏移量， 这个压缩数据块解压缩
出来之后，要找的数据在当前这个压缩数据快的偏移量） ==> 根据第一个偏移量去 .bin 文件中定位到一个 压缩数据快 ==> 读取数据到内存执行解压缩
==> 根据第二个偏移量去内存解压缩数据中找到对应的数据
关于分区 关于一级索引 关于二级索引 关于数据压缩 关于数据标记
提高数据查询效率的核心原则只有一个：谁做的辅助动作能快速的帮助我们去快速降低待搜寻的数据范围
分布式系统的核心思想：分而治之，必须提供一套架构方便用户的请求被快速的定位到某个单台服务器去处理。一般来说，这个服务器处理这个请求，都
是很快的！
ClickHouse 的适用场景：
1、绝大多数请求都是用于读访问，而且不是单点访问
2、数据需要以大批次（大于1000行）进行更新，而不是单行更新；或者根本没有更新操作
3、数据只是添加到数据库，没有必要修改
4、读取数据时，会从数据库中提取出大量的行，但只用到一小部分列
5、表很“宽”，即表中包含大量的列
6、查询频率相对较低（通常每台服务器每秒查询数百次或更少）
7、对于简单查询，允许大约50毫秒的延迟
8、列的值是比较小的数值和短字符串（例如，每个URL只有60个字节）
9、在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）
10、不需要事务
11、数据一致性要求较低
12、每次查询中只会查询一个大表。除了一个大表，其余都是小表
13、查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存大小
ClickHouse的缺点
1、没有完整的事务支持
2、稀疏索引导致 ClickHouse 不擅长细粒度或者 key-value 类型数据的查询需求
3、缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据
4、不擅长 join 操作
