【思维导图】分布式服务框架-thrift

HBase 系统架构图组成部件说明Client：使用HBase RPC机制与HMaster和HRegionServer进行通信Client与HMaster进行通信进行管理类操作Client与HRegionServer进行数据读写类操作Zookeeper：Zookeeper Quorum存储-ROOT-表地址、HMaster地址HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况Zookeeper避免HMaster单点问题HMaster：HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Ma ster Election机制保证总有一个Master在运行主要负责Table和Region的管理工作：1 管理用户对表的增删改查操作2 管理HRegionServer的负载均衡，调整Region分布3 Region Split后，负责新Region的分布4 在HRegionServer停机后，负责失效HRegionServer上Region迁移HRegionServer：HBase中最核心的模块，主要负责响应用户I/O请求，向HDFS文件系统中读写数据HRegionServer管理一些列HRegion对象；每个HRegion对应Table中一个Region，HRegion由多个HStore组成；每个HStore对应Table中一个Column Family的存储；Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效HStore：HBase存储的核心。

由MemStore和StoreFile组成。

MemStore是Sorted Memory Buffer。

用户写入数据的流程：Client写入-> 存入MemStore，一直到MemStore满-> Flush成一个StoreFil e，直至增长到一定阈值-> 触发Compact合并操作-> 多个StoreFile合并成一个St oreFile，同时进行版本合并和数据删除-> 当StoreFiles Compact后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Regio n Split成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster 分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Regio n上。

云计算的分布式计算框架思特奇分布式计算技术介绍（V1.0）北京神州数码思特奇信息技术股份有限公司二〇二〇年八月文档信息变更记录1引言框架中最核心的设计就是：MapReduce和HDFS。

MapReduce就是“任务的分解与结果的汇总”。

HDFS是分布式文件系统，为分布式计算存储提供了底层支持。

MapReduce先将一个任务分解成为多个任务，“Reduce”就是将分解后多任务处理的结果汇总起来，得出最后的分析结果。

在分布式系统中，机器集群把硬件看作资源池，将并行的任务拆分，然后交由每一个空闲机器资源去处理，能够极大地提高计算效率，同时这种资源无关性，对于计算集群的扩展无疑提供了最好的设计保证。

分布式计算就好比蚂蚁吃大象，廉价的机器群可以匹敌任何高性能的计算机。

任务分解处理以后，那就需要将处理以后的结果再汇总起来，这就是Reduce要做的工作。

2HDFS分布式文件系统HDFS是分布式计算的存储基石，具有如下几个特点：a)对于整个集群单一的命名空间。

b)数据一致性。

适合一次写入多次读取的模型，客户端在文件没有被成功创建之前无法看到文件存在。

c)文件会被分割成多个文件块，每个文件块被分配存储到数据节点上，而且根据配置会由复制文件块来保证数据的安全性。

HDFS采用master/slave架构。

一个HDFS集群由一个Namenode和一定数目的Datanode组成。

Namenode是一个中心服务器，负责管理文件系统的namespace和客户端对文件的访问。

Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。

在内部，一个文件分成一个或多个block，这些block存储在Datanode集合里。

Namenode执行文件系统的namespace操作，例如打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。

Datanode在Namenode的指挥下进行block的创建、删除和复制。

云计算学习笔记Hadoop+HDFS和MapReduce+架构浅析 - 34 -IT168文Hadoop HDFS和MapReduce 架构浅析前言Hadoop是一个基于Java的分布式密集数据处理和数据分析的软件框架。

Hadoop在很大程度上是受Google在2021年白皮书中阐述的MapReduce技术的启发。

MapReduce工作原理是将任务分解为成百上千个小任务，然后发送到计算机集群中。

每台计算机再传送自己那部分信息，MapReduce则迅速整合这些反馈并形成答案。

简单来说，就是任务的分解和结果的合成。

Hadoop的扩展性非常优秀，Hadoop可处理分布在数以千计的低成本x86服务器计算节点中的大型数据。

这种高容量低成本的组合引人注目，但Hadoop最吸引人的是其处理混合数据类型的能力。

Hadoop可以管理结构化数据，以及诸如服务器日志文件和Web点击流的数据。

同时还可以管理以非结构化文本为中心的数据，如Facebook和Twitter。

1 Hadoop基本架构Hadoop 并不仅仅是一个用于存储的分布式文件系统，而是在由通用计算设备组成的大型集群上执行分布式应用的框架。

Apache Hadoop项目中包含了下列产品（见图1）。

图1 Hadoop基本组成Pig和Hive是Hadoop的两个解决方案，使得在Hadoop上的编程更加容易，编程人员不再需要直接使用Java APIs。

Pig可加载数据、转换数据格式以及存储最终结果等一系列过程，从而优化MapReduce 运算。

Hive 在Hadoop 中扮演数据仓库的角色。

Hive 可向HDFS添加数据，并允许使用类似SQL的语言进行数据查询。

Chukwa是基于Hadoop集群的监控系统，简单来说就是一个WatchDog。

HBase是一个面向列的分布式存储系统，用于在Hadoop中支持大型稀疏表的列存储数据环境。

MapReduce用于超大型数据集的并行运算。

分布式事务架构设计现今互联网界，分布式系统和微服务架构盛行。

一个简单操作，在服务端非常可能是由多个服务和数据库实例协同完成的。

在一致性要求较高的场景下，多个独立操作之间的一致性问题显得格外棘手。

基于水平扩容能力和成本考虑，传统的强一致的解决方案（e.g.单机事务）纷纷被抛弃。

其理论依据就是响当当的CAP原理。

往往为了可用性和分区容错性，忍痛放弃强一致支持，转而追求最终一致性。

分布式系统的特性在分布式系统中，同时满足CAP定律中的一致性Consistency、可用性Availability和分区容错性Partition Tolerance三者是不可能的。

在绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。

CAP理解：•Consistency：强一致性就是在客户端任何时候看到各节点的数据都是一致的（All nodes see the same data at the same time）。

•Availability：高可用性就是在任何时候都可以读写（Reads and writes always succeed）。

•Partition Tolerance：分区容错性是在网络故障、某些节点不能通信的时候系统仍能继续工作（The system continue to operate despite arbitrary message loss or failure of part of the the system）。

以实际效果而言，分区相当于对通信的时限要求。

系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

ACID理解：•Atomicity 原子性：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。

事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

•Consistency 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。

Thrift基本原理与应用1 背景简介1.1什么是Thrift？Thrift是在2007 年facebook 提交Apache 基金会将Thrift 作为一个开源项目，对于当时的facebook 来说创造thrift 是为了解决facebook 系统中各系统间大数据量的传输通信以及系统之间语言环境不同需要跨平台的特性。

Thrift是一种实现RPC的软件框架，它自定义IDL，消息结构。

1.2RPC与IDLRPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。

RPC 协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。

在OSI网络通信模型中，RPC跨越了传输层和应用层。

RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

接口描述语言（Interface description language，缩写IDL），是CORBA规范的一部分，是跨平台开发的基础。

IDL是用来描述软件组件接口的一种计算机语言。

IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信交流。

1.3 为什么使用Thrift？(1)实现跨语言通信支持C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi等多种语言(2)完成高并发、大数据量传输(3) 使用方便，需要编写的代码较少Thrift的框架结构和原理1.4 其他实现RPC的框架和协议(1)Protocol Buffer，google公司2000年提出的RPC框架(2)Avro，Apache提出的RPC框架(3)SOAP：Simple Object Access Protocol，简单对象访问协议2 Thrift框架结构与基本原理2.1 Thrift框架结构图图 1 Thrift框架结构图2.2 TProtocolTProtocol主要负责结构化数据组装成Thrift消息结构，或者从消息结构中读出结构化数据。

详解Hadoop核心架构通过对Hadoop分布式计算平台最核心的分布式文件系统HDFS、MapReduce 处理过程，以及数据仓库工具Hive和分布式数据库Hbase的介绍，基本涵盖了Hadoop分布式平台的所有技术核心。

通过这一阶段的调研总结，从内部机理的角度详细分析，HDFS、MapReduce、Hbase、Hive是如何运行，以及基于Hadoop数据仓库的构建和分布式数据库内部具体实现。

如有不足，后续及时修改。

HDFS的体系架构整个Hadoop的体系结构主要是通过HDFS来实现对分布式存储的底层支持，并通过MR来实现对分布式并行任务处理的程序支持。

HDFS采用主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode 和若干个DataNode组成的（在最新的Hadoop2.2版本已经实现多个NameNode 的配置-这也是一些大公司通过修改hadoop源代码实现的功能，在最新的版本中就已经实现了）。

NameNode作为主服务器，管理文件系统命名空间和客户端对文件的访问操作。

DataNode管理存储的数据。

HDFS支持文件形式的数据。

从内部来看，文件被分成若干个数据块，这若干个数据块存放在一组DataNode 上。

NameNode执行文件系统的命名空间，如打开、关闭、重命名文件或目录等，也负责数据块到具体DataNode的映射。

DataNode负责处理文件系统客户端的文件读写，并在NameNode的统一调度下进行数据库的创建、删除和复制工作。

NameNode是所有HDFS元数据的管理者，用户数据永远不会经过NameNode。

如图：HDFS体系结构图图中涉及三个角色：NameNode、DataNode、Client。

NameNode是管理者，DataNode是文件存储者、Client是需要获取分布式文件系统的应用程序。

文件写入：1）Client向NameNode发起文件写入的请求。

dubbo和zookeeper的关系转载前⾔：⽹络上很多教程没有描述zookeeper和dubbo到底是什么关系、分别扮演了什么⾓⾊等信息，都是说⼀些似是⽽⾮的话，这⾥终于找到⼀篇⽂章，⽐较⽣动地描述了注册中⼼和微服务框架之间的关系，以及他们之间的合作分⼯。

下⾯附上我读完之后的理解：dubbo是⼀个远程调⽤服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。

⽐如在⼊门demo⾥的暴露服务，使得远程调⽤的协议可以使⽤dobbo协议(dubbo://x.x.x.x)或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡⽅式等。

在不搭配注册中⼼的时候，它也是可以实现服务端和调⽤端的通信的，这种⽅式是点对点通信的，所谓“没有中间商”。

但是如果配置服务发布和调⽤端过多特别是集群的⽅式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置⽂件、服务端机器宕机后不能被感知等。

它可以通过集成注册中⼼，来动态地治理服务发布和服务调⽤。

相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中⼼。

介绍微服务是最近⽐较⽕的概念，⽽微服务框架⽬前主流的有Dubbo和Spring Cloud，两者都是为了解决微服务遇到的各种问题⽽产⽣的，即遇到的问题是⼀样的，但是解决的策略却有所不同，所以这2个框架经常拿来⽐较。

没⽤过Dubbo的⼩伙伴也不⽤担⼼，其实Dubbo还是⽐较简单的，看完本⽂你也能掌握⼀个⼤概，重要的不是代码，⽽是思想。

Dubbo实现服务调⽤是通过RPC的⽅式，即客户端和服务端共⽤⼀个接⼝(将接⼝打成⼀个jar包，在客户端和服务端引⼊这个jar包)，客户端⾯向接⼝写调⽤，服务端⾯向接⼝写实现，中间的⽹络通信交给框架去实现，想深⼊了解的看推荐阅读。

原⽂链接有代码GitHub地址使⽤⼊门服务提供者定义服务接⼝public interface DemoService {String sayHello(String name);}在服务提供⽅实现接⼝public class DemoServiceImpl implements DemoService {@Overridepublic String sayHello(String name) {return "Hello " + name;}}⽤ Spring 配置声明暴露服务provider.xml（省略了beans标签的各种属性）<?xml version="1.0" encoding="UTF-8"?><beans><!-- 当前项⽬在整个分布式架构⾥⾯的唯⼀名称，⽤于计算依赖关系 --><dubbo:application name="helloworld-app" /><!--dubbo这个服务所要暴露的服务地址所对应的注册中⼼，N/A为不使⽤注册中⼼--><dubbo:registry address="N/A"/><!--当前服务发布所依赖的协议；webserovice、Thrift、Hessain、http--><dubbo:protocol name="dubbo" port="20880"/><!--服务发布的配置，需要暴露的服务接⼝--><dubbo:service interface="com.st.DemoService"ref="demoService"/><!--bean的定义--><bean id="demoService" class="com.st.DemoServiceImpl"/></beans>加载 Spring 配置public class Provider {public static void main(String[] args) throws Exception {ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("provider.xml");context.start();System.in.read(); // 按任意键退出}}服务消费者consumer.xml<?xml version="1.0" encoding="UTF-8"?><beans><!-- 消费⽅应⽤名，⽤于计算依赖关系，不是匹配条件，不要与提供⽅⼀样 --><dubbo:application name="consumer-of-helloworld-app"/><dubbo:registry address="N/A"/><!-- ⽣成远程服务代理，可以和本地bean⼀样使⽤demoService --><dubbo:reference id="demoService" interface="com.st.DemoService"url="dubbo://localhost:20880/com.st.DemoService"/></beans>加载Spring配置，并调⽤远程服务public class Consumer {public static void main(String[] args) throws Exception {ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("consumer.xml");context.start();// 获取远程服务代理DemoService demoService = (DemoService)context.getBean("demoService");// 执⾏远程⽅法String hello = demoService.sayHello("world");// Hello worldSystem.out.println( hello );}}这就是典型的点对点的服务调⽤。

Windows下Thrift环境搭建与示例目录WINDOWS下THRIFT环境搭建与示例 (1)目录 (2)1.引言 (3)2.环境搭建 (4)1.1.JAVA环境 (4)1.2.T HRIFT环境 (4)3.THRIFT的基本概念 (4)1.3.数据类型 (4)1.4.服务端编码基本步骤： (5)1.5.客户端编码基本步骤： (5)1.6.数据传输协议 (5)4.实例演示 (6)4.1.THRIFT生成代码 (6)4.1.1.创建thrift文件 (6)4.1.2.编译thrift文件 (6)4.2.代码实现 (7)4.2.1.实现服务端接口 (7)4.2.2.TSimpleServer服务端 (8)4.2.3.客户端 (9)4.3.依赖库设置 (12)4.4.运行 (12)1.引言本文档介绍windows环境下thrift的环境搭建与开发。

IDE为Eclipse，语言为Java。

Thrift是一个软件框架，用来进行可扩展且跨语言的服务的开发。

它结合了功能强大的软件堆栈和代码生成引擎，以构建在C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 等等编程语言间无缝结合的、高效的服务。

官网地址：参考：/soa/rpc/thrift-sample//jnb/jnbJun2009.html/thrift/static/files/thrift-20070401.pdf/search-engine/thrift-for-windows//search-engine/thrift-rpc/2.环境搭建1.1.java环境下载JDK和ANT，并且配置环境变量。

测试是否配置成功,如下:下载安装Eclipse，用于java程序的开发。

1.2.Thrift环境下载Thrift: /download解压thrift-0.9.1.tar.gz，复制到C盘。

Hadoop整体框架以及各组件⼯作机制、流程详解。

⼀、概述1.1、Hadoop是什么？Hadoop是⼀个由Apache基⾦会所开发的分布式系统基础架构。

⽤户可以在不了解分布式底层细节的情况下，开发分布式程序。

充分利⽤集群的威⼒进⾏⾼速运算和存储。

Hadoop由HDFS、MapReduce、HBase、Hive和ZooKeeper等成员组成，其中最基础最重要的两种组成元素为底层⽤于存储集群中所有存储节点⽂件的⽂件系统HDFS(Hadoop Distributed File System)和上层⽤来执⾏MapReduce程序的MapReduce引擎。

Hadoop=HDFS+MapReduce+HBase+...1.2、为什么要开发使⽤Hadoop？开发背景：我们处理的数据⽇趋庞⼤，⽆论是⼊库和查询，都出现性能瓶颈，⽤户的应⽤分析结果呈整合趋势，对实时性和响应时间要求越来越⾼。

使⽤的模型越来越复杂，计算量指数级上升。

简单说就是，需要储存的数据量和计算量都⾮常⼤，但⽤户对实时性和响应时间的要求却更⾼。

所以，⼈们希望出现⼀种技术或者⼯具来解决性能瓶颈，在可见未来不容易出现新瓶颈，并且学习成本尽量低，使得过去所拥有的技能可以平稳过渡。

⽐如SQL、R等，还有转移平台的成本能否控制最低，⽐如平台软硬件成本，再开发成本，技能再培养成本，维护成本等。

（能解决问题，适⽤时间长、容易上⼿、转移平台成本低）。

⽽Hadoop就能解决如上问题——分⽽治之，化繁为简。

Hdfs:⼆、HDFS运⾏机制 概述：⽤户的⽂件会被切块后存储在多台datanode节点中，并且每个⽂件在整个集群中存放多个副本，副本的数量可以通过修改配置⾃⼰设定。

HDFS：Hadoop Distributed file system，分布式⽂件系统。

HDFS的机制： HDFS集群中，有两种节点，分别为Namenode，Datanode； Namenode它的作⽤时记录元数据信息，记录块信息和对节点进⾏统⼀管理。

Thrift学习笔记—IDL基本类型thrift 采⽤IDL（Interface Definition Language）来定义通⽤的服务接⼝，并通过⽣成不同的语⾔代理实现来达到跨语⾔、平台的功能。

在thrift的IDL中可以定义以下⼀些类型：基本数据类型，结构体，容器，异常、服务1基本类型bool: 布尔值 (true or false), one bytebyte: 有符号字节i16: 16位有符号整型i32: 32位有符号整型i64: 64位有符号整型double: 64位浮点型string: Encoding agnostic text or binary string基本类型中基本都是有符号数，因为有些语⾔没有⽆符号数，所以Thrift不⽀持⽆符号整型。

2特殊类型binary: Blob (byte array) a sequence of unencoded bytes这是string类型的⼀种变形，主要是为使⽤，⽬前我主要使⽤C++的语⾔，所以java的这个类型没有⽤过3structthrift中struct是定义为⼀种对象，和⾯向对象语⾔的class差不多.,但是struct有以下⼀些约束：struct不能继承，但是可以嵌套，不能嵌套⾃⼰。

其成员都是有明确类型成员是被正整数编号过的，其中的编号使不能重复的，这个是为了在传输过程中编码使⽤。

成员分割符可以是逗号（,）或是分号（;），⽽且可以混⽤，但是为了清晰期间，建议在定义中只使⽤⼀种，⽐如C++学习者可以就使⽤分号（;）。

字段会有optional和required之分和protobuf⼀样，但是如果不指定则为⽆类型—可以不填充该值，但是在序列化传输的时候也会序列化进去，optional是不填充则部序列化，required是必须填充也必须序列化。

每个字段可以设置默认值同⼀⽂件可以定义多个struct，也可以定义在不同的⽂件，进⾏include引⼊。

分布式应用的各种交互协议thrift篇一：Thrift基本原理与应用Thrift基本原理与应用1 背景简介1.1什么是Thrift？Thrift是在2007 年facebook 提交Apache 基金会将Thrift 作为一个开源项目，对于当时的facebook 来说创造thrift 是为了解决facebook 系统中各系统间大数据量的传输通信以及系统之间语言环境不同需要跨平台的特性。

Thrift是一种实现RPC的软件框架，它自定义IDL，消息结构。

1.2RPC与IDLRPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。

RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。

在OSI 网络通信模型中，RPC跨越了传输层和应用层。

RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

接口描述语言（Interface description language，缩写IDL），是CORBA规范的一部分，是跨平台开发的基础。

IDL 是用来描述软件组件接口的一种计算机语言。

IDL通过一种中立的方式来描述接口，使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信交流。

1.3 为什么使用Thrift？(1)实现跨语言通信支持C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi等多种语言(2)完成高并发、大数据量传输(3) 使用方便，需要编写的代码较少Thrift的框架结构和原理1.4 其他实现RPC的框架和协议(1)Protocol Buffer，google公司2000年提出的RPC框架(2)Avro，Apache提出的RPC框架(3)SOAP：Simple Object Access Protocol，简单对象访问协议2 Thrift框架结构与基本原理2.1 Thrift框架结构图图1 Thrift框架结构图2.2 TProtocolTProtocol主要负责结构化数据组装成Thrift消息结构，或者从消息结构中读出结构化数据。

Elasticsearch分布式系统架构设计分布式系统类型多，涉及面非常广，不同类型的系统有不同的特点，批量计算和实时计算就差别非常大。

这篇文章中，重点会讨论下分布式数据系统的设计，比如分布式存储系统，分布式搜索系统，分布式分析系统等。

分布式系统类型多，涉及面非常广，不同类型的系统有不同的特点，批量计算和实时计算就差别非常大。

这篇文章中，重点会讨论下分布式数据系统的设计，比如分布式存储系统，分布式搜索系统，分布式分析系统等。

我们先来简单看下Elasticsearch的架构。

Elasticsearch 集群架构Elasticsearch是一个非常著名的开源搜索和分析系统，目前被广泛应用于互联网多种领域中，尤其是以下三个领域特别突出。

一是搜索领域，相对于solr，真正的后起之秀，成为很多搜索系统的不二之选。

二是Json文档数据库，相对于MongoDB，读写性能更佳，而且支持更丰富的地理位置查询以及数字、文本的混合查询等。

三是时序数据分析处理，目前是日志处理、监控数据的存储、分析和可视化方面做得非常好，可以说是该领域的引领者了。

Elasticsearch的详细介绍可以到官网查看。

我们先来看一下Elasticsearch中几个关键概念：节点（Node）：物理概念，一个运行的Elasticearch实例，一般是一台机器上的一个进程。

索引（Index），逻辑概念，包括配置信息mapping和倒排正排数据文件，一个索引的数据文件可能会分布于一台机器，也有可能分布于多台机器。

索引的另外一层意思是倒排索引文件。

分片（Shard）：为了支持更大量的数据，索引一般会按某个维度分成多个部分，每个部分就是一个分片，分片被节点(Node)管理。

一个节点(Node)一般会管理多个分片，这些分片可能是属于同一份索引，也有可能属于不同索引，但是为了可靠性和可用性，同一个索引的分片尽量会分布在不同节点(Node)上。

分片有两种，主分片和副本分片。

MRV1架构与讲解开始聊mapreduce，mapreduce是hadoop的计算框架，第一代MapReduce计算框架，它由两部分组成：编程模型（programming model）和运行时环境（runtime environment）。

它的基本编程模型是将问题抽象成Map和Reduce两个阶段，其中Map阶段将输入数据解析成key/value，迭代调用map()函数处理后，再以key/value的形式输出到本地目录，而Reduce阶段则将key相同的value进行规约处理，并将最终结果写到HDFS上。

它的运行时环境由两类服务组成：JobTracker和TaskTracker，其中，JobTracker负责资源管理和所有作业的控制，而TaskTracker负责接收来自JobTracker的命令并执行它。

Mapreduce初析Mapreduce是一个计算框架，既然是做计算的框架，那么表现形式就是有个输入（input），mapreduce操作这个输入（input），通过本身定义好的计算模型，得到一个输出（output），这个输出就是我们所需要的结果。

我们要学习的就是这个计算模型的运行规则。

在运行一个mapreduce计算任务时候，任务过程被分为两个阶段：map阶段和reduce阶段，每个阶段都是用键值对（key/value）作为输入（input）和输出（output）。

而程序员要做的就是定义好这两个阶段的函数：map函数和reduce函数。

Mapreduce的基础实例讲解mapreduce运行原理前，首先我们看看mapreduce里的hello world实例WordCount,这个实例在任何一个版本的hadoop安装程序里都会有，大家很容易找到，这里我还是贴出代码，便于我后面的讲解，代码如下：Wordcount代码示例：如何运行它，这里不做累述了，这里的实例代码是使用新的api，大家可能在很多书籍里看到讲解mapreduce的WordCount实例都是老版本的api，这里我不给出老版本的api，因为老版本的api不太建议使用了，大家做开发最好使用新版本的api，新版本api和旧版本api 有区别在哪里：新的api放在：org.apache.hadoop.mapreduce,旧版api放在：org.apache.hadoop.mapred 新版api使用虚类，而旧版的使用的是接口，虚类更加利于扩展，这个是一个经验，大家可以好好学习下hadoop的这个经验。

Thrift 是什么？Thrift源于大名鼎鼎的facebook之手，在2007年facebook提交Apache基金会将Thrift作为一个开源项目，对于当时的facebook来说创造thrift是为了解决facebook系统中各系统间大数据量的传输通信以及系统之间语言环境不同需要跨平台的特性。

所以thrift可以支持多种程序语言，例如: C++, C#, Cocoa, Erlang, Haskell, Java, Ocami, Perl, PHP, Python, Ruby, Smalltalk. 在多种不同的语言之间通信thrift可以作为二进制的高性能的通讯中间件，支持数据(对象)序列化和多种类型的RPC服务。

Thrift适用于程序对程序静态的数据交换，需要先确定好他的数据结构，他是完全静态化的，当数据结构发生变化时，必须重新编辑IDL文件，代码生成，再编译载入的流程，跟其他IDL工具相比较可以视为是Thrift的弱项，Thrift适用于搭建大型数据交换及存储的通用工具，对于大型系统中的内部数据传输相对于JSON和xml无论在性能、传输大小上有明显的优势。

Thrift是IDL(interface definition language)描述性语言的一个具体实现，关于IDL的话题我们可以追溯到CORBA 盛行1999-2001年(Common Object Request Broker Architecture/公用对象请求代理体系结构)，在IDL 中我们似乎不会忘记到这几个关键字：module、interface、string、long 和int，我还记得IDL利用module来创建名称空间，并且准确地映射为Java 的package，这些特性几乎和现在thrift的特性完全相同，所以thrift的设计思想和理念绝不是什么从火星来的new idea，看看在那个CORBA盛行的年代人们提出的概念，如图所示CORBA 请求的各个部分，回头我们再与thrift进行对比一下：Thrift 基础架构Thrift是一个服务端和客户端的架构体系，从我个人的感官上来看Thrift是一个类似XML-RPC+Java-to- IDL+Serialization Tools=Thrift 的东东，Thrift 具有自己内部定义的传输协议规范(TProtocol)和传输数据标准(TTransports)，通过IDL脚本对传输数据的数据结构(struct) 和传输数据的业务逻辑(service)根据不同的运行环境快速的构建相应的代码，并且通过自己内部的序列化机制对传输的数据进行简化和压缩提高高并发、大型系统中数据交互的成本，下图描绘了Thrift的整体架构，分为6个部分：1.你的业务逻辑实现(You Code) 2.客户端和服务端对应的Service 3.执行读写操作的计算结果4.TProtocol 5.TTransports 6.底层I/O通信图中前面3个部分是1.你通过Thrift脚本文件生成的代码，2.图中的褐色框部分是你根据生成代码构建的客户端和处理器的代码，3.图中红色的部分是2 端产生的计算结果。