作者：萧少聪
编辑：木环
“好好用MySQL和PostgreSQL不就行了？为啥阿里要劳神费力地又基于Greenplum的开源版本研发HybridDB方案？HybridDB方案深究之下，有什么技术细节与故事？编者按
在大数据火遍IT界之前，大家对数据信息的挖掘通常聚焦在BI（BusinessIntelligence）之上。BI具有着明确的分析需求，清晰地知道需要处理哪些信息，并且如何最终获得多维度的SQL类型数据，这种多维度的分析对应的是OLAP处理技术。在实际商业分析应用中，公司复杂信息模型、多样化的分析需求会给数据库带来极大的技术挑战。
对于阿里而言，实现OLAP、进行在线大规模并行处理，是一个无法规避的技术问题。为此，阿里云研发了HybridDB方案，它基于数据库Greenplum的开源版本，并且吸收PostgreSQL精髓。那么为什么会有HybridDB的诞生？它经历了怎样的研发历程？它的应用场景和情况是怎样的？带着这些问题，InfoQ对阿里的数据库专家萧少聪先生进行了采访，以下文字整理自采访文稿。
先来讲讲OLTP和OLAP
数据库领域中大家经常会看到两个词：OLTP及OLAP。
举例说明，比如进行一次交易，资金从A帐户转帐到B帐户，这整个过程就是一次交易事务。如果过程中有任何系统错误，交易会回滚A帐户中的金额都回恢到操作前的状态，这就是On-LineTransactionProcessing联机事务处理过程(OLTP)的操作。在OLTP场景中用户并发操作量会很大，要求系统实时进行数据操作的响应，在查询时往往也是只会检索一条或几条明确的目标数据，以实现用户的业务交互。
OLAP意思是On-LineAnalyticalProcessing联机分析处理，顾名思义就是主要针对于数据的分析汇总操作。如我们的业务系统中每天都需要出销售日报，这个操作需要对当天所有数据进行汇总，并需要进行计算，以得到全天收入、产品销售排名、分时段的销售量，甚至与过去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这样的大规模并行处理（MassiveParallelProcessing，MPP）分布式OLAP数据库。
新的分布式OLAP数据库
在提供HybridDB方案之前，我们会给用户提供如分库分表等处理方案，但这样的方案对于SQL查询内容不确定的OLAP业务并不友好。当用户需要进行多个数据表的组合操作时，由于数据需要跨服务器进行大规模的聚合，性能十分低下。
这个问题在HybridDB中也同样会出现，所幸的是，GreenplumDatabase开源项目中借助平行的数据扩展技术及interconnect的专用协议，通过自定义的网络协议有效地解决了网络瓶颈的问题。这也是我们选择基于GreenplumDatabase开源项目的原因之一。
简单来说，MPP是一种平衡的性能扩张模型。以HybridDB的模型为列，每个节点可存放的数据量及计算能力为1Core/8GBMem/80GBSSD（即将开放GBHDD版本），如果用户80GB以内的数据在这样的计算单元中，可以在毫秒内查询出结果，那将数据计算能力及容量平衡扩展到上百TB甚至PB时，用户查询“等比”数据量时依然可以达到毫秒级别。
MPP分布式OLAP数据库系统架构已经发展了有10多年之久，十分成熟，当前使用这类系统的企业都是中大型公司。OLAP是一个很大的市场，有别于如同EMR(Hadoop)的大数据分析市场，它要求海量数据的SQL查询在几分钟、几秒，甚至毫秒级返回结果，因此对于服务器、网络及数据库软件本身的架构都提出了很高的要求。
技术攻坚之路
阿里一直都在使用并研究OLAP，实际上在年左右开始使用Greenplum，如果没有记错，那个时候的规模应该是国内甚至全亚洲最大的GPDB集群。
研发之路并不是一帆风顺，甚至一度突围失败。一方面，彼时Greenplum还处在萌芽期，只发布了4年。另一方面，Greenplum没有开源，既无法掌握更为深入的资料，又不得不考虑价格因素。你可以想象阿里所在行业对于数据可靠性的要求以及规模量，使得对于数据库的选择会有多个维度的考虑。
不过早期的经历还是给我们留下了宝贵的经验。当年的很多运维经验我们都进行了收集，并在现有平台中变成了我们的监控项，通过自动化运维的手段进行资源调配及故障预警，这对我们平台的稳定性提供了很重要的经验。
同时针对以前遇到的很多让我们技术同学不理解的原理性问题，通过GreenplumDatabase的源代码我们进行了重点分析，并找到了问题的答案。有很多之前遇到过的问题，通过源码可以明确发现已经由厂商进行了修复，而有一些问题可能与我们的业务场景有关，结合源码我们也进行了内核的优化。
年10月GreenplumDatabase由Pivotal开源后，阿里云PostgreSQL内核团队便开始进行深度的调研，于年开始进行产品的研发工作，到今年7月份我们对用户开放了公测邀请并准备正式商业化的工作。
为什么选择基于Greenplum？主要有三点考虑：
生态：基于10年商业数据库建立的生态是宝贵的财富，让用户的使用变得更为便捷。
成熟：经过我们深度的压力测试（过程还是十分暴力的，在此不表^_^），我们验证了Greenplum本身的稳定性，同时GPDB提供丰富的SQL支持、编程接口易于进行扩展，这些都体现了她的成熟度。
开源：只有掌握源码才可以协助用户最快地解决问题，同时Greenplum基于PostgreSQL，基于这一点，用户可以使用统一的PostgreSQL的JDBC或.NET驱动开发OLTP及OLAP的软件，减少不同数据库协议之间的学习成本及研发复杂度。
揭秘HybridDB方案
HybridDB基于开源GreenplumDatabase(内核实际上就是PostgreSQL)项目的MPP分布式数据仓库，与PostgreSQL不同，HybridDB可以实现横向扩展，提供用户需要的百GB到百TB的高性能分析能力。
接下来结合项目说明实际应用。
我们有一个广告行业的用户，他们给用户提供线上的数据分析业务，同时也会将他们的产品进行线下私有环境的软件售卖。每天他们都需要进行过亿数据的汇总分析，增量数据也都在千万级别，当前通过使用HybridDB进行他们线上业务的支持。
一些单表的查询在毫秒级别就可以输出结果，而很多需要多表Join的复杂查询也在数秒内就会有结果返回。同时这个用户给HybridDB提出HyperLogLog的功能需求后，我们在2周内就给予了这个功能的支持，使得用户在进行数据预估分析的操作性能提高几十倍。
与此同时用户线上使用HybridDB开发的产品，也可以十分便捷地运行在线下的开源或商业版本的Greenplum上，避免了在不同数据库平台上需要重新开发应用系统的工作量。
在阿里云