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

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