这是我参与【第四届青训营-大数据场】笔记创作活动的第13天
- 计算层:各种计算引擎
- 存储层:承载数据的持久化存储
- 数据格式层:定义了存储层文件内部的组织格式，
- 计算引擎通过格式层的支持来读写文件
- 存储层:File，Blocks
- 格式层:File 内部的数据布局(Layout + Schema)
- 计算引擎:Rows +Columns
OLTP与OLAP 对比
OLTp
-
在线业务系统，例如:订单、交易、社交、评论等
-
·事务·实时性·低延时·高并发·高可用
-
·Schema 相对简单·数据维度不多数据规模较小
OLAP
-
数据仓库或者大数据分析系统，例如:决策分析、 BI系统、推荐系统等
-
弱事务性
-
近实时、离线分析大吞吐
-
并发相对不高
-
可用性可以有一定的妥协
-
Schema 复杂
-
数据维度很多，几百个Column很常见数据规模巨大
-
每列的数据在文件上是连续存储的
读取整列的效率较高
同列的数据类型一致，压缩编码的效率更好
典型系统
大数据分析系统:SQL-on-Hadoop，数据湖分析
数据仓库:ClickHouse，Greenplum，阿里云 MaxCompute
-
格式层定义了数据的布局，连接计算引擎和存储服务
-
OLTP 和 OLAP 场景话差异明显
-
业务场景决定了技术实现，行存适用于 OLTP，列存适用于 OLAP
-
RowGroup: 每一个行组包含一定数量或者固定大小的行的集合
-
ColumnChunk: RowGroup 中按照列切分成多个 ColumnChunk
-
Page:ColumnChunk内部继续切分成 Page，一般建议 8KB 大小。压缩和编码的基本单元
-
根据保存的数据类型分为:Data Page， Dictionary Page , Index Page Footer 保存文件的元信息
-
Schema Config Metadata
-
RowGroup Meta
-
Column Meta
编码 Encoding
- Plain 直接存储原始数据
- Run Length Encoding (RLE):适用于列基数不大，重复值较多的场景，例如:Boolean、枚举、固定的选项等
- Bit-Pack Encoding: 配合 RLE 编码使用，让整形数字存储的更加紧凑
- 字典编码 Dictionary Encoding:适用于列基数不大的场景，构造字典表，写入到 Dictionary Page;把数据用字典 Index 替换，然后用 RLE 编码
压缩 Compression
- Page 完成 Encoding 以后，进行压缩支持多种压缩算法
- snappy: 压缩速度快，压缩比不高，适用于热数据
- gzip:压缩速度慢，压缩比高，适用于冷数据
- zstd:新引入的压缩算法，压缩比和 gzip 差不多，而且压缩速度比肩 Snappy
- 建议选择 snappy 或者 zstd，根据业务数据类型充分测试压缩效果，以及对查询性能的影响
