云+微服务+新硬件:下一代大规模并行数据库架构风格

jopen 9年前
 

从上个世纪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 新一代架构设计图

总结几点:

  1. 并行数据库有其适用范围;
  2. 所有数据库设施都需要云化,实现专业分工;
  3. 组件的微服务和数据的微服务是新一代架构的主要特点;
  4. 硬件的变化将导致软件形态极大地改变。

云+微服务+新硬件:下一代大规模并行数据库架构风格 作者: 何鸿凌

简介: 中国移动集团公司业务支撑系统部信息处副经理,高级工程师。工信部和人社部认证的高级程序员、系统分析师、网络分析师。TDWI会员。主要精力放在大数据 技术以及大数据应用方面,主导引入Greenplum、Vertica、Gbase8a等MPP技术,以及Hadoop、流处理和Spark等技术来搭建 运营商的大数据平台,并探索大数据对内和对外的商业应用。