流计算概述

一、 流计算应用需求

静态数据（支持决策分析而构建的数据仓库系统）

  • 可以利用数据挖掘和OLAP.OLTP(transaction)
  • 数据存储和管理，除了用数据仓库做，还可以用hdfs，
  • hive就是基于hdfs的数据仓库
  • 挖掘引擎除了用数据仓库，还可以用hadoop,spark
  • 计算开始之前，数据已经存在了

流数据

  • 特征：大量、快速、时变的流形式
  • 数据量大，但是不十分关注存储（是没办法存，存到磁盘就速度慢了），一旦经过处理，要么被丢弃，要么被归档存储
  • 注重数据的整体价值，不过分关注个别数据（但对于注重异常的，就很关注个别数据了）
  • 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素的顺序。
  • 实例：电子商务网站用户点击流
  • 应用场景2：实时交通
  • 借助于流计算的实施特性，不仅可以根据交通情况制定路线。

流计算应用需求

  • 处理引擎：低延迟、可扩展、高可靠
  • 对于一个流计算系统来说，它应达到的需求：
  • 高性能，海量式，实时性（*），分布式，易用性，可靠性

流计算特征

  • 无界：数据记录在计算过程中不断地动态达到
  • 乱序：record的原始顺序和在处理节点上的处理顺序可能不一致
  • 1:20买茶杯，1:21买书，但到达系统上的顺序不一定茶杯在前，买书在后
  • 如果数据静态放在那儿，不存在乱序
  • 延迟：record的产生时间和在处理节点上的处理时间可能差别很大

流计算 vs. 批处理

hadoop 流式处理 流计算与hadoop_Time

  • 批处理环境下数据在计算开始前已经全部到达

二、 流计算基础概念

1. 状态

数据流基本知识
  • 输入数据是结构化（有一个schema）的以及没有开始没有结束
  • 每个记录有一个最先产生的时间抽 （买茶杯买书）
  • 应用逻辑：Processing Elements（PEs），最基本的计算单元，如map，reduce算子（函数转换）
  • 所有记录都需要通过不同的Pes，PEs输入一个数据流（一系列的记录），输出一个数据流
处理模型
  • Data Stream：一系列的记录
  • PE：基本的计算元素（认为是一个小的程序或者一个函数）
  • PE消耗和产生数据流
  • 每个事件只能(only once)顺序地执行一遍 ---- 没有回溯！！
计算存在哪里？
  • 在代码里，跟批处理一样的（但批处理的数据在hdfs或者磁盘中）
总结状态：
  • 不能无限期地存储所看到的的事件
  • synopsis（梗概）：一个无限流的总结
  • 例子：样本，直方图，sketches….
  • Pes,the loop：1. Process t ,s;2.update s; 3. produce t’;
  • 状态：针对PEs，算到当前为止，数据的情况。
  • 有些操作可以不关心state,有些操作需要把state存起来
  • 不关心state：map,filter

2. 窗口

  • 数据放在框里，因为数据是无界的
  • 范围：
  • 时间域：（Time-based)（1分钟，每隔20s，算一次），
  • 空间域：（Count-based) （1000tuples，每过20个tuples，算一次）
  • 窗口类型
  • 滑动窗口（Sliding) range > slide （窗口有重叠）

    • hadoop 流式处理 流计算与hadoop_Time_02

  • 滚动窗口（Tumbling） range = slide（窗口正好连接在一起）

    • hadoop 流式处理 流计算与hadoop_Time_03

  • 跳跃窗口（Jumping） range < slide

    • hadoop 流式处理 流计算与hadoop_数据_04

3. 时间

时间语义：
  • Processing Time 处理时间：PE上的处理时间 （可以把握的），但不总是有意义
  • Event-Time 事件时间：如购买一个茶杯的时间（无法把握的时间），是最准确的度量，但是我们不得不从数据中才能得知。
如何去测量event-time？
  • 问题：事件时间没有按时间时间戳排序，记录可以无序到达。
  • 设备可能暂时断开连接。
  • 在消息日志（kafka）和PEs间的shuffles 中都有交错
  • Processing Time 是最简单的一个时间概念，不需要在数据流和机器之间进行协调。它有最好的性能和最低的延迟。然而，在分布式或者异步环境中，处理时间具有不确定性，因为容易受到记录到达系统速度的影响(例如从消息队列到达的记录)，还会受到系统内记录流在不同算子之间的流动速度的影响
  • event-time 即使在乱序事件，延迟事件以及从备份或持久化日志中的重复数据也能获得正确的结果。对于事件时间，时间的进度取决于数据，而不是任何时钟。事件时间程序必须指定如何生成事件时间的Watermarks，这是表示事件时间进度的机制。
  • 按事件时间处理往往会导致一定的延迟，因为它要等待延迟事件和无序事件一段时间。因此，事件时间程序通常与处理时间操作相结合使用。
如何根据event-time进行window操作
  • Event-Time with Low Watermarks:
  • 表明每个PE都需要维护一个，表明当前最小的时刻，且能保证这个时刻之前的数据都已经到达。
  • Wall time vs. Low Watermark
  • Wall Time:系统当前的时间，就是processing time
  • Low Watermark： 系统可以确认该时间之前的数据全部已经收到并完成处理。
  • 例子：windows统计9:30-10:00的数据，因此A激发窗口操作的时间为10:00
  • 激发窗口操作的时间
  • Wall time == 10:00? ====> processing time
  • Lwm == 10:00 ? =====> event time
  • 每个计算节点都会维护这样一个时间戳作为low watermark。
  • 假设有计算节点A和C，C是A的上游节点，则A的低水位值的计算应该遵从以下公式
  • Ingestion Time: 处理时间和事件时间的混合
  • 流事件进入系统的时间（当processing time 丢了的时候被使用）
  • 当事件时间丢了的话，就一定要记录下ingestion time ,要保证这个时间的先后
三种时间的比较：
  • Event Time：流事件发生的时间
  • Ingestion time：流事件进入系统的时间
  • Processing Time：处理流事件的时间
Low Watermark局限性
  • 在一定程度上保证数据的完整性、时效性
  • 无法完全避免数据比low watermark晚到达
  • 比如数据在没有进入到流式计算系统之前就延误了，low watermark根本不得而知
  • 不同的系统处理方式不一样，例如丢弃等。

三、 流计算系统

1. 目的：
  • 分布式流处理系统要求
  • 大规模的集群（100多台机器）
  • 实现低延迟（几秒）
2. 系统基础知识：
  • 记录流经过一个DAG并且触发不同的Pes
  • 一系列的PEs和流连接之间定义了一个DAG
3. 数据并行（DATA Parallelism）
  • 为什么需要数据并行
  • 进程吞吐量跟不上输入
  • 状态太大以致于无法放入单节点中（如 graphs）
  • 数据流也许已经被分区 （Kafka(流式数据缓存的工具））
  • 数据订阅
  • 数据是流动的，先遇到的数据是上流，存在数据传递的过程，说是下流订阅了上流。
  • 三种数据传递方式
    1) Broadcast 广播出去
    2) Shuffle 一边两个分开，使得负载均衡
    3) Key-based （最常用） mapreduce阶段就是以这种划分数据的
  • 注： 不同方式对输入和状态都不一样（根据storm具体的系统再讲）
  • A physical Pipeline Graph
  • 跟RDD写个spark差不多

流计算与Hadoop

  • hadoop不适合做流计算
  • 变通方案：将基于mapreduce的批量处理转为小批量处理，将输入数据切成小的片段
  • 缺点：延迟大，而且要处理片段之间的依赖关系。

数据从何而来

  • 直接从数据源获取
  • 如twitter,weibo,系统实时的日志等等
  • 消息队列/发布订阅系统
  • Kafka,flume,kinesis,zeromq,mqtt
  • 从文件系统
  • HDFS,S3