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天内累计数据, 基于有状态的计算,将当日累计值存储在状态中, 当前数据与状态历史值进行累计, 再更新状态
无状态的计算
- 每次进行数据计算只是考虑当前数据ÿ