【大数据复习】知识点框架
1、大数据概述:复习习题集上的例题即可
大数据的特征:
1:数据量大(volume)
非结构化数据的超大规模增长导致数据集合的规模不断扩大,数据单位已经从GB级到TB级再到PB级,甚至开始以EB和ZB来计数。
2:类型繁多(variety)
大数据的类型不仅包括网络日志、音频、视频、图片、地理位置信息等结构化数据,还包括半结构化数据甚至是非结构化数据,具有异构性和多样性的特点。
3:价值密度低(value)
大数据价值密度相对较低。如随着物联网的广泛应用,信息感知无处不在,信息海量,但价值密度较低,存在大量不相关信息。因此需要对未来趋势与模式作可预测分析,利用机器学习、人工智能等进行深度复杂分析。而如何通过强大的机器算法更迅速地完成数据的价值提炼,是大数据时代亟待解决的难题。虽然单位数据的价值密度在不断降低,但是数据的整体价值在提高。
4:处理速度快(velocity)
处理速度快,时效性要求高。需要实时分析而非批量式分析,数据的输入、处理和分析连贯性地处理,这是大数据区分于传统数据挖掘最显著的特征。
大数据的应用:
- 互联网行业,通过大数据分析客户行为,进行商品推荐和针对性的广告投放
- 个人生活:分析个人生活行为习惯,提供更周到的个性化服务
- 物流行业:优化物流网络,提高物流效率,降低物流成本
大数据关键技术:
大数据计算模式:
- 批处理计算:MapReduce、Spark
- 流计算:Storm,S4
- 图计算:GraphX,Hama
- 查询分析计算:Impala,Hive
大数据、云计算、物联网的关系:
区别:大数据侧重于对海量数据的处理、存储和分析。云计算侧重于整合和优化各种IT资源。物联网侧重于实现物物相连,应用创新。
联系:大数据根植于云计算,很多技术都来自于云计算。反之,大数据也为云计算提供了”用武之地“。物联网的传感器产生大量数据,需要借助云计算和大数据技术,实现物联网大数据的存储、分析和处理。
2、Hadoop:注意单机安装和伪分布式安装的区别,以及Hadoop中块的概念及意义!
单机模式(standalone)
单机模式是Hadoop的默认模式。这种模式在一台单机上运行,没有分布式文件系统,而是直接读写本地操作系统的文件系统。
伪分布模式(Pseudo-Distributed Mode)
这种模式也是在一台单机上运行,但用不同的Java进程模仿分布式运行中的各类结点
伪分布模式在“单节点集群”上运行Hadoop,其中所有的守护进程都运行在同一台机器上。该模式在单机模式之上增加了代码调试功能,允许你检查内存使用情况,HDFS输入输出,以及其他的守护进程交互。
全分布模式(Fully Distributed Mode)
Hadoop守护进程运行在一个集群上
块的概念即意义:
在HDFS系统中,为了便于文件的管理和备份,引入分块概念(block)。这里的 块 是HDFS存储系统当中的最小单位,HDFS默认定义一个块的大小为64MB。当有文件上传到HDFS上时,若文件大小大于设置的块大小,则该文件会被切分存储为多个块,多个块可以存放在不同的DataNode上,整个过程中 HDFS系统会保证一个块存储在一个datanode上 。但值得注意的是 如果某文件大小没有到达64MB,该文件并不会占据整个块空间 。
关于块的大小:
设计较大的块,可以把寻址开销分摊到较多的数据中,降低了单位数据的寻址开销。
但也不宜过大,MapReduce中Map任务一次只处理一个块中的数据,启动任务太少,会降低作业并行处理速度。
设置数据块的好处:
- 支持大规模文件存储:文件以块为单位进行存储,一个大规模文件可以被分拆成若干个文件块,不同的文件块可以被分发到不同的节点上,因此,一个文件的大小不会受到单个节点的存储容量的限制,可以远远大于网络中任意节点的存储容量
- 简化系统设计:首先,大大简化了存储管理,因为文件块大小是固定的,这样就可以很容易计算出一个节点可以存储多少文件块;其次,方便了元数据的管理,元数据不需要和文件块一起存储,可以由其他系统负责管理元数据
- 适合数据备份:每个文件块都可以冗余存储到多个节点上,大大提高了系统的容错性和可用性
3、HDFS
(1)名称节点的3大数据结构(FsImage、EditLog以及放在内存中的元数据)的构成,以及合作关系!
- FsImage:维护文件系统树 以及 文件树中的文件和文件夹的元数据;
- EditLog:记录针对文件的创建、删除、重命名等这样的更新操作;
- 元数据(Metadata):维护HDFS文件系统中文件和目录的信息,分为内存元数据和元数据文件两种。NameNode维护整个元数据。
(2)数据存放的策略
集群内:发起操作请求的数据节点
集群外:挑一台磁盘不太满,CPU不太忙的数据节点
(3)数据上传(复制)的流程
流水线复制:
块向名称节点发起写请求,名称节点选择一个数据节点列表返回给客户端,客户端把数据写入第一个datanode,第一个datanode接收到数据,写入本地,然后向第二个datanode写入数据和列表,第二个datanode把数据写入本地,以此类推,形成流水线复制。
(4)数据错误的恢复
名称节点出错
名称节点保存了所有的元数据信息,其中,最核心的两大数据结构是FsImage和Editlog,如果这两个文件发生损坏,那么整个HDFS实例将失效。因此,HDFS设置了备份机制,把这些核心文件同步复制到 备份服务器SecondaryNameNode上。当名称节点出错时,到远程网络挂载的文件系统的获取备份的元数据信息,放到第二名称节点上恢复,然后就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。
数据节点出错
每个数据节点会定期向名称节点发送“心跳”信息,向名称节点报告自己的状态
当数据节点发生故障,或者网络发生断网时,名称节点就无法收到来自一些数据节点的心跳信息,这时,这些数据节点就会被标记为“宕机”,节点上面的所有数据都会被标记为“不可读”,名称节点不会再给它们发送任何I/O请求
这时,有可能出现一种情形,即由于一些数据节点的不可用,会导致一些数据块的副本数量小于冗余因子
名称节点会定期检查这种情况,一旦发现某个数据块的副本数量小于冗余因子,就会启动数据冗余复制,为它生成新的副本。
HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置
数据出错
网络传输和磁盘错误等因素,都会造成数据错误
客户端在读取到数据后,会采用md5和sha1对数据块进行校验,以确定读取到正确的数据
在文件被创建时,客户端就会对每一个文件块进行信息摘录,并把这些信息写入到同一个路径的隐藏文件里面
当客户端读取文件的时候,会先读取该信息文件,然后,利用该信息文件对每个读取的数据块进行校验,如果校验出错,客户端就会请求到另外一个数据节点读取该文件块,并且向名称节点报告这个文件块有错误,名称节点会定期检查并且重新复制这个块。
4、HBase
(1)HBase数据模型、概念视图、物理视图以及列式存储
数据模型:
- 表
- 行
- 列族
- 列限定符
- 单元格
- 时间戳
概念视图:
HBase是稀疏存储数据的,因此某些列可以是空白的
物理视图:
在概念视图上面有些列是空白的,在物理视图这样的列实际上并不会被存储,当请求这些空白的单元格时,会返回null值。
如果在查询的时候不提供时间戳,那么会返回距离现在最近的那一个版本的数据,因为在存储的时候,数据会按照时间戳来排序。
列示存储:
(2)Region定位的三层映射结构
(3)Region服务器的工作原理
1、读写数据
写数据:分配到Region服务器执行,用户数据先写入到MenStore和Hlog中,当写入HLog后,才会调用commit返回客户端。
读数据:Region首先访问MemStore缓存,当数据不在缓存中,才会到磁盘的StoreFile上去找。
2、缓存的刷新
系统会周期性的把MenStore缓存中的数据写到StoreFile中,清空缓存,并在HLog上写入一个标记。
每个Region都有一个HLog,启动时会进行检查,查看HLog是否已经发生写入操作。若无,则数据已经保存到StoreFile中。若有则把更新写入MenStore,然后写入缓存,最后写入StoreFile中,删除旧的HLog。
3、Store的合并
当StoreFile文件的数量达到一个阈值的时候,才会触发合并操作。把多个StoreFile文件合并成一个大文件。
(4)Store的工作原理
每个Store对应表中一个列族的存储,包含一个MemStore缓存和若干个StoreFile文件。
随着StoreFile文件数量的不断增加,达到阈值时,触发合并操作,多个StoreFile合并成一个大的StoreFile,当单个StoreFile的大小超过某个阈值时,又会触发分裂操作。
(5)HLog的工作原理
每个Region服务器共用一个HLog文件,所有Region对象共有一个Hlog文件。
数据恢复:
Zookeeper实时监测每个Region服务器的状态,当R发生故障时,Z会通知Master。系统会根据每条日志所属的Region对象进行拆分,分别放到对应Region对象的目录下,讲失效的R重新分配到可用的R服务器中,并把对应的HLog文件也发送过去,R服务器会重做一遍HLog记录的各种操作,把数据写入MemStore缓存,然后写入StoreFile文件中,完成数据恢复。
5、NoSQL:复习习题课例题即可
(1)NoSQL的四大类型:
- 键值数据库:Redis、Riak
- 列族数据库:HBase,HadoopDB
- 文档数据库:RavenDB,SosoDB
- 图数据库:OrientDB,GraphDB
(2)CAP理论:
- C(一致性):多点的数据是一致的;
- A(可用性):快速获取数据,在确定的时间返回操作结果;
- P(分区容忍性):当出现网络分区(系统部分节点间无法通信),分离的系统也能够正常运行;
- CA:严重影响系统的可拓展性
- CP:网络分区时,受影响的服务需要等待数据一致,在此期间无法对外服务
- AP:允许系统返回不一样的数据
(3)最终一致性:
概念:允许后续的访问操作可用暂时读不到更新后的数据,但一段时间后,必须最终读到更新后的数据。(只要最终数据是一致的就可以,不需要每时每刻数据都一致)
分类:
- 因果一致性
- 读己之所写一致性
- 会话一致性
- 单调读一致性
- 单调写一致性
6、MapReduce:
(1)注意基本关系运算(交,并,差,内外左右连接)的MapReduce中Map端、Shuffle操作以及Reduce端的设计。
基本关系运算:
交
并
差
除
笛卡尔积:R*S 即R的每一行和S的每一行连接
外连接(out join)
外连接分为外左连接(left outer join)和外右连接(right outer join)
注释:left outer join 与 left join 等价, 一般写成left join
right outer join 与 right join等价,一般写成right join
左连接,取左边的表的全部,右边的表按条件,符合的显示,不符合则显示null
举例:select <select list> from A left join B on A.id=B.id
右连接:取右边的表的全部,左边的表按条件,符合的显示,不符合则显示null
举例:select <select list> from A right join B on A.id=B.id
内连接(inner join)
内连接:也称为等值连接,返回两张表都满足条件的部分
注释:inner join 就等于 join
设计:
用MapReduce实现关系的自然连接:
假设有关系R(A,B)和S(B,C),对二者进行自然连接操作
使用Map过程,把来自R的每个元组<a,b>转换成一个键值对<b, <R,a>>,其中的键就是属性B的值。把关系R包含到值中,这样做使得我们可以在Reduce阶段,只把那些来自R的元组和来自S的元组进行匹配。类似地,使用Map过程,把来自S的每个元组<b,c>,转换成一个键值对<b,<S,c>> 所有具有相同B值的元组被发送到同一个Reduce进程中.
Reduce进程的任务是,把来自关系R和S的、具有相同属性B值的元组进行合并 Reduce进程的输出则是连接后的元组<a,b,c>,输出被写到一个单独的输出文件中
(2)尽量搞懂大作业3、5的MapReduce设计
3. Top-k 极值问题
本题为求解一堆数据中最大的前 k 个数,那么我们最终的输出应该是<商品,数量>的 形式。然而,本题中给出的是多个文件,且每个文件中会有商品的重复,因此,本问题可以 由两种方式来解决,一种是自己不写排序过程,2 次 MapReduce 即可完成;一种是把处理 逻辑放在 Reduce 中。 解题思路 1:首先,将该问题变成一个经典的 wordcount 问题,word 即为商品名称,对 应的 count 可以直接从原始文件中取,这样 Map 任务即输出<商品,数量>的集合,假设一 个文件对应一个 Map 任务,则 Reduce 端不需要任何处理,直接将最终的<数量,商品>写入 HDFS 即可,之所以是<数量,商品>的集合,是因为 Shuffle 过程中会对 key 进行排序,若 key 为数量,则我们不需要写任何排序代码,将第一次 MapReduce 生成的文件直接进行 MapReduce 任务,Map 直接读即可,Reduce 端直接迭代并倒序输出即可,不需要任何多余 的代码。该方法代码量非常少(可能自己写的代码只要十几行),实现也非常容易。 解题思路 2:该思路只需要一次 MapReduce 过程,Map 过程类似于 wordcount 过程,在 Reduce 任务中,可以获得所有商品的销售总量的哈希表,基于这个哈希表,我们可以设计 非常多高效的方法进行 Top-k 极值的选择,最简单的方法就是先排序,再取前 k 个,代码量 也很少,且容易实现,但时间复杂度为 O(n2 )。
5. 购物篮数据的关联分析
本题为求解所有的关联集合,用白话来说,给定某个集合 S,若 S 出现在数据集中的次 数达到了 d 以上,则 S 就可以输出了,因此,本题转化为求 S 的个数的问题,基于 MapReduce 的特性,我们 Map 的输出一定得是<集合,在当前数据集中存在的个数>这样的一个键值对, 然而,数据集给的是一条一条的记录,一个记录里可能包含了很多的集合,因此,本题的难 点在于如何把这些集合都拆解出来,而拆解集合其实就是一个求子集的过程,每读到一条购 物记录,则将其所有子集拆出来(只含 1 项的去掉),然后转化为<子集,1>的形式,这样 又变成了 1 个 wordcount 问题,Reduce 过程几乎不用做任何处理。所以,当数据集被读入时, 每读到一个购物记录,则生成该购物记录的所有子集,剔除其中只含有 1 个商品的子集,并 将每个子集计数为 1,并输出。Reduce 端不需要做任何处理,只要判断某个集合的计数是否 不小于 d,若不小于 d 则输出即可,本题完结。
7、Spark
(1)窄依赖、宽依赖的概念
窄依赖定义:一个父RDD的partition至多被子RDD的某个partition使用一次。 一对一、多对一。不会有shuffle的产生。父RDD的一个分区去到子RDD的一个分区。
宽依赖定义: 一个父RDD的partition会被子RDD的某个partition使用多次。 一对多。会有shuffle的产生。父RDD的一个分区的数据去到子RDD的不同分区里面。
(2)stage的划分
- Stage概念
Spark任务会根据RDD之间的依赖关系,形成一个DAG有向无环图,DAG会提交给DAGScheduler,DAGScheduler会把DAG划分相互依赖的多个stage,划分stage的依据就是RDD之间的宽窄依赖。遇到宽依赖就划分stage,每个stage包含一个或多个task任务。然后将这些task以taskSet的形式提交给TaskScheduler运行。 stage是由一组并行的task组成。
- stage切割规则
切割规则:从后往前,遇到宽依赖就切割stage。
(3)RDD的概念,对“血缘关系”以及“惰性调用”的理解
RDD概念:RDD(Resilient Distributed Dataset)叫做分布式数据集,是Spark中最基本的数据抽象,它代表一个不可变、可分区、弹性、里面的元素可并行计算的集合。
RDD的操作:转化操作(Transformation)和行动操作(Action)。RDD 的转化操作是返回一个新的 RDD的操作,比如 map()和 filter(),而行动操作则是向驱动器程序返回结果或把结果写入外部系统的操作。比如 count() 和 first()。
血缘关系:即依赖关系,就是在大量记录上执行的单个文件操作,将创建的RDD的一系列的血缘记录下来,以便恢复丢失的数据,记录的是粗颗粒度的转换操作行为。
惰性调用:RDD采用了惰性调用,即在RDD的执行过程中,真正的计算发生在RDD的“行动”操作,对于“行动”之前的所有“转换”操作,Spark只是记录下“转换”操作应用的一些基础数据集以及RDD生成的轨迹,即相互之间的依赖关系,而不会触发真正的计算。
(4)RDD的操作,以及各个操作的辨析(图10-12)
RDD运行过程
通过对RDD概念、依赖关系和阶段划分的介绍,结合之前介绍的Spark运行基本流程,这里再总结一下RDD在Spark架构中的运行过程(如图9-12所示):
(1)创建RDD对象;
(2)SparkContext负责计算RDD之间的依赖关系,构建DAG;
(3)DAGScheduler负责把DAG图分解成多个阶段,每个阶段中包含了多个任务,每个任务会被任务调度器分发给各个工作节点(Worker Node)上的Executor去执行。
(5)RDD的容错方式
容错方式:Spark的容错策略主要是根据RDD依赖关系重新计算、对RDD做cache、对RDD做checkpoint手段完成RDD计算的故障容错。
- 对于宽依赖实质是指一个父RDD的分区会对应一个或多个子RDD多个分区,在此情况下,如果出现部分计算结果丢失,单一计算丢失的数据无法达到效果,便采用计算该步骤的所有数据,从而导致计算数据重复。
- 对于窄依赖而言,由于窄依赖的一个RDD 分区最多对应一个子RDD 分区,在此情况下出现计算结果丢失,由于计算结果只依赖父RDD相关数据有关,所以不需要计算全部数据,只需计算部分数据即可。
Spark会对数据检查点开销和重新计算RDD分区的开销进行比较,自动选择最优的恢复策略。
(6)彻底搞懂RDD的wordcount代码(10.5.2)
import org.apache.spark.SparkContext import org.apache.spark.SparkContext._ import org.apache.spark.SparkConf object WordCount { def main(args: Array[String]) { val inputFile = "file:///usr/local/spark/mycode/wordcount/word.txt" //用于统计的文本文件 val conf = new SparkConf().setAppName("WordCount").setMaster("local[2]") val sc = new SparkContext(conf) val textFile = sc.textFile(inputFile) val wordCount = textFile.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey((a, b) => a + b) wordCount.foreach(println) } }
8、Storm
(1)彻底读懂Storm的wordcount代码(11.4.5)
public static class WordCount extends BaseBasicBolt { Map<String, Integer> counts = new HashMap<String, Integer>(); public void execute(Tuple tuple, BasicOutputCollector collector) { String word = tuple.getString(0); Integer count = counts.get(word); if (count == null) count = 0; count++; counts.put(word, count); collector.emit(new Values(word, count)); }
(2)会画拓扑图
一个Topology是由spouts和bolts组成的图,Topology是storm里面的最高一级的抽象(类似job),Topology里面的每一个处理节点都包含处理逻辑,而节点之间的连接则表示数据流动的方向。
Topology里面的每一个节点都是并行运行的,在topology里面,你可以指定每个节点的并行度,storm则会在集群里分配那么多线程来同时计算。
一个topology会一直执行,知道你手动kill掉他,storm会自动重新执行失败的任务,并且storm可以保证不会有数据丢失(如果开启了高可靠性的话)。
(3)Storm中各个分组策略的辨析
1)Shuffle Grouping: 随机分组,轮询,平均分配。随机派发stream里面的tuple,保证每个bolt接收到的tuple数目大致相同。
2)Fields Grouping:按字段分组,比如按userid来分组,具有同样userid的tuple会被分到相同的Bolts里的一个task,而不同的userid则会被分配到不同的bolts里的task。
3)All Grouping:广播发送,对于每一个tuple,所有的bolts都会收到。
4)Global Grouping:全局分组,这个tuple被分配到storm中的一个bolt的其中一个task。再具体一点就是分配给id值最低的那个task。
5)Non Grouping:不分组,这stream grouping个分组的意思是说stream不关心到底谁会收到它的tuple。目前这种分组和Shuffle grouping是一样的效果。在多线程情况下不平均分配。
6)Direct Grouping:直接分组,这是一种比较特别的分组方法,用这种分组意味着消息的发送者指定由消息接收者的哪个task处理这个消息。只有被声明为Direct Stream的消息流可以声明这种分组方法。而且这种消息tuple必须使用emitDirect方法来发射。消息处理者可以通过TopologyContext来获取处理它的消息的task的id (OutputCollector.emit方法也会返回task的id)。
7)Local or shuffle grouping:如果目标bolt有一个或者多个task在同一个工作进程中,tuple将会被随机发送给这些tasks。否则,和普通的Shuffle Grouping行为一致。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构