tasktracker 和 jobtracker之间通过发送心跳信息通信,作为心跳信息的一部分,tasktraceker会通知jobtracker自己是否准备好执行新的task.
心跳信息中还包含:当map任务运行完后,map函数会与tasktracker通信,告知自己的状态;同时tasktracker在与jobtracker的心跳信息中,告诉jobtracker map任务运行完毕.这样jobtracker会保留map任务的信息,包含map输入的数据.这样在运行reduce任务时,可以知道从哪里读取相应的数据.
MapReduce 保证传给Reducer的输入都是按键排序的。系统执行排序的过程(将Map输出作为输入传给Reducer)的阶段称为shuffle。
每一个map任务有一个环形内存缓冲区(默认100M,配置项:io.sort.mb)用于存储任务输出.一旦缓冲内容达到阈值(默认80%,配置项:0.80),一个后台线程开始把数据溢出(spill)到磁盘.在溢出到磁盘的过程中,map任务会继续写到缓冲区.如果此时缓冲区被填满,map任务会被阻塞.
溢出写过程按照轮询方式将缓冲区的内容写到mapred.local.dir属性指定的路径中.溢出写之前,线程根据reduce数把将要写的数据分区.在每个分区中,后台线程按键进行内排序.
配置优化总的原则是shuffle过程应该有尽量多的内存.
对于map端的优化,原则是避免溢出写磁盘;对于reduce端的优化,原则是使尽量多的数据保存在内存中
由于各种原因(任务执行节点硬件老化,配置错误等),导致某一个task执行比job的平均进度慢,这时候hadoop会启动一个新的任务(duplicate task)原有任务和新任务哪个先执行完就把另外一个kill掉.
推测执行不能弥补程序逻辑中的问题.
推测执行是以牺牲集群效率为代价的,因此可能关闭推测执行,尤其是对于reduce任务.因为reduce任务需要获得map任务的输出,任何新的duplicate task都需要获得map任务的输入,这会增加集群的网络传输.
传统数据库中,采用写时模式,即在写入数据时,按照表结构进行检查,如果不符合模式,则不写入库中。写时模式在写入\加载数据时较慢,在查询数据时较快;同时可以采用各种手段来加快查询速度,如建索引等。
与此对应,HIVE采用读时模式,即在查询数据时按照表结构检查数据。这样加载数据较快,查询时因为需要检查数据是否合规,较慢。
Hive不支持更新和事务,支持索引。
索引种类分为两种,紧凑索引(compact)和位图索引(bitmap)。位图索引适用于较少取值可能的列,紧凑索引存储HDFS块号,而不是文件内偏移量。
Hive中有锁,粒度分为表级和分区级。