【硬刚大数据之学习路线篇】2021年从零到大数据专家的学习指南(全面升级版)

大数据成神之路 同时被 2 个专栏收录
262 篇文章 69 订阅
26 篇文章 12 订阅

📢欢迎关注博客主页:https://blog.csdn.net/u013411339
📢本文由【王知无】原创,首发于 CSDN博客!
📢本文首发CSDN论坛,未经过官方和本人允许,严禁转载!
📢欢迎点赞 👍 收藏 ⭐留言 📝 ,欢迎留言交流!

声明:本篇博客在我之前发表的文章基础上进行了大量更新,旨在给大数据领域的新人提供一份详细的,未来天花板较高的学习路线。

在原文的基础上,新增了大数据最火热方向的详细学习路径,例如Flink和Spark的详细学习路径。

并且在面试部分进行了整理,将过去我个人面试超过2000+人次的经历进行了系统性总结。

以下是文章的主要内容:

第一部分:大数据学习路径概览篇
第二部分:大数据学习路径拆分篇
第三部分:大数据视频&学习资源推荐篇
第四部分:大数据面试篇
第五部分:学习建议篇

在2019年9月份的时候,我写过一篇文章《剑谱总纲 | 大数据方向学习面试知识图谱》

站在2019年的视角来看,应该成为了2019年我写的在CSDN平台最受欢迎的文章之一。

又过了两年,站在一个新的起点上。疫情突袭,反全球化浪潮迭起加之国内流量见顶,各大公司之间开启了白热化竞争。加之国家十四五规划出台,国家把信息科技作为了未来5-10年的核心发展方向,对我们传统的数据人提出了新的要求。

就像我在《大数据方向另一个十年开启》一文中所说,现在的大数据行业细分也秉持了10年的刚刚出现的时候的姿态一直在向前发展,未来可能有些方向会慢慢消亡,或者从传统的定义进化。

比如传统的BI岗位,这个岗位已经开始慢慢在消亡,和传统的离线数据仓库&实时数据仓库进行了有机的融合。再比如,原来有个岗位叫做 ETL,也慢慢要淡出大家视野了,因为技能的局限性和可替代性太强?

最近的一年来,Flink社区仍然保持比较旺盛的活力,更多的原因是因为社区的推动,与开发者不过是个工具,与阿里是技术影响力和商业化考量。

数据湖方向发展方兴未艾,都想攀上Flink社区的大树。未来谨慎看好吧,因为并未给一家业务主导的公司带来实质性的改变。

最近Apache社区停更了Sqoop,阿帕奇社区的几个项目在阶段性的完成了它的使命后最终都落幕了。比如刚刚停更的Sqoop,可能还有些同学在用的Kettle,还有我很早接触过的一个Falcon,它们早就该消失在历史的滚滚洪流中了。

自今年4月1日起,Apache软件基金会宣布将至少19个开源项目撤回到他们的Attic,其中13个与大数据相关,10个属于Hadoop生态系统。这种事情的发生基本也可以宣布大数据领域的黄金十年(2010-2020年)结束了。

file

2010年-2020年这10年是大数据从台后走到台前的10年,也是野蛮生长的10年。

各位也可以看到这个细分方向从业人员的专业,基本涵盖了各种各样的专业。

「风口上的猪」终究有落地的一天。各大公司流量见顶,外部受到反全球化影响,内部反垄断+国家大棒追杀。除了核心的搜索、推荐、广告业务和各个公司核心的地盘业务,严控成本也已经是各家共识。

数据组和算法组最受影响,人员成本叠加设备成本过高,ROI过低。

所以,2020年开始至未来10年是这个行业规范化的时代。不在是写写SQL,跑跑脚本就能拿到可观的薪水的时代了。

所以,我写了这个基于《剑谱总纲 | 大数据方向学习面试知识图谱》的升级版,希望每一个进入这个细分领域的人得到的不在是一个阉割版、未来天花板较低的学习大纲。

file

第一部分:学习路径概览篇

1. 编程语言

计算机专业的同学的第一门语言大都是C语言,然后是面向对象的Java。除此之外,可以学习Scala和Python。

Java是大数据领域的屠龙刀,适合集团化大规模作战。对Java的要求没有上限,越熟悉越好。Python更像一把锋利的匕首,更适用于短兵相接和贴身肉搏,用来写各种脚本。

2.Linux基础

需要掌握基于Linux系统下的常用命令和常见问题诊断。

3.数据库入门

基于MySQL了解常见的SQL语法,大数据领域SQL化是未来的发展方向。

4.计算机基础

计算机网络,操作系统,数据结构,计算机组成原理,这几门课非常重要的,虽然大多是纯理论知识,但是这都是底层,校招时,大厂都会问的。

对于计算机基础课,我找了一下读书的时候看过的视频和资源,后面还有工作中看的视频,稍有不同:

1、操作系统 Operating System

2、数据结构

3、计算机网络

4、计算机组成原理

这部分的内容非常多,需要抓住重点:

1. 计算机网络(OSI七层模型或TCP/IP五层模型)
2. 数据结构(数组、栈、队列、链表、树)
3. 算法(排序算法、查找算法、去重算法,最优解算法,LeetCode 算法题)
4. 操作系统(进程、线程、IO、调度、内存管理)

好了!假如以上的计算机基础你全部掌握了。那么就可以进入大数据领域的正式学习了。

5.语言基础篇

  • 语言基础
  • 多线程
  • 并发包中常用的并发容器(J.U.C)
  • JVM
  • NIO
  • RPC

6.分布式理论篇

  • 分布式中的一些基本概念:集群(Cluster)、负载均衡(Load Balancer)等
  • 分布式系统理论基础:一致性、2PC 和 3PC
  • 分布式系统理论基础:CAP
  • 分布式系统理论基础:时间、时钟和事件顺序
  • 分布式系统理论进阶:Paxos
  • 分布式系统理论进阶:Raft、Zab
  • 分布式系统理论进阶:选举、多数派和租约
  • 分布式锁的解决方案
  • 分布式事务的解决方案
  • 分布式 ID 生成器解决方案

7.网络通信篇

  • Netty 三层网络架构:Reactor 通信调度层、职责链 PipeLine、业务逻辑处理层
  • Netty 的线程调度模型
  • 序列化方式
  • 链路有效性检测
  • 流量整形
  • 优雅停机策略
  • Netty 对 SSL/TLS 的支持
    等等

8.离线计算篇

  • MapReduce
  • HDFS
  • YARN
  • Hive
  • Hbase

9.消息队列篇

  • Kafka
  • 了解Pulsar

10.实时计算篇

  • Spark
  • Flink

十分了解实时计算方向领域内的实时数据仓库、实时计算等的技术选型、架构设计、疑难杂症的排查。

11.数据仓库&数据湖

  • 数仓理论:范式、分层模型等
  • 数据仓库常见的问题:数据治理、元数据管理等
  • 数据湖理论和架构、用到的框架(Hudi、IceBerg)等

12.算法篇

  • 常见的大数据领域的算法:倒排、TopN、布隆过滤、字典树等
  • 了解常见的机器学习算法
  • 了解算法工程化

12.不可缺少的后端技能

  • Spring
  • Mybatis
  • SpringBoot

以及后端常见的一些接口抽象、分层设计和架构设计(DDD领域驱动,MVC等)

13.业务理解

基于当前业务的技术选型、成本控制、ROI投入产出比等

第二部分:学习路径拆分篇

1. 语言基础篇

语言基础

整个大数据开发技术栈我们从实时性的角度来看,主要包含了离线计算和实时计算两大部分,而整个大数据生态中的框架绝大部分都是用 Java 开发或者兼容了 Java 的 API 调用,那么作为基于 JVM 的第一语言 Java 就是我们绕不过去的坎,Java 语言的基础也是我们阅读源码和进行代码调优的基础。Java 基础主要包含以下部分:

  • Java 的面向对象
  • Java 语言的三大特征:封装、继承和多态
  • Java 语言数据类型
  • Java 的自动类型转换,强制类型转换
  • String 的不可变性,虚拟机的常量池,String.intern() 的底层原理
  • Java 语言中的关键字:final、static、transient、instanceof、volatile、synchronized的底层原理
  • Java 中常用的集合类的实现原理:ArrayList/LinkedList/Vector、SynchronizedList/Vector、HashMap/HashTable/ConcurrentHashMap 互相的区别以及底层实现原理
  • 动态代理

  • CAS、乐观锁与悲观锁、数据库相关锁机制、分布式锁、偏向锁、轻量级锁、重量级锁、monitor
  • 锁优化、锁消除、锁粗化、自旋锁、可重入锁、阻塞锁、死锁
  • 死锁的原因
  • 死锁的解决办法
  • CountDownLatch、CyclicBarrier 和 Semaphore 三个类的使用和原理

多线程

  • 并发和并行的区别
  • 线程与进程的区别
  • 线程的实现、线程的状态、优先级、线程调度、创建线程的多种方式、守护线程
  • 自己设计线程池、submit() 和 execute()、线程池原理
  • 为什么不允许使用 Executors 创建线程池
  • 死锁、死锁如何排查、线程安全和内存模型的关系
  • ThreadLocal 变量
  • Executor 创建线程池的方式:
  • ThreadPoolExecutor 创建线程池、拒绝策略
  • 线程池关闭的方式

并发容器(J.U.C)

  • JUC 包中 List 接口的实现类:CopyOnWriteArrayList
  • JUC 包中 Set 接口的实现类:CopyOnWriteArraySet、ConcurrentSkipListSet
  • JUC 包中 Map 接口的实现类:ConcurrentHashMap、ConcurrentSkipListMap
  • JUC包中Queue接口的实现类:ConcurrentLinkedQueue、ConcurrentLinkedDeque、ArrayBlockingQueue、LinkedBlockingQueue、LinkedBlockingDeque

以及Java并发包下的其他内容。

JVM

  • JVM 内存结构
  • 堆和栈
  • Java 内存模型
  • 垃圾回收
  • JVM 参数及调优
  • Java 对象模型
  • 虚拟机性能监控与故障处理工具
  • 即时编译器、编译优化
  • 类加载机制

NIO

  • 用户空间以及内核空间
  • Linux 网络 I/O 模型:阻塞 I/O (Blocking I/O)、非阻塞 I/O (Non-Blocking I/O)、I/O 复用(I/O Multiplexing)、信号驱动的 I/O (Signal Driven I/O)、异步 I/O
  • 灵拷贝(ZeroCopy)
  • BIO、AIO、NIO 对比
  • 缓冲区 Buffer
  • 通道 Channel
  • 反应堆
  • 选择器

RPC

  • RPC 的原理编程模型
  • 常用的 RPC 框架:Thrift、Dubbo、SpringCloud
  • RPC 的应用场景和与消息队列的差别
  • RPC 核心技术点:服务暴露、远程代理对象、通信、序列化

2. Linux基础

  • 基本指令
  • 系统和网络命令
  • 权限模型
  • 基础的Shell脚本

3.分布式理论篇

  • 分布式中的一些基本概念:集群(Cluster)、负载均衡(Load Balancer)等
  • 分布式系统理论基础:一致性、2PC 和 3PC
  • 分布式系统理论基础:CAP
  • 分布式系统理论基础:时间、时钟和事件顺序
  • 分布式系统理论进阶:Paxos
  • 分布式系统理论进阶:Raft、Zab
  • 分布式系统理论进阶:选举、多数派和租约
  • 分布式锁的解决方案
  • 分布式事务的解决方案
  • 分布式 ID 生成器解决方案

4.网络通信Netty

Netty 是当前最流行的 NIO 框架,Netty 在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用,业界著名的开源组件只要涉及到网络通信,Netty 是最佳的选择之一。

关于 Netty 我们要掌握:

  • Netty 三层网络架构:Reactor 通信调度层、职责链 PipeLine、业务逻辑处理层
  • Netty 的线程调度模型
  • 序列化方式
  • 链路有效性检测
  • 流量整形
  • 优雅停机策略
  • Netty 对 SSL/TLS 的支持
  • Netty的部分源码阅读举例:
Netty 的 Buffer
Netty 的 Reactor
Netty 的 Pipeline
Netty 的 Handler
Netty 的 ChannelHandler
Netty 的 LoggingHandler
Netty 的 TimeoutHandler
Netty 的 CodecHandler
Netty 的 MessageToByteEncoder

4.离线计算

Hadoop 体系是我们学习大数据框架的基石,尤其是 MapReduce、HDFS、Yarn 三驾马车基本垫定了整个数据方向的发展道路。也是后面我们学习其他框架的基础,关于 Hadoop 本身我们应该掌握哪些呢?

MapReduce

  • 掌握 MapReduce 的工作原理
  • 能用 MapReduce 手写代码实现简单的 WordCount 或者 TopN 算法
  • 掌握 MapReduce Combiner 和 Partitioner的作用
  • 熟悉 Hadoop 集群的搭建过程,并且能解决常见的错误
  • 熟悉 Hadoop 集群的扩容过程和常见的坑
  • 如何解决 MapReduce 的数据倾斜
  • Shuffle 原理和减少 Shuffle 的方法

HDFS

  • 十分熟悉 HDFS 的架构图和读写流程
  • 十分熟悉 HDFS 的配置
  • 熟悉 DataNode 和 NameNode 的作用
  • NameNode 的 HA 搭建和配置,Fsimage 和 EditJournal 的作用的场景
  • HDFS 操作文件的常用命令
  • HDFS 的安全模式

Yarn

  • Yarn 的产生背景和架构
  • Yarn 中的角色划分和各自的作用
  • Yarn 的配置和常用的资源调度策略
  • Yarn 任务资源调度的过程

Hive

Hive 是一个数据仓库基础工具,在 Hadoop 中用来处理结构化数据。它架构在 Hadoop 之上,总归为大数据,并使得查询和分析方便。Hive 是应用最广泛的 OLAP 框架。Hive SQL 也是我们进行 SQL 开发用的最多的框架。

关于 Hive 你必须掌握的知识点如下:

  • HiveSQL 的原理:我们都知道 HiveSQL 会被翻译成 MapReduce 任务执行,那么一条 SQL 是如何翻译成 MapReduce 的?
  • Hive 和普通关系型数据库有什么区别?
  • Hive 支持哪些数据格式
  • Hive 在底层是如何存储 NULL 的
  • HiveSQL 支持的几种排序各代表什么意思(Sort By/Order By/Cluster By/Distrbute By)
  • Hive 的动态分区
  • HQL 和 SQL 有哪些常见的区别
  • Hive 中的内部表和外部表的区别
  • Hive 表进行关联查询如何解决长尾和数据倾斜问题
  • HiveSQL 的优化(系统参数调整、SQL 语句优化)

列式数据库 Hbase

我们在提到列式数据库这个概念的时候,第一反应就是 Hbase。

HBase 本质上是一个数据模型,类似于谷歌的大表设计,可以提供快速随机访问海量结构化数据。它利用了 Hadoop 的文件系统(HDFS)提供的容错能力。
它是 Hadoop 的生态系统,提供对数据的随机实时读/写访问,是 Hadoop 文件系统的一部分。

我们可以直接或通过 HBase 的存储 HDFS 数据。使用 HBase 在 HDFS 读取消费/随机访问数据。 HBase 在 Hadoop 的文件系统之上,并提供了读写访问。

HBase 是一个面向列的数据库,在表中它由行排序。表模式定义只能列族,也就是键值对。一个表有多个列族以及每一个列族可以有任意数量的列。后续列的值连续地存储在磁盘上。

表中的每个单元格值都具有时间戳。总之,在一个 HBase:表是行的集合、行是列族的集合、列族是列的集合、列是键值对的集合。

关于 Hbase 你需要掌握:

  • Hbase 的架构和原理
  • Hbase 的读写流程
  • Hbase 有没有并发问题?Hbase 如何实现自己的 MVVC 的?
  • Hbase 中几个重要的概念:HMaster、RegionServer、WAL 机制、MemStore
  • Hbase 在进行表设计过程中如何进行列族和 RowKey 的设计
  • Hbase 的数据热点问题发现和解决办法
  • 提高 Hbase 的读写性能的通用做法
  • HBase 中 RowFilter 和 BloomFilter 的原理
  • Hbase API 中常见的比较器
  • Hbase 的预分区
  • Hbase 的 Compaction
  • Hbase 集群中 HRegionServer 宕机如何解决

5.消息队列篇

Kafka 是最初由 Linkedin 公司开发,是一个分布式、支持分区的(partition)、多副本的(replica)的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于 Hadoop 的批处理系统、低延迟的实时系统、Spark 流式处理引擎,Nginx 日志、访问日志,消息服务等等,用 Scala 语言编写,Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。

Kafka 或者类似 Kafka 各个公司自己造的消息’轮子’已经是大数据领域消息中间件的事实标准。Kafka 不满足单纯的消息中间件,也正朝着平台化的方向演进。

关于 Kafka 我们需要掌握:

  • Kafka 的特性和使用场景
  • Kafka 中的一些概念:Leader、Broker、Producer、Consumer、Topic、Group、Offset、Partition、ISR
  • Kafka 的整体架构
  • Kafka 选举策略
  • Kafka 读取和写入消息过程中都发生了什么
  • Kakfa 如何进行数据同步(ISR)
  • Kafka 实现分区消息顺序性的原理
  • 消费者和消费组的关系
  • 消费 Kafka 消息的 Best Practice(最佳实践)是怎样的
  • Kafka 如何保证消息投递的可靠性和幂等性
  • Kafka 消息的事务性是如何实现的
  • 如何管理 Kafka 消息的 Offset
  • Kafka 的文件存储机制
  • Kafka 是如何支持 Exactly-once 语义的
  • 通常 Kafka 还会要求和 RocketMQ 等消息中间件进行比较

6.实时计算篇

Spark

Spark 是专门为大数据处理设计的通用计算引擎,是一个实现快速通用的集群计算平台。它是由加州大学伯克利分校 AMP 实验室开发的通用内存并行计算框架,用来构建大型的、低延迟的数据分析应用程序。它扩展了广泛使用的 MapReduce 计算模型。高效的支撑更多计算模式,包括交互式查询和流处理。Spark 的一个主要特点是能够在内存中进行计算,即使依赖磁盘进行复杂的运算,Spark 依然比 MapReduce 更加高效。

Spark发展至今,应该说已经非常成熟了。是大数据计算领域不得不学习的框架。尤其是Spark在稳定性和社区发展的成熟度方面,基本可以吊打其他的大数据处理框架。

Spark 生态包含了:Spark Core、Spark Streaming、Spark SQL、Structured Streming 和机器学习相关的库等。

假如你是第一次接触Spark,那么你需要对Spark的设计思想有所了解,知道Spark用了哪些抽象,Spark在提出RDD的时候是基于什么样的考虑。

在这里给大家推荐几篇论文如下:

  • 第一篇:《弹性分布式数据集:一种为内存化集群计算设计的容错抽象》

这篇文章中提出了弹性分布式数据集(RDD,Resilient Distributed Datasets)这个概念,这个概念是贯穿Spark设计的始终,是Spark最重要的概念之一。RDD是一种分布式的内存抽象,允许在大型集群上执行基于内存的计算(In-Memory Computing),与此同时还保持了MapReduce等数据流模型的容错特性。

这篇文章中提到,Spark实现RDD在迭代计算方面比Hadoop快二十多倍,同时还可以在5-7秒的延时内交互式地查询1TB的数据集。

  • 第二篇:《大型集群上的快速和通用数据处理架构》。因为这个文章长达170多页,堪比一篇博士论文。相信绝大多数人都是没兴趣读完的。我在这里给出一个读后小总结:

这本书是Spark框架设计者–计算机科学博士Matei Alexandru Zaharia和加州大学伯克利分校教授、主席Scott Shenker撰写的。书中作者主要分析了当前流行的各种计算框架的使用场景以及他们对应的缺点,然后谈了下为什么编写了Spark这个框架和spark每个模块详细的设计理念及运行原理,这里是做一部分摘要。
随着现在需要处理的数据量越来越大,单机处理要向集群进行扩展,这就会带来三个集群维度上的问题
1)并行化:多个节点同时进行数据处理
2)容错:在多节点上处理数据,节点的故障和慢节点会变得非常常见
3)资源的动态分配:一般集群都是在多个用户之前进行切换,所以资源的动态扩展和缩减就变得非常重要。
和MapReduce对比 MapReduce做为计算引擎与Spark的区别在于:Spark RDD在并行计算阶段之间能够高效的共享数据。MapReduce计算模型中,map结果必须要从内存落到磁盘,然后reduce再将数据加载到内存中,得到的结果再次落到磁盘中;如果是多个MapReduce操作数据,那么reduce结果数据还要再次加载到下一个map内存。正是由于数据一次次从磁盘加载到内存,所以MapReduce才会异常的慢。这也是Spark和MapReduce的区别,Spark RDD能够将数据cache到内存中,省去了从磁盘加载的过程,同时Spark shuffle过程中的数据也是直接放在内存中的(为了避免shuffle失败map数据丢失Spark框架还对shuffle进行了checkpoint),这就是为什么spark比MapReduce块的原因。Spark解决的核心问题也就是数据流模型在计算过程中高效的共享数据 。RDD具有可容错和并行数据结构特征,这使得用户可以指定数据存储到硬盘还是内存、控制数据的分区方法并在数据集上进行种类丰富的操作。
容错 一般的框架有两种容错方式,提供容错性的方法就要么是在主机之间复制数据,要么对各主机的更新情况做日志记录。
第一种容错的方式恢复时间短但需要消耗更多的内存和磁盘空间用来存储数据。
第二种方式不需要额外内存但是恢复时间比较长。这两种方法对于数据密集型的任务来说代价很高,因为它们需要在带宽远低于内存的集群网络间拷贝大量的数据,同时还将产生大量的存储开销。与上述系统不同的是,RDD提供一种基于粗粒度变换(如, map, filter, join)的接口,该接口会将相同的操作应用到多个数据集上。这使得他们可以通过记录用来创建数据集的变换(lineage),而不需存储真正的数据,进而达到高效的容错性。当一个RDD的某个分区丢失的时候,RDD记录有足够的信息记录其如何通过其他的RDD进行计算,且只需重新计算该分区。因此,丢失的数据可以被很快的恢复,而不需要昂贵的复制代价。
RDD RDD是一个分区的只读记录的集合,用户可以控制RDD的其他两个方面:持久化和分区。用户可以选择重用哪个RDD,并为其制定存储策略(比如,内存存储),也可以让RDD中的数据根据记录的key分布到集群的多个机器,这对位置优化来说是有用的,比如可用来保证两个要Jion的数据集都使用了相同的哈希分区方式。默认情况下,Spark会将调用过persist的RDD存在内存中。但若内存不足,也可以将其写入到硬盘上。通过指定persist函数中的参数,用户也可以请求其他持久化策略并通过标记来进行persist,比如仅存储到硬盘上,又或是在各机器之间复制一份。
最后,用户可以在每个RDD上设定一个持久化的优先级来指定内存中的哪些数据应该被优先写入到磁盘。RDD的第一个优点是可以使用lineage恢复数据,不需要检查点的开销,此外,当出现失败时,RDDs的分区中只有丢失的那部分需要重新计算,而且该计算可在多个节点上并发完成,不必回滚整个程序 RDD的第二个优点是,不可变性让系统像MapReduce那样用后备任务代替运行缓慢的任务来减少缓慢节点 (stragglers) 的影响 在RDDs上的批量操作过程中,任务的执行可以根据数据的所处的位置来进行优化,从而提高性能,其次,只要所进行的操作是只基于扫描的,当内存不足时,RDD的性能下降也是平稳的。不能载入内存的分区可以存储在磁盘上,其性能也会与当前其他数据并行系统相当。RDDS最适合对数据集中所有的元素进行相同的操作的批处理类应用。RDDS不太适用于通过异步细粒度更新来共享状态的应用,比如针对Web应用或增量网络爬虫的存储系统.
宽窄依赖 窄依赖允许在单个集群节点上流水线式执行,这个节点可以计算所有父级分区 。相反,宽依赖需要所有的父RDD数据可用并且数据已经通过类MapReduce的操作shuffle完成 其次,在窄依赖中,节点失败后的恢复更加高效。因为只有丢失的父级分区需要重新计算,并且这些丢失的父级分区可以并行地在不同节点上重新计算。与此相反,在宽依赖的继承关系中,单个失败的节点可能导致一个RDD的所有先祖RDD中的一些分区丢失,导致计算的重新执行。
Spark的调度器会额外考虑被持久化(persist)的RDD的那个分区保存在内存中并可供使用,当用户对一个RDD执行Action(如count 或save)操作时,调度器会根据该RDD的lineage,来构建一个由若干 阶段(stage) 组成的一个DAG(有向无环图)以执行程序,每个stage都包含尽可能多的连续的窄依赖型转换。各个阶段之间的分界则是宽依赖所需的shuffle操作,或者是DAG中一个经由该分区能更快到达父RDD的已计算分区。之后,调度器运行多个任务来计算各个阶段所缺失的分区,直到最终得出目标RDD。调度器向各机器的任务分配采用延时调度机制并根据数据存储位置(本地性)来确定。若一个任务需要处理的某个分区刚好存储在某个节点的内存中,则该任务会分配给那个节点。否则,如果一个任务处理的某个分区,该分区含有的RDD提供较佳的位置(例如,一个HDFS文件),我们把该任务分配到这些位置。对应宽依赖类的操作 {比如w shuffle依赖),我们会将中间记录物理化到保存父分区的节点上。这和MapReduce物化Map的输出类似,能简化数据的故障恢复过程 对于执行失败的任务,只要它对应stage的父类信息仍然可用,它便会在其他节点上重新执行。如果某些stage变为不可用(例如,因为shuffle在map阶段的某个输出丢失了),则重新提交相应的任务以并行计算丢失的分区。(DAGscheduler官方定义) 若某个任务执行缓慢 (即"落后者"straggler),系统则会在其他节点上执行该任务的拷贝。这与MapReduce做法类似,并取最先得到的结果作为最终的结果。
Spark内存管理 Spark提供了三种对持久化RDD的存储策略:未序列化Java对象存于内存中、序列化后的数据存于内存及磁盘存储。第一个选项的性能表现是最优秀的,因为可以直接访问在JAVA虚拟机内存里的RDD对象。在空间有限的情况下,第二种方式可以让用户采用比JAVA对象图更有效的内存组织方式,代价是降低了性能。第三种策略适用于RDD太大难以存储在内存的情形,但每次重新计算该RDD会带来额外的资源开销。
对于有限可用内存,我们使用以RDD为对象的LRU(最近最少使用)回收算法来进行管理。当计算得到一个新的RDD分区,但却没有足够空间来存储它时,系统会从最近最少使用的RDD中回收其一个分区的空间。
除非该RDD便是新分区对应的RDD,这种情况下,Spark会将旧的分区继续保留在内存,防止同一个RDD的分区被循环调入调出。这点很关键–因为大部分的操作会在一个RDD的所有分区上进行,那么很有可能已经存在内存中的分区将会被再次使用。到目前为止,这种默认的策略在我们所有的应用中都运行很好, 当然我们也为用户提供了“持久化优先级”选项来控制RDD的存储。

大家可以看到,这些概念都是Spark中最最核心的几个概念。我们在学习过程中是万万绕不过去的。

在这里插入图片描述

file

第一张图是官方给出的Spark架构图,我们可以看到几个最重要的模块:Spark Core、Spark Streaming、Spark SQL。曾经还有一个部分叫做Structured Streaming,但是这部分好像慢慢被官方抛弃了,现在Spark官方主推SQL并且基于Spark SQL进行的优化和迭代非常之多。如果你是第一次接触Spark,并且业务没有特殊需要,可以暂时忽略Structured Streaming。此外Spark社区在努力的像机器学习和深度学习靠拢,Spark在完成最初的流计算目标后开始发力机器学习方向,如果有兴趣可以接触这一部分的内容。

第二张图是一个简单的Spark快速学习的路线图,一些基本的Linux操作和运维基础,一点简单的搭建虚拟机的基础,我相信这些对大家来说都不是问题。然后我们就可以按照官网的demo进行第一次体验了:http://spark.apache.org/examples.html

Spark的官网中给出了非常简单的Spark入门案例,同样我们也可以直接访问Spark在Github的仓库直接看更多的Demo:

Spark在Github的仓库

关于Spark的书,我个人读了应该有4-5本,每本书都没有达到我的预期,如果说你真的需要一本书来当成工具,我觉得下面的书和Github项目可以用来参考:

第一本书是:《大数据处理框架Apache Spark设计与实现》,这本书主要是介绍Spark的设计和原理,包含一部分源码。你可以把它当成一本八股文书来背,当然也可以当成一本指南来深入理解Spark的设计理念和深层次的原理。

这本书对应了一个Github的Repo:

还有一本电子书:

是关于Spark SQL的,这本书写的可谓用心良苦。对SparkSQL的发展历程和性能的优化、SparkSQL的使用方法、调优、架构、优化器Catalyst以及其他的各个模块都有详细介绍。

除了上面的推荐书对应的repo,Github还有一个酷玩Spark:

这个仓库是由腾讯广告部的同学发起的,主要是Spark 源代码解析、Spark 类库等,源代码部分对Spark Streaming 和 Structured Streaming部分由非常深入的解释。但是这个仓库最后一次维护已经是2019年五月份。大家都知道2019年底Flink开源,可能抢了一部分热度,很多公司都开始转向对Flink的研究。

Spark至今只经历过1.x、2.x和3.x三个大版本的变化,在核心实现上,我们在Github能看到的最早的实现是0.5版本,这个版本只有1万多行代码,就把Spark的核心功能实现了。

当然我们不可能从这么古老的版本看,假如你接触过Spark,现在准备看源码,那么我建议从2.x版本中选取一个,最好是2.3或者2.4。但是经过如此多的迭代,Spark的代码量已经暴增了几倍。关于Spark3.x中的新增功能和优化例如动态资源分配,可以针对性的进行补充即可。

学习 Spark 我们应该掌握:

Spark Core

  • Spark的集群搭建和集群架构(Spark 集群中的角色)
  • Spark Cluster 和 Client 模式的区别
  • Spark 的弹性分布式数据集 RDD
  • Spark DAG(有向无环图)
  • 掌握 Spark RDD 编程的算子 API(Transformation 和 Action 算子)
  • RDD 的依赖关系,什么是宽依赖和窄依赖
  • RDD 的血缘机制
  • Spark 核心的运算机制
  • Spark 的 CheckPoint 和容错
  • Spark 的通信机制
  • Spark Shuffle 原理和过程

Spark Streaming

  • 原理剖析(源码级别)和运行机制
  • Spark Dstream 及其 API 操作
  • Spark Streaming 消费 Kafka 的两种方式
  • Spark 消费 Kafka 消息的 Offset 处理
  • 数据倾斜的处理方案
  • Spark Streaming 的算子调优
  • 并行度和广播变量
  • Shuffle 调优

Spark SQL

  • Spark SQL 的原理和运行机制
  • Catalyst 的整体架构
  • Spark SQL 的 DataFrame
  • Spark SQL 的优化策略:内存列式存储和内存缓存表、列存储压缩、逻辑查询优化、Join 的优化

Structured Streaming

Spark 从 2.3.0 版本开始支持 Structured Streaming,它是一个建立在 Spark SQL 引擎之上可扩展且容错的流处理引擎,统一了批处理和流处理。正是 Structured Streaming 的加入使得 Spark 在统一流、批处理方面能和 Flink 分庭抗礼。

我们需要掌握:

  • Structured Streaming 的模型
  • Structured Streaming 的结果输出模式
  • 事件时间(Event-time)和延迟数据(Late Data)
  • 窗口操作
  • 水印
  • 容错和数据恢复

Spark Mlib

本部分是 Spark 对机器学习支持的部分,我们学有余力的同学可以了解一下 Spark 对常用的分类、回归、聚类、协同过滤、降维以及底层的优化原语等算法和工具。可以尝试自己使用 Spark Mlib 做一些简单的算法应用。

Flink

Flink框架自提出到实现,是有深厚的理论作为背书的,其中又以《Lightweight Asynchronous Snapshots for Distributed Dataflows》最为核心,本文提出了一种轻量级的异步分布式快照(Asynchronous Barrier Snapshot, 简称ABS)方法,既支持无环图,又支持有环图,而且可以做到线性扩展。

传统的流式计算由算子节点和连接算子的数据管道组成,传统的分布式快照方案就像拍照片一样,把每个算子内的state状态和彼此相连管道中的数据都保存下来。ABS方案的提出对传统的流式计算引擎的设计方案可以说是颠覆性的。

另外一篇是《Apache FlinkTM: Stream and Batch Processing in a Single Engine》,严格来说这篇论文是一篇Flink的概要设计文档。可以当成一个技术文档来看,对于很多我们难以理解的设计都有很大的帮助。

此外,《The world beyond batch: streaming 101/102》是由Google的大神Tyler Akidau写的两篇文章。第1篇文章,在深入了解时间,对批处理和流式数据常见处理方式进行高阶阐述之前,介绍一些基本的背景知识和术语。第2篇文章主要介绍包括Google Dataflow大数据平台使用的统一批量+流式传输模式。这两篇文章对于我们理解Flink中的时间、窗口、触发器等等的实现有十分重要的指导意义。并且作者还在YouTube上传了动画,可谓用心良苦。

Apache Flink(以下简称 Flink)项目是大数据处理领域最近冉冉升起的一颗新星,其不同于其他大数据项目的诸多特性吸引了越来越多人的关注。尤其是 2019 年初 Blink 开源将 Flink 的关注度提升到了前所未有的程度。

那么关于 Flink 这个框架我们应该掌握哪些核心知识点?

  • Flink 集群的搭建
  • Flink 的架构原理
  • Flink 的编程模型
  • Flink 集群的 HA 配置
  • Flink DataSet 和 DataSteam API
  • 序列化
  • Flink 累加器
  • 状态 State 的管理和恢复
  • 窗口和时间
  • 并行度
  • Flink 和消息中间件 Kafka 的结合
  • Flink Table 和 SQL 的原理和用法
  • Flink CDC
  • Flink和其他框架的Connector的原理和使用
  • Flink SQL中常见的问题

源码阅读部分:

  • Flink 基本组件和逻辑计划:介绍了 Flink 的基本组件、集群构建的过程、以及客户端逻辑计划的生成过程
  • Flink 物理计划生成:介绍了 Flink JobManager 对逻辑计划的运行时抽象,运行时物理计划的生成和管理等
  • Jobmanager 基本组件和TaskManager的基本组件
  • Flink 算子的生命周期:介绍了 Flink 的算子从构建、生成、运行、及销毁的过程
  • Flink 网络栈:介绍了 Flink 网络层的抽象,包括中间结果抽象、输入输出管理、BackPressure 技术、Netty 连接等
  • Flink的水印和Checkpoint
  • Flink-scheduler:介绍 Flink 的任务调度算法及负载均衡
  • Flink对用户代码异常处理:介绍作业的代码异常后 Flink 的处理逻辑,从而更好的理解 Flink 是如何保证了 exactly-once 的计算语义
  • Flink Table/SQL 执行流程、Flink和Hive的集成等

7.其他

数据仓库&数据湖

  • 数仓理论:范式、分层模型等
  • 数据仓库常见的问题:数据治理、元数据管理等
  • 数据湖理论和架构、用到的框架(Hudi、IceBerg)等

算法

  • 常见的大数据领域的算法:倒排、TopN、布隆过滤、字典树等
  • 了解常见的机器学习算法
  • 了解算法工程化

第三部分:视频&书籍推荐篇

这部分我在之前的分类文章中会有推荐,如果有遗漏可以参考之前的各个分类下的文章。

万能的B站!Orz…

操作系统

参考链接:

数据结构与算法

计算机网络

计算机组成原理

计算机专业应用

实战项目

第四部分:面试篇

我之前写过很详细的:

目前这部分,我会一直更新,让大家不输在面试起跑线上!

第五部分:关于建立知识体系的建议篇

大数据这个方向经过10年的发展已经到了一个分水岭。

对于那些刚入行或者工作有几年的同学们。你们需要:早点建立自己的知识体系。

之前跟几个前同事聊天,聊起招人,吐槽吐槽着聊到这个话题。关于技术人的知识体系的问题。

知识体系其实不光适用在技术人的技术建设上,个人的知识体系建设也很重要。

常见的几个问题,看看大家有没有体会:

一、经常过度陷入技术性细节中

这个表现在什么地方?比如我问你一个问题,xxx功能是如何实现的?很多同学就开始从功能、表结构等等开始讲,很少站在一个系统设计的角度讲这个功能的上下游,为什么需要,为什么不用其他方案。

二、懂的框架太多太杂,全是知识点

数据开发的同学们尤其严重,有些同学在简历上罗列的框架不少于30个。没有基本的工程能力,上来就是分布式、流计算,搞不清楚数据开发在整个企业技术架构中的上下承接关系,后端基础几乎为0。

对于数据这个点来说,搞不清10年来是如何发展到今天的,过度追逐新的框架,人云亦云,盲目上马。对于技术框架解决的业务问题思考过少。太多人问我用不用Pulsar、用不用Flink了,我怎么回答你?你首先要清楚Pulsar、Flink解决了别人解决不了的什么样问题,去翻官网,自己搞个脚手架玩一玩,而不是看到Pulsar吹自己要替代Kafka,Flink吹自己吊打Spark,所以就要用吧。

三、后端基础几乎为0

我可以很负责的告诉大家,一个没有后端开发基础、没有工程能力的数据开发是不合格的,严格意义上都不能被称为开发,不如叫数据分析师或者运维开发好了。所以做过后端的同学们,这是你的天然优势,Spring从0几年开始迭代至今快有20年了,从Spring1.x到Spring Boot的问世,没事就看上一眼,Github有海量的Demo可以一键跑起来,后端技能万万不可抛弃。

Java的后端生态是所有语言中最强大,最全面的。发展至今已经成了互联网的基石,是很难轻易替代的。这也是大多数大数据框架选择Java开发的原因之一。

四、自己画个思维导图,看看自己的技术栈是否完整

不知道有多少同学有这个能力能白板画出自己的技术栈和语言基础栈,你会哪些东西,这些知识点是如何关联的,各自适用于什么样的场景。有多少人能画出Java JUC这个包下的常用类的关系来,类似下图。

file

如果你工作3年以上,能徒手画出这样的类图是基本能力,然后不用别人问你问题,自己都能知道哪里是考点。

这就跟一个考研的同学需要能徒手画出专业课的知识架构来一样是基本要求。

建立自己的知识体系不是一件容易的事,需要大量的外部输入,看大量的文章和别人的经验,也需要强大的执行力。看是一回事,消化掉融进自己的知识体系是另外一回事。

每天我们都被海量的点状信息不断轰炸,各个门户网站、公众号的文章应接不暇,很多人保存一下就没下文了,很可能几年都不翻。我的习惯是,看到一篇好文章,觉得可以实践就立马保存,然后抽时间把他的东西整理一下,整理到自己的学习文档中,附个连接上去。久而久之,随着你自己整理的东西越来越多,整个知识就会像一个Xmind图一样印在脑海里。

没有这样的技术大图在脑海里,如何做技术选型,如何做技术架构?

这件事越早做越好。

你好,我是王知无,一个大数据领域的硬核原创作者,目前大厂在职大数据技术专家。

做过后端架构、数据中间件、数据平台&架构、算法工程化。

专注大数据领域实时动态&技术提升&个人成长&职场进阶,欢迎关注。

  • 7
    点赞
  • 1
    评论
  • 38
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值