云+微服务+新硬件：下一代大规模并行数据库架构风格
从上个世纪70年代开始，数据库就成为计算机软件中最重要的“中间件”。有了数据库后，关于数据操作的原语可以从应用代码中分离出 来，DBMS（数据库管理系统）承担了数据结构的管理、存取等任务，并维护了数据的可用性、一致性。这种专业化的分工，使得软件开发效率和系统运行效率大 大提升。进入21世纪后，随着软件和硬件技术的发展、互联网的兴起，数据库技术发展进入了一个百花齐放的新阶段，其指导思想仍旧是专业化分工。为每一种数 据类型和应用访问类型都有了其针对性的数据库技术。本文主要描述其中一个细分市场——大规模并行数据库的发展趋势。
并行数据库的定义和架构特点
在维基百科上，并行数据库被定义为通过并行使用多个CPU和磁盘来将诸如装载数据、建立索引、执行查询等操作并行化以提升性能的数据库系统。其中最重要的关键词是并行。
在组成大规模计算机集群的时候，通常有两种特性要考虑：并行和分布式。并行强调多节点同时执行，共同解决一个大问题，通常在严格的高性能网络环境 中，有严格的执行要求和反馈时限。因此，并行和并发大多数时候是矛盾的两面，你不应该指望并行数据库能在极短的时间处理大量的请求，因为它是为了解决大问 题而设计的，而不是大量的小问题。分布式则是另外一个特性，它强调数据或计算分布在不同的节点，并对上提供透明性。
因为目的不一样，通常设计运行在大规模集群的软件时，不会同时追求这两者。并行数据库被设计为最求极致的并行，即使仅查询一条数据的SQL，也会 被扔给所有的数据节点来执行；而HDFS则不是这样，它不会要求一个文件块完全分布在所有的数据节点上，并同时提供访问，它只需要将一个文件按照顺序分成 几个块分布在数个节点上即可，一个接一个地被访问。因此一个HDFS数据节点失效影响不了全局；但是一个MPP的数据节点失效会影响全局。这是两种特性的 典型差别。理解了这个“并行”的特点对理解并行数据库的设计非常重要。
很明显，因为并行数据库的技术特点是为了某类需求设计的，因此它有自己的适用环境。首先因为它采用关系理论，因此它仅适合结构化数据。非结构化或 者某些半结构化数据，当然也可以在其中存和取，但是实际上有很多更好的解决方案可以选择。其次还是因为它采用关系理论，关系代数和关系演算是其擅长的，因 此它在并行计算，特别是复杂的多表关联、流水线等一系列操作中特别擅长，如果只是存入和取出的话，NoSQL会更加适合。再次，因为并行数据库的SQL语 言是一种申明式的语言，甚至当初设计的目的并不是给程序员使用，而是给业务人员用的，因此处理日常重复性任务有更好的解决方案，比如MapReduce和 Spark。最后一点，因为并行数据库需要在数据分布（计算Hash）和存储格式（比如列存、压缩、索引、页面统计信息等）方面进行较多的处理以便为查询 进行优化，因此装载数据比较耗费精力，花费时间较长。所以入库后只会被读取少数次的任务，最好不要麻烦它来做。
并行数据库目前的主要问题来自于它的设计目的，因为要实现完美的并行，因此它大多被设计为计算和存储紧密耦合，这样计算可以控制每行数据的存储位 置和每个数据块的存储格式，这样对大任务提供了很好的性能（类比于“鱼”）。同时也使得系统鲁棒性不高，这体现在一个节点退服后性能下降严重，两个节点退 服有全库停止的可能。另外系统扩展性也受到限制，一是规模不能太大，二是基本需要对等性能的机器，三是重新计算Hash并移动数据是非常麻烦和缓慢的（类 比于“熊掌”，目前是鱼与熊掌不可兼得）。
并行数据库技术要点分析
并行数据库主要由执行引擎、存储引擎和管理功能模块组成。它们的不同技术风格形成了各个有特色的并行数据库产品。
因为是大规模集群的数据库，所以首要要面对的就是主、从节点的风格。主节点要承担入口、元数据管理、SQL Parser、生成执行计划和任务调度、管理两阶段提交等功能。目前有两种方式：有专职Master和无专职Master。
从开源的PostgreSQL演变来的并行数据库，多为有专职Master的。这种架构比较简单，因此数据节点的对等性比较容易维护，不会形成性能短板。它们的Master形成了主备模式，切换的时候影响比较大，而且主节点的动态伸缩也是问题。
从头设计的并行数据库多为无专职Master的，比如Gbase 8a和Vertica。数据节点和Master节点代码部署到一台物理机，被连接上即充当此次连接的Master。其优点是足够的扩展性和更好的高可用 性，但是缺点在于Master的进程可能拖慢数据节点，形成性能短板。而且Master之间的元数据同步也是一个负担。
两种方式各有优劣，在大规模集群下，无专职Master架构优势更加明显，其向“多Master”架构发展也很容易。我认为多Master是未来方向，这样在提供良好的扩展性和高可用的同时，也保持了数据节点的对等性。
在存储引擎中最为关键的就是数据分布。按行进行Hash分布是并行数据库的重要特征。其它数据分布方式无法精确控制数据摆放，也无法提供足够用于查询优化的存储信息。
就像之前说的那样：这种紧密耦合的非透明的方式带来了巨大的好处（同样分布的表的高效关联），同时也带来了麻烦（扩展性、高可用等）。鱼与熊掌不 可兼得。一些改进的SQL on Hadoop方案借用了这一点，比如HDFS Colocation、Pivotal HAWG、Vertica VIVE等。没有解决Hash分布的解决方案，都难以处理多个大表关联（Join）的问题，它们多通过预关联的方式来规避这个问题，形成某种类似OLAP 多维立方体的解决方案（比如Google Dremel、Mesa，eBay Kylin等）；或通过shuffle实现重新分布（比如Hive或者SparkSQL）。
数据库所用存储设备历经变迁，且当前面临大变革。目前典型的并行数据库多使用SAS磁盘，而HDFS使用容量更大、价格更便宜但性能和可靠性稍差 的SATA磁盘。使用这种慢速的磁盘是并行数据库目前最大的瓶颈，使它无法实现效率和可扩展、高可用兼得，也就是鱼与熊掌不可兼得的难题，主要来源就在于 此。磁盘IO的速度难以匹配摩尔定律要求的速度，但是电子盘和内存是可以的。随着后两者的价格快速下降、性能快速提高，并行数据库可能又将面临一次重大的 变革，并解决那个难题。
并行数据库目前主要的数据存储仍然使用磁盘，电子盘和内存盘最多只能作为缓存来使用。我认为接下来的1到2年，我们很快就将面对以SATA接口的 SSD替代SAS磁盘的过程。现在一些高端的并行数据库一体机已经可以采用全SSD的配置了。目前的并行数据库几乎不用改动任何代码，就可以运行在SSD 之上。
但是，因为硬件特性不一样，只有全新设计一个并行数据库系统，才能最佳发挥SSD的作用。因为现有的并行数据库系统是为了旋转磁盘的特性设计的， 为了将随机的读写转换为顺序的读写，用了非常多复杂的机制和复杂的代码。如果单个数据或者一小块数据的随机访问速度和顺序访问相当，那么就没有必要这样 做，节省下的代码将提高效率、系统的稳定性、可用性和扩展性。NoSQL数据库AeroSprik就是专门为SSD来设计，而取得了很好的性能。
我认为未来是内存为王的时代，天下武功为快不破。内存是数据存储的终极目标。目前柏睿Rapids DB和HANA等产品就是将内存作为数据的实际存储地方，SSD只是拿来做快照和日志的存储而已。这种方式，将解决MPP面临的“鱼与熊掌不可兼得”的问 题。在短期内，这种方案不能成为所有数据存储的选择，但是我坚信硬件的发展是持续的，用硬件来解决软件的问题是最直接有效的方式。因为内存的易失性，并不 能简单地将数据存储从SSD转移到内存中，这将面临一次更多的、更彻底的并行数据库软件平台的重新设计。
使用并行数据库必须了解这样一个事实，那就是单节点退服带来的总体性能下降超出你的想象，如果碰巧遇到某些脆弱的数据库和呵护不周到的DBA，还可能产生“雪崩”现象，即因为某一个节点下线导致整体异常繁忙而全库崩溃。这事情出现可不是特例。
这是一个我们的测试结果。24个节点退服一个的情况下，不同产品读的性能和写的性能下降的情况。
图1 24个节点退服情况对此测试结果
注意这不是满负荷（CPU BOUND或IO BOUND）的情况，这不是一个成比例的下降。100个节点和1000个节点会面临与此类似的情况，不能增加节点来解决这个问题。因此节点的退服影响很大，这和Hadoop非常不一样。
简单的说产生这个问题的原因就在于Hash分布。Hash分布带来了极致的并行（鱼），同时破坏了存储和执行之间的透明性（熊掌），因此深度绑定导致出现问题的节点的任务无法分散在所有节点，只能由备机所在的节点承担。
同样影响的是线性扩展性，目前世界上最大的MPP生产集群是300个节点。而且大家都倾向用性能更好的胖节点来减少节点的数目。比如我们的设备就有24个SAS盘位。扩展的时候移动数据也是一个很大的开销。
小结一下。目前我们可以看到三类典型的并行数据库架构风格：
最左侧是以Gbase8a、Vertica、GreenPlum为代表，典型的MPP数据库。数据采用Hash分片，存储引擎和执行引擎紧密耦合，数据完全的本地化，支持完整的SQL，基于成本进行SQL优化。
最右侧是以Impala为代表的典型的SQL on HDFS。存储引擎HDFS与查询引擎完全透明，数据不是由查询引擎写入的，实际上它们就不叫执行引擎，大多只支持“查询”。因为不能控制存储，所以没有统计信息，大部分只能实现基于规则的SQL优化。
图2 三类典型的并行数据库架构风格
存在一个中间的状态，请允许我用MPP over HDFS来命名它。以GreenPlum HAWG和Vertica刚推出的VIVE为代表。虽然它也利用HDFS，但是写入的数据均是通过它自己的存储引擎写入的，因此是要计算Hash的，有自 己的文件格式和压缩格式，不同节点的文件写到不同节点的目录中，类似Hbase那样。当然也有完整的统计信息，因此可以实现基于成本的SQL优化。它通过 HDFS的本地化机制部分实现了数据本地化。MPP节点（也就是执行节点）出现故障以后可以快速启动一个新的执行节点，因为执行节点并不带数据，当然这个 时候要损失掉数据本地化的收益。这种中间方案的性能和扩展性也处于中间。
比如HAWG。它基本上就是把GreenPlum DB的数据存储从本地磁盘的文件系统迁移到HDFS上，使用了一个自己扩展的HDFS接口（gphdfs，Vertica的VIVE使用的是 webhdfs的接口）。典型的MPP性能肯定比中间方案的MPP over HDFS高。Vertica自己的一个测试，大概是高一倍左右。GreenPlum的测试结果与这个类似。
并行数据库未来展望
如何既能充分发挥并行数据库的特点，又避免其问题呢？当前云计算+微服务的新一代架构风格，配合当前的硬件发展让我看到了一线曙光。
1. 云服务的模式，使得数据库规模越来越大，经济性越来越显著
在我的实践中，我感受到了云计算给IT带来的颠覆，虽然云计算热已经过了，但是它已经润物细无声地改变了业态。我认为数据库也是这样，以后以云的 方式提供的数据库会越来越多。无论是企业内部的私有云还是对外的公有云。比如AWS RedShift和Openstack Trove (DBaaS)。这给数据库软件带来的变化是它需要支持越来越大的集群，技术难度加大但经济性更好，可以拥有更加专业的运营团队来充分享受新技术的红利。
70年代数据库的出现实现了数据库中间件和应用软件的分工，因为分工而专业，而高效。同样在当前情况下，云服务的模式使得数据库的分工更加明显， 并不需要每个应用都有一个数据库集群为其服务，变拥有为租用，每个应用只需要订购相应的数据库服务即可。分工的细化带来的效率的提升，使得数据库的针对性 优化可以做到极致，出现问题后的解决方案也可以及时而迅速。
阿里云每一个数据库首要的要求就是云化，比如OceanBase、内存分析型数据库ADS等。多租户、负载管理、资源隔离、配额和用量，这些原来数据库并不看重的边缘能力，在云服务的时代变得非常重要，成为新时代数据库的标准配置。
2. 数据库组件的分工细化，通过微服务实现高内聚，松耦合
并行数据库的软件模块或者叫组件的分工会越来越细化。以前只有主节点和数据节点两类，此外还有一些数据库可以利用不带数据的数据节点来作为装载节 点。新一代架构风格会将接入节点、协调节点、元数据节点、日志节点、安全节点、SQL解析和优化节点、数据装载和导出节点、数据节点全部分拆成可以并行， 可以灵活部署到任何位置的容器级服务。
这些组件按照容器的标准（比如Docker）进行封装，并在微服务的框架下形成并行数据库的管理系统（比如通过K8s或者Mesos）。服务发 现、配置管理、健康管理、鉴权管理由运行框架实现，从而达到各个组件高可用、松耦合、屏蔽内部细节的效果。同时Docker这样的Build、Ship、 Run的方式为DevOps提供了便利的手段，使得数据库软件能像互联网应用一般快速迭代升级。
不仅仅是数据库功能组件的分工。对于数据库最重要的能力，数据节点部分，还可以进行更加极致的分工。当前的数据库设计模式下，数据节点承担了整个 数据库的一个分片，所管理的数据可能是上TB的量级。这样庞大的数据量使得数据节点本身难以形成“微服务”。同时也是为什么需要能力对等的服务器的原因， 性能低下的服务器，或者出现故障的服务器会形成木桶效应从而拉低整个集群的性能。
为什么不让数据节点管理更小的数据分片呢？无论是一个表，还是一个表的某个Hash值范围，或者一个逻辑数据库（数据沙盒）的某个Hash值范 围。如果一个数据节点仅管理数MB的数据，那么这些数据节点不仅可以更加方便地管理在内存中，而且方便地在物理机器之前迁移，出现问题以后重新载入一个微 型的数据节点结束带病工作状态的速度也会很快。此外按照服务器的能力来分布这些数据节点也会变得很简单，不再需要对等的服务器集群。
如果没有Docker这样的容器封装标准，通过进程来实现这种大量的微数据节点可能会很复杂。但是Docker天生就是为这种单进程、微服务的任 务所设计。从Docker Hub中，一个Docker的Image可以很快获取到一台机器上，一个容器可以很快生成，其所需要负担小的数据分片可以很快从其他副本分片获取数据或者 直接从持久化存储（File Server）中拉取数据，日志传至专门的日志服务器，从而实现无状态的服务。其初始化工作完成后，向“服务发现”进行注册，这个数据分片就可以对外提供 访问了。
这种微型数据节点设计将数据缓存在内存中，并使良好的资源管理成为可能。
3. 充分利用新型硬件的红利
新一代的架构可以针对新型硬件进行特别优化，3D内存、Flash卡、硬件压缩卡、Infiniband，这些硬件设备都是之前一代数据库系统所未面对过的。如果进行针对性开发，不仅可以充分利用其性能优势，还能延长硬件的生命周期。图3是一个大致的示意。
图3 新一代架构设计图
总结几点：
- 并行数据库有其适用范围；
- 所有数据库设施都需要云化，实现专业分工；
- 组件的微服务和数据的微服务是新一代架构的主要特点；
- 硬件的变化将导致软件形态极大地改变。
作者： 何鸿凌
简介： 中国移动集团公司业务支撑系统部信息处副经理，高级工程师。工信部和人社部认证的高级程序员、系统分析师、网络分析师。TDWI会员。主要精力放在大数据 技术以及大数据应用方面，主导引入Greenplum、Vertica、Gbase8a等MPP技术，以及Hadoop、流处理和Spark等技术来搭建 运营商的大数据平台，并探索大数据对内和对外的商业应用。