HybridDB数据库存在的价值

近在考虑解决打点问题的数据库选型。希望阿里云上能提供一些TiDB类似的产品，同时支持OLTP和OLAP的，因此找到了HybridDB。分享一下下面文章

       在大数据火遍 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 数据类型及基于事务一致性的存储过程。