HBase详细介绍:起源、实现原理、系统架构

1.Hbase起源

 

HBase是一个开源的非关系型分布式数据库,它参考了谷歌的BigTable建模,实现的编程语言为Java。它是Apache软件基金会的Hadoop项目的一部分,运行于HDFS文件系统之上,为 Hadoop 提供类似于BigTable 规模的服务。因此,它可以容错地存储海量稀疏的数据。

HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库,是谷歌BigTable的开源实现,主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表,可以通过水平扩展的方式,利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表

1.1 关系数据库已经流行很多年,并且Hadoop已经有了HDFS和MapReduce,为什么需要HBase?

Hadoop可以很好地解决大规模数据的离线批量处理问题,但是,受限于HadoopMapReduce编程框架的高延迟数据处理机制,使得Hadoop无法满足大规模数据实时处理应用的需求。HDFS面向批量访问模式,不是随机访问模式。

传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不能很好解决)。

传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间。

1.2 HBase与传统的关系数据库的区别主要体现在以下几个方面:

1、数据类型:关系数据库采用关系模型,具有丰富的数据类型和存储方式,HBase则采用了更加简单的数据模型,它把数据存储为未经解释的字符串。

2、数据操作:关系数据库中包含了丰富的操作,其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,因为HBase在设计上就避免了复杂的表和表之间的关系。

3、存储模式:关系数据库是基于行模式存储的。HBase是基于列存储的,每个列族都由几个文件保存,不同列族的文件是分离的。

4、数据索引:关系数据库通常可以针对不同列构建复杂的多个索引,以提高数据访问性能。HBase只有一个索引——行键,通过巧妙的设计,HBase中的所有访问方法,或者通过行键访问,或者通过行键扫描,从而使得整个系统不会慢下来。

5、数据维护:在关系数据库中,更新操作会用最新的当前值去替换记录中原来的旧值,旧值被覆盖后就不会存在。而在HBase中执行更新操作时,并不会删除数据旧的版本,而是生成一个新的版本,旧有的版本仍然保留。

6、可伸缩性:关系数据库很难实现横向扩展,纵向扩展的空间也比较有限。相反,HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的,能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。

2.Hbase访问接口

3.Hbase数据模型

Hbase是一个稀疏、多维度、排序的映射表,这张表的索引是行键、列族、列限定符和时间戳。

每个值是一个未经解释的字符串,没有数据类型。用户在表中存储数据,每一行都有一个可排序的行键和任意多的列。

表在水平方向由一个或多个列族组成,一个列族中可以包含任意多个列,同一个列族里面的数据存储在一起。

列族支持动态扩展,可以很轻松地添加一个列族或列,无需预先定义列的数量以及类型,所有列均以字符串形式存储,用户需要自行进行数据类型转换。

HBase中执行更新操作时,并不会删除数据旧的版本,而是生成一个新的版本,旧的版本仍然保留(这是和HDFS只允许追加不允许修改的特性相关的)

下面对上图的一个具体解释:

表:HBase采用表来组织数据,表由行和列组成,列划分为若干列族。

行:每个HBase表都由若干行组成,每个行由行键(row key)来标识。

列族:一个HBase表被分组成许多“列族”(Column Family)的集合,它是基本的访问控制单元。

列限定符:列族里的数据通过限定符(或列)来定位。

单元格:在HBase表中,通过行、列族和列限定符确定一个“单元格”(cell),单元格中存储的数据没有数据类型,总被视为字节数组byte[]

时间戳:每个单元格都保存着同一份数据的多个版本,这些版本采用时间戳进行索引。

4.Hbase的实现原理

HBase的实现包括三个主要的功能组件:

1、库函数:链接到每个客户端

2、一个Master主服务器

3、许多个Region服务器

主服务器Master负责管理和维护Hbase表的分区信息,维护Region服务器列表,分配Region,负载均衡。

Region服务器负责存储和维护分配给自己的Region,处理来自客户端的读写请求。

客户端并不是直接从Master主服务器上读取数据,而是在获得Region的存储位置信息后,直接从Region服务器上读取数据。

客户端并不依赖Master,而是通过Zookeeper来Region位置信息,大多数客户端甚至从来不和Master通信,这种设计方式使得Master负载很小。

补充:

One:写数据流程

Two:读数据流程

1)Client 先访问 zookeeper,从 meta 表读取 region 的位置,然后读取 meta 表中的数据。meta中又存储了用户表的 region 信息;

2)根据 namespace、表名和 rowkey 在 meta 表中找到对应的 region 信息;

3)找到这个 region 对应的 regionserver;

4)查找对应的 region;

5)先从 MemStore 找数据,如果没有,再到 BlockCache 里面读;

6)BlockCache 还没有,再到 StoreFile 上读(为了读取的效率);

7)如果是从 StoreFile 里面读取的数据,不是直接返回给客户端,而是先写入 BlockCache,再返回给客户端。

https://img-blog.csdnimg.cn/20200403143124752.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMjA4ODUx,size_16,color_FFFFFF,t_70#pic_center

4.1表和Region

一个HBase表被划分成多个Region。

开始只有一个Region,后台不断分裂。Region拆分操作非常快,接近瞬间,因为拆分之后Region读取的仍然是原存储文件,直到“合并”过程把存储文件异步地写到独立的文件之后,才会读取新文件。

4.2Region的定位

元数据表,又名.META.表,存储了Region和Region服务器的映射关系。当HBase表很大时, .META.表也会被分裂成多个Region

根数据表,又名-ROOT-表,记录所有元数据的具体位置,-ROOT-表只有唯一一个Region,名字是在程序中被写死的。Zookeeper文件记录了-ROOT-表的位置

Hbase的三层结构图如下:

客户端访问数据时的“三级寻址”:

为了加速寻址,客户端会缓存位置信息,同时,需要解决缓存失效问题。

寻址过程客户端只需要询问Zookeeper服务器,不需要连接Master服务器。

补充:

Meta表:描述HBase表的表,元数据表。有了 Region 标识符,就可以唯一标识每个 Region。为了定位每个 Region 所在的位置,可以构建一张映射表。映射表的每个条目包含两项内容,一项是 Region 标识符,另一项是 Region 服务器标识。这个条目就表示 Region 和 Region 服务器之间的对应关系,从而就可以使用户知道某个 Region 存储在哪个 Region 服务器中。这个映射表包含了关于 Region 的元数据,因此也被称为“元数据表”,又名“Meta表”。使用 scan 命令可查看 Meta 表的结构,如图所示

Meta 表中的每一行记录了一个 Region 的信息。RowKey 包含表名、起始行键和时间戳信息,中间用逗号隔开,第一个 Region 的起始行键为空。时间戳之后用.隔开的为分区名称的编码字符串,该信息是由前面的表名、起始行键和时间戳进行字符串编码后形成的。

Meta 表里有一个列族 info。info 包含了三个列,分别为 Regioninfo、Server 和 Serverstartcode。Regionlnfo中记录了 Region 的详细信息,包括行键范围 StartKey 和 EndKey、列族列表和属性。

Server 记录了管理该 Region 的 Region 服务器的地址,如 localhost:16201。Serverstartcode 记录了 Region 服务器开始托管该 Region 的时间。

当用户表特别大时,用户表的 Region 也会非常多。Meta 表存储了这些 Region 信息,也变得非常大。Meta 表也需要划分成多个 Region,每个 Meta 分区记录一部分用户表和分区管理的情况。(有了meta表,就可以得到region和HRegionServer的对应关系,可以进行Region定位:客户端通过 ZooKeeper 获取 Meta 表(分区表)存储的地址,首先在对应的 Regionserver上获取 Meta 表的信息(meta表存在Regionserver上),得到所需的Region对应的Regionserver的信息,然后从Region 服务器上找到所需的数据)

4.3 数据 flush 过程

(上图中,一个Region中有两个store(两个列族),在flush的时候会往hdfs的不同datanode中写入。每一个列族中的列具有高的‘查询同时性’,不同列族中的列再一次查询中不同时查询,所以可以存放在hdfs的不同DataNode节点上)

1)当 MemStore 数据达到阈值(默认是 128M,老版本是 64M),将数据刷到硬盘,将内存中的数据删除,同时删除 HLog 中的历史数据;

2)并将数据存储到 HDFS 中;

3)在 HLog 中做标记点。

4.4 数据合并拆分过程

1)当数据块达到 4 块,Hmaster 触发合并操作,Region 将数据块加载到本地,进行合并;

2)当合并的数据超过 256M,进行拆分,将拆分后的 Region 分配给不同的 HregionServer管理(一个表中的region就会被不同的HRegionServer管理,分布式存储,高可用容灾);

3)当 HregionServer 宕机后,将 HregionServer 上的 hlog 拆分,然后分配给不同的 HregionServer加载,修改.META.;

4)注意:HLog 会同步到 HDFS。

memstore每次刷写都会生成一个新的HFile,且同一个数据({namespace:table,rowkey,column family:column}相同)的不同版本(timestamp)和不同类型的(put/delete)有可能会分布在不同的HFile中,所以查询时需要遍历所有的HFile。为了减少HFile的个数,以及清理掉过期和最后版本是(delete)的数据,会进行StoreFile Compaction合。StoreFile Compaction分为Minor Compaction和Major Compaction,前者Minor将邻近的若干个HFile合并成一个较大的HFile,但不会清理过期和删除的数据;后者Major将一个Store下的所有HFile合并成一个大的HFile,并且会清理掉过期和删除的数据。

5.Hbase系统架构

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组件组成,HBase依赖于ZooKeeper和HDFS

客户端

客户端包含访问Hbase的接口,同时在缓存中维护着已经访问过的Region位置信息,用来加快后续数据访问过程。

Zookeeper服务器

Zookeeper可以帮助选举出一个Master作为集群的总管,并保证在任何时刻总有唯一一个Master在运行,这就避免了Master的“单点失效”的问题。

HBase 通过 Zookeeper 来做 master 的高可用(通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行,如果 master 异常,会通过竞争机制产生新的 master 提供服务。)、RegionServer 的监控(通过 Zoopkeeper 来监控 RegionServer 的状态,当 RegionSevrer 有异常的时候,通过回调的形式通知 Master RegionServer 上下线的信息)、元数据的入口以及集群配置的维护等工作。(DML的请求通过ZK分发到HRegionServer不通过HMaster,HMaster是处理DDL的请求。HMaster宕机不会影响客户端的读写请求;但是如果进行create 'stu4','info'的DDL操作。当原有的Meta元数据信息改变时也无法维护。)

https://img-blog.csdnimg.cn/20200403182708427.png#pic_center

Master服务器

主服务器Master主要负责表和Region的管理工作:

管理用户对表的增加、删除、修改、查询等操作

实现不同Region服务器之间的负载均衡

在Region分裂或合并后,负责重新调整Region的分布

对发生故障失效的Region服务器上Region进行迁移

监控 RegionServer,为 RegionServer 分配 Region(维护整个集群的负载均衡,在空闲时间进行数据的负载均衡 ) ,维护集群的元数据信息,处理 region 的分配或转移(发现失效的 Region,并将失效的 Region 分配到正常的 RegionServer 上 ;当 RegionSever 失效的时候,协调对应 Hlog 的拆分)

Region服务器

Region服务器是Hbase中最核心的模块,负责维护分配给自己的Region,并响应用户的读写请求。

HregionServer 直接对接用户的读写请求,是真正的“干活”的节点。它的功能概括如下: 管理 master 为其分配的 Region,处理来自客户端的读写请求 ,负责和底层 HDFS 的交互(存储数据到 HDFS),负责 Region 变大以后的拆分,负责 Storefile 的合并工作 ,刷新缓存到HDFS,维护Hlog

5.1Region服务器工作原理

Region服务器向HDFS文件系统中读写数据过程:

1、用户读写数据过程

用户写入数据时,被分配到相应Region服务器去执行

用户数据首先被写入到MEMStore和Hlog中

只有当操作写入Hlog之后,commit()调用才会将其返回给客户端

当用户读取数据时,Region服务器首先访问MEMStore缓存,如果找不到,再去磁盘上面的StoreFile中寻找

2、缓存的刷新

系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中,清空缓存,并在Hlog里面写入一个标记

每次刷写都生成一个新的StoreFile文件,因此,每个Store包含多个StoreFile文件

每个Region服务器都有一个自己的HLog 文件,每次启动都检查该文件,确认最近一次执行缓存刷新操作之后是否发生新的写入操作;如果发现更新,则先写入MemStore,再刷写到StoreFile,最后删除旧的Hlog文件,开始为用户提供服务。

3、StoreFile的合并

每次刷写都生成一个新的StoreFile,数量太多,影响查找速度

调用Store.compact()把多个合并成一个

合并操作比较耗费资源,只有数量达到一个阈值才启动合并

补充:

Store :HFile 存储在 Store 中,一个 Store 对应 HBase 表中的一个列族。

HFile :这是在磁盘上保存原始数据的实际的物理文件,是实际的存储文件。StoreFile 是以 Hfile的形式存储在 HDFS 的。

Block Cache:缓存磁盘中的数据(磁盘慢)(仅仅放内存中的数据,不放内存中的数据)。当读取stu3,1001,info:name的时候,如果Block Cache没有,同时读取内存和磁盘中的数据(将磁盘的数据放到block Cache,LRU原理,缓存淘汰),然后将merge(内存读取,磁盘读取)的结果返回。下图中,zhangsan在磁盘中(手动刷入),时间戳t1;lisi在内存中(默认等到一定大小或时间),时间戳t2,且t1>t2。如果是读取内存而不读取磁盘,得到的应该是lisi。而HBase通过上述的方式返回时间戳最大的那一条数据,为zhangsan。(读比写慢)

https://img-blog.csdnimg.cn/20200403140021404.png#pic_center

HDFS

为 Hbase 提供最终的底层数据存储服务,同时为HBase 提供高可用(Hlog 存储在HDFS)的支持,具体功能概括如下:提供元数据和表数据的底层分布式存储服务,保证的高可靠和高可用性 (数据多副本)

MemStore

内存缓存,达到一定缓存大小或者时间节点触发一次 flush,文件系统中生成新的 HFile,每次 Flush 的最小单位是 Region。每个 Column family 维护一个 MemStore。

Write-Ahead logs(WAL,Hlog)

用来容灾。当对 HBase 写数据的时候,数据会在内存MemStore中保留一段时间,MemStore达到一定的数据量(时间以及数据量阈值可以设定),数据再写进磁盘。但把数据保存在内存中可能有更高的概率引起数据丢失,为了解决这个问题,数据会先写在一个叫做 Write-Ahead logfile 的文件中,然后再写入内存中,所以在系统出现故障的时候,数据可以通过这个日志文件重建。

Region

Hbase表的分片,HBase 表会根据 RowKey 值被切分成不同的 region 存储在 RegionServer中,在一个 RegionServer 中可以有多个不同的 region。同一个行键的 Region 不会被拆分到多个 Region 服务器上。 一个HBase表被划分成多个Region,开始只有一个Region,后台不断分裂。

一个表中包含多个列族,一个列族一个文件存储,region的切分是横向切分的,那么包含了多个列族。

6.在Hbase之上构建SQL引擎

NoSQL区别于关系型数据库的一点就是NoSQL不使用SQL作为查询语言,至于为何在NoSQL数据存储HBase上提供SQL接口,有如下原因:

1、易使用。使用诸如SQL这样易于理解的语言,使人们能够更加轻松地使用Hasee。

2、减少编码。使用诸如SQL这样更高层次的语言来编写,减少了编写的代码量。

解决方案:Hive整合HBase

Hive与HBase的整合功能从Hive0.6.0版本已经开始出现,利用两者对外的API接口互相通信,通信主要依靠hive_hbase-handler.jar工具包(HiveStorage Handlers)。由于HBase有一次比较大的版本变动,所以并不是每个版本的Hive都能和现有的HBase版本进行整合,所以在使用过程中特别注意的就是两者版本的一致性。

7.构建Hbase二级索引

HBase只有一个针对行键的索引,访问Hbase表中的行,只有三种方式:

1) 通过单个Rowkey访问,即按照某个Rowkey键值进行get操作,这样获取唯一一条记录;

2) 通过Rowkey的range进行scan,即通过设置startRowKey和endRowKey,在这个范围内进行扫描。这样可以按指定的条件获取一批记录;

3) 全表扫描,即直接扫描整张表中所有行记录。

注:由于row key默认按照字典顺序升序排序,按照row key检索的效率很高

使用其他产品为Hbase行键提供索引功能:

Hindex二级索引

Hbase+Redis

Hbase+solr

8.扩展

META是什么东东?

META是一种思想概念,一种抽象思维,用来描述数据的数据,比如有一张学生表,记录着学生的基本信息,我们通过表可以获取学生信息(数据),但是有时候也要得到表本身的信息数据(比如表结构信息:字段名称,字段数据类型,长度等信息),对于这种基础信息的描述,就会使用META的概念,使用META元数据来描述表本身。放到HTML中也是一样的,HTML用来描述网页信息,但是HTML自己也有一些信息(比如网页标题,网页描述,搜索关键字),这些信息也就称之为HTML META信息,并且HTML也定义了专门的META标签。

列族是如何进行动态扩展的?

一个列族中的所有列是保存在同一个文件的(多了会分region),当有新的列族时,在一个新的文件中存储新的列族。某keyrow如果在这个列族中有相应的列的信息,则新文件中存储rowkey和列信息,没有的话不存储(而不是null值)。

为什么不建议用多个列族?

https://img-blog.csdnimg.cn/2020040320502416.png#pic_center

一个列族就对应一个store,当一个表中有多个列族时,这个表拆分后的一个Region中就会有多个Store文件。如果在一些Region中有大量的数据(存着那个列族中的列的数据),而剩下的Region仅有少量的数据,那么就会生成多个的小文件。当查询rowkey的数据时,会找到某个Region,然后在那个Region中需要扫描所有的Store中的文件(有多少个列族就有多少个Store)造成效率低。当使用多个列族时,需要每个列族中的列的数据的量差不多。

展开阅读全文

hive真是垃圾,处理从hbase映射的hive外表时因hbase数据量巨大总是跑崩。

05-06
hadoop集群三节点 centos7.5系统 4核 16G内存 <br> hbase表大概有七千万条数据 <br> hive建外表映射hbase表 ``` create external table worked_data_o( key String,province String,city String,code String,acc_number String,tel String,wd_date String,rep_disorder String,overtime String,receipt String,descr String,exp_empid String,fault_1 String,fault_2 String,fault_type String,acs_way String, address String) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES("hbase.columns.mapping"=":key,data:province,data:city,data:code,data:account,data:tel,data: date,data:rep_disorder,data:overtime,data:receipt,data:emp_descr,data:emp_id,data:fault_name,data:fault_desc r,data:fault_type,data:acs_way,data:address") TBLPROPERTIES("hbase.table.name"="worked_data"); ``` 对hive外表进行数据处理放入新表 ``` create table customer_intention as ( select wd.acc_number as acc_number,if(wd.descr='客户不满' OR wd.descr='客户不配合',2,IF(wd.descr='客户不听解释' OR wd.descr='客户情绪激动',4,IF(wd.descr='客户有投诉意向',6,IF(wd.descr='客户有强烈投诉意向',8,1)))) AS mood From worked_data_o as wd); ``` 报错: ``` WARNING: Hive-on-MR is deprecated in Hive 2 and may not be available in the future versions. Consider using a different execution engine (i.e. spark, tez) or using Hive 1.X releases. Query ID = zkpk_20190506095541_4af46dd8-bf98-4a0e-b0b4-d7ed2974ab7b Total jobs = 1 Launching Job 1 out of 1 Number of reduce tasks determined at compile time: 1 In order to change the average load for a reducer (in bytes): set hive.exec.reducers.bytes.per.reducer=<number> In order to limit the maximum number of reducers: set hive.exec.reducers.max=<number> In order to set a constant number of reducers: set mapreduce.job.reduces=<number> Starting Job = job_1556796305355_0016, Tracking URL = http://master:8088/proxy/application_1556796305355_0016/ Kill Command = /home/zkpk/hadoop-2.7.2/bin/hadoop job -kill job_1556796305355_0016 Hadoop job information for Stage-1: number of mappers: 8; number of reducers: 1 2019-05-06 09:55:54,098 Stage-1 map = 0%, reduce = 0% 2019-05-06 09:56:54,965 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 149.84 sec 2019-05-06 09:57:55,903 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 212.38 sec 2019-05-06 09:58:56,456 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 09:59:57,079 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:00:57,760 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:01:58,363 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:02:58,965 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:03:59,598 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:05:00,223 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:06:00,843 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:07:01,478 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:08:02,204 Stage-1 map = 0%, reduce = 0%, Cumulative CPU 266.3 sec 2019-05-06 10:09:02,871 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:10:02,902 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:11:03,408 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:12:04,032 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:13:04,624 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:14:05,247 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:15:05,844 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:16:06,468 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:17:07,159 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:18:07,762 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:19:08,330 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:20:08,556 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:21:09,202 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:22:09,765 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:23:10,416 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:24:10,989 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:25:11,574 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:26:12,113 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:27:12,720 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:28:13,333 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:29:13,919 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:30:14,194 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:31:14,707 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:32:15,303 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:33:15,933 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:34:16,503 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:35:17,051 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:36:17,718 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:37:18,231 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:38:18,866 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:39:19,420 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:40:19,987 Stage-1 map = 0%, reduce = 0% 2019-05-06 10:40:23,058 Stage-1 map = 100%, reduce = 100% MapReduce Total cumulative CPU time: 4 minutes 26 seconds 300 msec Ended Job = job_1556796305355_0016 with errors Error during job, obtaining debugging information... Examining task ID: task_1556796305355_0016_m_000006 (and more) from job job_1556796305355_0016 Examining task ID: task_1556796305355_0016_m_000002 (and more) from job job_1556796305355_0016 Examining task ID: task_1556796305355_0016_m_000000 (and more) from job job_1556796305355_0016 Task with the most failures(4): ----- Task ID: task_1556796305355_0016_m_000004 URL: http://master:8088/taskdetails.jsp?jobid=job_1556796305355_0016&tipid=task_1556796305355_0016_m_000004 ----- Diagnostic Messages for this Task: AttemptID:attempt_1556796305355_0016_m_000004_3 Timed out after 600 secs FAILED: Execution Error, return code 2 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask MapReduce Jobs Launched: Stage-Stage-1: Map: 8 Reduce: 1 Cumulative CPU: 266.3 sec HDFS Read: 0 HDFS Write: 0 FAIL Total MapReduce CPU Time Spent: 4 minutes 26 seconds 300 msec ``` 大佬们求解决方法
©️2020 CSDN 皮肤主题: 像素格子 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值