Hadoop

日志

Hadoop NameNode 高可用架构

NameNode是HDFS（hadoop分布式文件系统）的核心组件，在hadoop 1.x中NameNode存在SPOF（单点故障）问题，NameNode存储了HDFS的元数据信息，一旦NameNode宕机那么整个HDFS就无法访问，依赖HDFS的服务也会被波及（HBase、Hive…）同样无法访问，整个集群陷入瘫痪。NameNode的单点故障问题也使得Hadoop在1.x时代一直都只能用作离线存储和离线计算，无法满足对高可用要求很高的应用场景。Hadoop2.x针对NameNode的SPOF问题提出了高可用架构方案（HA），目前已经能在生产环境下应用。本文主要介绍该高可用架构的主备切换机制。

一、NameNode高可用架构

Hadoop NameNode高可用架构

Hadoop NameNode高可用架构

二、组件概述

Active NameNode 与 Standby NameNode

在NameNode的HA方案中有两个不同状态的NameNode，分别为活跃态（Active）和后备态（Standby），其中只有Active NameNode能对外提供服务，Standby NameNode会根据Active NameNode的状态变化，在必要时可切换成Active.

ZKFC

ZKFC即ZKFailoverController，是基于Zookeeper的故障转移控制器，它负责控制NameNode的主备切换，ZKFC会监测NameNode的健康状态，当发现Active NameNode出现异常时会通过Zookeeper进行一次新的选举，完成Active和Standby状态的切换

HealthMonitor

阅读全文 →

日志

Hadoop之YARN/MRv2

YARN又称为Mapreduce version 2（MRv2）是hadoop2.x的新架构，它将旧Hadoop Mapreduce框架中的JobTracker的资源管理和作业生命周期管理拆分成两个组件即ResourceManager(RM)和ApplicationMaster(AM)

一、为何需要MRv2？

mr1vsmr2

MRv1与MRv2对比

MRv1资源管理问题

  1. Hadoop1.0引入了“slot”的概念，每个slot代表了各个节点上的一份资源（CPU、内存等），MRv1把Map和Reduce的资源单独区分，即Map slot、Reduce slot，两个阶段的slot不能共享，这意味着资源的利用率大大降低
  2. 非MR应用不能分享资源，所以只能运行MR计算框架的应用
  3. 每个集群只有一个JobTracker,限制了集群的扩展，集群规模限制在4000个节点左右

MRv2资源管理方案

  1. 舍弃“slot”的概念，每个节点以“资源”（CPU、内存等）为单位分配给有需要的应用
  2. 支持运行MR应用和非MR应用
  3. JobTracker的大量功能被迁移到ApplicationMaster（AM），集群内可以存在多个AM（每个应用程序都拥有一个独立的AM），集群可以扩展到上万个节点

二、YARN架构

YARN_Architecture

YARN架构图(via Apache Hadoop)

资源管理器（ResourceManager，RM）

ResourceManager运行在主节点（Master）上，负责全局资源调度(分配/回收)，处理各个应用的资源请求，ResourceManager由调度器（Scheduler）和应用管理器（ApplicationsManager， AsM）组成

  • 调度器（Scheduler）
    调度器根据资源调度策略（例如Capacity Scheduler、Fair Scheduler），将包含适当资源（CPU、内存等）的资源容器（Container）分配给相应的节点，应用程序的各个任务均在容器内执行，且只能使用容器分配到的资源.调度器只负责资源调度，不关心应用的执行状态.
    阅读全文 →
日志

Hadoop之HDFS（NameNode、DataNode、SecondaryNameNode）

HDFS（hadoop分布式文件系统）是Hadoop的核心组成部分，HDFS采用master/slave架构，一个HDFS集群由一个NameNode（不考虑HA/Federation）和多个DataNode组成

hdfs架构

HDFS架构图（via Apache Hadoop）

一、NameNode

  • NameNode是HDFS的中心，也称作Master
  • NameNode只保存HDFS的元数据，负责管理HDFS的命名空间（namespace）和控制文件的访问操作
  • NameNode不保存任何实际的数据或数据集，真正的数据由DataNode负责存储
  • NameNode拥有HDFS内所有文件的数据块（blocks）列表及其位置，因而NameNode能通过这些数据块信息来重构对应的文件
  • NameNode是HDFS的核心，一旦NameNode挂了，整个集群将无法访问
  • NameNode具有单点故障问题（Hadoop2之后可以通过High Available方案解决）
  • NameNode需要配置相对较多的内存（相比DataNode而言），因为NameNode会把HDFS的命名空间和文件数据块映射（Blockmap）保存在内存中，这也意味着集群的横向扩展受到NameNode的限制，因为集群增长到一定的规模后NameNode需要的内存也会更大，另外由于所有的元数据操作都需要通过NameNode进行，这意味着集群的性能受到NameNode的限制（Hadoop2之后可以通过Federation方案解决）
  • NameNode有两个核心的数据结构，FsImage和EditsLog，FsImage是HDFS命名空间、文件数据块映射、文件属性等信息的镜像，EditsLog相当于一个日志文件，它记录了对HDFS元数据进行修改的所有事务操作，当NameNode启动时会首先合并FsImage和EditsLog，得到HDFS的最新状态然后写入FsImage镜像文件中，并使用一个新的EditsLog文件进行记录

SecondaryNameNode

“SecondaryNamenode”这个名字具有误导性，它不能和DataNode交互，更不能替代NameNode，相反它是用来弥补NameNode的一些缺点，由于NameNode启动时会合并FsImage和EditsLog，但随着集群的运行时间变长，EditsLog会变得非常庞大，这意味着下一次启动需要花很长的时间来进行合并操作.

SecondaryNameNode负责解决以上的问题
阅读全文 →

日志

大数据的技术生态圈

本文来源知乎一个题为“如何用形象的比喻描述大数据的技术生态？”的精彩回答

大数据本身是个很宽泛的概念，Hadoop生态圈（或者泛生态圈）基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。

大数据，首先你要能存的下大数据

传统的文件系统是单机的，不能横跨不同的机器。HDFS（Hadoop Distributed FileSystem）的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。

存的下数据之后，你就开始考虑怎么处理数据

虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。一台机器读取成T上P的数据（很大的数据哦，比如整个东京热有史以来所有高清电影的大小甚至更大），一台机器慢慢跑也许需要好几天甚至好几周。对于很多公司来说，单机处理是不可忍受的，比如微博要更新24小时热博，它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。这就是MapReduce / Tez / Spark的功能。MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了很简化的计算模型，只有Map和Reduce两个计算过程（中间用Shuffle串联），用这个模型，已经可以处理大数据领域很大一部分问题了。

那什么是Map什么是Reduce？

阅读全文 →