深度详解：NoSQL、RDS和大数据异构融合实战

原标题：NoSQL、RDS和大数据异构融合实战，详解PostgreSQL FDW功能原理

6月23日云栖社区《NoSQL、RDS和大数据异构融合实战》的直播顺利结束，来自阿里云的ApsaraDB数据库产品专家萧少聪(铁庵)与大家分享了通过PostgreSQL实现NoSQL、RDS和大数据异构融合实战。直播中，他重点介绍FDW原理，并结合金融报文处理、物联网数据整合、企业并购重组场景下的具体案例，详细讲解了PostgreSQL是如何通过FDW外部数据通道功能实现NoSQL、大数据异构融合以及开发效率的提升的。本次活动整理文章、视频、幻灯片整理如下。

直播视频：

（点击图片查看视频）

幻灯片下载地址：https://oss-cn-hangzhou.aliyuncs.com/yqfiles/e95acb3cc257c377ad8df5e944760638.pdf

Why PostgreSQL ？

图一 PostgreSQL的发展历程

PostgreSQL的前身为ingres Database，从1973年伯克利分校的Ingres项目至今，PostgreSQL现已经过了几十年的发展。相比较于广泛使用MySQL开源数据库，我们之所以对PostgreSQL数据库情有独钟，是因为其独特的魅力所在：

• 开放性更强：PostgreSQL基于BSD/MIT协议，对所有人免费，可以任意处置，包括使用、复制、修改、合并、发表、分发、再授权或者销售。唯一的限制是，软件中必须包含上述版权和许可提示；相比于其它如 GPL / Apache 开源协议更开放、更适合于长远的企业战略发展；

• 稳定性：PostgreSQL至今已有超过40年历史，专注于OLTP事务处理；其多程衍生产品已经用于用于传统金融、通讯、能源企业认可，如：平安集团、MasterCard、浙江移动、日本NTT、韩国KT、国家电网；

• 企业功能：在PostgreSQL 9.0中增加了大量的企业功能：

  • 数据流式复制（9.6支持多节点全同步）；

  • 基于ACID的JSON及KV数据类型；

  • PostGIS地理信息模型；

  • FDW对接第三方数据源，或实现Sharding；

  • 可扩展支持R语言、网络、生物、化学等函数；

  • 唯一明确说明对SQL 2011的兼容程度>90%；

目前,PostgreSQL正面临着巨大的机遇:首先国内PostgreSQL使用量仅是国外的三十分之一，潜力巨大；从2011年开始，PostgreSQL在国内的查询指数呈现逐年倍增；同时众多国内外商业数据库都是基于PostgreSQL，生态丰富，使其大有成为数据库界Linux之势。

Why FDW ？

FDW全称Foreign-Data Wrapper，简单来说就是PostgreSQL中的外部表功能。得益于PostgreSQL源代码的开放性，当前已经支持包括：MongoDB、Redis、MySQL、SQL Server、Oracle、Hadoop、Hive、Elastic Search等近30种不同的外部数据源（可点击此处查看所支持的全部数据源）。也就是说可以将这些数据库当做是PostgreSQL内的表格直接进行如insert、delete等操作处理。

首先来看一下传统企业现有的数据操作模型。

图二 传统企业的数据操作模型

从上图可以看出，传统企业的数据操作模型中的数据库主要使用Oracle、MSSQL或者MySQL等关系型数据库；前端包括业务系统、OA系统、财务系统等大大小小不同的系统，各系统与之对应的数据库也不尽相同。

当传统企业面向互联网/物联网进行转型时，必须要构建新的系统与数据库。对于大部分企业而言，通常会选择MongoDB作为其数据库，这是因为互联网应用中大量的数据是以JSON这类非结构化模式存储。但MongoDB实际上不是一个关系型数据库，因此不具有表格（Table）之类的概念。当企业开发的新应用需要与传统的应用进行通信时，目前采用的方法是：在原有的业务、OA等系统的原有程序上加入新代码，而且新代码操作并非传统的SQL语句，而是使用MongoDB专用的语法进行操作，这使得整体的开发变得更为复杂。

图三 传统企业整个大数据处理模型

对于传统企业整合大数据处理而言，需要将数据放入到Hadoop/Spark/HBase中进行整体分析。在这个过程中，需要将MongoDB以及传统的Oracle/MSSQL/MySQL中的数据通过定期ETL清洗等方式定期传回到大数据分析平台中，并且利用Hadoop编写MapReduce一系列的组件将Hadoop中的分析结果转存系统的数据库中，以供业务系统使用。

因此，在传统企业向互联网/物联网转型的过程中，会创造大量的软件，而这些软件可能是由不同的代码语言编写而成；同时还需要在旧的系统中扩展新的代码。总结来看，传统的企业（ISV）面临的问题可以概括成下面三点：

• 时间：不抓紧时间转型将可能错失良机；

• 复杂：新架构跨界操作多管理难；

• 团队：新知识积累不足，抗风险能力低。

如何去解决这些问题呢？我们采用的方式是：PostgreSQL FDW 。

图四 PostgreSQL FDW

从上图可以看出，通过FDW之后，可以将MongoDB/Redis等NoSQL数据库、MySQL/SQL server等RDS关系型数据库或者Hadoop等大数据处理平台，甚至是一些OSS/Excel等文件当成一系列的外部表进行操作。下面将借助具体案例进行分析。

FDW: SQL Everything加速传统行业转型

传统企业都需要向互联网、物联网或者移动端进行转型，在转型的过程中一定会遇到包括JS、JSON在内的移动端的数据类型。一个项目通常会相当复杂，在现有的基础上以最少量的改动实现代码的快速迭代，完成新的功能是非常重要的。目前，可借助PostgreSQL协助实现“敏捷项目”转型，通过使用FDW打破NoSQL和BigData的障碍，快速成型，充分发挥现有团队的SQL价值。通过SQL开发方式快速进入新领域，再进行代码向非关系型处理(JSON)或大数据处理的深度优化抽离开始，实例数据库架构的“敏捷”转型。

目前PostgreSQL 通过支持JSON数据类型，在传统行业转型的过程中，可以将传统用户数据场景轻松转换成移动互联网数据场景。通过全SQL在PostgreSQL中进行JSON数据操作，并可以对JSON中的某个属性进行索引以提高查询性能。实现NoSQL + SQL的有机整合，实现一类NewSQL的处理模型，同时在PostgreSQL中的JSON处理完全遵循ACID的数据库原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）要求。直接符合传统企业对于业务数据的可靠性、稳定性等需求，避免让用户为适应NoSQL数据库的CAP“最终一致”原理而不得不马上调整现有业务模型的窘境。

图五 SQL与JSON结合

由此上图可见通过PostgreSQL我们可以在一个SQL中操作原始的关系型数据，同时又可以进行JSON数据的整合处理。这为我们系统的“转型”开发争取到大量时间。但尽管部分的数据和JSON类型可以用PostgreSQL进行处理实现，解决了关系型数据库跟物联网对接的问题。当业务扩展到一定规模后，MongoDB数据库的需求依然会逐步展现，一是当JSON数据不要求ACID时MongoDB处理性能更高，二是当前体系下MongoDB扩展性事好；同时还可能需要用到Hadoop进行大数据分析，这又形成了非常复杂的架构和较大的任务量。针对这种情况，可以通过引入FDW模型加以解决。

图六 FDW实现“敏捷项目”成型

在FDW模型中，传统的系统业务依旧直接对应于Oracle/MSSQL/MySQL传统的关系型数据库；通过引入PostgreSQL作为中介库，也就是中间的处理节点，以便提供FDW和SQL的操作；新的互联网应用连接到MongoDB数据库中；通过在PostgreSQL中建立FDW与MongoDB的通道，将MongoDB中的数据当成PostgreSQL的数据表；在旧的业务系统中，仅需简单的SQL扩展就可以访问到MongoDB的数据；此外，PostgreSQL同样可以通过FDW与传统的数据库打通；最后，大数据处理平台以及OSS等文件也可以通过FDW与原来的业务系统进行连接。

FDW：金融报文处理

接下来看一下，在金融行业诸如报文处理等操作时FDW的是如何发挥作用的。

图七 FDW在金融报文处理中的应用

金融的报文有很多种处理方式，其中一种方式是将单个格式化文件上传到某个文件目录下；在数据库中，通过存储过程定期任务读取文件列表，在文件列表内直接将数据读出、汇总，经过计算之后重新入库。

在PostgreSQL中，同样可以利用FDW实现金融报文的处理。例如前端的前置系统会不停地将文件上传到OSS（这是一个阿里云的对象存储服务，用户可以将各种文件或对象存储于这个服务引擎中），FDW就可以访问OSS读取这些文件，具体操作如下图所示：

图八 FDW实现OSS操作

从上图可以看到，整体过程首先需要创建oss_fdw的插件；然后创建server，用于定位到OSS中的数据位置；接着创建基于OSS文件目录的名部表，将目录下所有文件的数据以表的形式展现；通过表的方式对OSS中的数据进行访问；再将OSS中的数据写入到PostgreSQL数据库中；数据并行的从 ossexample 装载到 example 中；最后，可以看到 oss_fdw 能够正确估计 oss 上的文件大小，正确的规划查询计划。

FDW：物联网数据整合

现在来看一下物联网数据整合的过程。在物联网环境中，有智能手环、车载系统等设备产生的大量的非格式化数据存储在MongoDB中。目前常用的模式是通过应用程序硬编码打通服务器上的关系数据库和大数据库处理平台。

图九 FDW用于物联网数据整合

上图是将物联网环境整合到PostgreSQL中的具体示意图，应用程序通过MongoDB的语法对存储在MongoDB数据库中数据进行操作。当需要高效开发时，通过FDW利用SQL操作快速地实现对MongoDB的操作；此外，在PostgreSQL中的PostGIS的系统，支持复杂的地理信息的计算，车载系统等路径信息可通过PostGIS先预处理，然后再输送到大数据处理平台中。

PostgreSQL也可以与MongoDB直接操作，通过表的处理方式处理一些无需硬编码的操作。对于那些需要快速、高性能处理的业务，可以通过MapReduce进行处理性能优化。

值得注意的是，由于所有的操作经过FDW进行转换，如果选用的FDW的组件并不能将所有的查询、分析等操作下发到Hadoop或MongoDB中处理，这时就需要将数据从Hadoop或MongoDB中读入，然后再通过PostgreSQL进行分析处后传递给应用端，这样的方式在提升开发效率的同时，会导致一定的性能损耗。

FDW：解决企业并购重组问题

企业并购是很多开发商都会碰到的问题，母公司和其他并购的公司使用的数据库可能完全不同，总部会有自己的数据库要求。传统的模式是通过硬编码，将数据先汇总到总部，然后总部再做其他的处理；同时总部有新的数据出现时，需要再将这些数据下发到子公司内。整个编码操作非常冗余复杂，不仅延长了企业并购的时间，同时也增加了开发和管理难度。

图十 FDW解决企业并购重组问题

如上图所示，通过FDW的形式，将所有的子公司与总部系统打通，即便子公司的数据库在异地，FDW依然可以通过互联网的形式连接到数据库中；总部应用系统除了可添加PostgreSQL数据源实现对所有子公司数据进行查询外，也可以通过简单的SQL操作将子公司的数据与总部数据进行整合；甚至可以将总部数据库与PostgreSQL进行打通连接，这样一来，各家子公司就可以访问权限范围内的总部数据。

总结

PostgreSQL是一个非常强大、功能齐全的开源数据库，本文重点介绍的只是FDW和JSON处理，未来期待更多的开发者成为PostgreSQL新生的一代，共同推进其在国内的发展。

更多深度技术内容，请关注云栖社区微信公众号：yunqiinsight。