[数据科学笔记]第6章 流数据处理

流数据处理

---

1.流数据处理应用

---

有一类数据密集型应用，数据快速到达，转瞬即逝，需要及时进行处理

这些应用来自不同的领域，包括网络监控(Network Monitoring)、电信数据管理(Telecommunication Data Management)、工业制造(Manufacturing)、传感器网络(Sensor Network)、电子商务(Electronic commerce)、量化交易(Algorithm Trading)等。

---

2.流式处理和批处理的区别

对于批处理来讲，首先数据被不断地采集，保存到数据库中(不一定是关系数据库，可以是HBase或者Hive数据库)，然后进行分析处理(包括SQL查询)。批处理适用于对大量数据(High Volume)进行处理的场合。人们需要等到整个分析处理任务完成，才能获得最终结果。

在流式数据处理模式里，数据持续到达，系统及时处理新到达的数据，并不断产生输出。处理过的数据一般丢弃掉，当然也可以保存起来。流式数据处理模式，强调数据处理的速度(Velocity)。部分原因，是因为数据产生的速度很快，需要及时进行处理。由于流式数据处理系统，能够对新到达的数据进行及时的处理，所以它能够给决策者提供最新的事物发展变化的趋势，以便对突发事件进行及时响应，调整应对措施。

---

3.流数据模型

在流数据模型(Stream Data Model)中，将要进行处理的数据，从一个或者多个上游数据源，持续不断地到达，而不是从保存在磁盘或者内存中的数据源，进行随机地存取。

流数据模型和传统的关系模型(Relational Model)，有几个重要的区别

(1) 数据流的数据元素持续到达。

(2) 流数据处理系统，不能控制数据元素到达的顺序。

(3) 数据流有可能是无限的，或者说数据流的大小是无限大(Infinite)。

(4) 数据流的一个数据元素被处理后，可以丢弃或者归档(Archived)，一般不容易再次提取，除非目前该数据元素还在内存中。能够保存在内存中的数据元素，相对于整个数据流来讲，是极少量的数据。

在流数据模型中，数据流可以看作是只允许进行元组添加操作(Append Only)的关系表。对应关系数据库的SQL查询语言，在数据流上，我们可以使用经过扩展的SQL语言，进行数据流的查询

---

4.数据流上的查询

数据流上的查询，和传统数据库上的查询(比如关系数据库上的SQL查询)，有很多共同的特点，但是两者有两个重要的区别

(1).第一个区别，是一次性查询(One Time Query)和持续查询(Continuous Query)的区别:

一次性查询One Time Query(比如关系数据库的SQL查询)，指的是在数据集的某个时刻的快照(Point in Time Snapshot)上执行的查询，对数据进行分析，获得结果后，返回给用户。

持续查询，则是在一系列持续到达的数据流的数据元素上执行的查询，它产生一系列结果。这些结果是根据查询不断执行时，不断看到的新数据而产生的

(2).第二个区别，是预定义查询(Predefined Query)和即席查询(Ad-Hoc Query)对系统的影响

预定义查询一般是持续查询，当然我们也可以预先定义一些一次性查询。

即席查询，则是在数据流的数据开始流动起来，数据不断到达的时候，才提交给流数据处理系统的。即席查询可以是一次性查询，也可以是持续查询。即席查询使得系统的设计和实现复杂化了

---

流数据管理系统一般通过提供面向流数据处理的一些原语(Primitive)，扩展SQL语言，支持用户通过熟悉的SQL查询语言，操作数据流

扩展的原语，主要提供时间窗口(Time Windows)的定义办法。

包括物理时间窗口(Physical Window)、和逻辑时间窗口(Logical Window)。物理时间窗口通过ROWS关键字指定,而逻辑时间窗口通过RANGE关键字指定

5.流数据处理系统的查询处理

内存需求

大部分数据流，是无法预知其最终大小的，或者说数据流的大小(记录数量)可能是无限的。在这种
情况下，如果要在数据流上计算一个准确的结果(比如累计数)，需要的存储空间将无法预知，有可
能超过可用的内存。
在某些流数据处理应用中，新数据以极高的速率到达，以至于老数据都还没有来得及处理。我们需
要尽量降低处理每个数据元素的时间，每个数据元素要处理得够快，否则流数据的处理，跟不上数
据到达的速度。为了达到高速的数据处理，流数据处理系统一般优先采用基于内存的数据处理算
法，无需存取磁盘

近似查询结果

在内存容量有限的情况下，获得一个准确的结果，是不太可能的。正好，在很多应用场合，我们无
需一个准确的答案。近似的查询结果，只要足够好，可以作为准确结果的替代。
在流数据处理领域，人们为数据流上的查询，研究了一系列数据缩减(Data Reduction)或者摘要
(Summary Construction)构建技术，具体包括数据轮廓(Sketche)、随机采样(Random 
Sampling)、直方图(Histogram)、小波变换(Wavelet)等。基于这些摘要(Summarization)数据
结构，实现了计算近似结果的方法，包括聚集查询(Aggregate Query)和连接查询(Join Query)

滑动窗口

从数据流上产生近似查询结果的一种技术，是滑动窗口及其之上的查询处理技术。所谓滑动窗口上
的查询处理，指的是在数据流的最近数据元素(记录)上执行查询，而不是在数据流的所有历史记录
上执行查询。比如，进行查询处理的时候，仅仅存取数据流上最近一天的数据元素，一天前的数据
元素则丢弃掉。在内存容量有限的情况下，获得一个准确的结果，是不太可能的。正好，在很多应
用场合，我们无需一个准确的答案。近似的查询结果，只要足够好，可以作为准确结果的替代。
为了实现数据流上基于滑动窗口的查询，一般需要在查询语言里，增加滑动窗口的定义方法(一般
是对SQL语言进行扩充)。滑动窗口的大小是任意的，当滑动窗口过大的时候，窗口里的数据元素
(记录)过多，不能缓存在内存里，需要利用磁盘保存部分数据，这将增加处理的延迟，研究人员在
研究利用有限的内存，实现近似计算的算法

查询数据流的历史数据

在标准的流数据处理模式中，当某个数据元素处理结束后，将无法再访问到。这就意味着，某些数
据已经被丢弃以后，用户发起即席查询(Ad-Hoc Query)，将无法获得准确的结果。
针对这个问题，最简单的办法，是规定即席查询只能参考它提交以后到达的新数据，之前的历史数
据直接忽略掉。这种办法简单粗暴，但是在很多应用中，这样的规定却是可以接受的。
另外一个办法，则稍微复杂一些，它允许新提交的即席查询参考历史数据。历史数据不是原原本本
地保存起来，而是保存一个摘要(Summary)，是数据的一个梗概(Synopsis)或者聚集汇总
(Aggregate)。这些数据摘要，有助于为未来的即席查询，计算一个近似的结果。这种办法，需要
考虑到系统需要支持什么类型的查询，然后利用内存资源，维护一个数据摘要，最大限度地支持这
些类型的查询

多查询优化与查询计划的适应性

在流数据处理系统中，大多数的查询是长时间运行的持续查询。系统同时运行大量的查询，可以通
过多查询优化(Multi Query Optimization)技术，提高查询处理的性能。由于系统不断有新的即
席查询提交上来，为一组查询寻找最佳的执行计划，需要在线(Online)进行优化决策。
此外，即席查询带来另外一个问题，就是查询计划的适应性(Adaptivity in Query Plan)

堵塞操作符

堵塞操作(Blocking Operator)，是这样的操作，它需要看到所有的输入数据以后，才能开始产
生输出结果。排序就是堵塞操作的一个实例，此外，包括Sum、Count、Min、Max、Avg等聚集操
作，也是堵塞操作，因为只有看到所有的输入数据，才能开始产生输出。
让流数据处理系统有效处理排序、聚集等操作，是一个严峻的挑战。
其中的一种技术，称为标点技术(Punctuation)。所谓标点，就是一个断言(Assertion)，它规
定，在剩下的数据流数据中，什么数据可以出现，什么数据不可以出现。标点和数据元素交织在一
块，被插入在数据流的不同位置上，帮助数据流上的操作做出决策。

数据流里的时间戳

滑动窗口，是基于是数据流元素的时间戳(Timestamp)或者顺序号(Sequence Number)属性进行
定义的。对于来自一个数据流的数据来讲，时间戳一般不存在歧义。但是在一些场合，我们必须对
时间戳给予关注，原因是：(1) 如果滑动窗口是在从多个数据流上产生的组合元组上定义的(比如
一个Join操作，连接了两个数据流S1/S2)，如果来自两个数据流的元素的时间戳数值不一样，那
么两个元组连接产生的组合元组，应该赋予什么时间戳，是一个问题。(2) 当若干分布式的数据
流，构成一个逻辑数据流的时候，以及在分布式的传感器网络上，比较不同数据流的数据元素的时
间戳，具有实际业务意义

批处理(Batch Processing)、采样(Sampling)、梗概(Synopsis)

批量处理(Batch Processing)
但是实际情况往往不是这样的。第一种情形是，update操作足够快，但是computeAnswer操作很
慢，跟不上数据流数据到达的速率。最自然的办法，是以批处理方式处理数据，也就是新来的数
据元素先缓存起来，在资源允许的情况下，定期计算查询的结果。查询结果不是根据最新的数据
进行计算的(最新数据缓存起来，有待下一次进行成批的处理)，而是有一定的时间延迟。这种计
算方法，获得的查询结果是准确的，只不过它是最近的准确的结果，而不是当前的准确结果。也
就是，因为使用批量处理，牺牲了结果的及时性，但是跟上了数据流新数据到达的速率。

采样(Sampling)
在第二种情况下，computeAnswer操作足够快，但是update操作很慢，不足以及时处理新到达的
数据。由于数据到达实在太快，没有必要利用所有的数据来计算查询的结果。我们可以忽略一部
分元组，在数据流上进行采样，在采样上而不是整个数据流上，计算查询的结果。

梗概(Synopsis)
我们希望有某种数据结构，既支持快速的update操作，也支持快速的computeAnswer操作，能够
及时处理数据流新到达的数据。对于很多数据流上的查询，根本就不存在两者兼得的数据结构。
于是人们设计一种近似数据结构，它是数据流的一个梗概(Synopsis or Sketch)。梗概是一个
比较小的数据结构，它能够把每个元素的处理代价保持到最低水平，从而使得流数据处理系统，
能够赶上数据到达的速度。梗概技术的细节，请参考下一节内容。

---

6.查询处理的基础算法

随机采样

数据上的随机采样，可以看作是一种摘要式的数据结构(Summary Structure)，它包含了整个数
据集的基本特征。在随机采样上，我们还可以建立各种梗概(Synopsis)。 

人们研发了各种采样方法，其中分层采样(Stratified Sampling)方法，首先按照对观察指标影
响较大的某种特征，将总体分为若干个类别，再从每一类别内随机抽取一定数量的样本，合起来组成一个样本。

蓄水池采样(Reservoir Sampling)方法，只需要对数据进行一遍扫描，特别适合于数据流的采样。

蓄水池采样的基本原理是，首先建立一个数组，将数据流里的前k个数，保存在数组中，即所谓
的"蓄水池"。对于第n个数据元素(元组)An，以k/n的概率取An并以1/k的概率随机替换“蓄水池”
中的某个元素，如果没有发生替换，则“蓄水池”数组元素不变，依此类推处理新到达的其它各个
元素。该算法可以保证取到数据的随机性

梗概技术

梗概(Sketch)技术，是在数据流上，使用少量的内存，建立一个摘要结构。这个摘要结构，可以
用于特定查询的近似结果的估计。梗概技术，能够解决数据流上的很多问题。比如估计数据集的二
阶矩的大小、估计数据集自连接(Self Join)的大小、获得数据集中热门元素的列表等

直方图(Histogram)

直方图是一种摘要数据结构，人们使用直方图，来捕抓数据集里的一个字段或者一组字段的取值的
分布情况。在数据库里，直方图一般用来进行查询结果集大小估计(Query Size Estimation)、
给出近似的查询结果(Approximate Query Answering)、以及用于数据挖掘(Data Mining)

布隆过滤器

Bloom Filter 是一种简单、高效的数据结构，用来判断一个元素是否属于一个集合。对其操作包
括初始化、元素插入和元素查询过程。Bloom Filter由一个长度为m的bit数组和k个Hash函数构
成。M和k两个参数，可以根据我们可以接受的假阳性(False Positive)比率来进行调整。

计数最小梗概

计数最小梗概(Count-Min Sketch)，使用一个次线性空间(Sub-Linear Space)，来计算频率。
它包含d行w列的一个矩阵，w和d的选择，体现了准确性和时间/空间开销的折中(Trade Off)。每
一行有一个Hash函数，当一个元素到达，它被针对每行进行Hash操作，即使用每行对应的Hash函
数，对元素数据进行映射，得到每行的一个下标，于是对应这些下标的列的元素保存的计数器
(Counter)，增加1，如图所示。可以看出，Count-Min Sketch和Bloom Filter有一些相似度之
处

---

7.流数据处理系统

Storm

Storm是一个分布式的、高度容错的实时数据(流数据)处理的开源系统。Storm是为流数据处理设
计的，具有很高的处理性能。一个小集群，每秒钟可以处理数以百万计的消息。Storm保证每个消
息至少能够得到一次完整的处理。任务失败时，它会负责从消息源重试消息，从而支持可靠的消息
处理。Storm 由Twitter开发并且开源，它使用 Clojure语言实现。

用户可以使用多种语言，为Storm编写应用程序，包括Clojure、Java、Ruby和Python等，还可以
通过实现Storm通讯协议，提供其它语言的支持。

Storm集群由一个主节点和多个工作节点组成。主节点运行一个 “Nimbus”守护进程，它的工作是分配代码、布置任务以及故障检测。每个工作节点运行一个“Supervisor”守护进程，用于监听、开始并终止工作(Worker)进程。

(1) 数据流(Stream)
数据流是Storm的一个关键的概念。

(2) 计算拓扑(Topology)
在Storm里，一个实时计算应用程序的处理逻辑，封装成一个Topology对象，称为计算拓扑。

(3) 消息源(Spout)
在Storm里，消息源称为Spout，是消息的生产者。

(4) 消息处理者(Bolt)
所有的消息处理逻辑，被封装在消息处理者(Bolt)里面。

(5) Spout和Bolt之间的数据分发策略(Stream Grouping)
Spout和Bolt之间的数据分发策略，称为Stream Grouping。

(6) 工作进程(Worker)
Supervisor监听分配给它那台机器的工作，根据需要启动/关闭工作进程，这些工作进程称为
Worker。

(7) 任务(Task)和执行器(Executor)
Topology的每个Spout或者Bolt，当作若干个任务(Task)在整个集群里面执行。一个进程包含若
干线程。默认情况下，每一个Task对应到一个线程，称为Executor，这个线程用来执行这个
Task。同一个Spout/Bolt的Task可能会共享一个物理线程。

Apex

Apache Apex是一个建立在Hadoop平台上的流数据处理系统，广泛用于数据导入(Ingestion)、ETL、实时分析(Real-Time Analytics)等应用场合。Apex使用Hadoop HDFS文件系统作为存储层，并且依赖于Hadoop平台的YARN资源管理器，实现资源分配和应用运行。Apex保证日志数据不会丢失，每个事件都得到处理。它利用基于内存的数据处理，获得极高的性能。Apex的扩展性好，容错性高，成为Storm及其后继者Heron的有力竞争者。

Spark Streaming

Spark大数据平台本质是一个批处理平台。在Spark平台上，Spark Streaming通过一系列小批量数据(Mini Batch)的及时处理，实现数据流处理。它把数据流缓存并且分割成一系列的小批量数据，每个Mini Batch一次进行处理。由此可见，Spark Streaming并不是真正的流数据处理系统，它使用批处理系统，来仿真实现了流数据处理模式

Flink

Apache Flink是一个开源的分布式流数据处理系统，它具有极高的性能、高度的容错性和扩展能力。Flink被Alibaba用于优化电子商务网站的搜索结果(用户对商品的搜索)，他们对商品的一些细节属性和库存信息，进行实时更新，提高查询结果的相关性。此外，Flink还被应用到网络/传感器监控及错误检测、ETL等应用场合(https://flink.apache.org/usecases.html)。

Onyx

Onyx是一个无中心的、容错的分布式计算系统，它支持批处理和流数据处理两种数据处理模式。Onyx应用于实时事件流处理、持续计算、ETL等应用场合。Onyx使用Clojure语言写成，开发人员可以使用Clojure或Java语言编写程序。

Samza

Apache Samza是一个开源的分布式流数据处理框架。它使用Apache Kafka作为消息队列，暂时存储不断到达的数据，保证数据不丢失。同时它利用Hadoop YARN资源管理和应用程序调度框架，获得高度的容错性和扩展能力。