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语句来加速。
   
    

你可能感兴趣的:(数据仓库)