从架构特点到功能缺陷，重新认识分析型分布式数据库
|
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机制是相同的。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
