Hadoop理论篇

最新推荐文章于 2024-08-27 09:43:06 发布

weixin_33728268

最新推荐文章于 2024-08-27 09:43:06 发布

阅读量290

点赞数

文章标签：数据库运维大数据

原文链接：https://my.oschina.net/niuruijing/blog/1523377

版权

2019独角兽企业重金招聘Python工程师标准>>>

来源

当时Google有大数据的三大基础：MapReduce、BigTable、GFS，但是没有开源，于是就有模仿Google大数据实现的Hadoop，已开源。

Hadoop：开源的分布式存储+分布式计算平台

一个分布式系统基础架构，由Apache基金会所开发。

用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。

Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。

Hadoop的框架最核心的设计就是：HDFS和MapReduce.HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。

主要作用：搭建大型数据仓库，PB级数据的存储、处理、分析、统计等业务。

例如：搜索引擎、日志分析、商业智能、数据挖掘等。

HDFS：分布式文件系统，存储海量数据

概念

Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。

HDFS的优缺点

优点

1.处理超大文件

这里的超大文件通常是指百MB、甚至数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

2.保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。

3.运行于廉价的商用机器集群上

Hadoop设计对应急需求比较低，只须运行在低廉的商用硬件集群上，而无需在昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。HDFS遇到了上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
4.流式的访问数据

HDFS的设计建立在“一次写入、多次读写”任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

缺点

1、不适合低延迟数据访问

如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。

改进策略：对于那些有低延时要求的应用程序，HBase是一个更好的选择，通过上层数据管理项目尽可能地弥补这个不足。在性能上有了很大的提升，它的口号是goes real time。使用缓存或多个master设计可以降低Clinet的数据请求压力，以减少延时。

2、无法高效存储大量的小文件

因为NameNode把文件系统的元数据放置在内存中，所有文件系统所能容纳的文件数目是由NameNode的内存大小来决定。还有一个问题就是，因为MapTask的数量是由Splits来决定的，所以用MR处理大量的小文件时，就会产生过多的MapTask，线程管理开销将会增加作业时间。当Hadoop处理很多小文件(文件大小小于HDFS中Block大小)的时候，由于FileInputFormat不会对小文件进行划分，所以每一个小文件都会被当做一个Split并分配一个Map任务，导致效率底下。

例如：一个1G的文件，会被划分成16个64MB的Split，并分配16个Map任务处理，而10000个100Kb的文件会被10000个Map任务处理。

改进策略：要想让HDFS能处理好小文件，有不少方法。利用SequenceFile、MapFile、Har等方式归档小文件，这个方法的原理就是把小文件归档起来管理，HBase就是基于此的。

3、不支持多用户写入及任意修改文件

在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作，目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

MapReduce：并行处理框架，实现任务分解和调度

Hadoop Hive: 数据仓库

Hive在Hadoop中扮演数据仓库的角色。Hive添加数据的结构在HDFS（hivesuperimposes structure on data in HDFS），并允许使用类似于SQL语法进行数据查询。

不支持更改数据的操作，Hive基于数据仓库，提供静态数据的动态查询。其使用类SQL语言，底层经过编译转为MapReduce程序，在Hadoop上运行，数据存储在HDFS上。简单来说：写一条sql语句，将sql语句转化为一个Hadoop任务，降低了使用Hadoop的门槛。

HBASE：一个分布式的、面向列的开源数据库

Hbase是Hadoop database，即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。

HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据。

Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

与HDFS不同的是：HBASE提供数据的随机读写和和实时访问，实现对数据表的读写功能。

ZooKeeper：一个针对大型分布式系统的可靠协调系统

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，包含一个简单的原语集，是Hadoop和Hbase的重要组件。提供Java和C的接口。

提供的功能包括：配置维护、名字服务、分布式同步、组服务等

目标：封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

作用：

监控Hadoop集群里每个节点的状态；

管理整个集群的配置；

维护节点间数据的一致性；

HBASE与Mongodb的区别

1.Mongodb bson文档型数据库，整个数据都存在磁盘中，hbase是列式数据库，集群部署时每个familycolumn保存在单独的hdfs文件中。

2.Mongodb 主键是“_id”,主键上面可以不建索引,记录插入的顺序和存放的顺序一样，hbase的主键就是row key，可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。
字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。

3.Mongodb支持二级索引，而hbase本身不支持二级索引

4.Mongodb支持集合查找，正则查找，范围查找，支持skip和limit等等，是最像mysql的nosql数据库，而hbase只支持三种查找：通过单个row key访问，通过row key的range，全表扫描

5.mongodb的update是update-in-place，也就是原地更新，除非原地容纳不下更新后的数据记录。而hbase的修改和添加都是同一个命令：put，如果put传入的row key已经存在就更新原记录,实际上hbase内部也不是更新，它只是将这一份数据已不同的版本保存下来而已，hbase默认的保存版本的历史数量是3。

6.mongodb的delete会将该行的数据标示为已删除，因为mongodb在删除记录时并不是真把记录从内存或文件中remove，而是将该删除记录数据置空（写0或特殊数字加以标识）同时将该记录所在地址放到一个list列表“释放列表”中，这样做的好就是就是如果有用户要执行插入记录操作时，mongodb会首先从该“释放列表”中获取size合适的“已删除记录”地址返回，这种方法会提升性能（避免了malloc内存操作），同时mongodb也使用了bucket size数组来定义多个大小size不同的列表，用于将要删除的记录根据其size大小放到合适的“释放列表”中。Hbase的delete是先新建一个tombstonemarkers，然后读的时候会和tombstonemarkers做merge，在发生major compaction时delete的数据记录才会真真删除。

7.mongodb和hbase都支持mapreduce，不过mongodb的mapreduce支持不够强大，如果没有使用mongodb分片，mapreduce实际上不是并行执行的

8.mongodb支持shard分片，hbase根据row key自动负载均衡，这里shard key和row key的选取尽量用非递增的字段，尽量用分布均衡的字段，因为分片都是根据范围来选择对应的存取server的，如果用递增字段很容易热点server的产生，由于是根据key的范围来自动分片的，如果key分布不均衡就会导致有些key根本就没法切分，从而产生负载不均衡。

9.mongodb的读效率比写高，hbase默认适合写多读少的情况，可以通过hfile.block.cache.size配置，该配置storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。如果写比读少很多，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认0.2吧。设置这个值的时候，你同时要参考hbase.regionserver.global.memstore.upperLimit，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。

10.hbase采用的LSM思想(Log-Structured Merge-Tree)，就是将对数据的更改hold在内存中，达到指定的threadhold后将该批更改merge后批量写入到磁盘，这样将单个写变成了批量写，大大提高了写入速度，不过这样的话读的时候就费劲了，需要merge disk上的数据和memory中的修改数据，这显然降低了读的性能。mongodb采用的是mapfile+Journal思想，如果记录不在内存，先加载到内存，然后在内存中更改后记录日志，然后隔一段时间批量的写入data文件，这样对内存的要求较高，至少需要容纳下热点数据和索引。

MapReduce和Spark

Spark概念

Apache Spark开发人员声称它是“一种用于数据大规模处理的快速通用引擎”。相比之下，如果说Hadoop的大数据框架好比是800磅重的大猩猩，Spark就好比是130磅重的猎豹。

相比MapReduce基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容。实际上，在Hadoop的项目页面上，Spark就被列为是一个模块。

Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和基于机器的学习。

Spark有自己的页面，因为虽然它可以通过YARN(另一种资源协调者)在Hadoop集群中运行，但是它也有一种独立模式。它可以作为 Hadoop模块来运行，也可以作为独立解决方案来运行;这样一来，很难直接比较两者。

Spark是一种集群计算框架，这意味着它更多地与MapReduce竞争，而不是与整个Hadoop生态系统竞争。比如说，Spark没有自己的分布式文件系统，但可以使用HDFS。

Spark使用内存，也可以使用磁盘进行处理，而MapReduce完全基于磁盘。MapReduce和Spark的主要区别在于，MapReduce使用持久存储，而Spark使用弹性分布式数据集(RDDS)，下面容错部分有更详细的解释。

性能

网上不缺关于Spark与MapReduce相比有多快的信息。对两者进行比较有个问题，那就是它们处理数据的方式不一样，数据处理部分有介绍。Spark之所以如此快速，原因在于它在内存中处理一切数据。没错，它还可以使用磁盘来处理未全部装入到内存中的数据。

Spark的内存处理为来自多个来源的数据提供了近乎实时分析的功能：营销活动、机器学习、物联网传感器、日志监控、安全分析和社交媒体网站。另外，MapReduce使用批量处理，其实从来就不是为惊人的速度设计的。它的初衷是不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。

易用性

众所周知，Spark以性能见长，但是它也因易用性而小有名气，原因是它随带易于使用的API，支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，所以几乎不需要经历一番学习，马上可以上手。

Spark还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapReduce没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapReduce来得容易一点。

成本

MapReduce和Spark都是Apache项目，这意味着它们是开源免费软件产品。虽然软件不需要成本，但是派人用硬件运行任何一种平台带来了成本。这两种产品都设计成可以在商用硬件上运行，比如所谓的低成本白盒服务器系统。

MapReduce和Spark在同样的硬件上运行，那么这两种解决方案的成本差异体现在哪里?MapReduce使用常规数量的内存，因为数据处理基于磁盘，所以公司得购买速度更快的磁盘和大量磁盘空间来运行MapReduce。MapReduce还需要更多的系统，将磁盘输入/输出分布到多个系统上。

Spark需要大量内存，但是可以使用常规数量的常规转速磁盘。一些用户抱怨会产生临时文件，需要清理。这些临时文件通常保存7天，以便加快针对同一数据集的任何处理。磁盘空间相对便宜，由于Spark不使用磁盘输入/输入用于处理，已使用的磁盘空间可以用于SAN或NAS。

然而，由于需要大量内存在内存中处理一切数据，Spark系统的成本更高，这点没错。但是Spark的技术同时减少了所需的系统数量。所以，最后的情形是，系统成本较高，但是数量大大减少。也许到时候，Spark实际上可以降低每个计算单位的成本，尽管内存方面有额外的要求。

举例说明，“Spark已证明在数据多达PB的情况下也轻松自如。它被用于在数量只有十分之一的机器上，对100TB数据进行排序的速度比Hadoop MapReduce快3倍。”这一成绩让Spark成为2014年Daytona GraySort基准。

兼容性

MapReduce和Spark相互兼容;MapReduce通过JDBC和ODC兼容诸多数据源、文件格式和商业智能工具，Spark具有与MapReduce同样的兼容性。

数据处理

MapReduce是一种批量处理引擎。MapReduce以顺序步骤来操作，先从集群读取数据，然后对数据执行操作，将结果写回到集群，从集群读取更新后的数据，执行下一个数据操作，将那些结果写回到结果，依次类推。Spark执行类似的操作，不过是在内存中一步执行。它从集群读取数据后，对数据执行操作，然后写回到集群。

Spark还包括自己的图形计算库GraphX。GraphX让用户可以查看与图形和集合同样的数据。用户还可以使用弹性分布式数据集(RDD)，改变和联合图形，容错部分作了讨论。

容错

至于容错，MapReduce和Spark从两个不同的方向来解决问题。MapReduce使用TaskTracker节点，它为 JobTracker节点提供了心跳(heartbeat)。如果没有心跳，那么JobTracker节点重新调度所有将执行的操作和正在进行的操作，交给另一个TaskTracker节点。这种方法在提供容错性方面很有效，可是会大大延长某些操作(即便只有一个故障)的完成时间。

Spark使用弹性分布式数据集(RDD)，它们是容错集合，里面的数据元素可执行并行操作。RDD可以引用外部存储系统中的数据集，比如共享式文件系统、HDFS、HBase，或者提供Hadoop InputFormat的任何数据源。Spark可以用Hadoop支持的任何存储源创建RDD，包括本地文件系统，或前面所列的其中一种文件系统。

RDD拥有五个主要属性：