大数据学习之——OLAP 核心知识

学习原文：每个大数据工程师都应该知道的OLAP 核心知识点_Storage

谈存储

行存

传统ods中的B+树聚簇索引，page中包含排序好的行，因此一次查询多个以及更新

列存

读取需要的列、跳过无用数据、避免IO放大、存储紧凑、压缩友好

简单类型：使用bitmap编码、字典编码等，付出一些cpu节省很多IO

复杂类型：parquet算法(定义级别DL+重复级别RL)

数值类型：bitshuffle转换

现代OLAP

多采用行列混存方案，采用DataBlock+Header/Footer结构

DataBlock使用RowGroup->Column Chunk->Page 三层级，每层都有metadata,对一些聚合值进行统计，如count,max,avg,sum，以及字典编码。

有的存储格式，还额外有index block索引块，将index常驻内存提速

分布式存储

以某个列做轮询roundrobin、常量constant、随机random、范围range、哈希hash等处理，将文件分片shading.

存储计算一体：greenpulm、clickhouse、doris ，扩容需要reshard比较耗时。可以更专心在文件设计和分片管理。

存储计算分离：hdfs等，扩展性可用性高。网络延迟大，用于批量写、追加写场景。

分片的基础上，还可以继续分区，分桶。

lambda架构链路长数据冗余一致性不好保证，借鉴lsm树思想，流式数据随机写，最终聚合分组提交group commit顺序写，通过wal日志保证持久性，

形成base+delta的结构，读数据时基于base再merge delta的数据，从而支持tp事务。mvcc机制保证查询、写入的一致性。

谈计算

sql是olap的标配

完整的sql查询步骤：

1、词法分析、语法分析

2、形成抽象语法数ast

3、校验检查

4、ast树转换成关系代数表达式

5、根据表达式生成执行计划之逻辑计划

6、使用优化器将逻辑计划优化

7、优化后的执行逻辑计划生成物理执行计划

8、执行器执行得到结果

olap数据建模：

rolap：偏关系型的olap，对sql支持友好，使用雪花、星型模型组织多张表。数据规模比离线hive/spark的小

代表产品greenpulm,presto,impala, spark sql,clickhouse

molap：多维度的olap，对数据进行多维度预计算，不需要详细粒度的数据，使用上卷roll-up做立方体cube，对高并发查询性能好，但不够灵活，数据有冗余。

代表产品kylin,druid、doris

计算引擎分类：

离线：hive on mr，spark sql，使用resource manager和调度、队列，作业持续长时间，占用大量资源，并发低

MPP：不需要resource manager，轻量级调度，不容错，算子并行执行，短任务，耗时较短。如impala，presto，greenpulm

MPP架构:

有coordinator协调器、worker工作节点、metastore元数据、scheduler调度器组成。通过metastore获取元数据，协助coordinator做校验，由coordinator生成物理计划和执行，计划被切分未多个plan fragment【stage】片段，片段之间通过exchangeOperator传递数据【shuffer】，scheduler管理多个worker，coordinator调用schduler把不同的stage分发到不同的worker上，对应多个task，每个task对应1个或多个算子。算子包括Project\Filter\TableScan\HashJoin\Aggregation等。Mpp架构充分利用分布式并行计算，task内部的并行处理，加速查询。

计算执行

数据流：

dag执行时，采用pipeline方式，上游stage不用等下游stage全部执行结束就可以拉取数据并执行，数据不落盘，通过内存。需要内存够大否则oom

火山模型：

一种基于行的流式迭代模型算子的实现。只需要open，next，close 3个函数，就实现了数据的从底向上的拉取，驱动计算执行

每个算子执行完1行数据传递给傻姑娘有蒜子继续执行，函数调用过多，大量虚函数调用，cpu利用率低。

向量化执行：

火山模型的改进。现带cpu有多级流水线指令并行，超标量（super scalar）乱序，cache，编译器优化等，可以加速计算过程。

向量化就是将数据的输入输出从单条变成一批，让计算停留在函数内，省去频繁的交互切换，以及利用cpu用的simd指令并行。

向量化的不足是会加大物化开销

动态代码生成codegen：

各个算子，都是解释执行的，是通用的，一年次效率不高。使用codegen动态生成算子逻辑，减少了冗余和虚函数调用，甚至多个算子柔和成1个函数，一些指令可以优化成汇编指令，从而进一步加速。

资源管理调度：

mpp架构下coordinator需要scheduler调度task到worker，针对长计算任务或者etl任务，会占用很多资源，导致olap并发度受限。因此，要进行任务的fine grained schedule，避免空闲，请求间对资源你的使用尽量隔离，避免1个bad query吃满资源。可以通过label、hint来优化集群和任务长短。

谈优化器

sql优化阶段的ast树转换成关系代数表达式时，根据等价交换原则进行表达式转换，来优化表达式。

其基本运算包括投影project、选择select、并union、差、连接join等。优化器分为RBO,CBO两种。

RBO基于规则的优化

会将原有表达式裁剪掉，遍历一系列规则，满足等价条件时就进行替换。

常见规则有：分区裁剪、列裁剪、谓词下推、投影下推、聚合下推、limit下推、sort下推、常量折叠、子查询关联转join

CBO基于成本的优化

保留表达式，基于统计信息+代价模型，生成等价的关系表达式，得到代价最小的执行计划。

两种模型：火山模型、级联模型(calcite,flink,hive)。

优化器原则：高效，生成搜索空间、动态规划遍历、剪枝策略

统计信息：表数据大小、记录量、列的元数据(最小、最大、基数、排序、索引、分布)

join：最耗性能，搜索树+索引的搭配。

小表+小表：in-memory hash join 、 simple nested loop join

大表+小表：广播小表，大表有索引做index lookup join，否则小表build table 大表probe table，实现hash join

大表+大表：根据joinkey对应分区是否对齐？能则大表shard做local join，否则按照join key shuffle到期待你节点重分布后再join。如果joinkey有序，则sort-merge join。

谈趋势

实时分析

传统olap中，数据经过的环节过多，造成冗余和不一致，也会引入过多的技术栈和复杂度。趋势是富裕olap高吞吐实时写实时查的能力。

HSAP(Hybrid serving/analytical process)就是这种理念。

HTAP

Hybrid transaction/analytical process 事务处理和事务分析在1个数据库中提供。挑战很大，思路是先支持oltp，然后支持olap。多副本存储，有的支持olap，使用olap专用引擎提供查询。富裕acid和事务能力到olap系统中，使olap支持insert，delete，update操作。

云原生

传统olap，依赖于高端硬件，面临扩展性和成本问题。云原生架构通过虚拟化计数，实现弹性计算。如果存储计算分离，还可以实现弹性存储。

多模数据结构分析

非结构化的数据也逐渐在olap中应用，包括向量检索、json、array检索

软硬一体化

多核并行，FPGA、GPU硬件加速，向量计算和集合。考虑针对高吞吐量的存储和网络设备做更深度的定制。

学习收获：

1、没想到sohu上发表的文章也这么有技术含量，这篇文章我收益匪浅

2、重温了mpp和olap的区别和联系

3、molap,rolap进行了重温

4、join的优化

5、htap的趋势