行式存储和列式存储优缺点和paruqet文件结构

﹏ヽ暗。殇╰゛Y 2023-02-17 03:15 0阅读 0赞

参考文章：[行式存储和列式存储优缺点和paruqet文件结构][paruqet]

# 优缺点分析 #

**列存储优点：**

>  *  单列数据保存在一起，不同列分开存储，导致存下同样一个表需要更多的Block文件，看起来是更复杂了，但是基于列和列分开存储，这种形式天生就适合分布式的存储，并能完全利用并发写入和并发读取的能力
>  *  同一列存放在一起，数据类型相同，则更好的进行压缩
>  *  同一列存放在一起，则排序更加方便，基于排序方便，where某一列会更加快

**行存储优点：**

>  *  更容易实现事务性、一致性控制。

**应用场景：**

>  *  关系型数据库基本都是行存储，Mysql、Oracle等，因其更强调一致性和事务性
>  *  NoSQL多数为列存储，因为高效、吞吐量高，但事务、一致性较弱（也有做到事务性比较强的，但实现更加复杂，需要更多东西来配合）

**总结：**

>  *  行： 一致性、事务更加容易实现
>  *  列：吞吐量高、性能强，一致性、事务性较弱

# 一、列式存储和行式存储的比较 #

列式存储和行式存储是针对数据在存储介质中的排序形式而言的，假设存在一张table，那么：

>  *  行式存储：依次连续存储第**1、2、3...行**的数据到存储介质中；
>  *  列式存储：依次连续存储第**1、2、3...列**的数据到存储介质中。

图1-1所示为行式存储和列式存储的示意图，一张table包含5个字段（列）即rowid、date/time、customer name以及quantity，共7行，图中的红色箭头表示存储顺序。

![format_png][] 标图1-1. 行式存储和列式存储区别题

# 二、行式存储和列式存储的优缺点和适用场景 #

存储形式的差异决定了适用场景的不同：

>  *  行式存储适合**”针对行”的查询**：  
>     比如（mysql）select \* from table\_name limit 1，因为只会读取图1-1中的“row-based store 第1个绿色部分的数据”（只有指定的行“1 845 2 3 1”才会被读取），而select rowid from table\_name则需要读取row-based store**所有**绿色部分的数据（虽然目的仅是要查询1个字段）；此外还适用于insert/update操作比较多的场景，因为只需要更改部分数据块即可。
>  *  列式存储适合**“针对列”的查询**：  
>     比如select rowid from table\_name，因为只会读取图1-1中的“column-based store 第1个绿色部分的数据”（查询时只有涉及到的字段会被读取），而select \* from table\_name limit 1则需要读取column-based stores**所有**绿色部分的数据（虽然目的就是要查询第1行的数据）；但是不适用于insert/update操作比较多的场景，比如当插入1个row时，由于列式存储导致同一个row的数据被分散在多个数据块中，因此需要去遍历所有数据块的数据。此外由于同一个字段连续存储（同一列的内容有很多值是重复的，可以压缩），因此更加便于编码压缩。

<table> 
 <thead> 
  <tr> 
   <th>存储类别</th> 
   <th>适用于</th> 
   <th>不适用于</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>row-based</strong></td> 
   <td>针对行的查询，<br> insert/update操作</td> 
   <td>针对列的查询</td> 
  </tr> 
  <tr> 
   <td><strong>column-based</strong></td> 
   <td>针对列的查询，<br> 编码压缩减小存储空间占用</td> 
   <td>针对行的查询，<br> insert/update操作</td> 
  </tr> 
 </tbody> 
</table>

综合来看，列式存储比较适合大数据量（压缩比高）、分析型操作（针对少数几列）；不适合频率较高的删除（全列检索）、更新（重新压缩）操作。

**列式存储基于字典表的编码压缩**

图2-1所示为列式存储中将某张table基于字典表进行编码压缩的示例，图中左边为源表，假设该table中的customers和material字段的取值均只有右上表所示的5种，那么当源表的行数很大时，customers和material字段就会存在大量重复的取值，为了节省存储空间对这两个字段进行编码，即使用一个字典表（右上图）记录该两个字段的distinct取值，又下表则用右上表字段取值对应的index（整数1、2、3、4、5）来代替原来的string，由于string占用的存储空间比这几个index占用的存储空间大多了，因此可以较大程度上压缩占用的存储空间。

![format_png 1][] 图2-1. 列式存储基于字典表压缩数据标题

# 三、parquet文件结构 #

基于列式存储的两个典型实现是：hbase和parquet，其中：

>  *  hbase可以看成是一个基于列式存储的非关系型数据库NoSQL；
>  *  parquet是基于列式存储定义的一种文件格式。

parquet的文件结构如图3-1所示：

![format_png 2][] 图3-1. parquet文件结构一览图标题

从图中可以看出，1个parquet文件由header（1个）、block（可以多个）、footer（1个）组成，分别负责：

>  *  header：只包含一个4个byte的数字PAR1，用来识别整个Parquet文件格式。文件中所有的metadata都存在于footer中；
>  *  block：存储数据；
>  *  footer：包含block中的metadata比如版本信息、schema信息等，footer中最后2个字段分别是1个4个byte长度的footer的metadata、同header中一样的PAR1。

图3-2所示为parquet文件中，block、rowgroup、columnchunk以及page的关系：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RscGY_size_16_color_FFFFFF_t_70][] 标图3-2. parquet中rowgroup、block、columnchunk以及page的关系题

**简而言之：**

>  *  1个block就是指1个rowgroup；
>  *  1个columnchunk对应1个字段；  
>     1个columnchunk中可能存在多个page（page默认大小为1M）。

因此如果将一个parquet文件类比成一张大excel 表，那么：

>  *  header就相当于excel表的后缀名；
>  *  block就相当于excel表中的某些数据行（如果行数太多导致需要的byte数超过了block size那就需要多个block）；
>  *  footer就相当于excel表的页脚记录了字段数、行数、各block占用的存储空间等元数据）。

[paruqet]: https://www.jianshu.com/p/2e4848f1569c
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU3ODkxMS04NDAzZDE2OTU2ZmY5YTZkLnBuZw?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU3ODkxMS0xYTIzYzYyYmRiMmI1ZGQ0LnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwfGltYWdlVmlldzIvMi93LzExNTgvZm9ybWF0L3dlYnA?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xMzU3ODkxMS1iNDI2NzQ5MWZiMTc4Nzc0LnBuZz9pbWFnZU1vZ3IyL2F1dG8tb3JpZW50L3N0cmlwfGltYWdlVmlldzIvMi93LzIzNS9mb3JtYXQvd2VicA?x-oss-process=image/format,png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RscGY_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200611175815234.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RscGY=,size_16,color_FFFFFF,t_70