1. 概述
AnalyticDB for PostgreSQL （原HybridDB for PostgreSQL，以下简称 ADB PG）是阿里云上的MPP数据仓库服务，其内核采用PostgreSQL引擎，基于开源数据库 Greenplum 改造，并在此基础上优化分析性能，其中列存储 metascan 就是提升数据库查询性能的一个关键特性。
ADB PG支持列存储格式，具有较高的数据压缩能力，以及查询性能，但是当针对有较高过滤率的查询条件时，依然要做整列数据读取，或者建 B-Tree 索引，但是索引也有其应用的约束：一是索引无压缩，数据膨胀较严重；二是结果集大的时候，索引代价比 tablescan 高，索引失效等问题。为此 ADB PG 开发了meta scan 功能，具有很好的过滤性能，并且占用的存储空间也基本可以忽略不计。
ADB PG 的meta scan是对列存表的一种加强，通过收集列存表列的max/min，并配合 block offset机制，可以实现类似于索引的过滤功能。meta信息里保存列的每个block的max、min，offset，max/min用于条件过滤，block offset用于跳过不满足过滤条件的block，以达到最大程度的减少列存读取的IO和block解压的CPU消耗，从而实现查询性能的提升。TPC-H 1TB 测试整体提升 29%，对于有高过滤率条件的查询里，可以提升最高5倍性能，比如 TPC-H的 Q06、Q12、Q14、Q15。
2. 列存 metascan的实现
ADB PG的 meta scan 机制类似于开源格式 ORC 或者 PARQUET的元信息，通过meta 信息过滤掉不满足条件的列存 block，来提升性能。
如上图所示，ADB PG的每张列存表的数据分为2部分，一部分是表数据，一部分是meta数据，存储收集的meta信息。在scan的时候，先读取meta数据，根据min、max过滤掉不需要读取的block，通过block offset直接读取满足条件的block，然后把tuple返回给executor，executor计算后，把结果返回给客户端。
ADB PG meta存储格式如下：
meta信息按行分为两级meta：row group meta和batch group meta
- row group meta：
每张表的meta信息有多个row group meta组成，每个row group meta的max/min反应了连续的1w行的meta信息。每个row group meta包含10个row batch meta，如上图所示，row group的meta为：(min, max) = (1, 4000)。 - row batch meta:
每个row batch meta的min/max反应了连续1000个行的meta信息。与row group meta不同的是row batch meta还会记录覆盖的第一行所在的block 的block offset。
metascan 在扫描时，会顺序读取row group meta，如果过滤条件满足当前row group的min/max，则依次遍历每个row batch meta，如果过滤条件满足row batch meta的min/max，则会根据block offset，直接定位到文件中的block，否则扫描下一个row batch meta；如果过滤条件不满足当前的row group，这读取下一个row group meta，如此循环，直到所有的数据遍历完全。
为了简单并且满足事务特性，meta信息我们采用heap表的形式保存，即meta保存到辅助表中。在创建一个列存表时，同时创建meta表。这样通过heap表的mvcc以及事务机制，可以自然的实现meta信息与表数据信息的一致性和原子性。
但是该实现方式有一个问题，按这种方式meta必须覆盖所有的数据，即表上的每一行数据更新，必须更新meta，如果用户使用单条insert这种方式插入数据，则meta信息会被频繁更新，这样既会降低写入的性能又会降低查询是scan meta信息的性能。为解决这个问题，我们把meta 表分成两个primary meta 表和secordary meta 表。随着insert/update主表，meta信息会同步更新到secordary meta表中，当每个row group meta覆盖1w个行时，把meta信息从secordary meta表移动到primary meta表中，查询的时候只查询primary meta表，这样就不会因为主表数据的频繁小量insert/update而导致primary meta膨胀。但是使用这种meta维护方式，scan就需要对primary meta 没有覆盖的行做特殊处理，因此meta scan执行逻辑如下：
meta信息的收集是按segfile来划分的，所以当一个segfile的meta读取完后，需要把该segfile文件尾部的tuple顺序返回给executor。对于primary meta表没有记录的segfile，scan完primary meta后，同样的把这些segfile顺序扫描一遍。这样通过meta scan就可以扫描所有的表数据。
目前的metascan支持如下的数据类型和操作符：
- 支持的类型：
Int2/int4/int8
Float4/float8
Time/timetz/timestamp/timestamptz
Varchar/text/bpchar
cash
- 支持的操作符
=、<、<=、>、>=
and 逻辑运算符
sortkey 是AnalyticDB for PostgreSQL的另一个特性，可以让表按指定的列排序，其用来指定在单分区内数据进行排序。把metascan与sortkey结合使用，可以更有效的提高meta scan执行的性能。如果列的值在数据文件中分布比较分散，即使过滤性比较好，meta scan的执行性能可能不好，因为列的值分散在太多的block内，导致只能跳过极少的block。这种情况就可以在表上创建 sortkey，使得在单分区内数据有序排列，让表按照过滤字段排序，这样相同的值都会集中在一起，这些block都是连续的，这样在执行metascan时，就可以跳过掉大部分block，从而提升扫描的性能。
3. TPC-H测试
TPCH 是一个测试OLAP数据仓库性能的标准测试集，其主要评价指标是各个查询的响应时间,即从提交查询到结果返回所需时间，我们在ADB PG上针对meta scan特性测试对tpch的加速效果，针对tpch 1TB数据HDD硬盘测试，在其中4个表上创建了sortkey：
tpch 测试结果如下：
从测试结果看，对于Q03、Q04、Q06、Q10、Q12、Q14、Q15有非常显著的性能提升，最多提升了5倍左右。对于tpch 整体性能，按Geomean算后，有22%的提升。
对于剩余的查询无明显的性能提升。分析这些查询的特性，meta scan对于tpch中有强过滤条件的查询，性能提升较明显，但对于全表scan或者join则没有效果。
4. 既有实例升级 meta scan
对于阿里云 AnalyticDB for PostgreSQL 的现有实例，如何使用新的meta scan机制？ meta scan在实现的时候做了存储格式的前向兼容，现有实例通过小版本升级后，如果要使用新的meta scan特性，则需要刷新列存表的 meta 信息，可以使用如下的 UDF 来刷新某张表的meta信息：
CREATE OR REPLACE FUNCTION UPGRADE_AOCS_TABLE_META(tname TEXT) RETURNS BOOL AS
$$
DECLARE
tcount INT := 0;
BEGIN
-- CHECK TABLE NAME
EXECUTE 'SELECT COUNT(1) FROM PG_AOCSMETA WHERE RELID = ''' || tname || '''::REGCLASS' INTO tcount;
IF tcount IS NOT NULL THEN
IF tcount > 1 THEN
RAISE EXCEPTION 'found more than one table of name %', tname;
ELSEIF tcount = 0 THEN
RAISE EXCEPTION 'not found target table in pg_aocsmeta, table name:%', tname;
END IF;
END IF;
EXECUTE 'ALTER TABLE ' || tname || ' SET WITH(REORGANIZE=TRUE)';
RETURN TRUE;
END;
$$
LANGUAGE PLPGSQL;
select UPGRADE_AOCS_TABLE_META(tname);AnalyticDB for PostgreSQL 提供了配置参数rds_enable_column_meta_scan用来启动和关闭metascan，可以使用如下sql启动或者关闭当前session的metascan：
-- disable metascan
set rds_enable_column_meta_scan = off;
-- enable metascan
set rds_enable_column_meta_scan = on;
-- show metascan is enable?
show rds_enable_column_meta_scan;如果需要实例级别的开启或者关闭metascan，可以提工单联系我们的技术支持同学修改。
5. 结论
ADB PG 的列存储 meta scan主要是通过row group 和batch group的max/min 过滤不满足的block，通过block offset，直接读取满足条件的block，这种方式减少扫描是的IO以及block解压时的CPU消耗，因此在查询的filter具有一定的过滤性时，meta scan可以有比较明显的性能提升。
ADB PG 基于开源数据库PostgreSQL/Greenplum构建，由阿里云数据库 OLAP 数据库团队维护演进，近期会将全部功能增强开源，回馈开源社区。
