ppg_fdw：如何使用pgsql构建mpp数据仓库

    在前面的博文介绍了PG的hook和数据仓库的join算法之后，现在终于要推出干货了：ppg_fdw。（大家可以从githup：https://github.com/scarbrofair/ppg_fdw上下载代码和相关的简要说明文档）。
    总的说来，ppg_fdw基于pgsql的hook和foreign data wrapper机制，力图使用透明的方式，使用PG构建一个mpp的数据仓库。目前，从数据仓库领域来说，普遍采用了mpp的结构。特别是greenplum和asterdata来说，更是很大程度采用了PG来构建一个分布式的并行数据仓库。（说起来，ppg_fdw这个项目其实是笔者5年前左右的一个idea，但是，在历经了诸多波折之后，笔者打算使用更加接近pg的风格来实现，并作为开源程序贡献出来。由于一个人摸黑写的，代码中借用了pg的一些代码，可能在代码中没有说明，希望大家能理解。当然，代码也只是简单的运行了TPCH测试集合，还存在很多bug，希望大家指正）。
    下面是一些大家可能会问到的问题，笔者一一作答：
    1，ppg_fdw能做什么？ppg_fdw力图使用多个PG构建一个mpp的数据仓库，来并行的加速OLAP。
    2，ppg_fdw如何测试的？作为数据仓库的领域的基准测试集，TPCH无疑是最基础的，也是最有说服力的。ppg_fdw使用TPCH进行了功能测试，通过了绝大部分的测试SQL。可能有人会问为什么不是全部的SQL？
     对于这个问题，需要仔细分析TPCH的数据集合和相应的测试SQL。TPCH的数据集合可以看做是一个雪花模型（星座模型）：其中的orders和lineitem表比较大，是fact表， 其他的几个表比较小，是dimension 表。一般来说，可以将fact表适用主键进行水平分片，对于dimension 表则在各个节点上全复制（mpp数据仓库一般会采用这种方式来分发数据到各个节点）。在TPCH的SQL实例中，大部分涉及到了fact表的查询，需要对这些复杂查询进行agg下推和二次聚合，处理比较复杂。而另外的一些SQL则只涉及到dimension表的操作，可以直接将SQL转发到某个PG节点获得结果后返回给用户，处理比较简单，一般来说没有加速的必要，因此目前没有处理这些只查询dimension表的SQL。（其实主要是精力有限，不想为这些10%的简单需求分散精力。）
   （之所以进行功能测试，主要是因为屌丝只有一台台式机，实在没有多的机器可以做性能测试。在公司也是用虚拟机搭建的测试环境，说起来都是泪~~~~(>_<)~~~~ 如果需要做性能测试，需要物理机进行测试才能反映实际的数据）
    3，ppg_fdw目前处于什么状态？目前只能说处于beta版，只是简单的验证了原来的一个idea。基本上对于TPCH中大部分SQL可以做到并行加速。
    4，ppg_fdw如何使用？（由于本人都是使用Linux环境，因此如何使用也只是针对Linux平台）
    a，首先安装PGSQL在N个节点上，作为从节点，选择一个节点作为主节点。从节点上建立统一的账号和密码（postgres：postgres），允许远程访问。主节点上源代码安装PG9.0以上。之所以需要9.0版本以上，主要是需要一个支持foreign data wraper的PG版本，目前来看，需要9.0以上（包括9.0）。因为ppg_fdw调用了PG中的许多内部接口，因此也需要主节点上存在源码的编译环境。
     b,在主节点上，在pg的源码目录的子目录contrib下建立子目录ppg_fdw，假设这个目录是~/postgres/contrib/ppg_fdw，将githup上代码下载到这个目录下。
     c,在主节点上编译ppg_fdw代码得到动态库ppg_fdw.so：
        make -C ~/postgres/contrib/ppg_fdw
     d,在主节点上将ppg_fdw的SQL上SQL申明脚本和control脚本复制到pg的系统目录下：
        cp ~/postgres/contrib/ppg_fdw/ppg_fdw--1.0.sql /usr/local/PG/share/postgresql/extension
        ~/postgres/contrib/ppg_fdw/ppg_fdw.control /usr/local/PG/share/postgresql/extension
        （假设主节点上将PG安装在/usr/local/PG）
      e,在主节点上，将ppg_fdw.so复制到PG的系统动态库下：
        cp ~/postgres/contrib/ppg_fdw/ppg_fdw.so /usr/local/PG/lib/postgresql
      f,在主节点的PG中，使用SQL建立基于ppg_fdw的虚拟server,并设置虚拟服务器的配置（主要是访问远程从PG用户名和密码）：
        CREATE SERVER testserver1 FOREIGN DATA WRAPPER ppg_fdw options (host 'localhost', dbname 'postgres', port '5430');
        CREATE USER MAPPING FOR public SERVER testserver1 OPTIONS (user 'postgres', password 'postgres');
      g,设置远程从PG节点的URL:
      update pg_catalog.pg_foreign_server set srvoptions=array['host1=127.0.0.1:5430:postgres','host2=127.0.0.1:5431:postgres'] where srvname = 'testserver1';
     (从节点两个PG实际上和主节点PG位于同一个机器上，但是分别使用了5430和5431这两个端口，database都是postgres。注意格式)
      h，使用时，在主节点上建立foreign table，然后在从节点的public schema下建立schema相同的同名的普通table。（注意是public schema，主要是因为目前没有元信息的存储，远程从PG的表的schema都是写死的，为public）
      j，在主节点上,使用load命令来加载ppg_fdw(这个是session级别的有效期)，或是在配置文件中制定，这样PG启动的时候会加载。 查询这些foreign table，ppg_fdw会生成分布式查询计划，然后执行并返回结果。
    5，ppg_fdw由哪些hook构成？
     总的来说，ppg_fdw包括了2个hook：一个hook是查询优化器ppg_planner，基于rule的优化器；一个是foreign table wrapper,封装了对远程的PG节点的访问。
    6，ppg_fdw下一步进行哪些改进的？
       a，增加元数据的管理模块，例如存储表分信息，使得ppg_planner能直接下推查询。例如哪些是dimension table哪些是fact table，哪些字段是用来水平分片的字段。如果知道查询所涉及到的表都是dimension table 或是group by的字段就是 数据分片的字段，可以直接下推SQL到从节点，无需做二次聚集或是数据迁移。
       b,对子查询的处理。对于关联子查询的支持，目前PG中关联子查询用SubPlan表示，SubPlan在运行时，需要从父节点输出的结果获得参数，然后将参数传给SubPlan的子节点（一般是rescan函数），然后调用某个scan来获得输出结果，并最终计算当期的expression的结果。因此后续需要修改ppg_fdw的foreign table的 rescan方法。
      c,快速的数据迁移，目前在处理不相关子查询时，是为子查询建立新的临时表，然后将子查询的结果使用insert 语句插入远程从节点，这种方式速度比较慢，需要使用copy语句来加速。