Streaming Systems 笔记一

最新推荐文章于 2023-03-08 16:01:37 发布

新手路上的程序员

最新推荐文章于 2023-03-08 16:01:37 发布

阅读量474

点赞数

分类专栏： Flink 读书笔记文章标签： flink

本文链接：https://blog.csdn.net/yidan7063/article/details/100895379

版权

Part 1 The Beam Model

CHAPTER 1 Streaming 101

Terminology: What Is Streaming?

这里的“streaming”会特指一种可以处理无限数据集的处理系统。
在讨论不同类型的数据时，精确的术语也很有用。定义|给定数据集形状的两个重要（正交）维度是：基数和构成。
基数:描述了数据集的大小，有两种精确的表达方式：

有界数据：大小有限的数据集
无界数据：大小无限的数据集（理论上）

构成:决定了数据集的物理表现形式。有两个主要的重要组成部分:

表：数据集在特定时间点的整体视图。传统的SQL系统都是在处理表。
流：随时间变化的数据集，从每个元素（变化）的视角看，得到的视图。基于MapReduce的系统都是在处理流。这里先打个问号，目前来看spark或者说MapReduce的都是在处理批数据为什么作者在这里说是处理流数据？

On the Greatly Exaggerated Limitations of Streaming(Streaming被夸大的局限性)
在lambda架构刚提出或者说storm流行时，人们对Streaming的认知是低延迟但是不准确的。如果Streaming系统经过良好的设计实际上可以做到低延迟而且准确的。并且在理论上流是批的超集。为了达到这个目标需要做好两件事情:

正确性：这里需要和批一样保证数据的正确。从核心上来说正确性可以归结为一致性储存。Streaming需要机器故障时保证持久状态的正确性。正确性必需的是系统能够做到exactlyonce
Tools for reasoning about time 时间推理工具：如何超越批。好的时间推理工具对于处理具有不同事件时间偏差的无界无序数据至关重要。目前越来越多的现代数据集表现出这些特征，而现有的批处理系统（以及许多流式处理系统）缺乏必要的工具来应对这些数据集。

Event Time Versus Processing Time

Event time ：事件真实的发生事件
Processing time ：这是在系统中观察事件的时间

事件时间和处理时间时域映射:

Process Time 和 Event Time 给 Streaming Processing 带来了很多的问题，由于 unbounded dataset 的无边界特性，这些系统会提供一些把输入数据源进行 window 操作的概念。window 操作的本质还是把无限流按时间切片，对于那些关注 Event Time 的应用来说，肯定是不能按照 Process Time 进行 window 操作的（Process Time 和 Event Time 之间的无关性会导致 window 之间的不准确性）。
之前的系统都依赖了【完整性】的概念，但如果把这个概念应用无限流上时就会有一些问题，假如在 window 中使用了 Event Time，那么应该如何定义数据的完整性呢？怎么决定什么时候拿到了 X （event time）之前的所有数据？与其想着如何去把无限流切片，不如我们思考一下：如何设计一种新的系统来适应这种不确定性？spark stream?

Data Processing Patterns

Bounded Data

Unbounded Data: Batch
Fixed windows
问题:数据延迟的问题，如果数据延迟到来应该如何处理？是不是需要新增一些缓解措施(比如一直等待所有数据到齐或者在数据晚到时重新处理整个窗口数据)

Sessions
当我们尝试使用批处理引擎将无界数据处理为更复杂的窗口策略(如会话)时，这种方法的问题就更大了。会话通常被定义为活动期间(例如，对于特定用户)，由不活动间隙终止。当使用典型的批处理引擎计算会话时，通常会得到跨批划分的会话，如图中的红色标记所示。我们可以通过增加批处理大小来减少分割的数量，但代价是增加延迟。另一种选择是添加额外的逻辑，以弥补之前运行的缺陷，但代价是进一步复杂化。

无论是哪一种，当我们使用经典的批处理引擎来计算时都不是很理想。

Unbounded Data: Streaming

将对无界数据的处理分为4个方面:

和时间无关
Filtering 简单的过滤操作

Inner joins

当连接两个无界数据源时，如果只关心来自两个数据源的元素到达时的连接结果，则逻辑中没有时间元素。在看到来自一个源的值时，您可以简单地将其缓冲到持久状态；只有在来自另一个源的第二个值到达后，才需要发出连接的记录。
在看到连接的一端之后，如何知道另一端是否会到达?说实话，不需要，所以需要引入一些超时的概念，这将引入时间元素。
近似计算
近似算法，像：近似 Top-N、Streaming K-means 等等，在