导论

大数据系统的需求包括数据需求、功能需求、性能需求（高性能、高可用、高可扩展、高容错、安全性等）、 计算场景需求

分布式系统/集群 or 大数据处理的目标需求：高性能、高可用、容错性、可伸缩，其中高性能包含三个衡量指标：响应时间（延时）、吞吐量、资源使用率；高可用指标：MTTF、MTTR、可用性=MTTF/（MTTF+MTTR）

大数据与云计算的关系：

• 云计算可以为大数据处理提供充足的计算资源。
• 大数据是云计算服务的典型应用。
• 大数据可以不使用云计算。 大数据计算的典型场景有
• 批处理
• 流计算
• 交互式查询 静态数据有界、持久存储，容量大，适合批处理。

流数据无界、持续产生，需要数据窗口及时处理且看不到尽头。

云计算概述

云计算定义

• 云计算是一种商业计算模型 。它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。
• 通过网络按需提供可动态伸缩的廉价计算服务 ，是一种普遍适用的资源治理思维和模式。
•  云计算是将计算资源比作无处不在的云，是综合虚拟化、分布式计算、效用计算、负载均衡、并行计算、网络存储、热备份冗杂等技术发展演进的结果。

云计算特征

1. 资源虚拟化和池化统一管理
2. 超大规模、高可用、高伸缩
3. 弹性、按需、自助提供服务
4. 泛在接入、准确计费、价格低廉

三类服务模式

1、基础设施即服务 IaaS（Infrastructure as a Service）

提供服务器、存储和网络等计算资源服务

主要功能：

• 用户按需支付 IaaS ，无需购买整套硬件。
• 可根据处理和存储需求扩展基础架构。
• 节省企业购买和维护硬件的成本。
• 数据位于云端，不会有单点故障。 2、平台即服务 PaaS（Platform as a Service）

提供开发、管理和交付的环境软件，如操作系统、数据库、中间件、开发平台。

主要功能

• 提供开发平台和工具，用于软件厂商快速开发、测试、部署运行。
• 软件厂商专注于开发，无需担心底层基础架构。
• 云厂商保证平台的安全性、可靠性和稳定性。 3、软件即服务 SaaS（Software as a Service）

通过网络提供云端软件服务。

主要功能

• 用户付费订阅软件，通过互联网直接访问应用软件，无需管理、安装或者升级软件。
• 数据在云端受到保护，设备故障不丢失。
• 可根据服务需求对资源用量进行扩展。

四种服务形态

公有云:由第三方云服务提供商拥有和运营，并通过 Internet 提供服务的IT基础设施。

优势：成本低、无需维护、按需伸缩、高可靠高可用。

缺点：安全性不可控、资源无法自由定制。

私有云由专供一个企业或组织使用的云计算资源构成。

优点：相比公有云，资源定制更灵活、安全性更高。

缺点：建设和运维成本高。

社区云由多个企业或组织

混合云，通过安全连接将公有云和私有云环境组合起来，允许在不同云环境之间共享数据和应用程序。

– 可控制性高，敏感资产私有云。

– 可用灵活，按需使用公有云。

– 成本效益高，具备公有云的伸缩性。

云计算体系结构

1、SOA构建层

封装云计算能力为标准Web services服务，并纳入到SOA体系。

2、管理中间件层

云计算的资源管理，并对众多应用任务进行调度，使资源能够高效、安全地为应用服务

云计算的核心技术

云计算核心技术主要有虚拟化和容器化，其中容器化技术因为利用共享的操作系统内核，打包应用及其运行环境，比虚拟化更加轻量、快速、低开销，所以是近些年比较受开发人员追捧的技术。

虚拟化技术

虚拟化（Virtualization ）是将计算机资源抽象映射为虚拟的逻辑实体，突破物理资源的界限进行统一管理，构建云计算环境的核心基础技术。

◼ 服务器虚拟化：将一台计算机虚拟为多台逻辑计算机

◼ 存储虚拟化：将底层存储设备抽象化和统一池化管理，独立对外提供存储服务

◼ 网络虚拟化：对将一张物理网卡虚拟成多张虚拟网卡，通过虚拟机来隔离不同应用

◼ 桌面虚拟化：将用户桌面环境与其使用的终端设备解耦，在服务商存放每个人的完整桌面环境，用户使用终端设备通过网络访问自己的桌面

1、服务器虚拟化

虚拟机（Virtual Machine） VM

将一台计算机（物理机、物理服务器）虚拟为多台逻辑计算机

每台虚拟机拥有独立的“硬件”。

虚拟机“硬件”是使用物理机的硬件模拟而来的。

虚拟机执行的工作，实际是由物理机硬件完成的。

虚拟机监视器（ Virtual Machine Monitor ）VMM

VMM是实现物理机虚拟为虚拟机的操作系统或者软件。主要功能是为虚拟机提供虚拟的硬件资源，负责管理和分配这些资源，并确保虚拟机之间的相互隔离。

VMM两种工作模式

1 Hosted 模式（寄居模式、托管模式）： VMM 运行在物理机的操作系统上，安装使用简易方便，性能较低。

寄居虚拟化的虚拟化层一般称为虚拟机监控器（ VMM ）。VMM 通过调用 host OS 获得资源，实现 CPU 、内存和 I/O 设备的虚拟化。 VMM 创建的虚拟机作为 host OS 的一个进程参与调度。寄居模式下 VMM 可以充分利用 host OS 功能来操作硬件设备；但是经过中间环节导致系统损较大。

2 Hypervisor 模式（裸金属模式）： VMM 直接运行在物理机的硬件上，提供接近于物理机的性能。

架构中的 VMM 是一个操作系统，一般称为Hypervisor 。Hypervisor = OS + 虚拟化——具备传统操作系统功能，具备虚拟化功能，包括虚拟资源到物理资源的映射，虚拟机系统的隔离。提供接近于物理机的性能，但是支持的 I/O 设备有限。

服务器虚拟化技术分类

根据对临界指令处理方式的不同

完全虚拟化（Full Virtualization）

半虚拟化（Para Virtualization）

硬件辅助虚拟化（Hardware Assisted Virtualization）

完全虚拟化

1. VMM 为 Guest OS 模拟了完整的底层硬件，包括处理器、物理内存、时钟、外设等，客户机操作系统完全不知道自己运行在虚拟机中。

2. 客户机操作系统及其系统软件不作任何修改就可以在虚拟机中运行。

3. 兼容性很好，安装使用简单。

4. 性能较低（因为VMM需要翻译二进制代码，替换敏感指令）。 半虚拟化

5. 半虚拟化需修改Guest OS 的内核，把原来在物理机上执行的特权指令或者敏感指令，修改成 VMM 的超级调用。

6. Guest OS知道自己运行在虚拟机环境中，不能直接调用内核的特权指令和敏感指令，它通过Host的内核直接对CPU进行调用

7. 性能提升，

8. 但实现困难。 硬件辅助虚拟化

CPU厂商改造 CPU ，引入新的指令和运行模式，帮助VMM 高效地识别和截获敏感指令， 从硬件层面支持虚拟化。通常， Guest OS 的核心指令可以直接下达计算机系统硬件执行，无需经过 VMM 。对于特殊指令，系统会切换到 VMM ，让VMM 来处理特殊指令。

2、存储虚拟化

将底层存储设备抽象化和统一池化管理，独立对外提供存储服务。可以实现：

1. 高可伸缩性，摆脱物理容量限制。

2. 隐藏设备复杂性，统一管理和服务。

3. 整合空间资源，提高设备利用率。

4. 高可靠、高可用。 技术类型

5. 基于主机的虚拟化（支持异构设备，性价比高，但是占有主机资源影响性能，影响主机安全和稳定，可拓展性差）

6. 基于存储设备的虚拟化（主机性能不受影响，但不支持异构设备特定厂商）

7. 基于网络的虚拟化

3、桌面虚拟化

远程桌面服务RDS

虚拟桌面基础架构VDI

智能桌面虚拟化IDV

4、网络虚拟化

open stack核心服务：计算服务nova,存储服务swift，镜像服务glance

虚拟化技术缺陷

1. 虚拟机操作系统运行资源消耗大、启动时间长
2. 中间环节(hypervisor)降低了系统的服务性能
3. 用户更关注自己部署的应用程序，却不得不部署运维操作系统和附带的依赖环境

容器化技术

容器化是在操作系统内核上的轻量级的虚拟化技术。利用共享的操作系统内核的功能，建立一系列资源相互隔离的封闭运行环境，这些封闭运行环境就像一个个容器（container ），应用程序就部署运行在其中。其优势是轻量、敏捷、易扩容、支持DevOps，提高资源利用率节约成本、加速产品迭代、支持微服务架构、实现运维自动化。

1. 容器共享同一套操作系统内核
2. 容器打包了应用及其运行环境
3. 一次构建、跨平台、处处运行
4. 容器轻量、快速启动、低开销 容器实现原理

1、namespace命名空间

命名空间定义了一个封闭的作用域范围，约定：处于处于同一命名空间的进程，只能看到该名字空间下的资源，如主机名、网络、进程、用户、文件系统等。不同名字空间的进程彼此不可见，互不影响。容器是拥有单独名字空间的进程，运行在容器中的应用像是在独立操作系统中运行一样，容器之间互不影响。

每个进程拥有七个命名空间用于隔离不同类型的资源

2、Cgroups(控制群组）

namespace能把进程隔离到一个特定环境中，但是无法限制进程使用的物理资源。cgroups（Control Groups ），是 Linux 内核提供的物理资源隔离机制，可以实现对 Linux 进程或者进程组的资源进行限制、隔离和统计的功能。

容器通过 cgroups 实现对容器所使用物理资源（ CPU 、memory 、 IO 等）的隔离、限制和记录。cgroups把每个容器都当成普通进程对待。通过设置进程组或某个进程的资源限制条件，实现将容器进程与其他进程在资源使用上隔离的目的。

·         A. namespace 实现资源隔离。

·         B. cgroups 实现资源控制。

·         C.每个进程拥有7种命名空间，用于隔离不同类型的资源。

·         D. cgroups 把每个容器都当成普通进程对待。通过设置进程组或某个进程的资源限制条件，实现将容器进程与其他进程在资源使用上隔离的目的。

大数据处理概述

大数据处理过程

大数据处理是针对大数据的采集和预处理、存储和管理、处理和分析、可视化呈现等任务的总和。

数据采集与预处理

数据类型：结构化、半结构化、非结构化

数据来源：业务数据、互联网数据、物联网数据

采集方法：日志采集、网络爬虫、API、政府企业机构共享

数据预处理包括：

• 数据清洗 删除重复值、缺失值处理、列名重命名

• 数据集成 将互相关联的分布式异构数据源逻辑或物理地集成为一体，为用户提供透明的访问服务，数据集成的方式有：

数据整合（ETL+数据仓库，物理统一）

数据联邦（建立统一的逻辑视图）

数据传播（数据在多个应用间传播）

混合方式

• 数据变换 将数据从一种表现形式转换为另一种表现形式：

平滑、聚集、泛化、规范化、属性构造

• 数据规约 在保证数据分析质量的前提下，缩小数据规模:

维度规约：小波变换、PCA（主成分分析）、特征选择

数量规约：聚类、抽样、Logistic回归

大数据数据处理与分析

• 分布式计算模式和框架
  • 批处理：Hadoop、spark
  • 流处理： Storm、Flink
  • 图计算：Pregel、Graph X
• 大数据分析
  • 交互式查询：Hive、Pig、Spark Sql
  • 数据挖掘：Mahout
  • 机器学习：Mllib

大数据存储与管理

大数据解释与可视化

分布式计算原理

分布式系统是网络中的一组计算机节点为了完成共同的任务而组成的协同工作系统，要求高可用、高性能、可伸缩、容错性；包括分布式存储和分布式计算。分片与副本是基本手段。

HDFS如何存储文件

把文件拆成固定大小的单元，单元分散存储到不同节点，访问时从各节点拿来合并。

HDFS如何写入文件

Client向Namenode申请写一个文件，Namenode做好准备，然后告诉Client准备好了。Client收到确认，循环执行如下步骤直至数据写完：（1）向Namenode申请一个Block，Namenode根据规则选出Data Node后告诉Client。（2）Client向指定的Datanode发送数据，Datanode接受数据写到本地。

HDFS如何读取文件

Client向Namenode申请读一个文件，Name Node做好准备后返回该文件对应的元数据。Client接收到文件的元数据信息后，去相应的Datanode请求相应的Block数据，最后拼接形成完整的文件内容。

数据分布式存储的作用：

一、数据冗余以提高可用性。

二、读写分离以提高性能。

分片

按一定规则将数据集划分成相互独立正交的数据子集，分布到不同的节点。分片可以实现高性能、水平扩展、高可用。

分片的要求：分布均匀、负载均衡、迁移数据少（扩缩容）

基于数据范围

数据按Key划分成不同的区间，每个节点负责一个或者多个区间。

支持范围查询，平衡不容易保证。

哈希方式

在哈希值和系统节点之间建立映射关系，从而将哈希值不同的数据分布到不同的节点上。

能解决不平衡问题，

范围查询性能受到影响。

扩缩容需要迁移很多数据

一致性哈希

• 将节点(server）按特征映射到一个首尾相接的hash环上。
• 将数据按特征映射到同一个hash环上。
• 将数据保存到环上顺时针第一个节点上。
• 并且为每个物理节点设置虚拟节点，哈希映射到虚拟节点的数据实际上保存到与之对应的物理节点，虚拟机节点均匀分散到哈希环上，避免数据倾斜和节点雪崩。 扩缩容迁移数据很少，

可能会发生数据倾斜

因为数据倾斜导致的节点雪崩

副本

建立冗余副本是实现容错、高可用的基本手段。

建立副本的策略

单主复制

单主复制有且仅有一个Master副本，其他都是备用的Slave副本，维护Master副本的节点作为中心节点，负责维护数据更新、并发控制、协调副本的一致性。

过程：Master副本宕机后，从Slave选举一个Master,已宕机的master恢复后降为 slave，向新master同步。slave 副本宕机，恢复后从 master 重新同步数据。

存在的问题：

（1）可用性问题：master 宕机后的failover操作、slave 竞选、服务切换到新 master 都需要时间，这段时间内系统阻塞，无法提供服务。

（2）数据一致性问题：master 宕机，某个slave通过竞选成为新的 master，此时新旧 master 之间尚未同步数据，当旧 master 恢复成为一个新slave后，新slave就比新master多一些数据，数据不一致。

（3）成本问题：slave 副本只用于失败转移，有些浪费。

多主复制

*所有副本都是 master，副本之间互为主从。*写操作可以由任意一个 master 处理，再同步到其它 master。

多主复制，在并发操作时存在数据不一致性问题。

无主复制

不区分 master 和 slave 副本，客户端更新数据时，向多个副本发出写请求；客户端查询数据时，向多个副本发出读请求。

客户端可以做一些数据补偿工作，但依然存在数据不一致问题。

副本同步策略

同步复制（synchronous replication）

保证数据复制到所有副本之后，才算是复制完成。副本之间具有强一致性，性能不高。

异步复制（asynchronous replication）

只要数据复制到 master 副本，就算复制完成，其它副本异步处理。性能高，但可能丢失数据或者发生数据脏读。

半同步复制（semi-synchronous replication）

当数据复制达到一个约定数量的副本时，就算复制完成。兼顾性能和一致性。

副本一致性模型

CAP定理

一个分布式系统不可能同时满足一致性、可用性和分区容错性，最多只能满足其中的两项。

• 一致性(Consistentcy) ：所有数据副本的数据都是一致的。
• 可用性(Availability) ：所有请求都能获取正确的响应。
• 分区容错性(Partition tolerance) ：即使发生了网络分区，系统也能对外提供满足一致性和可用性的服务。

网络分化是网络链路出现问题，将集群节点隔离成多个分区，分区之间网络不可达，分区内部正常。

分布式系统必须保证分区容错性，否则失去了分布式的意义，所以需要在一致性和可用性之间权衡。

ACID

• Atomicity（原子性）：事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
• Consistency（一致性）：在事务开始之前和事务结束以后，数据库从一个一致状态变成另一个一致状态，数据完整性不会被破坏。
• Isolation（隔离性）：多个并发事务同时执行，不会互相干扰而导致数据不一致。
• Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 BASE原理

BASE 弱化了一致性，追求分区容错性和可用性与ACID代表了两类不同的设计哲学。

• 基本可用(Basic Availability) 要求系统能够基本运行，一直提供服务，在出现不可预知故障的时候，允许损失部分可用性，如响应延时或者服务降级。

• 软状态(Soft State，柔性状态） 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许不同节点的副本之间存在暂时的不一致情况。

• 最终一致性(Eventually Consistency) 要求数据不能一直处于软状态，必须在一段时间后达到一致，保证所有副本中的数据一致性。

一致性模型定义了分布式系统中数据复制时保持一致性的基本约束。

• 强一致性 任何时刻，任何用户或节点都可以读到最近一次成功更新的副本数据。一致性要求最高，实践中最难以实现。

• 单调一致性 任何时刻，任何用户一旦读到某个数据在某次更新后的值，该用户将不会再读到比这个值更旧的值。弱于强一致性。

• 会话一致性 任何用户，在某一次会话内一旦读到某个数据在某次更新后的值，该用户在该次会话过程中不会再读到比这个值更旧的值。弱于单调一致性，只保证单个用户单次会话内数据的单调修改，对于不同用户间的一致性和同一用户不同会话间的一致性没有保障。

• 最终一致性 最终一致性要求一旦更新成功，各个副本上的数据最终将达到完全一致的状态，但达到完全一致状态所需要的时间不能保障。

• 弱一致性 一旦某个更新成功，用户无法在一个确定时间内读到这次更新的值，且即使在某个副本上读到了新的值，也不能保证在其他副本上可以读到新的值。弱一致性系统一般很难在实际中使用，使用弱一致性系统需要应用程序做更多的工作以使系统可用。

分布式系统的一致性协议

‘

其中Lease、2PC、PAXOS可以实现完全一致性

Lease机制

中心节点保存和维护元数据，要求保证各节点缓存的元数据始终与中心节点上的元数据一致。

使用场景：

（1）客户端读取cache节点的元数据

判断元数据是否已经处于cache节点且Lease处于有效期内。

若是：则直接返回元数据。

若否：则向中心节点请求读取数据。中心节点收到读取请求后，返回元数据一个对应的Lease。

若cache节点接收失败或超时则读取失败，退出流程重试。

若接收成功，则将中心节点返回的元数据及其Lease记录下来，并向客户端返回元数据。

（2）客户端修改元数据

客户端向中心节点发起修改元数据请求。

中心节点收到请求后，阻塞所有新读数据请求，即只接收读请求，但不返回数据。

中心节点等待所有与该数据相关的Lease超时，修改数据并向客户端返回修改成功的信息。

法定人数

假设总共N个副本，写操作至少要成功更新W个副本才认为更新成功，读操作至少要读R个副本才能读到更新后的数据。要求：

W + R > N

可以根据业务调整W和R，从而在可靠性和性能方面进行权衡

两阶段提交协议（2PC）

保持分布式事务一致性的协议，属于同步复制协议，即所有副本数据都同步完成之后才返回客户端结果。

2PC 把数据复制分为两个阶段

表决阶段：主节点将数据发送给所有副本，每个副本都要表决是提交还是回滚，如果副本投提交票，那么它会将数据放到暂存区域，等待最终提交。

提交阶段：主节点收到其他副本的响应，如果副本都投提交票，那么就发送确认提交给所有副本让它们提交更新，数据就会从暂存区域移到永久区域。只要有一个副本返回回滚就整体回滚。

2PC 是典型的 CA 系统，为了保证一致性和可用性，一旦出现网络分区或者节点不可用就会拒绝写操作，把系统变成只读的。

出现节点宕机，2PC会一直阻塞系统，所以在数据复制的场景中不常用，一般用于分布式事务。

Paxos协议

应用场景为多主复制保证一致性（状态机复制+共识算法）。

三种角色

• Proposer：提案者，提出提案（propose），可以有多个。
• Acceptor：表决者，对提案进行 accept 表决。
• Learner：同步者，对确定的提案进行同步。 提案：数据更新请求，可以表示为：[提案编号n，提案内容value]

步骤：

• 每个提案者Proposer在提出提案时，都会首先获取到一个全局唯一性的、递增的提案编号 N，将该编号赋予他要提出的提案。
• 每个表决者Accepter在 accept 某提案后，会将该提案的编号 N 记录在本地，其中最大的提案编号记作 MaxN。每个表决者仅会 accept 编号大于自己本地 MaxN 的提案。
• 一次选举，在众多提案中最终必定且只能有一个提案被选定。
• 一旦一个提案被选定，则其它节点会主动同步（learn）该提案到本地。
• 没有提案被提出，则不会有提案被选定。 prepare-promise, propose-accept or learn, learn

Basic PaxOS的问题只能对一个值形成决议，决议的形成至少需要两次网络来回，在高并发情况下可能需要更多的网络来回，极端情况下甚至可能形成活锁（livelock,两个节点恶意竞争一个值）。

Multi-Paxos基于Basic Paxos做了两点改进：

1. 针对每一个要确定的值，运行一次Paxos算法实例（Instance），形成决议。每一个Paxos实例使用唯一的Instance ID标识。
2. 在所有Proposers中选举一个Leader，由Leader唯一地提交Proposal给Acceptors进行表决。这样没有Proposer竞争，解决了活锁问题。在系统中仅有一个Leader进行Value提交的情况下，Prepare阶段就可以跳过，从而将两阶段变为一阶段，提高效率。 这样即使在网络分化的情况下有多个leader，multi-paxos也最多退化到basic-paxos

参考文章

时钟

分布式系统中的三类事件，每一件都可以触发时钟增加

1. 节点内部事件
2. 发送事件
3. 接收事件 分布式系统中建立逻辑时钟的两种方法

Lamport只能表示因果关系

向量时钟vector clock可以表示因果和并发关系

①Lamport时间戳是一种逻辑时钟表示法，是一个单调增加的整数。按照一定的规则为分布式系统中的每一个事件都打上一个Lamport时间戳，通过比较时间戳的数值大小，可以确定事件的偏序关系。

规 则

• 每个节点本地都有一个时间戳，初始值为0。
• 若事件在节点内发生，本地时间戳加1。
• 若是发送事件，本地时间戳加1并在消息中带上该时间戳。
• 若是接收事件，本地时间戳 = Max(本地时间戳，消息中的时间戳) + 1。 事件先后：先按时间戳排序，相同则按照节点编号排序（特别注意 节点编号由题目给出！！！！！！！！！！！！)

②向量时钟是在 Lamport 时间戳基础上演进的另一种逻辑时钟方法，它通过向量结构(Vector)记录本节点的 Lamport 时间戳和其他节点的 Lamport 时间戳，能够很好描述同时发生关系以及事件的因果关系。向量时钟算法利用了向量这种数据结构将全局各个进程的逻辑时间戳广播给各个进程：每个进程发送事件时都会将当前进程已知的所有进程时间写入到一个向量中，附带在消息中。

事件先后：如果 Tb[Q] > Ta[Q] 并且 Tb[P] < Ta[P]，（即在Q节点上事件b先发生，在P节点上a先发生）则认为a、b同时发生，记作 a <-> b，这也是lamport时间戳无法表示的并发关系(concurrent)。

大数据系统结构

简述什么是大数据系统，在建立大数据系统的时候需要考虑权衡哪些需求）

大数据系统：整合数据采集和预处理、存储和管理、处理和分析、可视化呈现等大数据处理功能的高性能、可伸缩、高可用、高容错、安全易用的软硬件系统；用于帮助用户发现大数据中潜在有价值的信息和知识，把握业务现实，预测业务走向。

大数据系统的结构取决于大数据系统构建的需求和宏观决策，包括业务目标、数据源类型和特点、性能要求、批处理/流式处理（计算框架）、技术选型等。

传统BI架构

数据源+ETL+数据仓库+分析报表

• 围绕数据仓库的结构化分析，缺乏非结构化分析。
• ETL数据预处理功能复杂、臃肿。
• ACID特性，影响性能，无法应对大数据规模。

批处理架构

数据源+ETL+数据存储+批处理+分析报表

• 优点：简单易用，技术选型时用大数据组件替换掉BI组件。
• 缺点：①没有数据仓库对业务支撑的灵活性，对大量报表和复杂钻取场景，需要手工定制；②以批处理为主，缺乏实时支撑。
• 适用场景：以BI场景为主，适于大规模历史数据的离线分析。

流处理架构

**数据源+实时数据通道+流式处理+**消息推送

• 优点：没有臃肿的ETL过程，数据的实效性高。
• 缺点：不存在批处理，对数据的重播和历史统计无法很好的支撑。对于离线分析仅仅支撑窗口之内的分析。
• 适用场景：预警，监控，对数据有有效期要求的情况。

Lambda架构

Lambda架构：批处理层 + 流处理层 +服务层。数据以追加的方式通过两条路径并行写到批和流处理系统。分别针对批和流式两条处理路径提供相应的数据计算逻辑。最终通过服务层整合计算结果视图，进行对外服务的输出。

• 优点：实时+离线分析，对数据分析场景涵盖全面。
• 缺点：需要维护批处理层和速度层两套系统：Hadoop & Storm。同一个业务计算逻辑需要在两层分别实现和运维。查询结果合并比较复杂 & 运维复杂。
• 适用场景：同时存在实时和离线需求的情况。

Kappa架构

简化Lambda架构，删除批处理系统，所有数据都走实时路径，一切数据都视为流。通过流处理系统全程处理实时数据和历史数据。数据作为事件按顺序引入到能容错的分布式统一日志中。事件流作为实时数据进入速度层做流式处理，产生实时视图。事件流同时在长期储存中保存。在必要的时候重播事件流，通过流计算引擎重新计算产生历史数据的视图。

• 优点：解决了Lambda架构里冗余部分，以数据可重播的思想进行了设计，架构简洁。
• 缺点：实施难度较高，尤其数据重播部分。
• 应用场景：同时存在实时和离线需求情况。

Hadoop

Hadoop版本演变：

2.0增加Yarn

3.0 MapReduce基于内存计算、支持多NameNode、精简内核

Hadoop三大核心组件：HDFS、MapReduce、YARN

作用：5731

◼ HDFS是分布式存储框架，把文件分布式存储到多个计算机节点上，适合海量数据的存储。

◼ MapReduce是分布式计算框架，将大规模集群上的并行计算过程抽象为两个函数：Map、Reduce，采用“分而治之”策略，存储在分布式文件系统中的大规模数据集会被切分成许多独立的分片 split，这些分片被多个 Map 任务并行处理。

◼ Yarn作为资源调度平台，并且负责根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩。

HDFS

HDFS体系结构

HDFS的体系结构采用主从（Master/Slave）结构模型，一个HDFS集群通常包括：

（1）一个名称节点（NameNode），名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。

（2）多个数据节点（DataNode），每个数据节点运行一个datanode进程，负责处理客户端的读/写请求，在名称节点的统一调度下进行数据块的创建、删除和复制等操作。数据节点的数据实际上保存在本地Linux文件系统中。

HDFS存储原理

为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上。客户端优先使用在同一机架的数据。优点：

（1）加快数据传输速度

（2）容易检查数据错误

（3）保证数据可靠性

副本存储策略：

（1）第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点；

（2）第二个副本：放置在与第一个副本不同的机架的节点上；

（3）第三个副本：与第一个副本相同机架的其他节点上；

（3）更多的副本：随机节点。

数据读写过程

写文件

Client向Namenode申请写一个文件，namenode做好准备后，告诉Client。Client收到确认，循环执行如下步骤直至数据写完：

1、向Namenode申请一个Block，Namenode根据规则选出DataNode后告诉Client。

2、Client向指定的Datanode发送数据，Datanode接受数据后写到本地。

读取文件

Client向Name Node申请读一个文件，Namenode做好准备后返回该文件对应的元数据信息。Client 接收到文件元数据信息后，去相应的DataNode请求相应Block数据，最后拼接成完整的文件内容。

数据错误与恢复

1、名称节点出错

名称节点保存了所有的元数据信息，如果出错则整个HDFS集群将失效。HDFS设置检查点机制，把这些元数据周期性复制到备份服务器SecondaryNameNode上。当名称节点出错时，就可以根据SecondaryNameNode进行NameNode元数据数据的恢复。

2、数据节点出错

• 每个数据节点会定期向名称节点发送心跳信息，报告自己的状态。
• 当数据节点发生故障或网络异常，名称节点无法收到来自数据集节点的心跳信息，此时数据节点会被标记为宕机，节点上所有数据会被标记为不可读，名称节点不会再给它们发送任何I/O请求。
• 名称节点会定期检查数据块的副本数量，若小于冗余因子，就会启动数据冗余复制。 3、数据出错

网络传输和磁盘错误等因素，会造成数据错误。客户端在读取到数据后，会采用md5码和sha1对数据块进行校验，以确定读取到正确的数据。

Map Reduce体系结构

计算模型

• 将大规模集群上的并行计算过程抽象为两个函数：Map、Reduce。
• 编程容易，无需要掌握分布式并行编程的繁琐细节，即可把自己的程序运行在分布式系统上，实现海量数据的计算。
• 采用“分而治之”策略，存储在分布式文件系统中的大规模数据集会被切分成许多独立的分片（split），这些分片被多个Map任务并行处理。
• 设计理念是“计算向数据靠拢”，而不是“数据向计算靠拢”，因为移动数据需要大量的网络传输开销。
• 采用了Master/Slave架构，包括一个Master和若干个Slave（或Worker）。Master上运行JobTracker，负责作业的调度、处理和失败后的恢复，Slave上运行TaskTracker ，负责接收JobTracker发给它的作业指令。

四个组成部分

1、Client：

• a用户编写MapReduce程序，通过Client提交到JobTracker端。

• b用户可通过Client提供的一些接口查看作业运行状态。 2、Job Tracker：

• a负责资源监控和作业调度，

• b 监控所有Task Tracker与Job的健康状态，一旦发现失败，就将相应的任务转移到其他节点。

• c JobTracker 会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler，可插拔，可自定义），而调度器会在资源出现空闲时，选择合适的任务去使用这些资源。 3、Task Tracker：

• a Task Tracker周期性地通过“心跳”将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker 发送过来的命令并执行相应的操作（如启动新任务、杀死任务等）。

• b Task Tracker 使用”slot（槽）”等量划分本节点上的资源量（CPU、内存等）。一个Task 只有获取到 slot 后才有机会运行，而Hadoop任务调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。（slot 分为Map slot 和Reduce slot 两种，分别供MapTask 和Reduce Task 使用。） 4、Task：分为Map Task 和Reduce Task 两种，均由Task Tracker 启动。

工作流程

（1）程序部署；（2）分配Map任务和Reduce任务；（3）map节点读取数据执行map任务并溢写中 间结果；（4）reduce节点接收中间结果数据并执行reduce任务；（5）将执行结果写入HDFS。

Yarn体系结构

Resource Manager

处理客户端请求、监控NodeManager、启动和监控Application Master、资源调度与分配

全局资源管理器，负责整个系统的资源管理和分配。包括两个组件：调度器（Scheduler）和应用程序管理器（Applications Manager）。

（1）调度器，把集群资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”。调度器是一个可插拔组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器。

（2）应用程序管理器，管理系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。

Application Master

主要功能是：

（1）当用户作业提交后，ApplicationMaster 会与 Resource Manager 协商获取资源，ResourceManager 会以容器的形式为 Application Master 分配资源；

（2）ApplicationMaster 把获得的资源进一步分配给内部的各个任务（Map或Reduce任务），实现资源的“二次分配”；

（3）与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；

（4）定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息；

（5）当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。

Node Manager

NodeManager是驻留在YARN集群中的每个节点上的代理，主要负责：

1. 容器生命周期管理、监控每个容器的资源（CPU、内存等）使用情况
2. 跟踪节点健康状况、以“心跳”的方式与ResourceManager保持通信、向ResourceManager汇报作业的资源使用情况和每个容器的运行状态、
3. 接收来自ApplicationMaster的启动/停止容器的各种请求。 注意：NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理。任务状态的管理工作，是ApplicationMaster完成的，ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态。

JobHistoryServer：统一管理YARN历史任务。

WebAppProxyServer： 任务执行时的Web页面代理。负责监管具体MapReduce任务执行全过程，将从Container那里收集过的任务执行信息汇总并显示到一个Web界面上。

Yarn工作流程

步骤1：用户编写客户端应用程序并向YARN提交，提交内容包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。

步骤2：YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个ApplicationMaster。

步骤3：ApplicationMaster被创建后会首先向ResourceManager注册。

步骤4：ApplicationMaster采用轮询的方式向ResourceManager申请资源。

步骤5：ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源。

步骤6：在容器中启动任务（运行环境、脚本）。

步骤7：各个任务向ApplicationMaster汇报自己的状态和进度。

步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。

YARN统一部署的作用

• 在集群中统一部署资源调度框架YARN，在YARN之上部署各种计算框架。
•  由YARN为这些计算框架提供统一的资源调度管理服务，并且根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩。
•  实现一个集群上的不同应用，负载混搭，有效提高了集群的利用率
•  不同计算框架可以共享底层存储，避免了数据集跨集群移动

ZooKeeper

分布式应用程序可以通过 Zookeeper 实现如下功能：配置管理、命名服务、分布式锁、集群管理

体系架构

Leader

1. 集群中事务请求（写操作）唯一的调度和处理者，保证集群事务的顺序性

2. 集群内部各个服务的调度者 Follower

3. 处理集群非事务请求（读操作）

4. 转发事务请求给Leader

5. 参与事务请求提案的投票

6. 参与Leader选举投票 Observer

7. 处理客户端的非事务请求

8. 转发事务请求给Leader

9. 只提供数据只读服务，不参与任何形式的投票 Leader/Followers 集群架构，使 Zookeeper 具备了主从和主备的能力。

（1）主从：主节点分配任务，从节点具体执行任务。

（2）主备：主节点与备份节点，当主节点失效，尽快从 Followers 中重新选出一个充当新的主节点，保证主节点不宕机。

三种Znode

1. 持久节点（PERSISTENT）：客户端与Zookeeper断开连接后，该节点依旧存在。默认情况下，所有 znode 均持久。
2. 临时节点（EPHEMERAL）：客户端活跃时临时节点有效，当客户端与zookeeper断开连接后，该节点自动删除。临时节点不允许有子节点，在leader选举中临时节点起着重要作用。
3. 顺序节点（SEQUENTIAL）：具有时序编号的节点。顺序节点可以是持久的或者临时的，因此，顺序节点可以是持久顺序节点（PERSISTENT_SEQUENTIAL），或者临时顺序节点（EPHEMERAL_SEQUENTIAL）。 Znode原语操作： 

创建节点（ create ）

 删除节点（ delete ）

 更新节点（ set ）

 获取节点信息（ get ）

 权限控制（getAcl/setAcl）

 事件监听（watch）

znode节点操作特性

1. 多台机器同时创建一个节点，只会有一个成功，可以用作分布式锁
2. 临时节点生命周期与会话一致，会话结束则临时节点删除，常用来做心跳、监控、负载等
3. 顺序节点保证全局节点名唯一，可以用作分布式环境下全局自增id
4. 客户端注册监听关心的目录节点，当节点目录数据发生变化时，Zookeeper会通知客户端

zookeeper提供的服务

配置管理

统一命名服务

集群管理

分布式锁（共享锁、排他锁）

zookeeper如何实现排他锁：

（1）排他锁的表示：通过 znode 表示一个排他锁，如 /x_lock/lock。

（2）获取锁：所有客户端都通过调用 create 接口尝试在 /x_lock 下创建临时子节点/x_lock/lock。当然，最终只会有一个客户端创建成功，则表示该客户端获取了该排他锁。同时，没有获取到锁的其他客户端，注册一个 Watcher 监听子节点的变更情况。

（3）释放锁：获取锁的客户端宕机或者正常完成业务逻辑后，把临时子节点删除，表示释放了这个排他锁。临时子节点删除后，其他客户端又开始新的一轮获取锁的过程。

Kafka

消息队列的两种模型

点对点模型和发布订阅模型

点对点无法实现消息的广播和组播

消息队列五大应用场景

应用解耦、异步通信、流量削峰、日志处理、消息通信

体系架构

• Producer 使用 push模式将消息发布到broke。
• Consumer 使用 pull 模式从 broker 订阅并消费消息。
• Broker（kafka服务器，多个broker构成kafka集群） 发布到Kafka的消息如何组织和存储，从而获得负载均衡和高吞吐量？

1. 发布到Kafka集群的消息都有一个类别，称为Topic。

2. Partition（分区）是实际存放消息的有序队列，其中的每条消息都分配一个有序的唯一标识（称为偏移量，offset） 。

3. 每个Topic可以保存到一个或多个Partition中。发送到Broker的消息会根据分区规则选择存储到哪一个 Partition。如果分区规则设置合理，则所有消息就可以均匀分布到不同的 Partition 中，从而将请求负载平衡到各个集群节点，提高吞吐率。

4. 任何发布到 Partition 的消息都会被追加到 Partition 尾部。这种顺序的磁盘写操作，是保证 Kafka 高吞吐率的重要原因。 Kafka集群如何使用副本获得可用性和容错能力？

5. 在Kafka中，一个 Partition 在集群的不同的 Broker 上有多个副本（Replication）。

6. 多副本的Partition中，只有一个副本是 Leader，其余副本都是 Follower。

7. Leader 负责处理该分区的所有读写操作，Follower 只是被动地从Leader 复制数据。当 Leader 故障时，通过Zookeeper选举一个 Follower 成为 Leader。 Kafka集群如何实现点对点模式和发布订阅模式？

8. Kafka 实现点对点模式。若所有的消费者都隶属于同一个消费组，则所有的消息都会被均衡地投递给每一个消费者，即每条消息只会被一个消费者处理，相当于点对点模式。

9. Kafka 实现发布/订阅模式。若所有的消费者都隶属于不同的消费组，则所有的消息都会被广播给所有的消费者，即每条消息会被所有的消费者处理，相当于发布/订阅模式。