随着大规模互联网应用的广泛出现，分布式数据库成为近两年的热门话题。同样，在银行老板力推X86限制大型机和小型机的背景下，传统单机数据库也逐渐出现了一些瓶颈，即将面临是否引入分布式数据库的问题。最近在个人的公众号里对“银行引入分布式数据库的必要性”做了一些展望，也收到了一些朋友的反馈。除了讨论分布式数据库的具体技术，还有一种很有意思的建议。“能不能也说说MPP，比如Teradata、Greenplum，这些也是分布式数据库，但是老大总觉得OLTP场景算数。”确实，为了满足OLAP场景的需求，很早就出现了分布式架构的产品和解决方案，与现在的OLTP解决方案有很多相似之处。而且相信在未来，OLAP和OLTP这两个分支技术的发展必然会交错推进，可以相互借鉴。鉴于此，本文还将包含OLAP场景的分布式数据，从两个维度对“分布式数据库”进行拆解。第一部分会横向的讲一下不同的“分布式数据库”，分为五类：类和三类OLAP场景的总结分析；第二部分结合NoSQL和NewSQL的区别，纵向讲了OLTP场景的“分布式数据库”实现方案的技术要点，是上篇文章的延伸，也是分布式数据库。专题文章的大纲，其中的要点也会单独写出来。首先，我们从横向的角度来说说不同的“分布式数据库”：1、同族的RDBMS。自20世纪90年代以来，关系数据库(RDBMS)已成为主流。典型产品有Sybase、Oracle、DB2等，国内IT行业还处于起步阶段。RDBMS的基本特性在学术上已经有定义，这里不再赘述。但是从实际应用的角度，我觉得最受关注的有两点：对内以关系模型存储数据，对外支持ANSISQL接口；支持事务管理ACID特性，特别是强一致性（指事务内的修改或全部失败或全部成功，无中间状态）。后来出现的各种“分布式数据库”，大多都是在这两点上做出取舍，以换取其他的能力。虽然“数据库”有一个经典的定义，但很多大数据产品也可能会借用“数据库”的名称，以宣传替代传统数据库的某些功能。模糊的。这篇文章的目的之一就是阐明这些产品与经典数据库的区别和继承，所以我们不妨先弱化“数据库”，放大为“数据存储”。那么什么才算是“分布式数据存储”系统呢？“分布式”是一种架构风格。用它来实现“数据存储”最现实的目的是打开数据库产品的性能天花板，保证系统的高可靠性。进一步发展，“分布式数据库”的必要条件有两点：支持水平扩展，保证高性能通过增加机器节点提高系统整体处理能力，摆脱对专用设备的依赖，突破性能极限的专用设备解决方案。这里的机器节点通常支持X86服务器。廉价设备+软件保证高可靠性在单机可靠性不高的前提下，依靠软件来保证系统整体的高可靠性可以细分为“数据存储的高可靠性”和“服务的高可靠性”。总之，任何单点故障都可能带来短期的、局部的服务水平下降，但不会影响整个系统的正常运行。以这两点作为“分布式数据库”的必要条件，我粗略总结一下，至少有五种不同的“分布式数据库”：NoSQLNewSQLMPPHadoop技术生态Like-Mesa注：可能有同学会提到Kafka、Zookeeper、等等，虽然这些也属于分布式数据存储，但由于其鲜明的特点和适用场景，无需将其纳入“数据库”的概念进行讨论。这五类中，前两类主要支持OLTP场景，后三类主要支持OLAP场景。我主要按照时间线来分析OLAP场景中的三个类。2.OLAP场景下的分布式数据库20世纪90年代和2000年代，随着应用系统的广泛建设和深入使用，数据规模越来越大。国内银行业“全国集中”基本完成。这一时期，RDBMS得到了广泛的应用，甲骨文也打败了Sybase，成为数据库领域的王者。满足基本的交易场景后，数据积累起来，进一步的分析需求自然而然地出现了。在单一数据库中支持在线交易和分析需求存在很多问题，往往会对在线交易造成干扰，因此需要新的解决方案。这为MPP的崛起提供了契机。1.MPPMPP（MassivelyParallelProcessing）是指多个处理器（或独立计算机）并行处理一组协同计算[1]。为了保证每个节点的独立计算能力，MPP数据库通常采用ShareNothing架构。最典型的产品是Teradata（简称TD），后来也出现了Greenplum（简称GPDB）、Vertica、Netezza等竞争对手。架构特点：MPP是一种多机水平扩展架构，满足“分布式”的基本要求。TD使用外部集中存储，而GPDB直接使用本地磁盘。从这个角度来看，GPDB是一个更彻底的ShareNothing架构。考虑到TD在业务策略上采用一体机解决方案，不开放，而GPDB开源程度高，下面将通过分析后者的架构特点来分析MPP的工作机制。GPDB属于主从架构[2]。Slave称为Segment，是主要的数据处理节点。它是在PostgreSQL的基础上进行封装和修改的。天然具备事务处理能力，可横向扩展；集群Nodes中有一个独特的Active状态Master，除了元数据存储和调度功能外，还承担一定的工作负载，即所有外部数据在线访问集群都必须经过Master节点。在高可靠设计上，首先设置StandbyMaster节点，在Master节点宕机时接管其任务，然后将Segment节点细分为Primary和Mirror两种不同角色。后者是前者的备用节点。两者之间进行强同步，保证当Primary宕机时，可以调度Mirror接替前者的任务。IT能力的数据分析需求包括：复杂查询能力；批量数据处理；某些并发访问能力。MPP较好地支持了上述能力，在前大数据时代得到了广泛应用。但是这个时期的数据总量还是比较有限的，一般在TB级别，对应的集群规模通常是单集群100个节点。下列。随着数据价值的不断提升，越来越多的数据被纳入企业分析的范围；同时，考虑到实际应用中数据存储和传输的成本，数据往往会集中在一个或几个集群中。促进了集群规模的快速增长。在大规模集群（几百到几千）的使用中，MPP无论是批处理还是在线访问都存在一些不足。以下内容主要取材于Pivotal（GPDB原厂）的一篇官方博客[3]。注：一位同学的翻译质量也不错，推荐阅读[4]。缺陷：batchMPP架构下，工作负载节点（GPDB为segment节点）完全对称，数据均匀存储在这些节点上。在处理过程中，每个节点（即节点上的Executor）使用本地的CPU、内存、磁盘等资源完成本地的数据处理。这种架构虽然提供了更好的可扩展性，但隐藏了一个巨大的问题——Straggler，即当一个节点出现问题，速度比其他节点慢时，该节点就会成为Straggler。这时候无论集群有多大，批处理的整体执行速度都是由Straggler决定的。其他节点上的任务执行完毕后，进入空闲状态等待Straggler，不能分担工作。节点处理速度变慢的原因大部分是磁盘等硬件损坏。考虑到磁盘本身一定的故障率（据Google统计，前三个月损坏率为2%，第二年达到8%）。当集群规模达到一定程度时，使用straggler时，会频繁出现故障，使straggler成为常态。并发性由于MPP的“完全对称性”，即当查询开始执行时，每个节点都在并行执行完全相同的任务，这意味着MPP支持的并发数与查询数无关集群中的节点。根据本文测试数据，4节点集群和400节点集群支持的并发查询数是一样的。随着并发数的增加，两者的性能会在几乎相同的时间点下降。传统MPP的在线查询主要面向企业管理中的小部分用户，对并发能力的要求相对较低。大数据时代，数据使用者从战略管理转向战术执行甚至一线人员，从孤立的分析场景转向与业务交易场景的融合。在线查询的并发能力已经远超MPP时代，成为分布式数据库在OLAP场景下需要考虑的重要问题。除了以上两点，GPDB架构中的Master节点承担了一定的工作量，所有在线查询数据流都要经过这个节点，所以Master也有一定的性能瓶颈。同时，在实践中，GPDB对数据库连接数的管理非常谨慎。在我参与过的项目中，Pivotal专家给出了一个不随集群规模增加而增加的建议最大值。综上所述，可以大致得出结论，MPP（至少GPDB）在集群规模上有一定的局限性。2000年代和2010年代，大部分股份制以上银行和少数城商行建立数据仓库或ODS系统，主要使用MPP产品。可以说，过去十年是MPP产品最为辉煌的时代。迄今为止，MPP仍然是银行业构建数据仓库和数据集市系统的主要技术选择。为了避免MPP并发访问的缺陷和批任务对在线查询的影响，通常将数据按照应用粒度拆分到不同的单体OLTP数据库中，以支持在线查询。2、Hadoop生态系统MPP在很长一段时间内相当于一个一体化解决方案（以TD为代表）。它的价格高到普通企业用不起，大部分被银行、电信等行业的龙头企业使用。2010年代，随着大数据时代的开启，Hadoop生态系统凭借开源的优势得到蓬勃发展和快速普及。Hadoop技术体系大大降低了数据分析系统的建设成本，数据分析和挖掘进入了“数据民主化”时代。在Hadoop生态中，需求分析所需要的能力被拆分为批处理和在线访问，通过不同组件的搭配来实现。批处理使用MapReduce、Tez、Spark等作为执行引擎。为了获得友好的语义支持，增加了Hive、SparkSQL等组件，提供SQL访问接口。在线访问部分，从早期的Hive过渡到Impala、Hawk、Kylin、Presto等方案，访问延迟逐渐降低。架构特点：HDFS、Spark、Hive等Hadoop生态中的组件在很多文章中都有介绍，本文不再赘述。总的来说，其架构侧重于高数据吞吐量的处理能力，在事务方面比MPP更加简化，只提供粗粒度的事务管理。缺陷：Hadoop也有其明显的缺陷，主要表现在三点：批处理效率低MPP支持者经常批评Hadoop计算引擎执行效率低下。确实，在同样规模的集群中执行同样的数据处理逻辑时，即使与Spark相比，MPP所花费的时间也会明显减少[3]。形式不同。MPP来源于RDBMS（例如Vertica、GPDB都是基于PostgreSQL开发的）。数据的组织方式更接近于传统方式。以区、段、块等单位组织，对数据进行预处理，提高使用效率。;Hadoop生态系统基于HDFS文件存储。HDFS并不像传统数据库那样独立管理一个连续的磁盘空间，而是直接将数据表映射到不同的数据文件中，甚至表分区体现在目录、文件等中。HDFS最简单的txt格式就是一个平铺的数据文件。加工过程不可避免地更加简单和粗糙。但是随着Avro、ORCFile、Parquet等众多新的存储格式的引入，基于HDFS的批处理也更加细化。从整体架构来看，Hadoop更注重批量处理大量数据的吞吐能力。同时，Hadoop具有MPP所缺乏的调整批处理任务的能力。数据的多副本存储，使其拥有更多的“本地化”数据处理的候选节点，数据处理和数据存储不受约束。运行效率动态调整任务分配，在大规模部署的情况下整体效率更稳定。相比之下，MPP在数据量相对较小的情况下执行效率更高。无法无缝集成EDW实现方法论在长期实践中，企业市场主流集成商针对EDW项目制定了一套固定的实现方法，匹配MPP的特点，但Hadoop无法与之无缝对接。最典型的例子之一就是历史数据的存储。传统的方法是采用“拉链表”的形式，即记录当前有效数据的有效开始时间。数据被更改或删除后，记录的行另一列记录失败时间。这样，当前数据就变成了历史数据。通过这种增量表达，节省了大量的存储空间和磁盘IO。可以看出，拉链表的设计思路其实和基于时间戳的MVCC机制是一样的。HDFS作为Hadoop的存储基础，本身不提供Update操作，所以所有数据操作层面的Update最终都会转化为文件层面的Delete和Insert操作，大大降低了效率。据我了解，在很多企业中，这种增量存储都会转为全量存储，带来大量的数据冗余，也改变了实现方式。在线查询并发不足对于在线查询场景，最常见的解决方案是SQLonHadoop方案。Impala、HAWQ等MPP引擎建立在HDFS的基础上，批量数据和在线查询共享一份数据。MPP引擎借鉴了MPP数据库的设计经验，提供比Hive等组件更低的延迟。但是有和MPP一样的问题，就是并发不足。通过一些项目测试，我发现在大致相同的数据量和查询逻辑下，Impala并发度会低于GPDB。这其中的原因可能有很多，不排除有一定的调优空间，但在系统架构层面也有值得探讨的地方。例如，在元数据读取方面，Impala复用了HiveMetaStore，但后者提供了相对较长的访问服务延迟，这也限制了Impala的并发能力[7]。3.Like-MesaMesa是Google开发的一个近实时分析数据仓库。2014年发表论文公开其设计思路[5]。它通过预先聚合和合并Delta文件来减少查询计算量，提高并发能力。Mesa充分利用了谷歌现有的技术组件，使用BigTable存储所有持久化的元数据，使用Colossus（谷歌的分布式文件系统）存储数据文件，使用MapReduce处理连续数据。Mesa相关的开源产品有Clickhouse[6]（2016年Yandex开源）和Palo[7]（2017年百度开源）。特点：目前ClickHouse上的资料还是以俄语社区为主。为了方便大家理解和进一步研究，下面主要以Palo为例进行说明。Palo并没有完全照搬Mesa的架构设计思路。它利用了Hadoop的批处理能力，但是将处理结果导入到Palo自己的存储中，专注于在线查询场景，在线查询部分主要借鉴了Impala技术。同时，Palo没有复用现有的分布式文件系统和类Bigtable系统，而是设计了一个独立的分布式存储引擎。虽然在数据存储上付出了一定的冗余，但是在在线查询的低延迟和高并发方面有了很大的提升。Palo在事务管理方面类似于Hadoop系统。数据更新的原子粒度小到一个数据加载batch，可以保证多表数据更新的一致性。整体架构由Frontend和Backend组成。查询编译、查询执行协调器和存储引擎目录管理集成到前端；查询执行器和数据存储集成到后端。Frontend负载较轻，通常配置下几个节点即可满足要求；而Backend作为一个工作负载节点，将大幅扩展到几十到上百个节点。数据处理部分采用物化Rollup（汇总表）的方式实现与Mesa相同的预计算。Palo和ClickHouse都声称实现了MPPDataWarehouse，但是从架构上看，它们与传统的MPP发生了很大的变化，几乎完全放弃了批处理，专注于在线部分。ClickHouse和Palo作为出现较晚的开源项目，目前还处于进一步开发的过程中。设定的使用场景主要是基于对广告业务时序数据的分析。有一定的局限性，但值得持续关注。以上就是我对“分布式数据库”在OLAP场景下的横向概览分析。我们两个拆解维度的第一部分，对不同“分布式数据库”的横向讨论就告一段落了，里面还有很多有意思的东西。话题，我们可以留到后续文章继续讨论。至于第二部分——“分布式数据库”的纵向探讨，我会结合NoSQL和NewSQL的不同点，纵向讲一下OLTP场景下“分布式数据库”实现方案的技术要点。感兴趣的同学请继续关注DBAplus社区后续文章的发布。文献参考：[1]http://en.wikipedia.org/wiki/Massively_parallel[2]http://greenplum.org/gpdb-sandbox-tutorials/introduction-greenplum-database-architecture/#ffs-tabbed-11[3]ApacheHAWQ:NextStepInMassivelyParallelProcessing,https://content.pivotal.io/blog/apache-hawq-next-step-in-massively-parallel-processing[4]MPP计算框架与批处理的比较处理计算框架，http://blog.csdn.net/rlnLo2pNEfx9c/article/details/78955006[5]A.Gupta等人，“Mesa：地理复制、近实时、可扩展数据仓库”，PVLDB，卷。7，没有。12,pp.1259–1270,2014.[6]http://clickhouse.yandex[7]http://github.com/baidu/palo
