流计算

概述

静态数据和流数据

• 静态数据

• 流数据(数据流)

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

  • 特征

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

批量计算和实时计算

• 批量计算

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

• 实时计算

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

流计算

• 流计算的概念

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

  • 需求

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

使用 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 进程执行具体的任务