5.1快乐学习time

流计算

概述

静态数据和流数据

  • 静态数据
  • 流数据(数据流)

    • 指在时间分布和数量上无限的一系列动态数据集合体
    • 数据记录是流数据的最小组成单元
    • 特征

      • 数据快速持续到达,潜在大小也许是无穷无尽的
      • 数据来源众多,格式复杂
      • 数据量大,但是不十分关注存储,一旦流数据中的某个元素经过处理,要么被丢弃,要么被归档存储
      • 注重数据的整体价值,不过分关注个别数据
      • 数据顺序颠倒,或者不完整,系统无法控制将要处理的新到达的数据元素的顺序

批量计算和实时计算

  • 批量计算

    • 以 静态数据 为对象,可以在充裕得时间内对海量数据进行批量处理
  • 实时计算

    • 处理流数据的实时计算=>流计算

流计算

  • 流计算的概念

    • 基本理念:数据的价值随着时间的流逝和降低
    • 需求

      • 高性能
      • 海量式
      • 实时性
      • 分布式
      • 易用性
      • 可靠性

使用 MapReduce 来满足计算系统需求遇到的问题

  • 方法

    • 将基于 MapReduce 的批量处理转为小批量处理,将输入数据切成小的片段,每隔一个周期就启动一次 MapReduce 作业
  • 遇到的问题

    • 虽然可以利用切分成小片段的方式降低延迟,但是也增加了任务处理的附加开销,而且还要处理片段之间的依赖关系(一个片段可能需要用到前一个片段的计算结果)
    • 需要对 MapReduce 进行改造以支持流式处理, Reduce 阶段的结果不能直接输出,而是保存在内存中,这种做法会大大增加 MapReduce 框架的复杂度,导致系统难以维护和扩展
    • 降低了用户程序的可伸缩性,因为用户必须使用 MapReduce 接口来定义流式作业

流计算框架

  • 商业级流计算平台

    • IBM InfoSphere Streams
    • IBM StreamBase
  • 开源流计算框架

    • Twitter Storm
    • JStorm
    • Yahoo!S4(Simple Scalable Streaming System)
  • 公司为自身业务开发的流计算框架

    • Facebook Puma
    • DStream
    • 银河流数据处理平台
    • Super Mario

流计算的处理流程

数据实时采集

  • 架构

    • Agent

      • 主动采集数据,并把数据推送到 Collector 部分
    • Collector

      • 接收多个 Agent 的数据,并实现有序、可靠、高性能的转发
    • Store

      一般不进行数据存储,而是将采集的数据直接发送给流计算平台进行实时计算

      • 存储 Collector 转发过来的数据

数据实时计算

  • 接受数据采集系统不断发来的实时数据进行实时分析计算,并反馈实时结果

实时查询服务

  • 不断地更新结果,并将用户所需的结果实时推送给用户

开源流计算框架 Storm

简介

  • Twitter Storm 是一个免费、开源的分布式实时计算系统,Storm 对于实时计算的意义类似于 Hadoop 对于批处理的意义,Storm 可以简单、高效、可靠地处理流数据,并支持多种编程语言

特点

  • 整合性
  • 简易的 API
  • 可扩展性
  • 容错性
  • 可靠的消息处理
  • 支持各种编程语言
  • 快速部署
  • 免费、开源

Storm 设计思想

抽象化的设计思想术语

  • Streams

    • 流数据 Streams 是一个无限的 Tuple 序列(Tuple 即元组,是元素的有序列表,每一个 Tuple 就是一个值列表,列表中的每个值都有一个名称,并且该值可以是基本类型、字符类型、字节数组等,也可以是其他可序列化的类型)
  • Spouts

    • 流数据Streams 的源头,Spouts 会从外部读取流数据并持续发出 Tuple
  • Bolts

    • Streams 的状态转换,Bolts 既可以处理 Tuple,也可以将处理后的 Tuple 作为新的 Streams 发送给其他 Bolts
    • 对 Tuple 的处理逻辑都被封装现在 Bolts 中,可执行过滤、聚合、查询等操作
  • Topology

    • Topology 是 Storm 中最高层次的抽象概念
    • 一个 Topology 就是一个流转换图,图中节点是一个 Spout 或 Bolt,图的边则表示 Bolt 订阅了那个 Stream
    • 当 Spout 或者 Bolt 发送元组时,它会把元组发送到每个订阅了该 Stream 的 Bolt 上进行处理
  • Stream Groupings

    • 用于告知 Topology 如何在两个组件间进行 Tuple 的传送
    • 传送方式

      • ShuffleGrouping

        • 随机分组,随即分发 Stream 中的 Tuple,保证每个 Bolt 的 Task 接收 Tuple 数量大致一致
      • FieldsGrouping

        • 按照字段分组,保证相同字段的 Tuple 分配到同一个 Task 中
      • AllGrouping

        • 广播发送,每一个 Task 都会收到所有的 Tuple
      • GlobalGrouping

        • 全局分组,所有的 Tuple 分配到同一个 Task 中
      • NonGrouping

        • 不分组,和 ShuffleGrouping 类似,当前 Task 的执行会和它的被订阅者在同一个线程中执行
      • DirectGrouping

        • 直接分组,直接指定由某个 Task 来执行 Tuple 的处理

Storm 框架设计

与 Hadoop 不同的是,一个 Topology 会持续处理消息直到人为终止

采用 Master-Worker 的节点方式

  • Master 节点运行 Nimbus 的后台程序(类似 Hadoop 中的 JobTracker),负责在集群范围内分发代码、为 Worker 分配任务和检测故障
  • 每个 Worker 节点运行 Supervisor 的后台程序,负责监听分配给它所在机器的工作,即根据 Nimbus 分配的任务来决定启动或停止 Worker 进程

采用 Zookeeper 来作为分布式协调组件,负责 Nimbus 和多个 Supervisor 之间的所有协调工作(一个完整的拓扑可能被分为多个子拓扑,并由多个 Supervisor 完成)

Storm 是极其稳定的

  • Nimbus 和 Supervisor 后台进程都是快速失败(Fail-fast)和无状态(Staeless)的
  • Master 节点没有直接和 Worker 节点通信,而实借助 Zookeeper 将状态信息存放在 Zookeeper 中或本地磁盘中,以便于节点故障时进行快速恢复

Storm 工作流程

  • 客户端提交 Topology 到 Storm 集群中
  • Nimbus 将分配给 Supervisor 的任务写入 Zookeeper
  • Supervisor 从 Zookeeper 中获取所分配的任务,并启动 Worker 进程
  • Worker 进程执行具体的任务
Last modification:May 1st, 2020 at 04:25 pm
如果觉得我的文章对你有用,请随意赞赏