flink简介

1.1 计算框架对比

1.1.1 自定义计算框架(灵活, 抽象度不够)

• 需要设计数据源的分片拉取策略, 数据计算的mapping shuffle reduce
• 需要选型计算中间结果存储
• 异常情况下的容错处理设计

1.1.2 Flink计算框架的特点和优势

• 有丰富的官方connector, sink; 也可以自定义
• Flink中提供了StateBackend来存储和管理状态数据, 支持有状态计算, 并且支持多种状态(RocksDB支持热数据存放内存, 冷数据存放文件)
• Flink中基于异步轻量级的分布式快照技术提供了Checkpoint容错机制, 状态数据全局统一快照处理, 可以基于保存的快照容错及保证exactly-once语义
• 支持事件时间（Event Time）概念，结合Watermark处理乱序数据
• 支持高度灵活的窗口（Window）操作 time、count、session
• 基于JVM实现独立的内存管理

1.1.3 大数据核心思想

• 分而治之
• 当数据量达到一定程度的规模时，普通的服务器很难短时间内去计算解决问题。所以需要多台廉价服务器分布式存储，并行计算去解决问题。
• 计算向数据移动
• 分布式环境下，网络的I/O是多机处理问题的速度瓶颈。那么数据的移动的时间成本很大。而计算程序基本很小。所以我们需要计算去向数据移动。尽量使用本地数据，减少网络I/O。

问题: 如果有一个1T的文本文件，仅有一台内存为百M的计算机。如何查询出这个文本文件中那条记录出现了两次。

• tips：单机计算机的计算瓶颈为磁盘I/O。假设读取速度为每秒300M。那么读取一次1T的文件为约1个小时。因为内存有限，无法将数据完全读取到1台机器上。
• 方法1：逐条便利对比。需要n次遍历这个文本去逐条比对。时间是指数级别的。
• 方法2：分而治之：先遍历一次文本。将每条数据取hash值模上10000的方法，将每条数据分别存储到不同的10000个文件中。再遍历这10000个文件，相当于遍历一遍源文件。这样只需要两次I/O，2个小时左右就能解决这个问题。

问题: 如果每天产生一个1T的文本文件, 多机器分布式计算真的块吗?

• tips：单台机子不需要分发。假设每秒100MB的网络分发速度分发至10000台机器, 光分发速度就需要3个小时。
• 30天的时候，数据来到了30T。单机遍历两次将近30个小时。而多机器每天需要3个小时去分发数据。
  到最后，每台机器上也就将近3000MB的数据。遍历时间10秒(不考虑倾斜)。

1.2 大数据计算框架对比

1.2.1 Storm Spark Flink对比

• Storm
• 仅支持流处理
• 目前活跃度不如spark flink
• Spark
• 设计为批处理大数据计算引擎
• Spark Streaming 把一段时间传输进来的数据合并在一起当做一个微批, 再去交给Spark去处理, 流是批的特例理念
• Spark MLlib 机器学习类库相对成熟
• Flink
• 按照流处理计算设计的大数据计算引擎
• 主要场景就是流数据(DataStream), 即可以逐条处理, 也可以定义数据流的边界(Window)攒微批
• 批数据(DataSet): 批数据是流数据的一个极限特例理念
• 有状态计算

1.2.2 流处理与批处理

• 流处理(流式计算/实时计算): 无界流(动态数据), 实时处理
• 批处理(批量计算): 有界流(静态数据), 一般为定时任务调度, 每次调度会一次性完成处理, 高延迟

无界流(Unbounded streams)

• 有定义流的开始，但没有定义流的结束。它们会无休止地产生数据。
• 无界流的数据必须持续处理，即数据被摄取后需要立刻处理。不能等到所有数据都到达再处理，因为输入是无限的，在任何时候输入都不会完成。
• 处理无界数据通常要求以特定顺序摄取事件，例如事件发生的顺序，以便能够推断结果的完整性。

有界流(Bounded streams)

• 有定义流的开始，也有定义流的结束。
• 有界流可以在摄取所有数据后再进行计算。
• 有界流所有数据可以被排序，所以并不需要有序摄取。
• 有界流处理通常被称为批处理。

1.2.2 有状态计算(stateful computations)

有状态的计算

• 每次进行数据计算的时候基于之前数据的计算结果（状态）做计算，并且每次计算结果都会保存到存储介质中，计算关联上下文context

• 如: 计算1天内累计数据, 基于有状态的计算，将当日累计值存储在状态中, 当前数据与状态历史值进行累计, 再更新状态

无状态的计算

• 每次进行数据计算只是考虑当前数据ÿ