敞开掘金成长之旅！这是我参加「掘金日新方案 12 月更文应战」的第22天，点击查看活动概况

大数据分布式核算引擎规划完结剖析

大数据分布式核算引擎规划完结剖析

0.1 前语

其实整个互联网职业的一切的产品的本质需求： 存 、取、剖析

存：HDFS + HBase + MySQL + Redis + MongoDB+ es + 时序数据库 + 图数据库 + 目标数据库 + 数据湖
取： 单点取（select * from table where id = 1），批量取(类似于 HBase 的规模查询)，全量取（文件上传下载）
剖析： 核算引擎（MR,spark,Flink），剖析型数据库(hive， OLAP 系统)

剩余的都是衍生需求：完整整个系统，保证整个架构平稳高效运行的

0.2 各大分布式引擎剖析

分布式核算引擎：海量大文件的核算，WordCount作为一个入门需求举例了解这些 分布式履行引擎的规划和履行原理：

  • MapReduce 离线批处理 非常大的进步 鼻祖
  • Storm 流式实时处理 开源界第一个最受欢迎的流式核算引擎 不必管了
  • Spark 离线批处理 + 交互式查询 + 伪流式处理/微批处理 + 机器学习 ===> 批处理之王， 几乎一切的离线核算需求都是运用 Spark 去做
  • Flink 实时流式核算引擎 出世便是为了解决流式核算
  • Hive 结构 工具 / 壳 底层的引擎，能够运用 sprak mr tez 等
核算引擎：
1、Hive + SparkCore / MR
2、SparkSQL
3、MR + Storm + Spark + Flink 等
​
数据库：
1、HBase
2、OLAP系统： Clickhouse/Doris/Kylin/Kudu/Druid/Impala/Presto

HBase(低延时的单点随机读写) + Clickhouse(全量剖析) 规划剖析的比照

也是为了剖析！

Flink 的真实的用途是干什么的？有三点！看官网解说！

0.2.1 MapReduce 履行引擎解析

MapReduce 履行引擎解析：

Flink系列之大数据分布式计算引擎设计实现剖析

最中心的思想： 分而治之 + 分阶段履行

  • 一个使命太大了，太复杂了，分而治之 大事化小 小事化了
  • 必定衍生出来 分布式批处理核算必定要分阶段。 第二个阶段中的 Task 是否能履行彻底取决于第一个阶段的 Task 是否悉数完结
  • 中心必定需求经过 网络来履行数据混洗：其实便是把符号相同的 value 传输到同一个节点，发动 Task 来履行聚合核算

MaReduce 引擎：

  • Mapper 分。不是用来做核算的，是用来给第二个阶段预备核算数据的：提取待核算的数据，然后打上标签！ Mapper 做核算是谓词下推的表现！本身核算做个事儿 reducer 去做，其实这个事儿，没必要非得比及 reducer 去做，mapper 能够先做一做！
  • Reducer 合。真实的核算在哪里？在这里，拿到了一组 key 相同的 value 数据然后履行聚合逻辑

有同学可能会问到：为什么 mapreduce 中的输出的 key 能够重复呢？不要把 这个key-value 当做 hashmap 中的 键值对来了解！

  • Key： 待核算数据的符号
  • value：待核算的数据

经典面试题：现在 有 1000亿 条数据，横竖很大（1000T）（横竖就一台机器搞不定），我需求核算一下，这些数据中最大的 50 条是谁？

  • 堆排序！ 数据量小，确实可用。花的时间会特别长，占用的资源少
  • 1000T 分成 1000 个使命，每个使命履行 1T 数据的核算，能够选用堆（堆中只保存了最大的50条）的方法来搞定，每个堆得到 50 条数据，1000个堆 便是50000 条数据，再维护一个最终的堆就搞定了（由于这 1000 个小使命是并行履行的）

大数据的分布式批处理核算引擎：分布式分阶段并行履行引擎

MapReduce 的组件规划完结图：

Flink系列之大数据分布式计算引擎设计实现剖析

面试题举例：运用 MR 来完结：

1000T数据求TopN 数据存储在HDFS 默许完结 界说 Mapper 逻辑 可选的动作 界说 Reducer 逻辑 默许组件 HDFS

读取一个分段文件  把1000个使命输出堆
维护一个小根堆   从5W条数据中求最大50

结构：半成品，把许多应用程序的共同部分做一个笼统和沉淀！ MapReduce : 分布式核算引用程序的编程结构！

类似于 责任链规划形式！ 处理器1 -> 处理器2 -> 处理器3 -> 处理器4

1、数据源： 存储数据的

数据读取组件：InputFormat + RecordReader 提供了一种笼统，不论从读哪里读取数据都能够，有默许完结，有内置完结，当然也能够自界说

- FileInputFormat + LineRecordReader 逐行读取文件，默许完结
- DBInputFormat 读取数据库 MySQL 批量读取 + 单条记载读取

2、Mapper： 界说了每一条数据到底履行什么样的处理（怎样提取数据打符号？用户来写）

3、Shuffle：到底运用哪个规矩来决议什么样的数据作为一组传输到同一个节点来履行 reduce 核算

- Paritioner 分区规矩： 用户要写
- Sorter 排序器： MR 内部直接默许运用了 归并排序 + 快速排序
- Combiner 局部合并器： 取决你的逻辑要不要，如果能写，最好写一个

4、Reducer： 界说了每一组数据到底履行什么样的处理（拿到key相同的一组数据之后，怎样履行核算呢？用户来写）

5、数据输出组件：OutputFormat + RecordWriter

FileOutputFormat + LineRecordWriter 默许完结

弥补：海量数据的常见面试题

Spark、Flink 或者说 Java、Scala 到底谁多一点？归根结底都是工具。你的团队对那个熟悉就能够考虑用哪个，生态的多样性。

0.2.2 Spark 履行引擎解析

Spark 履行引擎解析：

Flink系列之大数据分布式计算引擎设计实现剖析

Spark 相比于 MR的真实优势的当地在哪里：Simple Fast Scalable Unified

  • DAG 引擎
  • 中心核算结果能够进行内存耐久化
  • 依据内存核算(不合适，如果要解说合理一些：咱们能够把数据都加载（从内存中心件中读取）到内存中，然后来履行核算)
  • 生态多样，算子丰厚，API 应用库丰厚，支撑的资源调度也丰厚

真实的核算，都是迭代： 从文件中，读取一条，履行一条数据的核算 MR、Spark 读取 HDFS 的数据，履行核算的方法是相同的，由于底层运用的 读取数据是相同的

Spark 履行引擎组件图：

Flink系列之大数据分布式计算引擎设计实现剖析
总结一下：

  • MapReduce：批核算引擎
  • Storm：流核算引擎
  • Spark：批核算引擎 + 流核算引擎（微批/伪流式）
  • Flink：批核算引擎 + 流核算引擎

现在开源大数据核算引擎有许多选择，流核算如 Storm,Samza,Flink,Kafka Stream 等，批处理如 MapReduce,Spark,Hive,Pig,Flink 等。而同时支撑流处理和批处理的核算引擎，只有两种选择：一个是 Apache Spark，一个是 Apache Flink。

而 Flink 和 Spark 的不同点在于：

1、Spark的技能理念是依据批核算来模仿流核算。以为批处理是常态，而把流式处理看做是批处理的特例。
2、Flink的技能理念是依据流核算来模仿批核算。以为流处理是常态，而把批处理看做是流式处理的特例。

用批来模仿流有必定的技能局限性，所以从技能的长远发展来看，Flink会更耐久。 针对待核算的数据来说的：

有开端，有结束
有开端，没有结束

经典：

1、Spark的技能理念是依据批完结批和流。
2、Flink的技能理念是依据流完结流和批。


声明：
文章中代码及相关句子为自己依据相应了解编写，文章中呈现的相关图片为自己实践中的截图和相关技能对应的图片，若有相关异议，请联系删去。感谢。转载请注明出处，感谢。

落叶飘雪