20200609——阅读 企业级大数据平台架构

直接记录，我有收益的干货

hdfs

hadoop distributed file system

raid技术

hdfs与raid

hdfs首先以数据块作为文件的最基本单元，然后通过分块存储的方式增强数据的读写性能并突破单机的物理内存瓶颈（raid 0），接着使用数据块多冗余存储的方式实现数据的可靠性，保证数据不会丢失（raid 1）

命名空间

hdfs支持传统的层次型文件结构，用户或者应用程序可以创建目录，然后将文件保存在这些目录里。文件系统名字空间的层级结构和大多数现有的文件系统类似：用户可以创建/删除/移动或者重命名文件。这种设计使得我们在使用hdfs的时候感觉和本地文件毫无差异。

namenode负责维护文件系统命名空间的元数据和操作日志。其中元数据由fsimage镜像文件保存，它等于hdfs命名空间的一个快照文件，保存了所有文件的地址/描述和创建时间。namenode在启动的时候会将fsimages中的信息载入内存以供客户端访问，而操作日志则由edites文件的大小增长达到阈值的时候，hdfs会将fsimage文件和edites文件进行合并，生成新的fsimages快照。

namenode和datanode

一个hdfs的集群是由一个namenode和数个datanode组成，namenode是一个中心服务器，负责管理文件系统的命名空间以及客户端对文件的访问。集群中的namenode负责管理它所在的节点上的存储。hdfs暴露了文件系统的命名空间，用户能够类似linux文件系统的形式在上面存储数据。namenode执行文件系统的命名空间的操作，比如打开等，它也负责确定数据块到具体的datanode的映射。datanode负责处理文件系统客户端的读写请求，在namenode的统一调度下进行数据块的创建/删除和复制。

客户端发送创建文件请求的时候其实并没有立即发送给namenode，hdfs客户端首先会将文件数据缓存到本地的一个临时文件中去。直到这个临时文件的大小累积到了一个数据块大小的时候，客户端才会联系namenode，namenode会记录这个数据块的元数据并分配一个datanode的数据块分配给它。之后客户端会将本地临时文件传到制定的的datanode上面。假设副本的数量是3，当第一个datanode接受到一小部分数据就将数据写入到本地仓库，并且同时传输该部分到第二个datanode，以此类推

zookeeper

概述

zk是一个分布式协同管理框架，主要用于解决分布式的诸多问题。

既然是分布式系统，我们的程序进程自然会在多台服务器上协同工作，那么我们要解决的第一个问题就是配置同步的问题

配置同步的问题

当配置文件有更新的时候，如何快速的将运行在多个服务器上程序配置进行同步更新？主从架构是分布式常见的一种集群模式，即通过一个master节点就能管理其他的slave节点。那么就会遇到第二个问题，master节点如何感知slave节点的存在，比如现在有多少个slave链接到了master，他们的状态是健康的还是异常的，当master节点不可用的时候，通常需要slave节点中选举一个master保持服务的正常工作。

zk的作用

zk的作用就是帮助我们解决以上的问题。
zk自身拥有高度的可靠性，可拓展性和容错性，能提供统一命名服务，分布式锁，分布式队列，选举，配置同步，心跳检测等功能。有了zk，开发一个分布式系统就会显得容易的很多。

核心特性

zk的目标是基于自身构建更为复杂的分布式应用场景，例如分布式数据库，分布式消息系统和分布式搜索引擎这类实时性要求很高的系统，所以他们自身被设计的非常高速，简单，同时，为了能够支撑分布式场景下事务的一致性，zk提供了一些核心特性

顺序一致性，客户端发送的更新的请求将按照发送的顺序进行执行
原子性，更新操作只有成功和失败两种操作，不会存在其他状态
单一系统视图，客户端链接到任意的服务器都将看到相同的数据视图
可靠性，一旦一个动作被执行更新，所有的服务器都将执行这个动作
及时性，客户看到的视图在一定的时间内保证都是最新的

命名空间

zk允许分布式进程通过共享一个分层的命名空间来进行协同，这点有点类似与linux文件系统的树形结构。这种结构在zk中称为znodes。但是与linux文件系统不同的是，它没有目录和文件之分，所有节点都称为znode。并且znode可以挂载数据，znode也可以嵌套znode

数据模型

zk将znode保存在内存中，这是他能实现高吞吐和低延迟的特性能的重要原因，为了增强可靠性，zk同时会将这些数据以操作日志和快照的形式持久化到硬盘上，以免重启的时候数据丢失。

znode节点分类

persisetent node ：永久节点，除非client显示的删除它，否他它会一直存在。
ephemeral node：ephemeral node是临时的节点，仅在创建该节点client与服务器保持会话期间有效，一旦会话失败，zk会自动删除该节点。同时ephemeral node不能含有子节点

squence node：顺序的节点，创建的时候，zk会自动在节点路径末尾添加递增序号，同时创建client也能设置它是永久保存的还是会话的。

节点监听状态

zk在znode上设计了多种监听状态，创建一个子节点，修改节点，删除节点，我们的客户端可以在这些监听事件中注册自己的回调函数，当某个事件发生的时候，就会自动的触发相应的回调函数。

原子消息广播协议

ZAB 是一种分布式一致性算法， 是Paxos算法的简化版本，可以说是ZAB是zk的立足根本

俩阶段提交协议

在单机数据库时代，我们没有分布式数据一致性问题的困扰，通过数据库事务就能达成轻松的acid的特性从而保证数据的一致性。

当我们进入分布式时代，单机事务就显得力不从心了，在分布式场景下，我们会有多个物理上独立的数据库分布在不同的物理机上。从单独的角度来看，每个单独的数据库内部都能通过单机事务保证数据的一致性，但是一个操作如果同时涉及多个独立数据库的时候，就会出现数据不一致的情况。

于是人们涉及了2pc叫两提交阶段，（two-phasecommit-2pc）的协议来解决这个问题，简单的来说在两阶段提交就是在客户端和多个数据库之间增加了一个事务协调者，同时将事务的提交分为准备和提交两个阶段。

准备阶段

大致流程如下：
1）事务协调者节点向所有数据库询问是否可以执行提交操作，并等待各个参与者节点的相应。
2）数据库节点执行询问发起为止的所有事务操作，并将undo和redo信息写入日志
3）数据库节点相应事务协调者节点发送的询问，如何数据库节点的事务操作实际执行成功，则返回一个同意消息，如何数据库节点的事务操作执行失败，则返回一个中止消息

提交阶段

1）事务协调者向所有数据库发起commit/rollback请求，并开始等待各参与者节点的响应。
2）数据库节点执行commit/rollback动作并释放事务占用的资源，之后向协调者发送完成消息。
3）事务协调者收到所有数据库的反馈消息完成事务或者取消事务。

ZAB协议

zab协议有三种角色，
leader：所有的写请求都会转发到leader节点上，leader节点上数据变更会同步到集群的follower节点上。
follower：负责同步leader节点的数据，并提供数据的查询功能，当leader节点失效的时候，有权利参与投票选举。
observer：同步leader节点的数据，并提供数据的查询功能，没有投票选举，设计的目的是提高集群的查询性能。

hbase

hbase的出现很好的弥补了大数据快查询的能力的空缺。通过hdfs我们拥有了能够海量存储文件的分布式文件系统，通过mr我们拥有了一种对海量数据进行批处理的途径。但是还不够，我们在大数据领域还没有一款可以被称之为数据库的产品。hbase就诞生了。

hbase是一个构建在hdfs之上，分布式的，支持多版本的nosql数据库。它也是google bigtable的开源实现。hbase非常适合于海量数据进行实时随机读写，hbase中的一张表能够支撑十亿行

yarn

yarn是一款优秀的的集群资源调度框架，它是hadoop的第二代集群资源调度框架。解决了hadoop第一代集群资源调框架上可靠性差，拓展性差等一系列问题，同时yarn从mapreduce中完全独立出来，从专门支撑mr任务调度升级成为一个支持多种应用类型的通用集群资源调度框架。除了mr之外，hive，spark等一系列服务都可以作为应用运行在yarn上，统一使用yarn为整个集群资源进行宏观的调度与分配。

资源模型和container

yarn将服务集群资源进行了封装抽象，它使用Container对象代表申请资源的基本单元。这些资源包括（服务器名称，机架）/内存和cpu，yarn通过container机制将服务器资源进行了隔离，每个应用都可以用appmaster向resourcemananger申请资源，

resource manager

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

application master

appmaster进程在运行的过程中主要负责与Resourcemanager进行通信，以申请执行任务时所需要的资源，在申请到一定的资源之后再进一步执行自身内部的调度任务。在任务失败的时候重新为任务申请相应资源并重启任务。