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