大数据平台架构与原型实现-读书笔记7

第7章 实时计算

一、ETL已过，流计算永存

       流计算比传统ETL更有优势，有能力成为数据进入大数据平台的“门户”。在大数据平台上，ETL工作由多种组件协同完成，每一种组件都提供了足够的弹性来应对多样和灵活的需求，体现在：

• 数据采集工具可针对不同的数据源与协同使用不同的预设接口；
• 数据采集工具也能完成一些初步的数据转换和清洗工作，减少不必要的数据传输与重复处理；
• 流计算提供了绝佳的数据清洗和转换的场所，强大的编程环境可在流上实现任意复杂程度的ETL工作；
• 流计算可将清洗转换后的数据分别传输给批处理和后续流计算环节继续处理，并最终写入各自的目标数据源吗，如NoSQL数据库或HDFS。

二、技术堆栈与选型

       当前主流的流计算工具非Flink和Spark Streaming莫属，两者的实现思想和编程模型都是不同的，因此适用场景也有差异。

2.1 Storm

       Storm的计算模型被称为“Topology”，Topology从结构上看有Spout和Bolt组成的有向无环图，图中每一个节点都会对流上的数据进行一定的处理，然后传递给后续节点做下一步处理。

（1）Spout

       Spout是Stream的起点，是产生Tuple的源头，Spout会对接某类数据源（如Kafka），把数据封装成Tuple的形式吐给后续的Bolt进行处理，一个Spout可以同时为两个以上的Stream供给数据。

（2）Bolt

       Bolt是Topology中进行数据处理的单元，是实现业务逻辑的关键节点。可在Bolit上进行过滤、清洗、转换、聚合和关联等各种操作。在理想情况下，每个Bolt对于Tuple的处理应该是一个简单的边界清晰的操作，然后用多个Bolt相互协作来构建一个复杂的Topology。

（3）Stream

       Storm的Stream指一个没有边界的、永远向前“流动”的数据流，在一个实时计算系统里，Stream就是刚刚生成即被采集的源源不断的数据，这些数据“流入”像Storm这样的流计算框架，经过各种处理并以期望的格式和方式输出给下游。

（4）Tuple

       Tuple是Storm中对数据的统一封装格式，是Stream的数据载体，一个Tuple中可以包含多个预定义的基本类型字段。Storm也提供API让用户定义自己的数据结构，以便让自定义数据类型能够以Tuple字段的形式进行序列化和反序列化。

2.2 Spark Streaming

       Spark Streaming是以Mico-Batch方式工作的，在实时性上要比Storm差，但是依托Spark平台，从统一技术堆栈和与其他Spark组件交互的角度考虑，使得Spark Streaming进行实时处理正变得越来越流行。

2.2.1 DStream编程模型

（1）编程模型

       DStream是Spark早期唯一的流计算编程模型，DStream是将极短时间间隔内的数据组织成一个RDD，在流上的各种操作都是以RDD为基本单元进行的，因为Spark的流处理被认为是Micro-Batch的，并非实质意义上的“流”，也是Spark Streaming只能实现近实时计算的主要原因。

（2）窗口操作

       DStream还支持流计算上普遍用到的窗口操作，它是指以一个限定的时间窗口观察流上的数据，刚好出现在整个时间窗口内的数据会作为一个整体参与计算，DStream上的窗口计算有countByWindow、reduceByWindow、reduceByKeyAndWindow和countByValueAndWindow。

（3）有状态的流

       在流计算过程中需要维持一种状态，每次流入或流出的数据都会基于流上维持的“状态”进行计算，并且会对状态进行更新。有状态的流最常见的应用就是维持某种Session或上下文。DStream使用updateStateByKey方法来更新流上的状态，置于这个“状态”是怎样的一种数据结构，Spark并没有硬性规定，而是留给开发人员自行定义，只需要确保它可以被序列化即可。

2.2.2 Structured Streaming编程模型

（1）编程模型

       Structured Streaming模型把数据流当成一张没有边界的“数据表”来对待，流上的计算会被转化为数据表上的“查询”，每次的查询结构会作为一个新的“数据表”，后续的操作将在新的数据表上执行，这种处理方式与DStream类似都是受函数式编程的影响，为的是确保数据的不可变性，还有利于分布式和多核并行计算。

（2）窗口操作

       Structured Streaming同样支持窗口操作，新API显得更加实用和强大，新的窗口计算可以基于“事件时间”而不再是数据进入流的时间，所谓“事件时间”是指数据所代表的时间发生时的时间，这显然更加具有实用性。

（3）流关联操作

       自Spark2.3开始，Spark Structured Streaming开始支持Stream-stream Join。对于流来说，任意时刻Join双方的数据都是“没有边界”的，当前流上的任何一行数据都有可能会和另一条流上的未来某行数据Join上，为此，开发人员在进行Stream-stream Join时必须指定时间范围。

       内关联：Structured Streaming支持任何列之间的Join，但是这样会带来一个问题，随着Stream的长期运行，Stream的状态数据会无限制地增长，并且这些状态数据不能被释放，所以我们必须在join时追加一些额外的条件来减轻Spark维护数据的负担，可以使用的方法：

• 设定Watermark，抛弃超过约定时限到达的输入数据；
• 在事件时间上添加约束，约定晚于指定时间的数据不再参与Join。

       外关联：Watermark和Event Time对内关联不是必须的，是可选的，但是对外关联就是强制的，因为在外关联中，如果关联的任何一方没有匹配的数据，都需要补齐控制，如果不对关联数据的范围进行限定，外关联的结果集会膨胀得非常厉害，也就是每一条没有匹配到的输入数据都要依赖另一个流上的全体数据的总行数使用空置补齐。

（4）应付多数据延迟就绪

Structured Streaming给出了基于Watermark的解决方案，Watermark指的是当一条记录进入流时，流计算引擎会检查这条记录的事件时间与当前流上最新的事件时间的差值，党这个差值大于某个设定的阈值时，就说明当前这条记录太“旧”了，从而会被排除在流计算之外，这个阈值就是Watermark。

2.3 Flink

（1）编程模型

       Flink的API和Spark Streaming DStream的API非常相似，也抽象出了Stream概念来表示没有边界的数据流，针对Stream所施加的操作被称为Transformation，与很多流计算模型一样，流的起点往往是数据的输入源，被称为Source，流的终点是数据的输出目的地称为Sink。

（2）窗口计算

       Flink同样支持窗口计算，并提供多种不同的时间概念供开发者选择，包括：

• 事件时间：事件创建的时间，它通常由事件中的时间戳描述，Flink通过时间戳分配器访问事件的时间戳
• 摄取时间：事件进入Flink数据流的时间
• 处理时间：是每一个操作在执行时的本地时间

（3）批处理与更多的编程模型

       Flink以流计算内核的基础，将数据处理能力从流计算拓展到了批处理，同时在内核之上提供了面向不同场景的“上层接口”。Flink底层是完全面向流计算设计的即Stateful Stream Processing，Flink所有的编程接口和上层服务都是基于这层基础设施构建的，即使批处理作业也是以流计算模型运行的。在基础设施之上，是核心API（DataStream/DataSet API），再往上，是针对结构化数据操作而封装的Table API，是面向结构化数据而设计的一套DSL（领域特定语言），顶层是直接面向SQL的一层封装，便于开发者可以在流上使用SQL语句处理结构化数据。

2.4 Kafka Stream

       Kafka Stream的编程模型与Storm的Topology非常类似，被称为Processor Topology，Kafka中的Stream Processor相当于Storm中的Bolt，同时它有两类特殊的Processor：Source Process和Sink Processor。前者是流的源头，负责接入数据，没有上游节点，类似于Storm中的Spout；后者是流的出口，负责将数据出书到目标位置。Kafka Stream同样支持窗口计算，同样支持事件时间、摄取时间和处理时间，也可实现由状态的流。

2.5 关于选型的考量

       一般来说，Storm是基于时间的流处理框架，如果业务上需要的实时处理是以事件驱动的，那么从编程模型上讲，Storm是最适合的，同时Storm的时时想非常高，可以做到百毫秒或更低的延时。

       而对于Spark Streaming，它的micro-batch编程模型决定了它只能实现近实时的计算，这也能满足大多数系统的需求，由于在Spark Streaming上可以无障碍地应用Spark SQL、Mlib等Spark组件，从同一技术堆栈的角度出发，Spark Streaming成为越来越多人的选择。

       Flink吸取了其他流计算框架的诸多优势，在性能、实时性和编程模型的完备性上都要比Storm和Spark Streaming更胜一筹，但是Flink距离在业界全面推开还有一段路要走。

三、流计算工程结构

• Stream：系统中的每一条流都会封装在一个类中，我们把这些类统一按“XxxStream”形势命名，放在Stream包，Stream类里出现的大都是与Spark Streaming相关的API，在涉及实际的业务处理时，会调用相应的Service方法。
• Service：也业务相关的处理逻辑会封装到Service类里，这是很传统的做法，如果在项目中深度地应用了领域驱动设计，那么绝大部分业务逻辑已经自然地委派到了领域对象的方法上，此时的Service会变成很薄的一层封装。
• Restful API Client/Repository：该层主要是Service提供数据读写服务。一般的流计算程序在运行中需要对两类数据进行读写：一类是流计算要依赖的主数据，另一类是流计算的处理结果。
• Model：领域模型涉及的实体和值对象都会放在这个包里，业务处理和分析的逻辑会按照面向对象的设计理念分散到领域对象的业务方法上。同样，如果建立了统一的主数据和配置信息的读写组件，则Model也将不复存在。
• DTO：流计算中的DTO并不是为传输领域对象而设计的，它是外部采集的原生数据经过结构化处理之后在流上的数据对象。