TDW作为一个离线数据分析系统，在处理海量数据方面，通过并行计算，有很好的性能优势。但是腾讯知道，想用一个大而全的系统解决所有问题一般也是不现实的，同样，TDW也有它的劣势，比如对小数据处理性能低，update/delete性能差、接口不丰富等。因此腾讯引入一个强大的开源数据库PostgreSQL，并对其做一些功能扩展，使之有访问TDW数据的能力；同时腾讯在TDW中开发了一种新的存储引擎，腾讯称之为pgdata存储引擎，使得TDW具备读写PostgreSQL中的数据的能力。
PostgreSQL在腾讯应用概述
- 主要业务场景为OLAP数据分析
- 大部分为内部系统，少量应用于对外服务
- 作为TDW系统的补充而存在
- 主要应用形式为业务使用TDW提供的tPG服务
- TDW团队负责机器、运营和技术支持
- 业务提交申请即可使用
- PG与MySQL
- MySQL可以支撑，则优先使用MySQL
- MySQL不能满足，再考虑使用PG
TDW与PostgreSQL互访问功能的实现，对TDW是一个强有力的补充，这些主要体现在如下3点：
- 弥补TDW接口不丰富的短板。TDW缺乏标准化的JDBC/ODBC，编程接口也不丰富，而PostgreSQL有社区强大的力量，提供了JDBC/ODBC, shell, C/C++, C#, python, perl等各种语言的接口，用户通过这些丰富的接口和腾讯开发的PostgreSQL的TDW桥接工具tdwlink，访问TDW中的数据。
- 弥补TDW小数据分析效率底的短板。TDW在海量数据处理时，可以发挥它并行执行的优势。但是对于小数据分析，它的性能反而不如传统的DB。使用PostgreSQL，对于10GB以内的数据分析，可以获得更好的性能和时间响应，一般可以在秒级返回结果，相比TDW分钟级的响应，tPG在这种场景下更有优势。
- 作为TDW的pgdata存储引擎，弥补TDW update/delete效率底下的短板。TDW作为数据仓库系统，对于记录级的update/delete支持不是很好。在TDW中记录级的update/delete，会导致整个表的重写，也就是说，即使delete一条数据，也会导致整个表重写一遍，耗费大量系统资源。而tPG作为传统数据库，记录级的update和delete效率非常高。
tPG的作用
- TDW数据集市，结果展示
- 对外提供JDBC/ODBC等标准化接口
- 提高高校的小数据分析功能
- 提高高校的update/delete功能
TDW为什么要引入tPG
TDW应用推广遇到的挑战
- TDW离线分析，不能满足业务的结果库需求
- TDW没有标准的JDBC、ODBC接口，难以与商业工具对接
- TDW处理小数据、做update和delete效率低
解决方案
- TDW不是万能的，不可能满足所有应用场景
- 需要建设一套RDBMS，作为TDW的补充
- 要方便用户迁移已有业务，做好有工具做迁移
- 要有标准的JDBC、ODBC接口
- 性能要好
- 功能容易扩展
为什么选择PostgreSQL
- 完善的DB功能
- SQL标准支持较好
- 支持PL/pgSQL等多种过程语言
- 支持视图、分析函数、CTE等高级特性
- OLAP性能超过MySQL
- 复杂SQL性能高10倍+
- 基于cost的SQL优化，调优手段更多
- 部分索引，函数索引，cluster索引
- 插件式的功能扩展
- 已有访问Mysql、Redis、文本等外部数据源插件
- 很容易开发访问TDW的插件
- TB级数据库备份与恢复(基于zfs快照技术)
- 速度快，对上TB的数据做快照耗时小于1秒
- 占用空间小，新生成的快照几乎不占空间
- 支持快照增量备份，支持快速rollback
PostgreSQL系统在TDW生态圈中的位置如下图所示，tPG是腾讯对扩充之后的PostgreSQL的一个叫法：
下面分两个部分对TDW与PostgreSQL的互访问功能做一个介绍，也即是pgdata存储引擎以及tdwlink功能。
pgdata存储引擎
TDW本身支持多种存储格式，包括textfile，rcfile，pbfile，在这个基础上，腾讯开发一种新的存储引擎，也即pgdata存储引擎，能够透明的存储以及访问PostgreSQL中的数据，具体情况如下图：
在使用上，只需要在创建表的时候指定为pgdata存储引擎即可，例如使用如下语句就可以创建此类型的外表
|
1 |
create external table foo(idx bigint, str string) stored as pgdata |
在后续访问过程中就和使用其他TDW表一般即可，在此简单说明一下访问的实现方式，访问的数据流大致如下
- 在解析SQL查询语句时，先分解出每个子查询，然后对每个子查询总是会首先判断当前查询涉及的表中是pgdata外表，如果没有DB外表则走正常的查询语句执行流程；
- 如果有pgdata外表, 接着再检查在本次查询中涉及到的外表数据是否已经导入，如果导入则直接复用已经导入的数据，如果没有则对相应的子查询进行加工，将其转换为相应的标准关系型数据库SQL语句，然后从表中获取连接信息，使用JDBC执行查询语句；
- 将查询结果的数据从数据库中导入到位于tmp目录下的一个随机HDFS目录中，这个随机目录使用UUID生成，因此可以保证唯一性，而不与其他查询语句产生冲突，然后将其设置为外表的数据所在的HDFS文件路径，Mapreduce任务会自动读取该路径作为任务的输入路径；
- 在该条查询执行结束以后，并且查询结果已经获取成功，则清除掉这个临时文件。如果查询出现了异常也会自动的清理到已经导入的垃圾数据信息。
tdwlink功能
SQL标准中包含了一个名为SQL/MED也即”SQL Management of External Data”的功能， PostgreSQL在2011年的9.1版本使用一种叫Foreign Data Wrappers的机制对此标准做了只读支持，开发人员只需要对相应的数据源开发相应的插件即可通过PostgreSQL对远端数据源进行访问。目前社区已经有很多基于此功能开发的插件，诸如oracle_fdw，mysql_fdw，redis_fdw等，腾讯团队基于PostgreSQL的这个特性，开发了具备访问TDW数据能力的插件，称之为tdw_fdw，可以参考下图：
为了方便用户使用此功能，腾讯开发了一个存储过程tdwlink，用户只需要事先配置好对应的Foreign server以及认证信息，即可很方便的使用，例如腾讯已经定义好了tdw_svr这个server，想访问tdw里的test库的test表，只需要select tdw_meta.tdwlink(‘tdw_svr’,‘test’,‘select col1, col2 from test’)即可。由于此函数是通过PostgreSQL提供的，因此可以使用PostgreSQL提供的任意接口来使用，这样也间接的扩充了TDW所具备的访问接口。这里补充一点，腾讯的tdw_fdw插件是基于PostgreSQL 9.1版本开发的，这个版本的Foreign Data Wrappers只能对外部数据源提供只读访问，因此腾讯的tdw_fdw只能够提供对TDW的只读访问，而最新发布的PostgreSQL9.3版本的Foreign Data Wrappers已经提供写支持，这个也是腾讯的tdw_fdw插件后续可以进行功能扩充的地方。
tPG使用的开源插件
- 分区管理：基于pg_partman进行改造
- 监控：check_postgres和pgBadger
- 缓存预热：pgfincore
- 实例间互相访问：dblink
- 读取MySQL数据：mysql_fdw
- 中文全文检索：zhparser
tPG运营现状
目前运营情况
- 11套tPG实例，共约40台机器
- 已用存储约30TB，最大实例存储达5TB
- tPG在公司内的用总户数100人+
- 没有因PG本身出过事故，用户评价积极
业务类型
- 对外：用户报表
- 对内：TDW系统，30多个业务的报表系统、数据提取系统、BI系统、营销系统等
tPG应用未来规划
- 为业务提供集群版PG-XC服务
- 更丰富的应用场景
- 地理信息（PostGis ）
- 机器学习与数据挖掘（Madlib ）
- R统计分析（PL/R ）
- …
- 接入流程自助化
- 将tPG服务云化，降低运维人工参与量