本文是分布式数据库的总纲文章的第一部分主要探讨分析性分布式数据库的发展和技术差异第二部分则是交易性数据库的一些关键特性分析。Ivan开始计划的分布式数据库是不含分析场景的所以严格来说本篇算是番外篇后续待条件具备将以独立主题的方式展开。特别说明本文是原创文章首发在DBAplus社群转载须获得作者同意。正文随着大规模互联网应用的广泛出现分布式数据库成为近两年的一个热门话题。同样在银行业主推X86限制主机与小型机的背景下传统的单机数据库逐渐出现了一些瓶颈马上会面临是否引入分布式数据库的问题。近期Ivan在个人公众号就“银行引入分布式数据库的必要性”做过一些展望并收到了一些朋友的反馈除了对分布式数据库具体技术探讨外还有一类很有趣的建议“能不能也讲讲Teradata、Greenplum这类MPP这些也是分布式数据库但老板总是认为OLTP场景下的才算数”。的确为了解决OLAP场景需求其实很早就出现了分布式架构的产品和解决方案其与目前的OLTP方案有很多共通的地方。而且Ivan相信今后OLAP和OLTP两个分支技术的发展也必然是交错前行可以相互借鉴的。鉴于此本文会将OLAP类场景的分布式数据也纳入进来从两个维度对“分布式数据库”进行拆解第一部分会横向谈谈不同的“分布式数据库”把它们分为五类并对其中OLAP场景的三类做概要分析第二部分结合NoSQL与NewSQL的差异纵向来谈谈OLTP场景“分布式数据库”实现方案的关键技术要点是前文的延伸也是分布式数据库专题文章的一个总纲其中的要点也都会单独撰文阐述。首先Ivan们从横向谈谈不同的“分布式数据库”一、万法同宗RDBMS1990年代开始关系型数据库RDBMS成为主流典型的产品包括Sybase、Oracle、DB2等同期大约也是国内IT产业的起步阶段。RDBMS的基本特征已有学术上的定义这里不再赘述。但从实际应用的角度看Ivan认为有两点最受关注内部以关系模型存储数据对外支持ANSI SQL接口支持事务管理ACID特性尤其是强一致性指事务内的修改要么全部失败要么全部成功不会出现中间状态。而后出现的各种“分布式数据库”大多都是在这两点上做权衡以交换其他方面的能力。“数据库”虽然有经典定义但很多大数据产品或许是为了标榜对传统数据库部分功能的替代作用也借用了“数据库”的名号导致在实践中这个概念被不断放大边界越来越模糊。本文一个目标是要厘清这些产品与经典数据库的差异与传承所以不妨先弱化“数据库”将其放大为“数据存储”。那么怎样才算是“分布式数据存储”系统“分布式”是一种架构风格用其实现“数据存储”最现实的目的是为了打开数据库产品的性能天花板并保证系统的高可靠进一步展开“分布式数据库”的必要条件有两点支持水平扩展保证高性能通过增加机器节点的方式提升系统整体处理能力摆脱对专用设备的依赖并且突破专用设备方案的性能上限。这里的机器节点通常是要支持X86服务器。廉价设备软件保证高可靠在单机可靠性较低的前提下依靠软件保证系统整体的高可靠又可以细分为“数据存储的高可靠”和“服务的高可靠”。总之任何单点的故障可能会带来短时间、局部的服务水平下降但不会影响系统整体的正常运转。将这两点作为“分布式数据库”的必要条件Ivan大致归纳了一下至少有五种不同的“分布式数据库”NoSQLNewSQLMPPHadoop技术生态Like-Mesa注也许有些同学会提到Kafka、Zookeeper等这些虽然也是分布式数据存储但因为具有鲜明的特点和适用场景无需再纳入“数据库”概念进行探讨。这五类中前两类以支持OLTP场景为主后三类则以OLAP场景为主。Ivan将按照时间线主要对OLAP场景下的三类进行概要分析。二、OLAP场景下的分布式数据库1990-2000年代随着应用系统广泛建设与深入使用数据规模越来越大国内银行业的“全国大集中”基本都是在这个阶段完成。这期间RDBMS得到了广泛运用Oracle也击败Sybase成为数据库领域的王者。在满足了基本的交易场景后数据得到了累积进一步的分析性需求自然就涌现了出来。单一数据库内同时支持联机交易和分析需求存在很多问题往往会造成对联机交易的干扰因此需要新的解决方案。这就为MPP崛起提供了机会。1. MPPMPPMassively Parallel Processing是指多个处理器或独立的计算机并行处理一组协同计算[1]。为了保证各节点的独立计算能力MPP数据库通常采用ShareNothing架构最为典型的产品是Teradata简称TD后来也出现Greenplum简称GPDB、Vertica、Netezza等竞争者。架构特点MPP是多机可水平扩展的架构符合“分布式”的基本要求其中TD采用外置集中存储而GPDB直接使用本地磁盘从这点来说GPDB是更彻底的Share Nothing架构。考虑到TD商业策略上采用一体机方案不具有开放性而GPDB具有较高的开源程度下文中通过分析后者架构特点来分析MPP工作机制。GPDB属于主从架构[2]Slave称为Segment是主要的数据加工节点是在PostgreSQL基础上的封装和修改天然具备事务处理的能力可进行水平扩展集群内有唯一Active状态的Master节点除了元数据存储和调度功能外同时承担一定的工作负载即所有外部对集群的数据联机访问都要经过Master节点。在高可靠设计方面首先设置了Standby Master节点在Master节点宕机时接管其任务其次将Segment节点则细分为两类不同角色Primary和Mirror后者是前者的备节点数据提交时在两者间进行强同步以此保证Primary宕机时Mirror可以被调度起来接替前者的任务。数据分析性需求对IT能力的要求包括复杂查询能力批量数据处理一定的并发访问能力。MPP较好的实现了对上述能力的支撑在前大数据时代得到了广泛的应用但这个时期的数据总量相对仍然有限普遍在TB级别对应的集群规模也通常在单集群百节点以下。随着数据价值关注度的不断提升越来越多的数据被纳入企业分析范围同时实际应用中考虑到数据存储和传输成本往往倾向于将数据集中在一个或少数几个集群中这样推动了集群规模的快速增长。在大规模集群几百至上千的使用上MPP从批处理和联机访问两个方面都显现了一些不足。以下内容主要借鉴了PivotalGPDB原厂的一篇官方博客[3]。注有位同学给出的译文也具有较好的质量推荐阅读[4]。缺陷批处理MPP架构下工作负载节点对GPDB而言是Segment节点是完全对称的数据均匀的存储在这些节点处理过程中每个节点即该节点上的Executor使用本地的CPU、内存和磁盘等资源完成本地的数据加工。这个架构虽然提供了较好的扩展性但隐藏了极大的问题——Straggler即当某个节点出现问题导致速度比其他节点慢时该节点会成为Straggler。此时无论集群规模多大批处理的整体执行速度都由Straggler决定其他节点上的任务执行完毕后则进入空闲状态等待Straggler而无法分担其工作。导致节点处理速度降低的原因多数是磁盘等硬件损坏考虑到磁盘本身的一定故障率根据Google统计前三个月内2%损坏率第二年时达到8%当集群规模达到一定程度时故障会频繁出现使straggler成为一个常规问题。并发由于MPP的“完全对称性”即当查询开始执行时每个节点都在并行的执行完全相同的任务这意味着MPP支持的并发数和集群的节点数完全无关。根据该文中的测试数据4个节点的集群和400个节点的集群支持的并发查询数是相同的随着并发数增加这二者几乎在相同的时点出现性能骤降。传统MPP的联机查询主要面向企业管理层的少数用户对并发能力的要求较低。而在大数据时代数据的使用者从战略管理层转向战术执行层乃至一线人员从孤立的分析场景转向与业务交易场景的融合。对于联机查询的并发能力已经远超MPP时代成为OLAP场景分布式数据库要考虑的一个重要问题。除上述两点以外GPDB架构中的Master节点承担了一定的工作负载所有联机查询的数据流都要经过该节点这样Master也存在一定的性能瓶颈。同时在实践中GPDB对数据库连接数量的管理也是非常谨慎的。在Ivan曾参与的项目中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等方案逐渐降低了访问延时。架构特点Hadoop生态体系下HDFS、Spark、Hive等组件已经有很多文章介绍本文不再赘述。总的来说其架构的着力点在于数据高吞吐处理能力在事务方面相较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操作效率上显著降低。据Ivan所知在很多企业实践中会将这种增量存储转换为全量存储带来大量数据冗余的同时也造成实施方法上的变更。联机查询并发能力不足对于联机查询场景最常见的是SQL on Hadoop方案将Impala、HAWQ等MPP引擎架设在HDFS基础上批量数据与联机查询共用一份数据。MPP引擎借鉴了MPP数据库的设计经验相对Hive等组件提供了更低的延迟。但存在一个与MPP相同的问题即并发能力不足。通过一些项目测试中Ivan发现在大体相同的数据量和查询逻辑情况下 Impala并发会低于GPDB。其原因可能是多方面的不排除存在一些调优空间但在系统架构层面也有值得探讨的内容。例如在元数据读取上Impala复用了Hive MetaStore但后者提供的访问服务延时相对较长这也限制了Impala的并发能力[7]。3. Like-MesaMesa是Google开发的近实时分析型数据仓库2014年发布了论文披露其设计思想[5]其通过预聚合合并Delta文件等方式减少查询的计算量提升了并发能力。Mesa充分利用了现有的Google技术组件使用BigTable来存储所有持久化的元数据使用了Colossus (Google的分布式文件系统)来存储数据文件使用MapReduce来处理连续的数据。Mesa相关的开源产品为Clickhouse[6]2016年Yandex开源和Palo[7]2017年百度开源。架构特点目前ClickHouse的资料仍以俄语社区为主为便于大家理解和进一步研究下面主要以Palo为例进行说明。Palo没有完全照搬Mesa的架构设计的思路其借助了Hadoop的批量处理能力但将加工结果导入到了Palo自身存储专注于联机查询场景在联机查询部分主要借鉴了Impala技术。同时Palo没有复用已有的分布式文件系统和类BigTable系统而是设计了独立的分布式存储引擎。虽然数据存储上付出了一定的冗余但在联机查询的低延迟、高并发两方面都得到了很大的改善。Palo在事务管理上与Hadoop体系类似数据更新的原子粒度最小为一个数据加载批次可以保证多表数据更新的一致性。整体架构由Frontend和Backend两部分组成查询编译、查询执行协调器和存储引擎目录管理被集成到Frontend查询执行器和数据存储被集成到Backend。Frontend负载较轻通常配置下几个节点即可满足要求而Backend作为工作负载节点会大幅扩展到几十至上百节点。数据处理部分与Mesa相同采用了物化Rollup上卷表的方式实现预计算。Palo和ClickHouse都宣称实现了MPP Data Warehouse但从架构上看已经与传统的MPP发生很大的变化几乎完全舍弃了批量处理专注于联机部分。ClickHouse和Palo作为较晚出现的开源项目还在进一步发展过程中设定的使用场景以广告业务时序数据分析为主存在一定局限性但值得持续关注。