大数据 Shuffle 原理与实践 课后习题 | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第6天

题目来源：【大数据专场 学习资料二】第四届字节跳动青训营 - 掘金

1. 自己构造一个会产生shuffle 的spark作业，修改shuffle相关的参数，对比一下不同参数对作业运行的影响

略

2. 在spark中shuffle实现的发展过程中，每一次变化都优化了之前哪些缺点，又带来了哪些问题？

   1. Spark0.8 Shuffle使用hash based shuffle

      1. 问题：每个partition会映射到文件，需要打开M*R个文件，资源消耗过多，容易OOM

   2. Spark 0.8.1为 Hash Based Shuffle引入File Consolidation机制

      1. 优化：把每个partition映射到一个文件的片段，同时跑的任务为申请到的CPU数，需要打开C*R
      2. 问题：没有根本解决问题，打开文件数量比较多

   3. Spark 1.1引入Sort Based Shuffle

      1. 优化：每个task生成一个排序后的文件，使用索引文件标识数据开始位置，创建文件数是2*M个，支持map-side combine
      2. 问题：需要排序，对于小任务反而会提升耗时

   4. Spark 1.4 引入 Tungsten-Sort Based Shuffle

      1. 优化：更快的排序效率，更高的内存利用效率
      2. 问题：不支持key排序，不支持map-side combine

   5. Spark 1.6 Tungsten-Sort Based Shuffle 并入 Sort Based Shuffie

      1. 优化：根据数据量以及是否需要map-side combine，判断使用哪种shuffle方式

   6. 引入Push Shuffle

      1. 优化：解决Fetch Shuffle的大量随机读问题，网络连接M*R个，影响稳定性
      2. 问题：远程存储merge文件，如果丢失需要所有task重算，成本巨大；merge操作失败后，需要重试，需要解决数据重复的问题

3. Push Shuffle相对比Fetch Shuffle最大的挑战是什么？

   1. Push Shuffle为了解决Fetch Shuffle的问题

      1. Avg IO size太小，造成了大量的随机IO，严重影响磁盘的吞吐
      2. M*R次读请求，造成大量的网络连接，影响稳定性

   2. 挑战

      1. 远程存储merge文件，如果丢失需要所有task重算，成本巨大，需要做好持久化存储
      2. merge操作失败后，需要重试，需要解决数据重复的问题
      3. 如果merge文件拉取不到数据，需要转到原始block拉取数据