大数据技术学习回顾01-大数据的特点、技术体系(三驾马车) ...

参考泉源：
极客时间专栏：从0开始学大数据，作者：李智慧
大数据技术整体概览

大数据技术体系

大数据处理的主要应用场景包括数据分析、数据挖掘与机器学习。数据分析主要使用 Hive、Spark SQL 等 SQL 引擎完成；数据挖掘与机器学习则有专门的机器学习框架 TensorFlow、Mahout 以及 MLlib 等，内置了主要的机器学习和数据挖掘算法。
别的，大数据要存入分布式文件系统（HDFS），要有序调度 MapReduce 和 Spark 作业执行，并能把执行结果写入到各个应用系统的数据库中，还必要有一个大数据平台整合全部这些大数据组件和企业应用系统。

大数据的两个盘算场景

一般说来，像 MapReduce、Spark 这类盘算框架处理的业务场景都被称作批处理盘算，因为它们通常针对以“天”为单元产生的数据举行一次盘算，然后得到必要的结果，这中心盘算必要花费的时间大概是几十分钟甚至更长的时间。因为盘算的数据是非在线得到的实时数据，而是历史数据，所以这类盘算也被称为大数据离线盘算。
而在大数据领域，另有另外一类应用场景，它们必要对实时产生的大量数据举行即时盘算，比如对于遍布都会的监控摄像头举行人脸识别和嫌犯追踪。这类盘算称为大数据流盘算，相应地，有Storm、Flink、Spark Streaming 等流盘算框架来满意此类大数据应用的场景。 流式盘算要处理的数据是实时在线产生的数据，所以这类盘算也被称为大数据实时盘算。
在典型的大数据的业务场景下，数据业务最通用的做法是，采用批处理的技术处理历史全量数据，采用流式盘算处理实时新增数据。而像 Flink 这样的盘算引擎，可以同时支持流式盘算和批处理盘算。
除了大数据批处理和流处理，NoSQL 系统处理的主要也是大规模海量数据的存储与访问，所以也被归为大数据技术。 NoSQL 曾经在 2011 年左右非常火爆，涌现出 HBase、Cassandra 等很多优秀的产品，其中 HBase 是从 Hadoop 中分离出来的、基于 HDFS 的 NoSQL 系统。
大数据和云盘算的区别

在当今的技术语言体系中，我们应该这样来理解：大数据主要是技术手段，是一系列处理海量数据的方法论和技术实现的总称；而云是一种资源和能力的载体，也是一种商业存在，是可以运行大数据负载和应用的平台。
举个例子来形容两者的区别：你可以把云比作一艘航空母舰，是一个大型综合作战平台，而大数据呢，就比如战斗机这个武器门类，在航母上就成了舰载机，依托航母可以到达更大的作战纵深和更强的投递能力。
平台和工具的区别

现实上，平台除了有用户量、认可度、老板加持等因素之外，还会有 3 个显著特性。

• 吸附效应：平台会不断地吸收中小型的工具，渐渐成为一个能力聚集体。
  
• 规模效应：平台的本钱不会随着使用方的扩展而线性增长，可以或许实现规模化。
  
• 积木效应：平台具备底子通用共享能力，可以或许快速搭建新的业务实现。
  

简单来说，平台就是搭台子，工具来唱戏。平台提供场合，举行宣传，吸引用户，同时还能提供演出的道具，以及数据方面的分析。观众的喜欢各不雷同，但是平台将各种戏搜集在一起，就能满意大多数人的需求。
大数据岗位

通常在互联网领域，越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就必要有懂内核、懂网络、懂 OpenStack、懂分布式存储如Ceph 等等的专业人才。
人才紧缺，就意味着人力本钱会很高，这个就是技术投入的隐性本钱。而且因为技术门槛高，一旦发生职员活动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理本钱所在。
以业务发展为生命线的公司，我们更期望可以或许在业务上取得创新和发展，而不是在技术上取得多么非凡的成绩（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的本钱在这些底子技术的研究上。
进一步讲，论体量和规模，我们自有的底层技术无论怎样是无法与专业的云盘算公司相比的，这就带来另一个问题：怎样为这些优秀人才提供发展和发展？因为既然在体量和规模上比不过，那我们可以或许提供的个人发展空间和机会，肯定也比不过专业云盘算公司
对于大数据，分布式中心件等岗位，也会存在类似的情况，因为它们大多必要体量和规模才气体现技术挑战性和发展空间。
大数据的基本特点

Volume(大量）、Variety(多样性）、Velocity(速度）、Value(代价）、Veracity(精确性）。因为是5个特性都是以“V”开头的英文单词，又叫大数据5V特性
大数据技术的三驾马车

今天我们常说的大数据技术，其实劈头于 Google 在 2004 年前后发表的三篇论文，也就是我们经常听到的“三驾马车”，分别是分布式文件系统 GFS、大数据分布式盘算框架 MapReduce和 NoSQL 数据库系统 BigTable，从先容中也能看出来，一个文件系统、一个盘算框架、一个数据库系统。
三驾马车之一的分布式文件系统 HDFS

大规模数据存储的三个核心问题

1.数据存储容量的问题。既然大数据要办理的是数以 PB 计的数据盘算问题，而一般的服务器磁盘容量通常 1～2TB，那么怎样存储这么大规模的数据呢？
2.数据读写速度的问题。一般磁盘的一连读写速度为几十 MB，以这样的速度，几十 PB 的数据恐怕要读写到天荒地老。
3.数据可靠性的问题。磁盘大约是盘算机装备中最易破坏的硬件了，通常情况一块磁盘使用寿命大概是一年，如果磁盘破坏了，数据怎么办？
通过RAID方式办理大规模存储问题

• 数据存储容量的问题。RAID 使用了 N 块磁盘构成一个存储阵列，如果使用 RAID 5，数据就可以存储在 N-1 块磁盘上，这样将存储空间扩大了 N-1 倍。
  
• 数据读写速度的问题。RAID 根据可以使用的磁盘数量，将待写入的数据分成多片，并发同时向多块磁盘进行写入，显然写入的速度可以得到显着提高；同理，读取速度也可以得到显着提高。不过，必要注意的是，由于传统机械磁盘的访问延长主要来自于寻址时间，数据真正进行读写的时间可能只占据整个数据访问时间的一小部分，所以数据分片后对 N 块磁盘进行并发读写
  操作并不能将访问速度提高 N 倍。
  
• 数据可靠性的问题。使用 RAID 10、RAID 5 或者 RAID 6 方案的时候，由于数据有冗余存储，或者存储校验信息，所以当某块磁盘破坏的时候，可以通过其他磁盘上的数据和校验数据将丢失磁盘上的数据还原。
  

大数据存储的王者-- HDFS

和 RAID 在多个磁盘上进行文件存储及并行读写的思路一样，HDFS 是在一个大规模分布式服务
器集群上，对数据分片后进行并行读写及冗余存储。因为 HDFS 可以摆设在一个比力大的服务
器集群上，集群中全部服务器的磁盘都可供 HDFS 使用，所以整个 HDFS 的存储空间可以到达
PB 级容量

上图是 HDFS 的架构图，从图中你可以看到 HDFS 的关键组件有两个，一个是 DataNode，一个是 NameNode。（21年左右网规的下午考试填空题考过）
DataNode 负责文件数据的存储和读写操作，HDFS 将文件数据分割成若干数据块（Block），
每个 DataNode 存储一部分数据块，这样文件就分布存储在整个 HDFS 服务器集群中。
应用程序客户端（Client）可以并行对这些数据块进行访问，从而使得 HDFS 可以在服务器集群规模上
实现数据并行访问，极大地提高了访问速度。
NameNode 负责整个分布式文件系统的元数据（MetaData）管理，也就是文件路径名、数据块
的 ID 以及存储位置等信息，相当于操作系统中文件分配表（FAT）的角色。HDFS 为了保证数
据的高可用，会将一个数据块复制为多份（缺省情况为 3 份），并将多份雷同的数据块存储在
不同的服务器上，甚至不同的机架上。这样当有磁盘破坏，或者某个 DataNode 服务器宕机，
甚至某个互换机宕机，导致其存储的数据块不能访问的时候，客户端会查找其备份的数据块进行
访问。
HDFS 的高可用设计

• 数据存储故障容错
  

磁盘介质在存储过程中受情况或者老化影响，其存储的数据可能会出现庞杂。HDFS 的应对措施
是，对于存储在 DataNode 上的数据块，盘算并存储校验和（CheckSum）。在读取数据的时
候，重新盘算读取出来的数据的校验和，如果校验不精确就抛出非常，应用程序捕获非常后就到
其他 DataNode 上读取备份数据。

• 磁盘故障容错
  

如果 DataNode 监测到本机的某块磁盘破坏，就将该块磁盘上存储的全部 BlockID 报告给
NameNode，NameNode 检查这些数据块还在哪些 DataNode 上有备份，通知相应的
DataNode 服务器将对应的数据块复制到其他服务器上，以保证数据块的备份数满意要求。
3.DataNode 故障容错
DataNode 会通过心跳和 NameNode 保持通讯，如果 DataNode 超时未发送心跳，NameNode
就会以为这个 DataNode 已经宕机失效，立即查找这个 DataNode 上存储的数据块有哪些，以
及这些数据块还存储在哪些服务器上，随后通知这些服务器再复制一份数据块到其他服务器上，
保证 HDFS 存储的数据块备份数符适用户设置的数目，纵然再出现服务器宕机，也不会丢失数
据。
4.NameNode 故障容错
NameNode 是整个 HDFS 的核心，记录着 HDFS 文件分配表信息，全部的文件路径和数据块存
储信息都生存在 NameNode，如果 NameNode 故障，整个 HDFS 系统集群都无法使用；如果
NameNode 上记录的数据丢失，整个集群全部 DataNode 存储的数据也就没用了。
所以，NameNode 高可用容错能力非常重要。NameNode 采用主从热备的方式提供高可用服
务，请看下图。

集群摆设两台 NameNode 服务器，一台作为主服务器提供服务，一台作为从服务器进行热备，
两台服务器通过 ZooKeeper 推举，主要是通过争夺 znode 锁资源，决定谁是主服务器。而
DataNode 则会向两个 NameNode 同时发送心跳数据，但是只有主 NameNode 才气向
DataNode 返回控制信息。
不要以为 NoSQL 是大数据量的一个一定选择

值得注意的是，不要以为 NoSQL 是大数据量的一个一定选择。事实上，即便数据量增大，关系数据库偶然也依然是一个选择。固然必要明确的是，通常单表在数据量增大时，会产生性能方面的问题，但是可以使用 Sharding 和 Partitioning 技术来缓和；而数据可用性的问题，也可以使用集群加冗余技术来办理，固然，有得必有失，这种情况下，通常会牺牲肯定水平的一致性。
那么，这个数据量多大算大到关系数据库无法承担了呢？我可以给你一个事实，即微博和Twitter 都是使用 MySQL 作为主要推文存储的（，因此你可以看到在现实应用中，关系数据库对于特大数据量的支持也是有乐成实践的。
三驾马车之一的分布式盘算框架 MapReduce

大数据盘算实现过程的简单形貌

如今我们来看，移动盘算程序到数据所在位置举行盘算是怎样实现的呢？

• 将待处理的大规模数据存储在服务器集群的全部服务器上，主要使用 HDFS 分布式文件存储系统，将文件分成很多块（Block），以块为单元存储在集群的服务器上。
  
• 大数据引擎根据集群里差别服务器的盘算能力强弱，在每台服务器上启动若干分布式任务执行进程，这些进程会等待给它们分配执行任务。
  
• 使用大数据盘算框架支持的编程模子举行编程，比如 Hadoop 的 MapReduce 编程模子，或者 Spark 的 RDD 编程模子。应用程序编写好以后，将其打包，MapReduce 和 Spark 都是在JVM 情况中运行，所以打包出来的是一个 Java 的 JAR 包。
  
• 用 Hadoop 或者 Spark 的启动下令执行这个应用程序的 JAR 包，起首执行引擎会解析程序要处理的数据输入路径，根据输入数据量的大小，将数据分成若干片（Split），每一个数据片都分配给一个任务执行进程去处理。
  
• 任务执行进程收到分配的任务后，检查自己是否有任务对应的程序包，如果没有就去下载程序包，下载以后通过反射的方式加载程序。走到这里，最重要的一步，也就是移动盘算就完成了。
  
• 加载程序后，任务执行进程根据分配的数据片的文件地址和数据在文件内的偏移量读取数据，并把数据输入给应用程序相应的方法去执行，从而实如今分布式服务器集群中移动盘算程序，对大规模数据举行并行处理的盘算目的。
  

办理大规模数据分布式盘算的方案——MapReduce

大数据盘算的核心思路是移动盘算比移动数据更划算。
MapReduce 编程模子将大数据盘算过程切分为 Map 和 Reduce 两个阶段，先
复习一下，在 Map 阶段为每个数据块分配一个 Map 盘算任务，然后将全部 map 输出的 Key
进行归并，雷同的 Key 及其对应的 Value 发送给同一个 Reduce 任务去处理。通过这两个阶
段，工程师只必要遵照 MapReduce 编程模子就可以开发出复杂的大数据盘算程序。
MapReduce 运行过程涉及三类关键进程

• 大数据应用进程。这类进程是启动 MapReduce 程序的主入口，主要是指定 Map 和 Reduce
  类、输入输出文件路径等，并提交作业给 Hadoop 集群，也就是下面提到的 JobTracker 进程。
  这是由用户启动的 MapReduce 程序进程，比如我们上期提到的 WordCount 程序。
  

2.JobTracker 进程。这类进程根据要处理的输入数据量，下令下面提到的 TaskTracker 进程启
动相应数量的 Map 和 Reduce 进程任务，并管理整个作业生命周期的任务调度和监控。这是
Hadoop 集群的常驻进程，必要注意的是，JobTracker 进程在整个 Hadoop 集群全局唯一。
3.TaskTracker 进程。这个进程负责启动和管理 Map 进程以及 Reduce 进程。因为必要每个数
据块都有对应的 map 函数，TaskTracker 进程通常和 HDFS 的 DataNode 进程启动在同一个
服务器。也就是说，Hadoop 集群中绝大多数服务器同时运行 DataNode 进程和 TaskTacker
进程。
JobTracker 进程和 TaskTracker 进程是主从关系，主服务器通常只有一台（或者另有一台备机
提供高可用服务，但运行时只有一台服务器对外提供服务，真正起作用的只有一台），从服务器
可能有几百上千台，全部的从服务器听从主服务器的控制和调度安排。主服务器负责为应用程序
分配服务器资源以及作业执行的调度，而详细的盘算操作则在从服务器上完成。
详细的作业启动和盘算过程到底是怎样的呢？

如果我们把这个盘算过程看作一次小小的旅行，这个旅程可以概括如下：

• 应用进程 JobClient 将用户作业 JAR 包存储在 HDFS 中，未来这些 JAR 包会分发给Hadoop 集群中的服务器执行 MapReduce 盘算。
  
• 应用程序提交 job 作业给 JobTracker。
  3.JobTacker 根据作业调度策略创建 JobInProcess 树，每个作业都会有一个自己的JobInProcess 树。
  4.JobInProcess 根据输入数据分片数目（通常情况就是数据块的数目）和设置的 Reduce 数目创建相应数量的 TaskInProcess。
  5.TaskTracker 进程和 JobTracker 进程进行定时通讯。
  
• 如果 TaskTracker 有空闲的盘算资源（有空闲 CPU 核心），JobTracker 就会给它分配任务。分配任务的时候会根据 TaskTracker 的服务器名字匹配在同一台机器上的数据块盘算任务给它，使启动的盘算任务正好处理本机上的数据，以实现我们一开始就提到的“移动盘算比移动数据更划算”。
  7.TaskTracker 收到任务后根据任务类型（是 Map 还是 Reduce）和任务参数（作业 JAR 包路径、输入数据文件路径、要处理的数据在文件中的起始位置和偏移量、数据块多个备份的DataNode 主机名等），启动相应的 Map 或者 Reduce 进程。
  8.Map 或者 Reduce 进程启动后，检查本地是否有要执行任务的 JAR 包文件，如果没有，就去HDFS 上下载，然后加载 Map 或者 Reduce 代码开始执行。
  
• 如果是 Map 进程，从 HDFS 读取数据（通常要读取的数据块正好存储在本机）；如果是Reduce 进程，将结果数据写出到 HDFS。
  

通过这样一个盘算旅程，MapReduce 可以将大数据作业盘算任务分布在整个 Hadoop 集群中运
行，每个 Map 盘算任务要处理的数据通常都能从本地磁盘上读取到。
MapReduce 盘算真正产生奇迹的地方是数据的归并与毗连

对 shuffle 的理解，你只必要记着这一点：分布式盘算必要将不同服务器上的相干
数据归并到一起进行下一步盘算，这就是 shuffle。
shuffle 是大数据盘算过程中最神奇的地方，不管是 MapReduce 还是 Spark，只要是大数据批
处理盘算，肯定都会有 shuffle 过程，只有让数据关联起来，数据的内在关系和代价才会呈现出
来。如果你不理解 shuffle，肯定会在 map 和 reduce 编程中产生狐疑，不知道该怎样精确设计
map 的输出和 reduce 的输入。shuffle 也是整个 MapReduce 过程中最难、最消耗性能的地
方，在 MapReduce 早期代码中，一半代码都是关于 shuffle 处理的。
三驾马车之一的分布式集群资源调度框架 Yarn

要办理什么问题？

在 MapReduce 应用程序的启动过程中，最重要的就是要把 MapReduce 程序分发到大数据集群的服务器上，在 Hadoop 1 中，这个过程主要是通过 TaskTracker 和 JobTracker 通讯来完成。
这个方案有什么缺点吗？
这种架构方案的主要缺点是，服务器集群资源调度管理和 MapReduce 执行过程耦合在一起，如果想在当前集群中运行其他盘算任务，比如 Spark 或者 Storm，就无法统一使用集群中的资源了。
Yarn 是“Yet Another Resource Negotiator”的缩写，字面意思就是“另一种资源调度器”。
Yarn 的架构

下图是 Yarn 的架构。

从图上看，Yarn 包括两个部分：一个是资源管理器（Resource Manager），一个是节点管理器
（Node Manager）。这也是 Yarn 的两种主要进程：ResourceManager 进程负责整个集群的
资源调度管理，通常摆设在独立的服务器上；NodeManager 进程负责详细服务器上的资源和任
务管理，在集群的每一台盘算服务器上都会启动，基本上跟 HDFS 的 DataNode 进程一起出
现。
详细说来，资源管理器又包括两个主要组件：调度器和应用程序管理器。
调度器其实就是一个资源分配算法，根据应用程序（Client）提交的资源申请和当前服务器集群的资源状况进行资源分配。Yarn 内置了几种资源调度算法，包括 Fair Scheduler、Capacity Scheduler 等，你也可以开发自己的资源调度算法供 Yarn 调用。
Yarn 进行资源分配的单元是容器（Container），每个容器包罗了肯定量的内存、CPU 等盘算资源，默认设置下，每个容器包罗一个 CPU 核心。容器由 NodeManager 进程启动和管理，NodeManger 进程会监控本节点上容器的运行状况并向 ResourceManger 进程报告。
应用程序管理器负责应用程序的提交、监控应用程序运行状态等。应用程序启动后必要在集群中运行一个 ApplicationMaster，ApplicationMaster 也必要运行在容器里面。每个应用程序启动后都会先启动自己的 ApplicationMaster，由 ApplicationMaster 根据应用程序的资源需求进一步向 ResourceManager 进程申请容器资源，得到容器以后就会分发自己的应用程序代码到容器上启动，进而开始分布式盘算。
Yarn 的整个工作流程

我们以一个 MapReduce 程序为例，来看一下 Yarn 的整个工作流程。

• 我们向 Yarn 提交应用程序，包括 MapReduce ApplicationMaster、我们的 MapReduce 程
  序，以及 MapReduce Application 启动下令。
  2.ResourceManager 进程和 NodeManager 进程通讯，根据集群资源，为用户程序分配第一个
  容器，并将 MapReduce ApplicationMaster 分发到这个容器上面，并在容器里面启动
  MapReduce ApplicationMaster。
  3.MapReduce ApplicationMaster 启动后立即向 ResourceManager 进程注册，并为自己的应
  用程序申请容器资源。
  4.MapReduce ApplicationMaster 申请到必要的容器后，立即和相应的 NodeManager 进程通
  信，将用户 MapReduce 程序分发到 NodeManager 进程所在服务器，并在容器中运行，运行
  的就是 Map 或者 Reduce 任务。
  5.Map 或者 Reduce 任务在运行期和 MapReduce ApplicationMaster 通讯，报告自己的运行
  状态，如果运行竣事，MapReduce ApplicationMaster 向 ResourceManager 进程注销并释放
  全部的容器资源。
  

MapReduce 如果想在 Yarn 上运行，就必要开发遵照 Yarn 规范的 MapReduce
ApplicationMaster，相应地，其他大数据盘算框架也可以开发遵照 Yarn 规范的
ApplicationMaster，这样在一个 Yarn 集群中就可以同时并发执行各种不同的大数据盘算框架，
实现资源的统一调度管理。
三驾马车回顾–为什么 HDFS 是系统，而 MapReduce 和 Yarn 则是框架？

依靠倒转原则

框架在架构设计上遵照一个重要的设计原则叫“依靠倒转原则”，依靠倒转原则是高层模块不能依靠低层模块，它们应该共同依靠一个抽象，这个抽象由高层模块定义，由低层模块实现。
所谓高层模块和低层模块的划分，简单说来就是在调用链上，处于前面的是高层，后面的是低层。我们以典型的 Java Web 应用举例，用户哀求在到达服务器以后，最先处理用户哀求的是Java Web 容器，比如 Tomcat、Jetty 这些，通过监听 80 端口，把 HTTP 二进制流封装成Request 对象；然后是 Spring MVC 框架，把 Request 对象里的用户参数提取出来，根据哀求的 URL 分发给相应的 Model 对象处理；再然后就是我们的应用程序，负责处理用户哀求，详细来看，还会分成服务层、数据持久层等。
在这个例子中，Tomcat 相对于 Spring MVC 就是高层模块，Spring MVC 相对于我们的应用程序也算是高层模块。我们看到固然 Tomcat 会调用 Spring MVC，因为 Tomcat 要把 Request交给 Spring MVC 处理，但是 Tomcat 并没有依靠 Spring MVC，Tomcat 的代码里不可能有任
何一行关于 Spring MVC 的代码。
那么，**Tomcat 怎样做到不依靠 Spring MVC，却可以调用 Spring MVC？**如果你不了解框架的一般设计方法，这里还是会感到有点小小的神奇是不是？法门就是 Tomcat 和 Spring MVC 都依靠 J2EE 规范，Spring MVC 实现了 J2EE 规范的HttpServlet 抽象类，即 DispatcherServlet，并设置在 web.xml 中。这样，Tomcat 就可以调用 DispatcherServlet 处理用户发来的哀求。
同样 Spring MVC 也不必要依靠我们写的 Java 代码，而是通过依靠 Spring MVC 的设置文件或者 Annotation 这样的抽象，来调用我们的 Java 代码。
所以，Tomcat 或者 Spring MVC 都可以称作是框架，它们都遵照依靠倒转原则。
如今我们再回到 MapReduce 和 Yarn。实现 MapReduce 编程接口、遵照 MapReduce 编程规范就可以被 MapReduce 框架调用，在分布式集群中盘算大规模数据；实现了 Yarn 的接口规范，比如 Hadoop 2 的 MapReduce，就可以被 Yarn 调度管理，统一安排服务器资源。所以说，MapReduce 和 Yarn 都是框架。
相反地，HDFS 就不是框架，使用 HDFS 就是直接调用 HDFS 提供的 API 接口，HDFS 作为底
层模块被直接依靠。
##END提示，>!<

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。