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

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

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

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

图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的数据被分散在多个数据块中，因此需要去遍历所有数据块的数据。此外由于同一个字段连续存储（同一列的内容有很多值是重复的，可以压缩），因此更加便于编码压缩。

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

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

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

图2-1. 列式存储基于字典表压缩数据

三、parquet文件结构

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

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

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

图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的关系：

图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占用的存储空间等元数据）。