分布式概论课程知识总结1

最新推荐文章于 2022-06-03 10:43:15 发布

muzilan

最新推荐文章于 2022-06-03 10:43:15 发布

阅读量1.8k

点赞数

分类专栏：读书笔记

本文链接：https://blog.csdn.net/muzilanlan/article/details/18570991

版权

读书笔记专栏收录该内容

10 篇文章 0 订阅

订阅专栏

服务器

服务器概念，组成，与主机的区别，分类

概念：在网络环境下运行相应的应用软件，为网上用户提供共享信息资源和各种服务的一种高性能计算机

组成：服务器软件，服务器操作系统，计算机硬件

服务器与主机的区别：

1、主机是通过终端给用户使用的；2、服务器是通过网络给客户端用户使用的。

服务器与PC的区别：

服务器稳定性要求很高，服务器内存都是带ECC校验的，硬盘上服务器一般都会做RAID，安全性很高，速度快

服务器分类：

按计算能力分类：工作组级，部门级，企业级，

按服务类型分类：文件服务器，邮件服务器，数据库服务器，应用程序服务器，Web服务器，缓存服务器。

典型数据库服务器软件

Mysql,sqlserver,orcle

典型Web服务器软件

Nginx,apache

典型Web应用程序服务器容器

IIS，PHP，weblogic，Tomcat，Jetty，Jboss

客户端的分类

桌面应用，智能手机应用，平板电脑应用，（胖客户端）浏览器（瘦客户端）

分布式计算概述

并发与并行概念以及区别

并行：多个任务在同一时刻同时执行，不管在宏观还是微观都是同时执行；并发：多个任务在同一时段同时执行，它在宏观上是同时执行，微观上相互交替执行。“并发”执行，在多个进程存在资源冲突时，并没有从根本提高执行效率。

分布式计算定义

分布式计算是一门计算机科学，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多计算机进行处理，最后把这些计算结果综合起来得到最终的结果

并行计算是相对于串行计算来说的。可分为时间上的并行和空间上的并行。时间上的并行就是指流水线技术，而空间上的并行则是指用多个处理器并发的执行计算。并行计算的目的就是提供单处理器无法提供的性能（处理器能力或存储器），使用多处理器求解单个问题。

分布式计算与并行计算区别

（1）简单的理解，并行计算借助并行算法和并行编程语言能够实现进程级并行（如MPI）和线程级并行（如openMP）。而分布式计算只是将任务分成小块到各个计算机分别计算各自执行。（2）粒度方面，并行计算中，处理器间的交互一般很频繁，往往具有细粒度和低开销的特征，并且被认为是可靠的。而在分布式计算中，处理器间的交互不频繁，交互特征是粗粒度，并且被认为是不可靠的。并行计算注重短的执行时间，分布式计算则注重长的正常运行时间。（3）联系，并行计算和分布式计算两者是密切相关的。某些特征与程度（处理器间交互频率）有关，而我们还未对这种交叉点（crossoverpoint）进行解释。另一些特征则与侧重点有关（速度与可靠性），而且我们知道这两个特性对并行和分布两类系统都很重要。（4）总之，这两种不同类型的计算在一个多维空间中代表不同但又相邻的点。

集群计算定义，集群计算分类

计算机集群使将一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。

集群计算机按功能和结构可以分为，高可用性集群（High-availability (HA) clusters）、负载均衡集群（Loadbalancing clusters）、高性能计算集群（High-performance (HPC)clusters）、网格计算（Grid computing）

网格计算定义，网格计算与集群计算区别

网格计算通过利用大量异构计算机（通常为台式机）的未用资源（CPU周期和磁盘存储），将其作为嵌入在分布式电信基础设施中的一个虚拟的计算机集群，为解决大规模的计算问题提供了一个模型。

区别：

集群是同构的，网格是异构的

（1）简单地，网格与传统集群的主要差别是网格是连接一组相关并不信任的计算机，它的运作更像一个计算公共设施而不是一个独立的计算机。网格通常比集群支持更多不同类型的计算机集合。

（2）网格本质上就是动态的，集群包含的处理器和资源的数量通常都是静态的。在网格上，资源则可以动态出现，资源可以根据需要添加到网格中或从网格中删除。

（3）网格天生就是在本地网、城域网或广域网上进行分布的。网格可以分布在任何地方。而集群物理上都包含在一个位置的相同地方，通常只是局域网互连。集群互连技术可以产生非常低的网络延时，如果集群距离很远，这可能会导致产生很多问题。物理临近和网络延时限制了集群地域分布的能力，而网格由于动态特性，可以提供很好的高可扩展性。

（4）集群仅仅通过增加服务器满足增长的需求。然而，集群的服务器数量、以及由此导致的集群性能是有限的：互连网络容量。也就是说如果一味地想通过扩大规模来提高集群计算机的性能，它的性价比会相应下降，这意味着我们不可能无限制地扩大集群的规模。而网格虚拟出空前的超级计算机，不受规模的限制，成为下一代Internet的发展方向。

（5）集群和网格计算是相互补充的。很多网格都在自己管理的资源中采用了集群。实际上，网格用户可能并不清楚他的工作负载是在一个远程的集群上执行的。尽管网格与集群之间存在很多区别，但是这些区别使它们构成了一个非常重要的关系，因为集群在网格中总有一席之地—— 特定的问题通常都需要一些紧耦合的处理器来解决。然而，随着网络功能和带宽的发展，以前采用集群计算很难解决的问题现在可以使用网格计算技术解决了。理解网格固有的可扩展性和集群提供的紧耦合互连机制所带来的性能优势之间的平衡是非常重要的。

云计算与并行、分布式、网格和集群计算的区别：

云计算是从集群技术发展而来，区别在于集群虽然把多台机器联了起来，但其某项具体任务执行的时候还是会被转发到某台服务器上，而云可以简单的认为是任务可以被分割成多个进程在多台服务器上并行计算，然后得到结果，好处在于大数据量的操作性能非常好。云可以使用廉价的PC服务器，可以管理大数据量与大集群，关键技术在于能够对云内的基础设施进行动态按需分配与管理。云计算与并行计算、分布式计算的区别，以计算机用户来说，并行计算是由单个用户完成的，分布式计算是由多个用户合作完成的，云计算是没有用户参与，而是交给网络另一端的服务器完成的。

分布式系统定义，大型分布式应用系统指标以及分布式计算发展

分布式系统是一组自治的计算机组合，通过通信网络相互连接，实现资源共享和协同工作，而呈现用户的是单个完整的计算机系统。

分布式应用系统指标：资源可访问性，可扩展性，透明性，开放性

大型分布式应用系统指标:高可用性，高可扩展性，高稳定性，高并发，高性能计算，高吞吐，高管理性

XML、JSON

XML概念，特点

XML：可扩展标记语言

特点：

XML 被设计为传输和存储数据，其焦点是数据的内容。

HTML 被设计用来显示数据，其焦点是数据的外观

HTML 旨在显示信息，而XML 旨在传输信息

什么是DTD? 为什么使用DTD?

DTD：文档类型定义

为什么使用DTD：

通过DTD，每一个XML 文件均可携带一个有关其自身格式的描述；通过DTD，独立的团体可一致地使用某个标准的DTD 来交换数据；应用程序也可使用某个标准的DTD 来验证从外部接收到的数据；可以使用DTD 来验证您自身的数据

什么是XML Schema? 为什么使用XML Schema?

XML Schema 是DTD 的继任者

JSON概念，特点，数据结构

JSON指的是JavaScript对象表示法，是轻量级的文本数据交换格式，独立于语言，具有自我描述性，更易理解

特点：是纯文本，具有“自我描述性”，具有层级结构，可通过JavaScript 进行解析

，数据可使用AJAX 进行传输

数据结构：1)Map，也称为对象；｛....｝2)Array；[......]

Object是以｛｝表示，Array是以[ ]表示

XML与JSON转换

WebService

Webservice架构，特点

架构：三个参与者：服务提供者，服务代理，服务请求，三个基本操作：发布（publish），查找（find），绑定/调用（Bind/Invoke）

特点：完好的封装性，松散耦合，使用标准协议规范，高度可互操作性，高度可集成能力，动态性

WebService服务标准（ SOAP,WSDL, UDDI)

对象界面描述: WSDL

对象访问: SOAP 是一个简单的用于在Web上交换结构信息的XML协议

对象界面发现: UDDI

SOAP概念，特性，消息结构，SOAP与HTTP关系

SOAP是一个简单的用于在Web上交换结构信息的XML协议

特性：

1）信封

2）定义了一套编码机制用于交换应用程序定义的数据类型的实例（数据的编码规则）

3）定义了一个用于表示远程过程调用和响应的约定（RPC调用规范）

4）定义了一个使用底层传输协议来完成节点之间交换SOAP信封的约定（SOAP绑定）

消息结构：Request/ResponseMessage

Request 调用远端对象的某个方法

Response 返回该方法运行后的输出结果

Soap与http关系：

SOAP在HTTP协议的基础上，把编写成XML的REQUEST参数, 放在HTTP BODY上提交个WEBSERVICE服务器(SERVLET，ASP什么的) 处理完成后，结果也写成XML作为RESPONSE送回用户端

WSDL概念，三个基本属性，特点，结构，消息交换方式

WSDL：Web服务描述语言

基本属性：服务所提供的操作；数据格式以及访问服务操作的必要协议；由特定协议决定的网络地址，如URL

特点：实现Web 服务体系结构的松散耦合；无论是请求者还是提供者可以各自独立地使用平台、编程语言或分布式对象模型

结构：tyes,message,porttype,binding,service

消息交换方式：单向（One-way）：服务访问端点接收消息；请求响应（Request-response）：服务访问端点接收请求消息，然后发送响应消息；要求应答（Solicit-response）：服务访问端点发送要求消息，然后接收应答消息；通知（Notification）：服务访问端点发送通知消息。

UDDI概念

UDDI概念：通用描述、发现与集成服务，是一个独立于平台的框架，用于通过使用Internet 来描述服务，发现企业，并对企业服务进行集成。

RESTful API

RESTful API概念，特点

概念：表征状态转移，是一种架构风格

特点：一种架构风格；RESTful Web 服务使用标准的HTTP 方法(GET/PUT/POST/DELETE) 来抽象所有Web 系统的服务能力；使用HTTP协议；连接具有无状态性，用json格式来传递消息。

优点：可以利用缓存Cache来提高响应速度；通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性；浏览器即可作为客户端，简化软件需求

相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小；不需要额外的资源发现机制；在软件技术演进中的长期的兼容性更好

REST与SOAP关系

关系：SOAP也可以看作是一种风格，面对的应用需求是RPC，而Rest面对的应用需求是分布式超媒体系统（Web）；Rest架构风格更强调数据，请求和响应消息都是数据的封装。而Soap风格更强调接口， SOAP消息封装的是过程调用。REST是面向资源的，而SOAP是面向接口的；REST架构下，HTTP是承载协议，也是应用协议，而SOAP架构下，HTTP只是承载协议，Soap才是应用协议。

设计思想

网络上的所有事物都被抽象为资源. (Resource)；每个资源有一个唯一的资源标识（resource identifier）；通过通用的连接器接口（generic connector interface）对资源进行操作；对资源的各种操作不会改变资源标识；所有的操作都是无状态的（stateless）

JAX-WS框架

JAX-WS规范是一组XML web services的JAVA API，JAX-WS允许开发者可以选择RPC-oriented或者message-oriented来实现自己的web services。

在服务器端，用户只需要通过Java语言定义远程调用所需要实现的接口SEI（service endpoint interface），并提供相关的实现，通过调用JAX-WS的服务发布接口就可以将其发布为WebService接口。

在客户端，用户可以通过JAX-WS的API创建一个代理（用本地对象来替代远程的服务）来实现对于远程服务器端的调用。

当然 JAX-WS 也提供了一组针对底层消息进行操作的API调用，你可以通过Dispatch 直接使用SOAP消息或XML消息发送请求或者使用Provider处理SOAP或XML消息。

如何利用Jersey编写RESTful API

packagewebresources;

importjavax.ws.rs.Consumes;

importjavax.ws.rs.DELETE;

importjavax.ws.rs.GET;

importjavax.ws.rs.POST;

importjavax.ws.rs.PUT;

importjavax.ws.rs.Path;

importjavax.ws.rs.PathParam;

importjavax.ws.rs.Produces;

importjavax.ws.rs.core.MediaType;

importjavax.ws.rs.core.Response;

importjavax.ws.rs.core.Response.Status;

@Path("/")

public class TaskResource {

privateTaskMgrmgr= null;

publicTaskResource(){

mgr= new TaskMgrImpl();

}

@GET

@Produces(MediaType.APPLICATION_JSON)

@Path("/task/{taskID}")

publicResponse getTask(@PathParam("taskID") String taskID){

TasktaskVO = mgr.getTask(taskID);

if(taskVO!=null){

returnResponse.status(Status.OK).entity(taskVO).build();

}else{

returnResponse.status(Status.NO_CONTENT).entity("").build();

}

@GET

@Produces(MediaType.APPLICATION_JSON)

@Path("/tasks/")

publicResponse searchAllTasks(){

SearchResulttasks = mgr.searchTask();

returnResponse.status(Status.OK).entity(tasks).build();

}

@POST

@Path("/task/")

@Produces(MediaType.APPLICATION_JSON)

@Consumes(MediaType.APPLICATION_JSON)

publicResponse createTask(Task task){

StringtaskID = this.mgr.createTask(task);

StringjsonString ="{\"taskID\":\""+taskID+"\"}";

returnResponse.status(Status.OK).entity(jsonString).build();

}

@PUT

@Path("/task/{taskID}")

@Produces(MediaType.APPLICATION_JSON)

@Consumes(MediaType.APPLICATION_JSON)

publicResponse updateTask(@PathParam("taskID") String taskID, Task task){

TasktaskVO = mgr.getTask(taskID);

if(task==null){

returnResponse.status(Status.BAD_REQUEST).entity("").build();

}else{

if(task.getName()!=null){

taskVO.setName(task.getName());

}

if(task.getDescription()!=null){

taskVO.setDescription(task.getDescription());

}

if(task.getOwner()!=null){

taskVO.setOwner(task.getOwner());

}

mgr.updateTask(taskID,taskVO);

returnResponse.status(Status.OK).entity(taskVO).build();

}

@DELETE

@Produces(MediaType.APPLICATION_JSON)

@Path("/task/{taskID}")

publicResponse deleteTask(@PathParam("taskID") String taskID){

TasktaskVO = mgr.getTask(taskID);

if(taskVO==null){

returnResponse.status(Status.BAD_REQUEST).entity("").build();

}else{

mgr.deleteTask(taskID);

returnResponse.status(Status.NO_CONTENT).entity("").build();

}

GFS, Map-Reduce, Big Table

GFS设计约定，角色，设计思想

GFS设计约定：

1）系统是建立在大量廉价的普通计算机上，这些计算机经常故障。必须对这些计算机持续进行检测，并且在系统的基础上进行：检查，容错，以及从故障中进行恢复。

2）系统存储了大量的超大文件。我们与其有好几百万个文件，每一个超过100MB。数GB的文件经常出现并且应当对大文件进行有效的管理。同时必须支持小型文件，但是我们不必为小型文件进行特别的优化。

3）一般的工作都是由两类读取组成：大的流式读取和小规模的随机读取。在大的流式读取中，每个读操作通常要读取几百k的数据，每次读取1M或者以上的数据也很常见。对于同一个客户端来说，往往会发起连续的读取操作顺序读取一个文件。小规模的随机读取通常在文件的不同位置，读取几k数据。对于性能有过特别考虑的应用通常会作批处理并且对他们读取的内容进行排序，这样可以使得他们的读取始终是单向顺序读取，而不需要往回读取数据

4）通常基于GFS的操作都有很多超大的，顺序写入的文件操作。一旦完成写入，文件就很少会更改。对于文件的随机小规模写入是要被支持的，但是不需要为此作特别的优化

系统必须非常有效的，明确细节的对多客户端并行添加同一个文件进行支持。我们的文件经常使用生产者/消费者队列模式，或者作为多路合并模式进行操作。好几百个运行在不同机器上的生产者，将会并行增加一个文件。其本质就是最小的原子操作的定义。读取操作可能接着生产者操作进行，消费者会同时读取这个文件。

5）高性能的稳定带宽的网络要比低延时更加重要。

GFS概念：

Google文件系统（Google File System），是一个可扩展的分布式文件系统，用于大型的、分布式的对大量数据进行访问的应用。

角色：Client（客户端）：提供给应用程序的访问接口,Master（主服务器）：负责整个文件系统的管理,Chunk Server（数据块服务器）：负责具体的存储工作，数据以文件的形式存储在Chunk Server 上。

设计思想：不同于传统的文件系统，是针对大规模数据处理和Google应用特性而设计的。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。文件以数据块的形式存储；数据块大小固定，每个Chunk都有一个对应的索引号（Index）。利用副本技术保证可靠性；主服务器维护所有文件系统的元数据

GFS架构，GFS读写操作流程

GFS架构：

GFS集群由一个单个的master和好多个chunk server（块服务器）组成；每一个节点都是一个普通的Linux计算机，运行的是一个用户级别（user-level）的服务器进程。

GFS读操作流程：

应用程序发出读请求。
Client将请求转换为（文件名、块位置），然后发送给主服务器。
主服务器返回数据块的指引信息和副本位置信息。
Client选择其中一个位置信息，并给那个块服务器发送请求。
块服务器返回请求的数据。
Client将数据传送给应用程序

GFS写操作流程：

GFS客户端发送请求到主服务器；
主服务器返回块的句柄和副本的位置信息；
客户端将写数据发送给所有副本服务器；
数据存储在副本服务器的缓存中；
客户发送写命令到主副本服务器；
主副本服务器给出写的次序；
主副本服务器将该次序发送给二级副本服务器；
二级副本管理器响应主副本服务器；
主服务器响应客户端。

GFS令牌以及变化顺序：

GFS用令牌的方式来管理在不同副本中的一致的更改顺序。master首先为副本中的一个chunk分配一个令牌，这个副本就是primary副本。这个primary对所有对chunk更改进行序列化。所有的副本都需要根据这个primary的序列进行更改。这样，全局的更改顺序就是首先由master分配的chunk令牌顺序决定的，并且primary决定更改的序列。随着chunk的更改操作的进行，primary可以请求延期并且一般情况下都会收到master的批准。这些延期请求并且批准延期都是通过在master和所有chunkserver之间的HeartBeat心跳消息来承载的。

通过把数据流和控制流的分离，我们可以不考虑哪个chunkserver是primary

GFS高可用性，垃圾回收，数据完整性

高可用性：在一个GFS集群里，会有好几百台服务器，在任何时候都可能会有机器不可用。我们用两条很简单有效的策略来保证整体上的系统高可用性：迅速的恢复机制以及副本机制。

垃圾回收：文件被删除以后，GFS并不立刻要求归还可用的物理存储。它是通过滞后的基于文件和chunk级别的普通垃圾回收机制来完成的。我们发现这样可以使得系统更加简单和可靠。

数据完整性：

各个块服务器利用校检和独立地验证它的副本的完整性。

一个数据块被分为64M大小的小块，每个小块有一个32bit的校检和。

读取时，块服务器先验证数据块的校检和，然后将数据返回给请求者。

遇到读取错误，错误被报告给请求者。主服务器重读数据块

Map-Reduce概述，处理流程，工作过程，整体数据流程图，数据结构，容错考虑，存储位置，任务颗粒度，分区函数，combine函数

概述：它是一种简化并行计算的编程模型，用以进行大数据量的计算，两项核心操作：Map和 Reduce。

处理流程：一组Chunk数据通过Map函数进行一对一的进行映射为另外一组数据，然后分别对这些数据进行并行计算，计算好的结果进行Reduce归约，得最后需要的结果。

工作过程：在Map/Reduce框架中，每一次计算请求，被称为作业。在分布式计算Map/Reduce框架中，为了完成这个作业，它进行两步走的战略，首先是将其拆分成若干个Map任务，分配到不同的机器上去执行，每一个Map任务拿输入文件的一部分作为自己的输入，经过一些计算，生成某种格式的中间文件，这种格式，与最终所需的文件格式完全一致，但是仅仅包含一部分数据。因此，等到所有Map任务完成后，它会进入下一个步骤，用以合并这些中间文件获得最后的输出文件。此时，系统会生成若干个Reduce任务，同样也是分配到不同的机器去执行，它的目标，就是将若干个Map任务生成的中间文件为汇总到最后的输出文件中去。经过如上步骤，最终，作业完成，所需的目标文件生成。整个算法的关键，就在于增加了一个中间文件生成的流程，大大提高了灵活性，使其分布式扩展性得到了保证。

整体数据流程图：

1）用户程序中的MapReduce函数库首先把输入文件分成M块，每块大概16M到64M（可以通过参数决定）。接着在cluster的机器上执行处理程序。

2）这些分排的执行程序中有一个程序比较特别，它是主控程序master。剩下的执行程序都是作为master分排工作的worker。总共有M个map任务和R个reduce任务需要分排。master选择空闲的worker并且分配这些map任务或者reduce任务。

3）一个分配了map任务的worker读取并处理相关的输入小块。他处理输入的数据，并且将分析出的key/value对传递给用户定义的map函数。map函数产生的中间结果key/value对暂时缓冲到内存。

4）这些缓冲到内存的中间结果将被定时刷写到本地硬盘，这些数据通过分区函数分成R个区。这些中间结果在本地硬盘的位置信息将被发送回master，然后这个master负责把这些位置信息传送给reduce的worker

5）当master通知reduce的worker关于中间key/value对的位置时，他调用remoteprocedure来从map worker的本地硬盘上读取缓冲的中间数据。当reduce的worker读到了所有的中间数据，他就使用中间key进行排序，这样可以使得相同key的值都在一起。因为有许多不同key的map都对应相同的reduce任务，所以，排序是必须的。如果中间结果集太大了，那么就需要使用外排序。

6）reduce worker根据每一个唯一中间key来遍历所有的排序后的中间数据，并且把key和相关的中间结果值集合传递给用户定义的reduce函数。reduce函数的对于本reduce区块的输出到一个最终的输出文件

7）当所有的map任务和reduce任务都已经完成了的时候，master激活用户程序。在这时候MapReduce返回用户程序的调用点

数据结构：master需要保存一定的数据结构。对于每一个map和reduce任务来说，都需要保存它的状态（idle，in-progress或者completed），并且识别不同的worker机器（对于非idel的任务状态）

容错考虑：由于MapReduce函数库是设计用于在成百上千台机器上处理海量数据的，所以这个函数库必须考虑到机器故障的容错处理。

存诸位置：网络带宽资源是相对缺乏的，要尽量让输入数据保存在构成集群机器的本地硬盘上(通过GFS管理)的方式来减少网络带宽的开销。GFS把文件分成64M一块，并且每一块都有几个拷贝(通常是3个拷贝)，分布到不同的机器上。

任务颗粒度：

把map阶段拆分到M小块，并且reduce阶段拆分到R小块执行。在理想状态下，M和R应当比worker机器数量要多得多。每一个worker机器都通过执行大量的任务来提高动态的负载均衡能力，并且能够加快故障恢复的速度：这个失效机器上执行的大量map任务都可以分布到所有其他worker机器上执行.

我们通常会用这样的比例来执行MapReduce:M=200，000，R=5，000，使用2，000台worker机器。

分区函数：

MapReduce的使用者通过指定（R）来给出reduce 任务/输出文件的数量。他们处理的数据在这些任务上通过对中间结果key得分区函数来进行分区。缺省的分区函数时使用hash函数

Combine函数：

Combiner函数在每一个map任务的机器上执行。通常这个combiner函数的代码和reduce的代码实现上都是一样的。reduce函数和combiner函数唯一的不同就是MapReduce对于这两个函数的输出处理上不同。对于reduce函数的输出是直接写到最终的输出文件。对于combiner函数来说，输出是写到中间文件，并且会被发送到reduce任务中去。

适应条件：Map/Reduce并不是万能的，适用于Map/Reduce计算有一个先提条件是：待处理的数据集可以分解成许多小的数据集，而且每一个小数据集都可以完全并行地进行处理。

Chubby是Google为解决分布式一致性问题而设计的提供粗粒度锁服务的文件系统

Big Table的数据模型：行，列族，逻辑试图，物理试图，体系结构，数据读写过程

数据模型：BigTable一个稀疏的，长期存储的｛存在硬盘上｝，多维度的，排序的映射表．这张表的索引是行关键字，列关键字和时间戳．每个值是一个不解释的字符数组

行：每行数据有一个可排序的关键字和任意列项

列：特定含义的数据的集合，如图片、链接等

列族：一组列关键字组成了“列族”，这是访问控制的基本单位

物理视图：逻辑上的“表”被划分为若干子表（Tablet）；每个Tablet由多个SSTable文件组成；SSTable文件存储在GFS之上；每个子表存储了table的一部分行

元数据：起始行键、终止行键，如果子表体积超过了阈值（如200M），则进行分割

体系结构：

数据写的流程：

1）任何对子表的写操作都会记录到一个存储在GFS之上的commit log中

* 每个子表服务器上所有子表变化对应于一个commit log

2）新的数据存储到子表服务器的内存（memtable）中

3）次压缩

* 旧数据存储在SSTable中，而新数据存放在memtable中

* 当memtable体积超过一定阈值，将形成SSTable，并写入GFS

* 每个tablet对应多个SSTable

数据读的流程：

Hadoop

Hadoop项目介绍

GFS-->HDFS

MapReduce-->Hadoop
BigTable-->HBase

• 一个分布式文件系统和并行执行环境

• 让用户便捷地处理海量数据

• Apache软件基金会下面的一个开源项目

• 目前Yahoo!是最主要的贡献者

Hadoop特点

1）扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。

2）成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。

3）高效率（Efficient）：通过分发数据，hadoop可以在数据所在的节点上并行地（parallel）处理它们，这使得处理非常的快速。

4）可靠性（Reliable）：hadoop能自动地维护数据的多份复制，并且在任务失败后能自动地重新部署（redeploy）计算任务

Hadoop集群

一个主服务器包含一个namenode和一个jobTracker管理多个slave服器，而每个slave服务器又包含一个datanode和taskTracker

HDFS定义，设计目标，核心组件，系统结构，读写文件过程，失效处理

HDFS定义：Hadoop分布式文件系统，

设计目标：1)write-once-read-many存取模式2)不支持文件并发写入3)不支持文件修改

核心组件：NameNode和DataNode

NameNode	DataNode
• 存储元数据	• 存储文件内容
• 元数据保存在内存中	• 文件内容保存在磁盘
• 保存文件,block ，datanode之间的映射关系	• 维护了block id到datanode本地文件的映射关系

系统结构：

读文件过程：

* 客户端联系NameNode,得到所有数据块信息，以及数据块对应的所有数据服务器的位置信息

* 尝试从某个数据块对应的一组数据服务器中选出一个，进行连接

* 数据被一个包一个包发送回客户端，等到整个数据块的数据都被读取完了，就会断开此链接，尝试连接下一个数据块对应的数据服务器，整个流程，依次如此反复，直到所有想读的都读取完了为止

写文件过程：

失效处理：

MapRedue特性，系统架构，单一Reduce/多个Reduce/无reduce处理

MapReduce特性：1)自动实现分布式并行计算2)容错3)提供状态监控工具4)模型抽象简洁，程序员易用

MapReduce系统架构：它由称为map和reduce的两部分用户程序组成，然后利用框架在计算机集群上面根据需求运行多个程序实例来处理各个子任务，然后再对结果进行归并。

Hadoop应用特点

1）多种应用共用一个Hadoop平台

2）不同应用对硬件资源要求不同

3）作业之间存在依赖关系

4）并发作业数量不稳定

Hadoop主要调度方法：单队列调度，容量调度，公平调度

主要调度方法：

* 单队列调度

* 特点：FIFO

* 优点：简单

* 缺点：资源利用率低

* 容量调度（Capacity Scheduler ，Hadoop-0.19.0 ）

* 特点：

* 多队列，每个队列分配一定系统容量（Guaranteed Capacity）

* 空闲资源可以被动态分配给负载重的队列

* 支持作业优先级

* 作业选择：

* 选择队列：资源回收请求队列优先；最多自由空间队列优先。

* 选择作业：按提交时间、优先级排队；检查用户配额；检查内存。

* 优点：

* 支持多作业并行执行，提高资源利用率

* 动态调整资源分配，提高作业执行效率

* 缺点：

* 队列设置和队列选择无法自动进行，用户需要了解大量系统信息

* 公平调度（Fair Scheduler，Hadoop-0.19.0）

* 目标：

* 改善小作业的响应时间

* 确保生产性作业的服务水平

* 特点：

* 将作业分组——形成作业池（based on a configurable attribute , such as user name, unix group,…）

* 给每个作业池分配最小共享资源（Minimum map slots, Minimum reduce slots ）

* 将多余的资源平均分配给每个作业

* 作业选择：

* 优先调度资源小于最小共享资源的作业

* 选择分配资源与所需资源差距最大的作业

* 优点：

* 支持作业分类调度，使不同类型的作业获得不同的资源分配，提高服务质量

* 动态调整并行作业数量，充分利用资源

* 缺点：

* 不考虑节点的实际负载状态，导致节点负载实际不均衡

Hadoop编程

* 分析WordCount程序

* Map基类Mapper

* Reduce接口

* Combiner函数

* InputFormat, FileInputFormat,TextInputFormat

* OutputFormat, FileOutputFormat,TextOutputFormat

* 例子：日志分析

Hadoop2

Hadoop版本演变

0.20.x è最后演化成1.0.x

0.21.x0.22 è增加NameNode HA等新的重大特性。

Hadoop1与Hadoop2区别

Hadoop1由HDFS与MapReduce组也，而Hadoop2由HDFS、MapReduce和YARN三个分支构成；YARN：资源管理系统

Hadoop2完全不同于Hadoop 1.0，是一套全新的架构，均包含HDFSFederation和YARN两个系统

Hadoop1单个Namenode的HDFS缺陷

1) Namespace（命名空间）的限制

2)性能的瓶颈

3) 隔离问题

4) 集群的可用性

5) Namespace和BlockManagement的紧密耦合

Hadoop2新特性HDFS Federation: 概念，优势以及架构

概念：HDFS Federation就是针对当前HDFS架构上的缺陷所做的改进，简单说HDFS Federation就是使得HDFS支持多个命名空间，并且允许在HDFS中同时存在多个Name Node。

优势：1)先前HDFS只有一个命名空间（Namespace），它使用全部的块。而FederationHDFS中有多个独立的命名空间（Namespace），并且每一个命名空间使用一个块池（block pool）。2)先前HDFS中只有一组块。而Federation HDFS中有多组独立的块。块池（block pool）就是属于同一个命名空间的一组块。3)先前HDFS由一个Namenode和一组datanode组成。而Federation HDFS由多个Namenode和一组datanode，每一个datanode会为多个块池（block pool）存储块。