查看: 200|回复: 0

从架构特点到功能缺陷,重新认识分析型分布式数据库

[复制链接]

该用户从未签到

发表于 2019-11-7 18:50:45 | 显示全部楼层 |阅读模式
写在前面

本文是分布式数据库的总纲文章的第一部分,主要探究分析性分布式数据库的发展和技术差异;第二部分则是交易性数据库的一些关键特性分析。Ivan开始计划的分布式数据库是不含分析场景的,所以严格来说本篇算是番外篇,后续待条件具备将以独立主题的方式展开。
特殊阐明:本文是原创文章,首发在DBAplus社群,转载须得到作者同意。
正文

随着大规模互联网应用的广泛出现,分布式数据库成为近两年的一个热门话题。同样,在银行业主推X86限制主机与小型机的背景下,传统的单机数据库逐渐出现了一些瓶颈,马上碰面临是否引入分布式数据库的问题。
近期,Ivan在个人公众号就“银行引入分布式数据库的必要性”做过一些展望,并收到了一些朋友的反馈,除了对分布式数据库具体技术探究外,还有一类很有趣的建议,“能不能也讲讲Teradata、Greenplum这类MPP,这些也是分布式数据库,但老板总是认为OLTP场景下的才算数”。
的确,为相识决OLAP场景需求,实在很早就出现了分布式架构的产品和解决方案,其与如今的OLTP方案有许多共通的地方。而且Ivan相信,以后OLAP和OLTP两个分支技术的发展也必然是交错前行,可以相互鉴戒的。
鉴于此,本文会将OLAP类场景的分布式数据也纳入进来,从两个维度对“分布式数据库”进行拆解,第一部分会横向谈谈不同的“分布式数据库”,把它们分为五类并对其中OLAP场景的三类做概要分析;第二部分结合NoSQL与NewSQL的差异,纵向来谈谈OLTP场景“分布式数据库”实现方案的关键技术要点,是前文的延伸,也是分布式数据库专题文章的一个总纲,其中的要点也都会单独撰文论述。
起首,Ivan们从横向谈谈不同的“分布式数据库”:
一、万法同宗RDBMS

1990年代开始,关系型数据库(RDBMS)成为主流,典范的产品包括Sybase、Oracle、DB2等,同期大约也是国内IT财产的起步阶段。RDBMS的根本特征已有学术上的定义,这里不再赘述。
但从实际应用的角度看,Ivan认为有两点最受关注:

  • 内部以关系模型存储数据,对外支持ANSI SQL接口;
  • 支持事务管理ACID特性,尤其是强一致性(指事务内的修改要么全部失败要么全部乐成,不会出现中间状态)。
而后出现的各种“分布式数据库”,大多都是在这两点上做权衡以交换其他方面的能力。
“数据库”固然有经典定义,但许多大数据产品或许是为了标榜对传统数据库部分功能的替代作用,也借用了“数据库”的名号,导致在实践中这个概念被不断放大,边界越来越模糊。本文一个目标是要厘清这些产品与经典数据库的差异与传承,所以不妨先弱化“数据库”,将其放大为“数据存储”。
那么怎样才算是“分布式数据存储”系统
“分布式”是一种架构风格,用实在现“数据存储”,最现实的目标是为了打开数据库产品的性能天花板,并保证系统的高可靠,进一步展开,“分布式数据库”的必要条件有两点:

  • 支持程度扩展,保证高性能
通过增加机器节点的方式提拔系统整体处置处罚能力,摆脱对专用设备的依赖,而且突破专用设备方案的性能上限。这里的机器节点,通常是要支持X86服务器

  • 廉价设备+软件,保证高可靠
在单机可靠性较低的前提下,依靠软件保证系统整体的高可靠,又可以细分为“数据存储的高可靠”和“服务的高可靠”。总之,任何单点的故障,可能会带来短时间、局部的服务程度降落,但不会影响系统整体的正常运转。
将这两点作为“分布式数据库”的必要条件,Ivan大抵归纳了一下,至少有五种不同的“分布式数据库”:

  • NoSQL
  • NewSQL
  • MPP
  • Hadoop技术生态
  • Like-Mesa
注:也许有些同学会提到Kafka、Zookeeper等,这些固然也是分布式数据存储,但因为具有鲜明的特点和实用场景,无需再纳入“数据库”概念进行探究。
这五类中,前两类以支持OLTP场景为主,后三类则以OLAP场景为主。Ivan将按照时间线,主要对OLAP场景下的三类进行概要分析。
二、OLAP场景下的分布式数据库

1990-2000年代,随着应用系统广泛建设与深入使用,数据规模越来越大,国内银行业的“全国大集中”根本都是在这个阶段完成。这期间,RDBMS得到了广泛运用,Oracle也击败Sybase成为数据库范畴的王者。
在满足了根本的交易场景后,数据得到了累积,进一步的分析性需求自然就涌现了出来。单一数据库内同时支持联机交易和分析需求存在许多问题,每每会造成对联机交易的干扰,因此需要新的解决方案。这就为MPP崛起提供了时机。
1. MPP

MPP(Massively 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从批处置处罚和联机访问两个方面都显现了一些不敷。以下内容主要鉴戒了Pivotal(GPDB原厂)的一篇官方博客[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-Mesa

Mesa是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作为较晚出现的开源项目,还在进一步发展过程中,设定的使用场景以广告业务时序数据分析为主,存在一定局限性,但值得持续关注。
文献参考:
[1] http://en.wikipedia.org/wiki/Massively_parallel
[2] http://greenplum.org/gpdb-sandbox-tutorials/introduction-greenplum-database-architecture/#ffs-tabbed-11
[3] Apache HAWQ: Next Step In Massively Parallel Processing,
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 and et al., “Mesa: Geo-replicated, near real-time, scalabledata warehousing,”PVLDB, vol. 7, no. 12, pp. 1259–1270, 2014.
[6] http://clickhouse.yandex
[7] http://github.com/baidu/palo

相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表