思考题：

  • Hadoop项目的由来
  • HDFS的体系结构
  • HDFS的运行机制
  • Hadoop中MapReduce的实现机制
  • Htable的数据结构
  • Hbase的运行机制
  • Yarn对Hadoop的核心改进
  • Spark架构及运行机制
  • Storm架构及运行机制
  • Kafka架构及运行机制
  • Pregel架构及运行机制

  • 各种分布式处理框架的异同点

    Hadoop

    Overview

  • 得名于一头大象的名字

  • 起源于一个开源的网络搜索引擎项目Apache Nutch

  • 重要组件

    • MapReduce——分布式数据处理模型和执行环境
    • HDFS——分布式文件系统
    • HBase——分布式、按列存储数据库
    • ZooKeeper——分布式、可用性高的协调服务
    • Pig——数据流语言和运行环境，用于检索非常大的数据集
    • Hive——分布式、按列存储的数据仓库

      HDFS

  • 主要概念：数据块、NameNode、DataNode、命令行接口、基本文件系统操作

  • NameNode——Master，DataNode——ChunkServer

  • 引入了Node之间的距离，通过网络拓扑结构来衡量节点的距离，网络可以看做一棵树，节点间的距离是节点到他们最近的共同祖先的距离和。

    MapReduce实现过程

  • Job Distribution：MR程序被打包成jar文件和XML文件，被传送到各个数据所在HDFS的datanode上运行，Job在执行前就被序列化和分布式

  • Data Distribution：计算数据的存储是分布的——HDFS，Mapper被传送到数据节点计算，传输中间结果到Reducer，然后Reducer汇总计算结果保存到HDFS中

  • 不同的进程

    • JobTracker
    • TaskTracker
    • TaskRunner

      Hadoop扩展

      原始Hadoop存在的问题

  • JobTracker是MapReduce的集中处理点，存在单点故障的风险。JobTracker不只是简单的分配任务，还需要负责监控运行状态，重新调度任务等等。

  • JobTracker完成了太多了任务，造成了过多的资源消耗。MapReduceJob非常多的时候，会造成很大的内存开销，潜在来说，也增加了JobTracker fail的风险。在一主多辅的架构下，老Hadoop存在4000个辅节点的上限。
  • TaskTracker端，没有考虑具体资源的使用情况，仅仅是以Map/Reduce task的数目作为资源调度的指标。比如说，两个大内存消耗的task被调度到一块，很容易出现OOM。
  • TaskTracker把资源强制划分为Map Task Slot和Reduce Task Slot，过于简单粗暴，可能造成资源浪费。

  • 代码陈旧复杂，bug修复和版本维护困难。

    Yarn架构

  • ResourceManager进行资源分配

  • Yarn的变化
    • 客户端不变，开发使用者是透明的，原有代码不必大改
    • JobTracker和TaskTracker被拆分成ResourceManager、ApplicationMaster和NodeManager三部分
    • ResourceManager 是一个中心的服务，它做的事情是调度、启动每一个 Job 所属的 ApplicationMaster、另外监控 ApplicationMaster 的存在情况。
    • ResourceManager 负责作业与资源的调度。接收JobSubmitter 提交的作业，按照作业的上下文 (Context)信息，以及从 NodeManager 收集来的状态信息，启动调度过程，分配一个 Container 作为 App Master
    • ApplicationMaster负责一个 Job 生命周期内的所有工作，包括task 的监控、重启等等。类似老的框架中JobTracker。但注意每一个 Job（不是每一种）都有一个ApplicationMaster，它可以运行在 ResourceManager以外的机器上。
    • NodeManager 功能比较专一，就是负责 Container 状态的维护，并向RM保持心跳。

  • Yarn的优势

    • 大大减小了JobTracker的资源消耗，并且让检测每一个Job子任务状态的程序分布式化了，更安全，优美
    • 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
    • AppMst可自定义，更多类型的编程模型能够运行在Hadoop集群上。
    • 资源的表示以内存为单位，比之前的slot更为合理
    • Container资源隔离。

      HBase

  • HBase即Hadoop Database，是Hadoop中的数据库

    • 数据模型——行，每行数据有一个可排序的key关键字和任意数量的列
    • 可以理解为横线本，但是每一行是无限长的，不存在代表列的格子的限制
    • 行是按照字节排序的，不同长度的行
    • 可以对行加锁，对行的操作具有原子性

      系统总体架构

  • Master Server存放元数据

    • 管理区域服务器
    • 指派区域服务器服务特定区域
    • 恢复失效的区域服务器
    • 元数据META
      • 全部用户区域的属性数据都放在元数据表中
      • 包括区域中数据起止行、区域在线状态等
      • 保存区域服务器地址
      • META表包含多个区域，区域属性数据存储在ROOT节点上
    • 根表ROOT
      • 只包含一个区域
      • 将META元数据中的区域映射到Region Server
      • 存储元数据服务器的位置，以及映射了哪些元数据区域

  • Region Server存放表的一部分，即若干行，这些行叫做“区域”

    • 为区域的访问提供服务，负责维护区域的分割，负责数据持久化
    • 每个区域包含一个随机ID，区域内的行也是按行键有序的
    • 弹性可扩展机制：每个表最初只有一个区域，当体积超过某个阈值时，表会被分成两个大小相同的Region
    • 处理读写请求，向Master上报自己的心跳
    • 写：首先写预写日志，数据并非直接写文件系统，先缓存，然后批量写，同时在日志中做标记
    • 读：首先在内存缓存中找，如果存在多个版本，返回顺序按照从最新到最老
    • 如果映射文件数量超过阈值，区域服务器会进行一次合并
    • 如果Region文件大过阈值，会按照行的方式对半分割，被分割区域通过垃圾回收机制回收
    • 由于检测没有心跳，主服务器能够探知区域服务器的失效；主服务器将失效服务器所提供服务的区域重新分配给其它区域服务器；原失效区域服务器的“预写”日志由主服务器进行分割并派送给新的区域服务器。

      Pig

      可以理解为HBase的SQL

      Hive

      Hive是Hadoop中的数据仓库，注重数据的分析和处理

  • 将SQL查询转换成一系列在Hadoop集群上的MapReduce作业

  • 将数据组织成表

  • 通过HiveQL命令执行

    Spark

  • 适用场景：适用于反复迭代运算场景，机器学习、数据挖掘等；

  • 不适用于异步细粒度更新状态的应用：比如增量爬虫、索引等；
  • 磁盘数据本地化，内存数据本地化，计算本地化
  • RDD
    • RDD是一个数据集，不可改变，分布在集群上
    • 通过DAG来实现自动数据恢复，支持内存物化和硬盘物化，来保存中间结果
    • 所有的操作都是针对RDD的。

  • RDD

    • 分布式数据集在内存的抽象实现
    • 集群节点上不可改变的，已分区的集合对象
    • 只读、不可修改
    • 允许降级、写入磁盘

      Storm

  • Storm是一个分布式流处理框架，实时处理数据，一主多辅架构，一个master和一群worker组成，通过zookeeper集群协调

  • 主节点后台程序Nimbus
    • 响应集群节点，分配任务和检测故障
    • 流式计算不存在结束，计算拓扑一直存在，不断等待新的数据到来，直到该计算拓扑被手动停止然后释放
  • 工作阶段后台程序Supervisor
    • 收听工作指派，运行工作进程
    • Supervisor接受任务，然后管理自己的worker来执行任务
  • 流
    • Storm中数据处理的核心概念
    • Storm中的数据处理从最初输入到最终输出是一个流，每个流构成了一个拓扑topology
    • 也就是说，Storm中一个应用是一个拓扑，拓扑中的每一步（spout或bolt）都是一个task
    • 拓扑的组件
      • Spout喷口：Topology中产生源数据流的组件，只发不收
      • Bolt门闩：Topology中接收数据和处理数据的组件，必收可发可不发
      • Tuple：一次消息传递的基本单元

  • Storm消息分组方式

    • 随机分组
    • 字段分组
    • 全部分组（泛洪）
    • 全局分组：全部流被分配到bolt的一个任务

      Kafka

      Overview

  • 订阅-发布机制

    • 在模块较多、连接复杂的情况下，指向性传递存在效率低下的问题。
    • 当交互频繁时，需要一个消息总线，实现“消息快递”：消息发送者A通过快递服务（消息总线）将消息传递给B，消息总线批量处理消息。
    • 消息生产者将消息发布给消息管理器；消息的消费者从消息管理器处进行订阅，消息管理器接受到消息之后将消息向已订阅该消息的消费者转发消息。

  • 消息系统的特点

    • 解耦：提供统一的数据结构屏蔽数据产生与处理的差异
    • 冗余：把数据进行持久化，直到该消息被确认处理完成，避免消息丢失的风险
    • 扩展：可以方便的扩展消息入队节点（发送者）和处理节点（接收者），还可以增加消息转发节点
    • 灵活性：消息处理解耦，可方便地进行业务流程调整和处理逻辑调整
    • 峰值处理：解决发送接收速度不匹配的问题
    • 可恢复性
    • 顺序保障
    • 缓冲
    • 异步通信

      Kafka

      LinkedIn开发的一种分布式消息系统

  • 适用于单位消息量较小但传递频繁的领域：社交网络、非视频类的传感器IoT数据、日志类

  • 特点
    • 高吞吐量：同时为发布和订阅提供高吞吐量，每秒可以产生250K消息，每秒处理550K消息
    • 可持久化：消息可持久化到磁盘，防止数据丢失
    • 分布式，易于扩展
    • 支持online和offline场景
    • 消息被处理的状态在consumer端维护，而不是有server维护，失败时自动平衡
  • 架构
    • Producer：Producer通过push向kafka发布消息
    • Broker
    • Consumer：Consumer通过pull方式从kafka获取消息
  • 消息管理的基本概念
    • Topic：消息类别
    • Partition：每个Topic包含若干个partition，每个partition对应一个文件夹，存储该partition的数据和索引文件
    • Consumer Group：同一个topic的一条消息只能被同一个group内的一个consumer消费，但多个group可以同时消费这个消息
  • 消息发布机制
    • Producer指定发布的topic
    • Topic里的信息物理上分为多个partition存储
    • Broker存储若干topic的partition，允许同topic的不同 partition存储在不同的broker上
    • 由zookeeper统一管理
    • Producer可以通过指定消息的key控制将消息发到某个 partition
  • 消息消费机制
    • Consumer需要指定消费的Topic
    • Consumer需要指定隶属的consumer group
    • 一个Topic里的每条信息只能被consumer group中的一个 consumer消费，属于不同consumer group的consumer 可以共同消费一个topic的相同信息
    • Consumer group里的consumer和topic的partition按照 id顺序进行消费，例如0/1/2consumer分别消费0、3/1、 4/2号partition，如果partition数比consumer数少，则id 数超过partition数的consumer无法获取数据
  • 消息存储机制
    • 消息在partition上顺序写磁盘，通过偏移量访问
    • 消息被持久化，在访问后不删除
    • 通过配置保存时长和partition文件大小控制删除
  • 发布——订阅
    • 传统发布订阅只需要topic和consumer
    • 增加了partition和consumer group概念
    • Partition能够增加消息发布效率 ，相当于把topic的存储机器分布式化，避免单一机器速度过慢导致 性能受限
    • Consumer group能够增加消息消费效率 相当于把topic的消费者分布式化，避免单一消费者过慢导致性能 受限

  • 可靠性保障

    • 三种可选的方式
      • At most once 消息可能会丢，但绝不会重复传输
      • At least one 消息绝不会丢，但可能会重复传输
      • Exactly once 每条消息肯定会被传输一次且仅传输一次
    • Kafka默认保证At least once
      • 允许通过设置Producer异步提交来实现At most once
      • 支持通过offset与外部存储系统协作实现Exactly once

        Pregel

  • Google提出的分布式图计算平台，采用BSP模型

  • 架构
    • 一主多辅的主从架构
    • 切边法分割子图
    • 主节点负责管理工作，不参与具体计算
    • 从节点负责每步的计算，负责相互传递消息
  • 节点状态
    • Step 0时每个节点均活跃
    • 执行之后进入不活动状态
    • 接收消息则转入激活
    • 没有活动节点和消息时，整个算法结束