20200622——阅读 企业级大数据平台技术栈介绍

大数据历史背景

时间可以拨回到2002年，当时还没有所谓的“大数据”一词，处理海量数据的技术还不为人知。
Doug Cutting创建了全文搜索函数库Lucene想进一步提升，于是在那年2002年10月，Mike Cafarella一起创建了网络搜索引擎Nutch。次年google在发表了著名了《Google File System》论文，这篇论文给予了很大的灵感，于04年7月Nutch实现了GFS的类似的功能NDFS。同年十月，google又发表了著名的论文《MapReduce》，描述了一种基于MapReduce模型的分布式计算框架。零六年，Apache Hadoop项目正式以支持MapReduce和HDFS的独立发展，从此开源的大数据技术逐渐的步入人们的视野。

如果在十年前，我们能使用的开源技术可能仅仅只有Hadoop中的HDFS和MapReduce，经过这么多年发展，Hadoop已经开始泛指大数据生态的代名词。如今的hadoop生态体系已经非常的丰富了，从根本原因来说硬件提升与软件发展使我们不单单要求我们可以存储和计算海量数据，还想更廉价存储海量数据，越来越快的计算数据。不仅如此，大数据的涉足领域也越来越广泛，像批处理，流计算，人工智能和物联网领域都可以看到一些技术框架的身影。那么下面我会以我个人的视角以及技术路线介绍我认知的大数据。

HDFS

之所以把HDFS放在首位介绍，是我认识分布式文件系统在软件架构中是一个重要的基础部分，称作基石。
HDFS是hadoop distributed file system的简称，它是一个被设计成适合运行在廉价机器上的分布式文件存储系统，是GFS的开源实现。

RAID技术

独立冗余磁盘技术，初衷是为了组合诸多廉价的小磁盘来代替昂贵磁盘，同时希望不会因为数据受损而开发出的一种数据保护技术。RAID可以提升硬盘速度增大容量，并且提供容错功能以确保数据安全性。

HDFS个人感觉从基本的设计思路可能和RAID技术一样，只不过HDFS是从软件层面来实现RAID。通过分块存储的方式增强数据的读写性能并突破单机的物理性能的瓶颈，接着用多份冗余存储的方式实现数据的可靠性，保证数据不会丢失。

命名空间

NameNode负责维护文件系统的元数据和操作日志，元数据由fsimage镜像文件保存，等同于在hdfs命名空间中的一个快照文件，保存了所有的地址，描述和创建信息，NameNode在启动的时候会将fsimages中的信息载入到内存以供客户端访问，操作日志由另一个edites文件保存，任何对命名空间或属性的修改都被写入记录下来，当edites文件增长到了阈值之后，hdfs将fsimages和edites文件进行合并，生成的新的文件。

NameNode 与 DataNode

HDFS从设计上是一个Master/Slave架构的服务。NameNode执行文件系统的命名空间操作，比如打开，关闭，重命名文件或者目录。同时它也负责数据块到具体DataNode节点映射。而DataNode负责处理文件系统客户端的读写请求，在NameNode的统一的调度下进行数据快的创建，删除和复制。

Zookeeper

zookeeper是一款分布式协同管理的框架，那么所谓的这种分布式管理到底是在管理些什么。

问题

那么第一个问题，如何快速地运行在多台服务器上的程序配置进行同步更新
master/slave架构是分布式架构常见的集群模式，通过master节点统一管理协调多个slave节点，那么第二个问题是master如何感知slave节点的存在，比如现在有多少个slave链接到了master，他们的状态是什么样的。当master不可用的时候，我们又应该怎么处理。

原子消息广播协议

zab（zookeeper atomic broadcast）是一种分布式一致性的算法，是Paxos算法的简化版本。zab是zookeeper的立足之本。

两阶段提交协议

事务协调者向所有数据库发起commit/rollback请求，并开始等待各参与者节点的响应。

数据库节点执行commit/rollback动作并释放事务占用的资源，之后向事务协调者发送完成消息。

事务协调者收到所有数据库的反馈消息后或取消事务。

两阶段看似解决了分布式数据一致性问题，其实这个设计存在明显的问题。
1）阻塞执行，速度慢，从刚才描述可以看出，协调者和数据库一系列提交或者回滚动作都是阻塞执行的，这必然会导致整个分布式事务运行效率缓慢。

2）单点问题，如果这个节点失效了，整个机制也就瘫痪了。同时由于协调者失败了，会导致数据库的资源一直占用无法释放。

3）数据不一致性，由于网络问题，只有一部分数据库收到了请求信息并执行了commit动作，而另一部分数据库没有收到commit请求，多个数据库之间就会出现一致性问题。

Paxos协议

为了完美解决分布式场景数据一致性的问题，Paxos算法诞生了

Yarn

作为一个大数据底层支撑平台，同时部署Hive，Hbase，等技术组件是一件很正常的事情，这些作为大数据的场景设计的技术组件可以说个个都是消耗资源的大户，这些资源通常就是cpu和内存。通常这些技术组件都有各自的资源调度系统用来管理任务的资源分配，但是同时部署在一起可能就会产生问题了。

这里就会产生两个问题

第一种情况是某些组件可能申请不到服务器资源，比如一台拥有32G内存的服务器资源同时部署了Hbase和Spark，Hbase需要20G内存启动RegionServer，Spark启动某个任务也需要20G内存。每个人都觉得自己可以利用100%的资源，实际上这是不可能满足的事情。

第二种情况是可能出现资源分配不合理的情况，导致整体资源利用率偏低。

Yarn是一款优秀的集群资源调度系统，是Yet Another Resource Negotiator的缩写，它是hadoop的第二代集群资源调度框架。解决了hadoop第一代集群资源调度框架上可靠性差，拓展性等一系列任务。同时yarn从mapreduce中完全独立出来，从专门支撑MapReduce任务升级成了一个支持多种应用类型的通用集群资源调度框架，除了MapReduce之外，Spark和Hive等一系列服务都可以作为应用运行在Yarn上。

资源模型和Container

Yarn将服务器的资源进行了抽象，它使用Container对象代表申请资源的基本单元。这些资源包括资源名称（服务器名称，机架），内存和cpu，Yarn通过Container机制将服务器资源进行了隔离。每个应用都可以通过ApplicationMaster向ResourceManager申请资源。当ApplicationMaster向ResourceMananger申请资源的时候，ResourceMananger返回的是Container的数量来计算。

ResourceManager

ResourceManager是一个全局的资源管理器，负责整个系统的资源管理和分配以保证整个集群的高速有效的运行。它会根据容量，队列等限制条件（比如每个队列分配一定的资源，最多执行的作业等），将系统中的资源分配给各个正在运行的应用程序。ResourceManager只负责根据各个应用程序的请求进行资源分配，不参与任何与具体应用程序相关的工作。比如负责监控或者跟踪应用的执行状态等，负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些都交给ApplicationMaster来管理

applicationMaster

每一个想要运行在yarn上的应用都必须有一个相应的applicationMaster实现，应用将内部的任务调度逻辑和监控都交由他们自己的applicationMaster实现类处理。applicationMaster是Yarn的一个崭新设计。

applicationMaster进程在运行的过程主要负责与ResourceManager进行通信，以申请执行任务时候所需要的资源，在申请资源之后再进一步执行自身内部的调度任务。同时applicationMaster也负责监控自己内部任务状态，在任务失败的时候重新为任务申请相应的资源进行重启。

nodemanager

是每个服务器节点上的资源管理器，负责管理自己所处服务器Containers的整个周期，在yarn上运行的应用最终的逻辑执行程序都会在NodeManager中的Container中运行，可以说nodemanager是yarn计算的节点的代理，