如何选择aligned format和hbase format（浅谈Esgyndb中的行存与列存）

在逻辑概念上，数据库表是一种二维的数据结构，具有行和列。但在内存、磁盘等物理存储上，数据一般是需要线性顺序组织的。所以为了存储数据库表中的数据，有了两种常见的组织方式：基于行的存储和基于列的存储。

​ 基于行的存储，是将整行数据连续存在一起。在基于行存储的表中，即使只需要读取指定列时，也需要先将对应行的数据读取到内存，然后再过滤目标列，这样会导致过多的磁盘IO、内存和时间开销，所以行式存储比较适用于每次需要访问完整行的场景。

​ 基于列的存储，是将列数据连续存储在一起。因为是将相同类型的数据存储在了一起，往往压缩比比较高，从而也会降低磁盘IO、内存和时间开销，所以，列式存储适用于仅在单列或少数列上操作的场景。特别是在大数据时代，数据的列和行都比较多时候，列式存储优势会更加明显。但反过来，列式存储对于获取整行的请求效率就没那么高了，需要多次IO读取多个列的数据，然后再合并返回。

​ HBase表数据模型比较特别，也可以简单理解为有行和列的二维表，只是它的列称为“列族”，列族下面又可以在数据写入时指定很多的子列。另外，HBase物理存储上是将整个列族数据存储在一起的。所以，如果HBase中的一张表只有一个列族的话，等于是这个列族包含了这张表的所有列，也就是将表正行的数据连续存储在了一起，就等于是行式存储了。再比如，一张表有多个列族，并且每个列族下仅有一列（虽然HBase不建议这么做），也就是将表的列数据连续存储在了一起，就等于是列式存储了。

EsygnDB使用hbase作为存储引擎，支持aligned format和hbase format两种格式，默认为aligned format。与上面说的两种做法有些不同的是，Esgyndb会将表的所有列映射到hbase的同一个列族下。
Hbase format将表的每一列映射到hbase列族下的不同列，Aligned format则是将所有列的数据通过内部编码后合并成同一列再映射到hbase下。这种情况下hbase format可以视作列式存储（并非严格意义上的列存），而aligned format可以视作行式存储。

create table tt1(c1 int primary key, c2 int, c3 int, c4 int, c5 int)attribute hbase format;
--创建出hbase format的表
create table tt2(c1 int primary key, c2 int, c3 int, c4 int, c5 int); 
--不指定选项的情况下默认为aligned format

--sql语句查询c3,c4列，观察执行计划
explain select c3,c4 from tt1;    
……
  column_retrieved ....... #1:1,#1:3,#1:4
  key_columns ............ C1

explain select c3,c4 from tt2;    
……
  column_retrieved ....... #1:1
  key_columns ............ C1

可以看到，在hbase format表中查询c3,c4列时，下推到hbase上的查询，实际上是查询了#1:1,#1:3,#1:4这三列，其中#1是列族的名称，这个是固定的。1，3，4是实际的列名，按照顺序依次递增。主键C1对应#1:1，C3对应#1:3，C4对应#1:4。主键是用来标识一行的，必须要返回。所以一共返回的是#1:1,#1:3,#1:4这三列。而在aligned format的表中，只存在#1:1这一列。

Hbase format和aligned format对比分别有哪些优劣，下面一一进行对比。
首先是写性能。Aligned format的写入过程，需要先将数据进行编码，多列合并成一列。这一步是在本地内存中进行，因此耗时极短可以忽略不计。写入hbase时，aligned format只需要写入一列，而hbase format需要写入多列，所以aligned format的写入性能优于hbase format的写入性能。在实际测试中，根据列数的不同，大约在5%-50%之间。

其实是读性能。Aligned format的读取过程，需要将hbase中的数据读出后，在本地内存中进行解码还原成表上的多列数据。但是aligned format只需要读取一列，而hbase format则看情况需要读取多列，因此读取性能需要看具体场景来进行比较。如果表的列数比较多，查询语句又是需要读出大部分列，甚至全部列的，那么aligned format性能占优。如果表列数很多，而实际查询的列很少，那么hbase format需要读取的IO数据量大大减小，此时hbase format性能占优。如果列数很少，此时hbase format和aligned format差距不大。

此外还有个重要的功能：谓词下推。例如用户查询语句为select * from t1 where c5=2; 由于c5列既不是主键，也没有建立索引，因此只能走全表扫描的执行计划。对于aligned format来说，需要将全表所有数据拉回本地内存中，再解码得到c5列后判断谓词c5=2。对于hbase format来说，可以将c5=2这个谓词下推到hbase中，hbase判断谓词后，例如只有1行符合条件，此时hbase再将这一行读出并返回给sql引擎。这样就极大减少了IO数据量，提高了性能。
例如查看explain select c3,c4 from tt1 where c5=2;执行计划
（注意需要打开cqd HBASE_FILTER_PREDS ‘on', 这个cqd的默认值是off）
  
column_retrieved ....... #1:1,#1:3,#1:4,#1:5
  pushed_down_rpn ........ (#1:5=?)
  key_columns ............ C1
  executor_predicates .... (C5 = %(2))
pushed_down_rpn这一行代表产生了谓词下推，executor_predicates这一行表示需要sql引擎来判断的谓词。

目前aligned format不支持谓词下推，现在也有开发aligned format谓词下推的计划。由于aligned format是将多列编码后形成一列写入到hbase中，因此要下推的话，必须通过hbase 的coprocessor来处理数据，将一行数据解码成多列后，再来判断谓词。相当于将sql引擎需要做的任务这一段代码移植到hbase coprocessor中去。目前尚未开发完成，因此在这个场景下hbase format对aligned format具有相当大的优势。

在实际应用中，如何选择aligned format和hbase format，需要根据以上情况进行判断。默认是aligned format，但是某些场景下使用hbase format会更好。下面介绍一个丰县农商行使用中的场景。

客户场景中有这样一张表，表非常宽，有两百多列，数据量大约两百多万行。这是一张汇总表，每天通过存储过程计算汇总数据后写入这张表，之后会对这张表进行大量的人工查询操作。客户希望查询操作可以控制在秒级。

由于是每天定时批量写入，200万行数据是5分钟写完还是10分钟写完并没有什么区别。其他情况下没有写操作，因此写入性能不是很敏感，可以考虑使用hbase format。

两百多列的数据，每次查询并不会访问所有列，而是访问十到二十列左右的数据。这种情况下使用hbase format可以减少90%以上的网络IO，应该选择hbase format。

在查询时，这两百多列都有可能产生查询条件并组合成查询语句。对于aligned format，查询性能完全依靠索引，否则只能走全表扫描，会相当之慢。但是在这个场景下不可能给表建立上百个索引。对于hbase format，即使不建立索引，也可以通过谓词下推的优化来加速查询。这种情况下必须选择hbase format。

之前使用aligned format时，查询操作耗时超过1分钟。改成hbase format后，可以控制在3-4秒左右完成，符合客户需求。