http://www.infoq.com/cn/news/2016/12/MySQL-PostgreSQL-Greenplum
编者按
在大数据火遍IT界之前，大家对数据信息的挖掘通常聚焦在BI（Business Intelligence）之上。BI具有着明确的分析需求，清晰地知道需要处理哪些信息，并且如何最终获得多维度的SQL类型数据，这种多维度的分析对应的是OLAP处理技术。在实际商业分析应用中，公司复杂信息模型、多样化的分析需求会给数据库带来极大的技术挑战。
对于阿里而言，实现OLAP、进行在线大规模并行处理，是一个无法规避的技术问题。为此，阿里云研发了HybridDB方案，它基于数据库Greenplum的开源版本，并且吸收PostgreSQL精髓。那么为什么会有HybridDB的诞生？它经历了怎样的研发历程？它的应用场景和情况是怎样的？带着这些问题，InfoQ对阿里云的数据库专家兼Postgres中国社区/中国用户会主席萧少聪先生进行了采访，以下文字整理自采访文稿。
先来讲讲OLTP和OLAP
数据库领域中大家经常会看到两个词：OLTP及OLAP。
举例说明，比如进行一次交易，资金从A帐户转帐到B帐户，这整个过程就是一次交易事务。如果过程中有任何系统错误，交易会回滚A帐户中的金额都回恢到操作前的状态，这就是On-Line Transaction Processing联机事务处理过程(OLTP)的操作。在OLTP场景中用户并发操作量会很大，要求系统实时进行数据操作的响应，在查询时往往也是只会检索一条或几条明确的目标数据，以实现用户的业务交互。
OLAP意思是On-Line Analytical Processing联机分析处理，顾名思义就是主要针对于数据的分析汇总操作。如我们的业务系统中每天都需要出销售日报，这个操作需要对当天所有数据进行汇总，并需要进行计算，以得到全天收入、产品销售排名、分时段的销售量，甚至与过去30天及去年当天进行对比，这样的操作都属于OLAP。
业界早期使用数据时，尤其是OLTP场景下，通常选择非分布式的关系型数据库，如MySQL、SQLServer、Oracle、PostgreSQL即可满足大部份的需求。
OLAP中主流数据库遭遇瓶颈
从技术角度而言，OLAP场景，不仅涉及的数据量大而且要求分析的结果实时返回，对应的SQL查询十分复杂。如何做到技术性能和业务功能权衡，对于数据库而言是一个重大考验。
已有的两个主流开源数据库，MySQL和PostgreSQL都是针对OLTP环境的，在OLAP在线分析需求下它们的性能明显不足。特别是MySQL在大规模分析操作时多表Join的性能是当前互联网用户的一大痛点。
在OLAP发展的早期，其操作并没有专门的数据库支撑，直接就与OLTP业务放在同一个数据库中完成。但随着业务量的增加，OLAP每次要分析的数据量越来越大，这样的分析操作执行时就会导致数据库的业务交易下降。因此业界开始将OLTP、OLAP拆分成两套不同的数据库进行处理，OLTP数据库中的数据通过ETL软件持续或定期抽取到OLAP数据库，让业务交易与报表分析进行分离。
而新的问题很快又到来了，联互网爆发后数据量也激增，OLTP的业务库可以保存比较少的数据量如3个月到半年，但OLAP的数据量将可能要保存几年甚至更多。单台服务服务的性能上限已经无法满足OLAP分析数据持续增加所带来的压力，因此催生出如阿里HybridDB这样的大规模并行处理（Massive Parallel Processing，MPP）分布式OLAP数据库。
新的分布式OLAP数据库
在提供HybridDB方案之前，我们会给用户提供如分库分表等处理方案，但这样的方案对于SQL查询内容不确定的OLAP业务并不友好。当用户需要进行多个数据表的组合操作时，由于数据需要跨服务器进行大规模的聚合，性能十分低下。这个问题在HybridDB中也同样会出现，所幸的是，Greenplum Database开源项目中借助平行的数据扩展技术及interconnect的专用协议，通过自定义的网络协议有效地解决了网络瓶颈的问题。这也是我们选择基于Greenplum Database开源项目的原因之一。
简单来说，MPP是一种平衡的性能扩张模型。以HybridDB的模型为列，每个节点可存放的数据量及计算能力为1Core / 8GB Mem / 80GB SSD（即将开放500GB HDD版本），如果用户80GB以内的数据在这样的计算单元中，可以在毫秒内查询出结果，那将数据计算能力及容量平衡扩展到上百TB甚至PB时，用户查询“等比”数据量时依然可以达到毫秒级别。
MPP分布式OLAP数据库系统架构已经发展了有10多年之久，十分成熟，当前使用这类系统的企业都是中大型公司。OLAP是一个很大的市场，有别于如同EMR(Hadoop)的大数据分析市场，它要求海量数据的SQL查询在几分钟、几秒，甚至毫秒级返回结果，因此对于服务器、网络及数据库软件本身的架构都提出了很高的要求。
技术攻坚之路
阿里一直都在使用并研究OLAP，实际上在2009年左右开始使用Greenplum，如果没有记错，那个时候的规模应该是国内甚至全亚洲最大的GPDB集群。
研发之路并不是一帆风顺，甚至一度突围失败。一方面，彼时Greenplum还处在萌芽期，只发布了4年。另一方面，Greenplum没有开源，既无法掌握更为深入的资料，又不得不考虑价格因素。你可以想象阿里所在行业对于数据可靠性的要求以及规模量，使得对于数据库的选择会有多个维度的考虑。
不过早期的经历还是给我们留下了宝贵的经验。当年的很多运维经验我们都进行了收集，并在现有平台中变成了我们的监控项，通过自动化运维的手段进行资源调配及故障预警，这对我们平台的稳定性提供了很重要的经验。同时针对以前遇到的很多让我们技术同学不理解的原理性问题，通过Greenplum Database的源代码我们进行了重点分析，并找到了问题的答案。有很多之前遇到过的问题，通过源码可以明确发现已经由厂商进行了修复，而有一些问题可能与我们的业务场景有关，结合源码我们也进行了内核的优化。
2015年10月Greenplum Database由Pivotal开源后，阿里云PostgreSQL内核团队便开始进行深度的调研，于2016年开始进行产品的研发工作，到今年7月份我们对用户开放了公测邀请并准备正式商业化的工作。
为什么选择基于Greenplum？主要有三点考虑：
- 生态：基于10年商业数据库建立的生态是宝贵的财富，让用户的使用变得更为便捷。
- 成熟：经过我们深度的压力测试（过程还是十分暴力的，在此不表^_^），我们验证了Greenplum本身的稳定性，同时GPDB提供丰富的SQL支持、编程接口易于进行扩展，这些都体现了她的成熟度。
- 开源：只有掌握源码才可以协助用户最快地解决问题，同时Greenplum基于PostgreSQL，基于这一点，用户可以使用统一的PostgreSQL的JDBC或.NET驱动开发OLTP及OLAP的软件，减少不同数据库协议之间的学习成本及研发复杂度。
揭秘HybridDB方案
HybridDB基于开源Greenplum Database(内核实际上就是PostgreSQL)项目的MPP分布式数据仓库，与PostgreSQL不同，HybridDB可以实现横向扩展，提供用户需要的百GB到百TB的高性能分析能力。
接下来结合项目说明实际应用。
我们有一个广告行业的用户，他们给用户提供线上的数据分析业务，同时也会将他们的产品进行线下私有环境的软件售卖。每天他们都需要进行过亿数据的汇总分析，增量数据也都在千万级别，当前通过使用HybridDB进行他们线上业务的支持。一些单表的查询在毫秒级别就可以输出结果，而很多需要多表Join的复杂查询也在数秒内就会有结果返回。同时这个用户给 HybridDB 提出 HyperLogLog 的功能需求后，我们在2周内就给予了这个功能的支持，使得用户在进行数据预估分析的操作性能提高几十倍。与此同时用户线上使用 HybridDB 开发的产品，也可以十分便捷地运行在线下的开源或商业版本的 Greenplum 上，避免了在不同数据库平台上需要重新开发应用系统的工作量。
在阿里云官网上，HybridDB 归结在 “数据库” 和 “分析” 两个类目。阿里内部已经有业务开始使用 HybridDB ，主要是看重它对SQL的丰富支持，同时可以支持GIS数据类型及基于事务一致性的存储过程。
HybridDB最大的三个特色：
- 基于成熟的GPDB及PostgreSQL生态，软开发合作伙伴进行一次软件开发，即可在云上云下同样使用，免去迁移的烦恼，更容易实现混合云中的数据分析支持。
-
支持多种混合数据类型（多达23种）的SQL统一查询，包括：
传统数据类型：字符、数字、浮点、日期等；
非结构化数据：JSON、XML；
特殊功能数据类型：GIS地理信息数据、IPv4/v6网络数据、HyperLogLog预估分析数据。
- 支持混合的数据存储，包括：行存、列存、SSD/HDD本地存储、OSS云存储，未来更将支持“存储计算分离”，用户可以更为灵活在进行资源的购买及分配。
那么，HybridDB在OLAP读取中都做了哪些优化？
优化方面从引擎底层我们针对阿里云的硬件及网络特点，进行的源码级别的深度优化，特别是在网络调度上进行了针对性的处理，提高跨网络数据节点的吞吐能力。同时在用户业务层中对特殊数据类型进行扩展，如果物联网中的JSON数据类型是Greenplum Database所不支持的，HybridDB通过直接支持这一数据类型，避免用户自行进行非结果化的解析，同时提供基于函数的JSON属性级索引，提高数据库处理JSON的检索性能。
除此之外，HybridDB还有哪些新意？
HybridDB是云上的数据仓库，用户如果在自己的私有环境中进行类似架构的部署，将需要富有经验的架构师进行完整的规划，同时还要聘用高水平的技术团队进行持续管理。因为如果系统出现故障无法提供服务，将很可能影响到企业的决策分析，对于以数据分析的基础的企业甚至会导致业务中断，通过使用云数据库HybridDB将免除这些烦恼。
将MySQL和PostgreSQL数据导入到HybridDB的这个流程实际上并没有很深的数据难度，因为MySQL和PostgreSQL都支持基于的逻辑日志，我们只需要进行解析并入库就可以了。在数据导入方面，我们借助OSS分布式数据存储的能力，实现了多计算节点的并行导入，每个计算单元（1Core/8GBMem为一个计算单元）可以达到接近20MB/s的数据导入，如果用户构建出一个64节点的 HybridDB 集群将可以达到1GB/s的数据导入能力。在我们的实际用户使用中，已经有用户通过这个方法在4分钟内导入了4亿条数据。
另一方面HybridDB还支持将数据存放到OSS云存储，实现廉价的数据存储方案，为用户节省更多成本。
数据存储
1、本地存储
HybridDB的本地存储分为行储存和列存储两种方式。行存储和列存储各有长处。行存适合于近线数据的分析，特别是要求查询结果返回表中某几跳符合条件记录的所有字段的情况。列存适合用于数据的统计分析。
那么两者的适用情况是怎样的呢？举例说明：在行存的情况下，如果一个用于存放用户的表中有20个字段，但我们只要统计用户年龄的平均值，这时数据库要对用户表进行全表扫描，遍历所有行的所有数据；但如果使用列存，数据库只要定位到这一列，然后只扫描这一列的数据就可以得到所有的结果，性能上相比列存理论上就会直接快20倍，加上HybridDB将数据分布式存储到多个计算节点，性能将再次提高几倍，达到100倍性能提升是十分常见。
HybridDB是混合两者搭配使用的。用户可以配搭进行使用，定义不同的表使用不同的存储方式，让用户适应不同的业务场景，并进行数据生态周期的管理。如6个月内的数据可能要经常获取全行数据，因此使用行存储，6个月后的数据通过列存储进行保存提高分析汇总操作的查询性能。
2、外部存储
高性能的数据分析是在本地存储完成的。OSS作为外部存储，HybridDB可以将OSS中的CSV格式化文本作为外部表进行数据查询，同时还可以对这些外部表进行写入操作。写入到OSS的数据可以提供给RDS for PostgreSQL或EMR等云数据库服务进行读取及处理，因此也同时实现了数据的无缝打通。
同时我们也将支持“存储计算分析”的模型，在这样模型上我们平时甚至可以只通过OSS进行数据的存储，当需要进行计算时再开启足够的计算节点进行数据分析处理，计算处理结束后关闭计算节点资源以节省使用成本。
HybridDB的幕后故事
1、扎根社区
当前我们基于开源版本的Greenplum Database，同时我们也会进行一些功能的添加及性能稳定性上的优化工作，我们也会逐步进行对开源社区的更多的贡献，如当前我们就已经开源了支持Greenplum、PostgreSQL及HybridDB的数据同步工具dbsync(https://github.com/aliyun/rds_dbsync)，有兴趣的读者可以下载测试及使用。
在Greenplum Database的开源社区我们会有很多的合作，甚至我们已经在向开源社区提交新功能及patch。同时Greenplum也是PostgreSQL开源数据库生态重要的力量，我个人同时作为PostgreSQL中国社区及用户会的主席也当然会进行更多线上线下活动的支持。
2、商业合作
Greenplum背后的公司是Pivotal。所以同时也与Pivotal有更多的商业合作。阿里也会与Pivotal方面进行持续的接触，相信我们会有机会碰出绚丽的火花。
写在最后
长期以来国外开源社区都认为中国用户仅仅使用开源软件，但是贡献甚少。不过，随着阿里的发展，我们已经开始反哺开源社区并共同建立生态。几个月前，AliSQL的开源说明了阿里对开源业界的支持。HybridDB同样如此，虽然我们的版本才刚刚发布，但在版本研发的过程中已经开始向社区共享代码。
阿里云当前支持云数据库HybridDB，暂时没有计划去支持私有环境的Greenplum数据库。不过我们团队的大神德哥，会继续贡献他在使用Greenplum的经验心得。希望对大家有所帮助。
用户在线下可以使用Greenplum的开源数据库版本或商业版本，据我所了解也已经有很多数据库服务商开始提供Greenplum的技术支持，使用这个数据库的用户不需要再担心未来上云迁移的问题。同时，我们也会在未来结合PostgreSQL及HybridDB提供一系列的使用教学视频，让用户更快速地掌握产品的正确使用场景及方法。