新書推薦：
《
当代精神分析新论
》
售價：HK$
94.6
《
宋初三先生集（中国思想史资料丛刊）
》
售價：HK$
217.8
《
定言命令式：康德道德哲学研究（政治哲学名著译丛）
》
售價：HK$
129.8
《
棕榈油的全球史 ： 从奴隶船到购物篮
》
售價：HK$
96.8
《
简帛时代与早期中国思想世界（上下册）（王中江著作系列）
》
售價：HK$
308.0
《
进化主义在中国的兴起（王中江著作系列）
》
售價：HK$
209.0
《
不废风雅 生活的意趣（汪曾祺风雅意趣妙文）
》
售價：HK$
61.6
《
东亚世界形成史论（新版）
》
售價：HK$
107.8
|
| 編輯推薦： |
|
本书详细介绍了大数据的基本概念、原理与方法，以及通过大数据实践来讲述大数据技术的应用，包括如何运用阿里云大数据计算平台解决和分析实际的问题。本书*后还提供了大数据实践案例，完整地体现了理论与实践的有机结合
|
| 內容簡介： |
|
本书从大数据的基本概念开始，由浅入深地领会大数据的精髓。本书除了讲述必要的大数据理论之外，还通过大数据实践来讲述大数据技术的应用，包括如何运用阿里云大数据计算平台分析和解决实际问题，很好地体现了大数据理论与实践的有机结合。本书分为三大部分，分别是大数据概述及基础、大数据处理和大数据分析与应用。其中，大数据概述及基础部分重点介绍数据组织、重要数据结构、大数据协同技术以及大数据存储技术等内容； 大数据处理部分重点介绍大数据处理框架，包括大数据批处理和流处理框架等内容； 大数据分析与应用部分重点介绍数据分析技术和机器学习的相关内容，以及如何利用阿里云的数加平台进行基本的大数据开发工作。本书既可以作为高等院校计算机科学、软件工程及相关专业大数据课程的教材，也可以供系统分析师、系统架构师、软件开发工程师和项目经理，以及其他准备或正在学习大数据技术的读者（包括参加计算机等级考试或相关专业自学考试的人员）阅读和参考。
|
| 目錄：
|
目录
第一部分大数据概述及基础
第1章大数据概念和发展背景
1.1什么是大数据
1.2大数据的特点
1.3大数据的发展
1.4大数据的应用
1.5习题
第2章大数据系统架构概述
2.1总体架构概述
2.1.1总体架构设计原则
2.1.2总体架构参考模型
2.2运行架构概述
2.2.1物理架构
2.2.2集成架构
2.2.3安全架构
2.3阿里云飞天系统体系架构
2.3.1阿里云飞天整体架构
2.3.2阿里云飞天平台内核
2.3.3阿里云飞天开放服务
2.3.4阿里云飞天的特色
2.4主流大数据系统厂商
2.4.1阿里云数加平台
2.4.2Cloudera
2.4.3Hortonworks
2.4.4Amazon
2.4.5Google
2.4.6微软
2.5习题
第3章分布式通信与协同
3.1数据编码传输
3.1.1数据编码概述
3.1.2LZSS算法
3.1.3Snappy压缩库
3.2分布式通信系统
3.2.1远程过程调用
3.2.2消息队列
3.2.3应用层多播通信
3.2.4阿里云夸父RPC系统
3.2.5Hadoop IPC的应用
3.3分布式协同系统
3.3.1Chubby锁服务
3.3.2ZooKeeper
3.3.3阿里云女娲协同系统
3.3.4ZooKeeper在HDFS高可用方案中的使用
3.4习题
第4章大数据存储
4.1大数据存储技术的发展
4.2海量数据存储的关键技术
4.2.1数据分片与路由
4.2.2数据复制与一致性
4.3重要数据结构和算法
4.3.1Bloom Filter
4.3.2LSM Tree
4.3.3Merkle Tree
4.3.4Cuckoo Hash
4.4分布式文件系统
4.4.1文件存储格式
4.4.2GFS
4.4.3HDFS
4.4.4阿里云盘古
4.5分布式数据库NoSQL
4.5.1NoSQL数据库概述
4.5.2KV数据库
4.5.3列式数据库
4.5.4图数据库
4.5.5文档数据库
4.6阿里云数据库
4.6.1云数据库Redis
4.6.2云数据库RDS
4.6.3云数据库Memcache
4.7大数据存储技术的趋势
4.8习题
第二部分大数据处理
第5章分布式处理
5.1CPU多核和POSIX Thread
5.2MPI并行计算框架
5.3Hadoop MapReduce
5.4Spark
5.5数据处理技术的发展
5.6习题
第6章Hadoop MapReduce解析
6.1Hadoop MapReduce架构
6.2Hadoop MapReduce与高效能计算、网格计算的区别
6.3MapReduce工作机制
6.3.1Map
6.3.2Reduce
6.3.3Combine
6.3.4Shuffle
6.3.5Speculative Task
6.3.6任务容错
6.4应用案例
6.4.1WordCount
6.4.2WordMean
6.4.3Grep
6.5MapReduce的缺陷与不足
6.6习题
第7章Spark解析
7.1Spark RDD
7.2Spark与MapReduce的对比
7.3Spark的工作机制
7.3.1DAG工作图
7.3.2Partition
7.3.3Lineage容错方法
7.3.4内存管理
7.3.5数据持久化
7.4数据的读取
7.4.1HDFS
7.4.2Amazon S3
7.4.3HBase
7.5应用案例
7.5.1日志挖掘
7.5.2判别西瓜好坏
7.6Spark的发展趋势
7.7习题
第8章流计算
8.1流计算概述
8.2流计算与批处理系统的对比
8.3Storm流计算系统
8.4Samza流计算系统
8.5阿里云流计算
8.6集群日志文件的实时分析
8.7流计算的发展趋势
8.8习题
第9章图计算
9.1图计算概述
9.2图计算与流计算、批处理的对比
9.3Spark GraphX
9.4Pregel
9.5航班机场状态分析
9.6图计算的发展趋势
9.7习题
第10章阿里云大数据计算服务平台
10.1MaxCompute概述
10.2MR计算
10.3SQL计算
10.4Graph计算
10.5习题
第11章集群资源管理与调度
11.1集群资源统一管理系统
11.1.1集群资源管理概述
11.1.2Apache YARN
11.1.3Apache Mesos
11.1.4Google Omega
11.2资源管理模型
11.2.1基于slot的资源表示模型
11.2.2基于最大最小公平原则的资源分配模型
11.3资源调度策略
11.3.1调度策略概述
11.3.2Capacity Scheduler调度
11.3.3Fair Scheduler调度
11.4在YARN上运行计算框架
11.4.1MapReduce on YARN
11.4.2Spark on YARN
11.4.3YARN程序设计
11.5阿里云伏羲调度系统
11.5.1伏羲调度系统架构
11.5.25K挑战
11.5.3伏羲优化实践
11.6习题
第三部分大数据分析与应用
第12章数据分析
12.1数据操作与绘图
12.1.1数据结构
12.1.2绘图功能
12.2初级数据分析
12.2.1描述性统计分析
12.2.2回归诊断
12.3交互式数据分析
12.3.1交互式数据分析的特征
12.3.2交互式数据处理的典型应用
12.3.3典型的处理系统
12.4数据仓库与分析
12.4.1数据仓库的基本架构
12.4.2数据仓库的实现步骤
12.4.3分布式数据仓库Hive
12.4.4数据仓库之SQL分析
12.4.5阿里云MaxCompute数据仓库案例
12.5习题
第13章数据挖掘与机器学习技术
13.1相关理论基础知识
13.1.1数据挖掘与机器学习简介
13.1.2关联分析
13.1.3分类与回归
13.1.4聚类分析
13.1.5离群点检测
13.1.6复杂数据类型的挖掘
13.2应用实践
13.2.1广告点击率预测
13.2.2并行随机梯度下降
13.2.3自然语言处理： 文档相似性的计算
13.2.4阿里云PAI与ET
13.3深度学习
13.3.1深度学习简介
13.3.2DistBelief
13.3.3TensorFlow
13.4数据挖掘与机器学习的发展趋势
13.5习题
第14章大数据实践：
基于数加平台的推荐系统
14.1数据集简介
14.2数据探索
14.3方案设计
14.4训练集构造
14.4.1MapReduce环境配置
14.4.2MapReduce代码编写
14.4.3特征提取与标签提取
14.4.4训练集采样
14.4.5缺失值填充
14.5模型训练与预测
14.6模型预测的准确性评测
14.7特征重要性的评估
14.8总结
参考文献
|
| 內容試閱：
|
前言
互联网技术不断发展，各种技术不断涌现，其中大数据技术已成为一颗闪耀的新星。我们已经处于数据世界，互联网每天产生大量的数据，利用好这些数据可以给我们的生活带来巨大的变化以及提供极大的便利。目前大数据技术受到越来越多的机构的重视，因为大数据技术可以给其创造巨大的利润，其中的典型代表是个性化推荐以及大数据精准营销。本书在讲述大数据的基本概念、原理与方法的基础上，详细而全面地介绍了可以实际用于大数据实践的各种技能，旨在使学生通过有限课时的学习后，不仅能对大数据技术的基本原理有所认识，而且能够具备基本的大数据技术开发能力以及运用大数据技术解决基本的数据分析问题，理解大数据框架（尤其是阿里云大数据计算平台），在阿里云大数据平台上进行基本的大数据开发工作的能力。本书分为三大部分，分别是大数据概述及基础、大数据处理和大数据分析与应用。其中，大数据概述及基础部分重点介绍数据组织、重要数据结构、大数据协同技术以及大数据存储技术等内容； 大数据处理部分重点介绍大数据处理框架，包括大数据批处理和流处理框架等内容； 大数据分析与应用部分重点介绍数据分析技术和机器学习的相关内容，以及如何利用阿里云的数加平台进行基本的大数据开发工作。本书与其他类似著作的不同之处在于，除了讲述必要的大数据理论之外，还通过大数据实践来讲述大数据技术的应用，包括如何运用阿里云大数据计算平台解决和分析实际的问题，如阿里云MaxCompute和StreamCompute等。本书的最后一章大数据实践： 基于数加平台的推荐系统是学生在做课程设计时可供模仿的一个项目，它完整地体现了理论与实践的有机结合。本书的理论知识的教学安排建议如下。
章节内容学时数第1章大数据概念和发展背景1第2章大数据系统架构概述1~2第3章分布式通信与协同2~4第4章大数据存储4~6第5章分布式处理2第6章Hadoop MapReduce解析2~4第7章Spark解析2~4第8章流计算2第9章图计算2第10章阿里云大数据计算服务平台2第11章集群资源管理与调度4~6第12章数据分析2~4第13章数据挖掘与机器学习技术2~4第14章大数据实践： 基于数加平台的推荐系统4~5
建议理论教学时数： 32~48学时。建议实验（实践）教学时数： 16~32学时。教师可以按照自己对大数据的理解适当地删除一些章节，也可以根据教学目标，灵活地调整章节的顺序，增减各章的学时数。在本书成书的过程中，得到了万昭祎、李旭、苏俊洋以及阿里巴巴的李妹芳等人的大力支持，在此表示衷心的感谢。由于大数据是一门新兴学科，大数据的教学方法本身还在探索之中，加之我们的水平和能力有限，本书难免有疏漏之处。恳请各位同仁和广大读者给予批评指正，也希望各位能将实践过程中的经验和心得与我们交流（yunxianglu@hotmail.com）。作者2017年1月
第3章分布式通信与协同在大规模分布式系统中，为了高效地处理大量任务以及存储大量数据，通常需要涉及多个处理节点，需要在多个节点之间通信以及协同处理。高效的节点之间的通信以及节点之间的可靠协同技术是保证分布式系统正常运行的关键。3.1数据编码传输3.1.1数据编码概述
在分布式系统中需要处理大量的网络数据，为了加快网络数据的传输速度，通常需要对传输数据进行编码压缩，当然数据编码压缩传输技术也在其他电子信息领域中大量使用，由于数字化的多媒体信息尤其是数字视频、音频信号的数据量特别庞大，如果不对其进行有效的压缩难以得到实际的应用，因此数据编码压缩技术已成为当今数字通信、广播、存储和多媒体娱乐中的一项关键的共性技术。数据压缩是以尽可能少的数码来表示信源所发出的信号，减少容纳给定的消息集合或数据采样集合的信号空间。这里讲的信号空间就是被压缩的对象，是指某信号集合所占的时域、空域和频域。信号空间的这几种形式是相互关联的，存储空间的减少意味着信号传输效率的提高，所占用带宽的节省。只要采取某种方法来减少某个信号空间就能够压缩数据。一般来说，数据压缩主要是通过数据压缩编码来实现的。要想使编码有效，必须建立相应的系统模型。在给定的模型下通过数据编码来消除冗余，大致有以下3种情况。1 信源符号之间存在相关性。如果消除了这些相关性，就意味着数据压缩。例如，位图图像像素与像素之间的相关性，动态视频帧与帧之间的相关性。去掉这些相关性通常采用预测编码、变换编码等方法。2 信源符号之间存在分布不等概性。根据不同符号出现的不同概率分别进行编码，概率大的符号用较短的码长编码，概率小的符号用较长的码长编码，最终使信源的平均码长达到最短。通常采用统计编码的方法。3 利用信息内容本身的特点如自相似性。用模型的方法对需传输的信息进行参数估测，充分利用人类的视觉、听觉等特性，同时考虑信息内容的特性，确定并遴选出其中的部分内容而不是全部内容进行编码，从而实现数据压缩。通常采用模型基编码的方法。目前比较认同的、常用的数据压缩的编码方法大致分为两大类。1 冗余压缩法或无损压缩法。冗余压缩法或无损压缩法又称为无失真压缩法或熵编码法。这类压缩方法只是去掉数据中的冗余部分，并没有损失熵，而这些冗余数据是可以重新插入到原数据中的。也就是说，去掉冗余不会减少信息量，而且仍可原样恢复数据。因此，这类压缩方法是可逆的。2 熵压缩法或有损压缩法。这类压缩法由于压缩了熵，也就损失了信息量，而损失的信息是不能恢复的。因此，在用门限值采样量化时，如果只存储门限内的数据，那么原来超过这个预置门限的数据将丢失。这种压缩方法虽然可压缩大量的信号空间，但那些丢失的实际样值不可能恢复，是不可逆的。也就是说，在用熵压缩法时数据压缩要以一定的信息损失为代价，而数据的恢复只能是近似的，应根据条件和要求在允许的范围内进行压缩。3.1.2LZSS算法LZSS算法属于字典算法，是把文本中出现频率较高的字符组合做成一个对应的字典列表，并用特殊代码来表示这个字符。图31为字典算法原理图示。
LZSS算法的字典模型使用自适应方式，基本的思路是搜索目前待压缩串是否在以前出现过，如果出现过，则利用前次出现的位置和长度来代替现在的待压缩串，输出该字符串的出现位置及长度； 否则，输出新的字符串，从而起到压缩的目的。但是在实际使用过程中，由于被压缩的文件往往较大，一般使用滑动窗口压缩方式，也就是说将一个虚拟的、可以跟随压缩进程滑动的窗口作为术语字典。LZSS算法最大的好处是压缩算法的细节处理不同，只对压缩率和压缩时间有影响，不会影响到解压程序。LZSS算法最大的问题是速度，每次都需要向前搜索到原文开头，对于较长的原文需要的时间是不可忍受的，这也是LZSS算法较大的一个缺点。
图31字典算法原理
3.1.3Snappy压缩库Snappy是在Google公司内部生产环境中被许多项目使用的压缩解压缩的链接库，使用该库的软件包括BigTable、MapReduce和RPC等，Google公司于2011年开源了该压缩解压缩库。在Intel酷睿i7处理器上，在单核64位模式下，Snappy的压缩速度大概可以达到250MBs或者更快，解压缩可以达到大约500MBs甚至更快。如此高的压缩速度是通过降低压缩率来实现的，因此其输出要比其他库大20%~100％。Snappy对于纯文本的压缩率为1.5~1.7，对于HTML是2~4，当然，对于JPEG、PNG和其他已经压缩过的数据的压缩率为1.0。Snappy压缩库采用C实现，同时提供了多种其他语言的接口，包括C、C#、Go、Haskell等。Snappy是面向字节编码的LZ77类型压缩器。Snappy采用的编码单元是字节byte，而不是比特bit，采用该压缩库压缩后的数据形成一个字节流的格式，格式如下： 前面几个字节表示总体为压缩的数据流长度，采用小端方式littleendian存储，同时兼顾可变长度编码，每个字节的后面7位存储具体的数据，最高位用于表示下一个字节是否为同一个整数； 剩下的字节用4种元素类型中的一种进行编码，元素类型在元素数据中的第一个字节，该字节的最后2位表示类型。 00。文本数据，属于未压缩数据，类型字节的高6位用于存储每个元素的数据内容长度。当数据内容超过60个字节时，采用额外的可变长编码方式存储数据。 01。数据长度用3位存储，偏移量用11位存储。紧接着类型字节后的第一个字节也用于存储偏移量。 10。类型字节中剩下的高6位用于存储数据长度，在类型字节后的两个字节用于存储数据的偏移量。 11。类型字节中剩下的高6位用于存储数据长度，数据偏移量存储在类型字节后的4个字节，偏移量采用小端方式存储数据。3.2分布式通信系统分布式通信研究分布式系统中不同子系统或进程之间的信息交换机制。我们从各种大数据系统中归纳出3种最常见的通信机制： 远程过程调用、消息队列和多播通信。其中，远程过程调用的重点是网络中位于不同机器上进程之间的交互； 消息队列的重点是子系统之间的消息可靠传递； 多播通信是实现信息的高效多播传递。这三者都是黏合子系统的有效工具，同时，它们对于减少大数据系统中构件之间的耦合、增强各自的独立演进有很大的帮助作用。3.2.1远程过程调用远程过程调用Remote Procedure Call，RPC是一个计算机通信协议，通过该协议运行于一台计算机上的程序可以调用另一台计算机的子程序，而程序员无须额外地为这个交互编程。通用的RPC框架都支持以下特性： 接口描述语言、高性能、数据版本支持以及二进制数据格式。Thrift是由Facebook公司开发的远程服务调用框架，它采用接口描述语言定义并创建服务，支持可扩展的跨语言服务开发，所包含的代码生成引擎可以在多种语言中，如C、Java、Python、PHP、Ruby、Erlang、Perl、Haskell、C#、Cocoa、Smalltalk等，创建高效的、无缝的服务。其传输数据采用二进制格式，相对于XML和JSON体积更小，对于高并发、大数据量和多语言的环境更有优势。Thrift包含了一个完整的堆栈结构，用于构建客户端和服务器端。服务器包含用于绑定协议和传输层的基础架构，它提供阻塞、非阻塞、单线程和多线程的模式运行在服务器上，可以配合服务器容器一起运行，可以和现有的服务器容器无缝结合。其使用流程大致如下。首先使用IDL定义消息体以及RPC函数调用接口。使用IDL可以在调用方和被调用方解耦，比如调用方可以使用C，被调用方可以使用Java，这样给整个系统带来了极大的灵活性。然后使用工具根据IDL定义文件生成指定编程语言的代码。最后即可在应用程序中连接使用上一步生成的代码。对于RPC来说，调用方和被调用方同时引入后即可实现透明的网络访问。3.2.2消息队列消息队列也是设计大规模分布式系统时经常采用的中间件产品。分布式系统构件之间通过传递消息可以解除相互之间的功能耦合，这样减轻了子系统之间的依赖，使得各个子系统或者构建可以独立演进、维护或重用。消息队列是在消息传递过程中保存消息的容器或中间件，其主要目的是提供消息路由并保障消息可靠传递。下面通过Linkedin开源的分布式消息系统Kafka介绍消息队列系统的整体设计思路。Kafka采用PubSub机制，具有极高的消息吞吐量、较强的可扩展性和高可用性，消息传递延迟低，能够对消息队列进行持久化保存，且支持消息传递的至少送达一次语义。一个典型的Kafka集群中包含若干producer、若干broker、若干consumer group，以及一个ZooKeeper集群。Kafka通过ZooKeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。作为一个消息系统，Kafka遵循了传统的方式，选择由producer向broker push消息并由consumer向broker pull消息。push模式很难适应消费速率不同的consumer，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快的速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络阻塞。pull模式可以根据consumer的消费能力以适当的速率消费信息。3.2.3应用层多播通信分布式系统中的一个重要的研究内容是如何将数据通知到网络中的多个接收方，这一般被称为多播通信。与网络协议层的多播通信不同，这里介绍的是应用层多播通信。Gossip协议就是常见的应用层多播通信协议，与其他多播协议相比，其在信息传递的健壮性和传播效率方面有较好的折中效果，使其在大数据领域中得以广泛使用。Gossip协议也被称为感染协议Epidemic Protocol，用来尽快地将本地更新数据通知到网络中的所有其他节点。其具体更新模型又可以分为3种： 全通知模型、反熵模型和散步谣言模型。在全通知模型中，当某个节点有更新消息时立即通知所有其他节点； 其他节点在接收到通知后判断接收到的消息是否比本地消息要新，如果是，则更新本地数据，否则，不采取任何行为。反熵模型是最常用的Gossip协议，之所以称之为反熵，是因为熵是用来衡量系统混乱无序程度的指标，熵越大说明系统越无序。系统中更新的信息经过一定轮数的传播后，集群内的所有节点都会获得全局最新信息，所以系统变得越来越有序，这就是反熵的含义。在反熵模型中，节点P随机选择集群中的另一个节点Q，然后与Q交换更新信息； 如果Q信息有更新，则类似P一样传播给任意其他节点此时P也可以再传播给其他节点，这样经过一定轮数的信息交换，更新的信息就会快速传播到整个网络节点。散步谣言模型与反熵模型相比增加了传播停止判断。即如果节点P更新了数据，则随机选择节点Q交换信息； 如果节点Q已经从其他节点处得知了该更新，那么节点P降低其主动通知其他节点的概率，直到一定程度后，节点P停止通知行为。散布谣言模型能够快速传播变化，但不能保证所有节点都能最终获得更新。3.2.4阿里云夸父RPC系统在分布式系统中，不同计算机之间只能通过消息交换的方式进行通信。显式的消息通信必须通过Socket接口编程，而RPC可以隐藏显式的消息交换，使得程序员可以像调用本地函数一样来调用远程的服务。夸父Kuafu是飞天平台内核中负责网络通信的模块，它提供了一个RPC的接口，简化编写基于网络的分布式应用。夸父的设计目标是提供高可用724小时、大吞吐量Gigabyte、高效率、易用简明API、多种协议和编程接口的RPC服务。RPC客户端RPC Client通过URI指定请求需要发送的RPC服务端RPC Server的地址，目前夸父支持两种协议形式。 TCP。例如tcp：fooserver01：9000。 Nuwa。例如nuwa：nuwa01FooServer。与用流Stream传输的TCP通信相比，夸父通信是以消息Message为单位的，支持多种类型的消息对象，包括标准字符串std∷string和基于std∷map实现的若干string键值对。夸父RPC同时支持异步asynchronous和同步synchronous的远程过程调用形式。（1） 异步调用。RPC函数调用时不等接收到结果就会立即返回，用户必须通过显式调用接收函数取得请求结果。（2） 同步调用。RPC函数调用时会等待，直到接收到结果才返回。在实现中，同步调用是通过封装异步调用来实现的。在夸父的实现中，客户端程序通过UNIX Domain Socket与本机上的一个夸父代理Kuafu Proxy连接，不同计算机之间的夸父代理会建立一个TCP连接。这样做的好处是可以更高效地使用网络带宽，系统可以支持上千台计算机之间的互联需求。此外，夸父利用女娲来实现负载均衡； 对大块数据的传输作了优化； 与TCP类似，夸父代理之间还实现了发送端和接收端的流控Flow Control机制。3.2.5Hadoop IPC的应用这里以Hadoop中的RPC框架Hadoop IPC为基础讲述RPC框架在大数据系统中的应用。Hadoop系统包括Hadoop Common、Hadoop Distributed File System、Hadoop MapReduce几个重要的组成部分，其中，Hadoop Common用于提供整个Hadoop公共服务，包括Hadoop IPC。在Hadoop系统中，Hadoop IPC为HDFS、MapReduce提供了高效的RPC通信机制，在HDFS中，DFSClient模块需要与NameNode模块通信、DFSClient模块需要与DataNode模块通信、MapReduce客户端需要与JobTracker通信，Hadoop IPC为这些模块之间的通信提供了一种便利的方式。目前实现的Hadoop IPC具有采用TCP方式连接、支持超时、缓存等特征。Hadoop IPC采用的是经典的CS结构。Hadoop IPC的Server端相对比较复杂，包括Listener、Reader、Handler和Responder等多种类型的线程，Listener用于侦听来自IPC Client端的连接，同时也负责管理与Client端之间的连接，包括Client端超时需要删除连接； Reader线程用于读取来自Client端的数据，Handler线程用于处理来自Client端的请求，执行具体的操作； Responder线程用于返回处理结果给Client端。一般配置是一个Listener、多个Reader、多个Handler和一个Responder。Hadoop IPC的组成如图32所示。
图32Hadoop IPC的组成
执行HDFS读文件操作，首先DFSClient利用Hadoop IPC框架发起一次RPC请求给NameNode，获取DataBlock信息。在执行HDFS数据恢复操作的时候，DFSClient需要执行recoverBlock RPC操作，发送该请求到DataNode节点上。
3.3分布式协同系统当前的大规模分布式系统涉及大量的机器，这些机器之间需要进行大量的网络通信以及各个节点之间的消息通信协同。为了减少分布式系统中这些工作的重复开发，解耦出分布式协同系统，有效地提高了分布式计算、分布式存储等系统的开发速度。3.3.1Chubby锁服务Chubby是Google公司研发的针对分布式系统协调管理的粗粒度服务，一个Chubby实例大约可以负责1万台4核CPU机器之间对资源的协同管理。这种服务的主要功能是让众多客户端程序进行相互之间的同步，并对系统环境或资源达成一致的认知。Chubby的理论基础是Paxos（一致性协议），Paxos是在完全分布式环境下不同客户端能够通过交互通信并投票对于某个决定达成一致的算法。Chubby以此为基础，但是也进行了改造，Paxos是完全分布的，没有中心管理节点，需要通过多轮通信和投票来达成最终的一致，所以效率低； Chubby出于对系统效率的考虑，增加了一些中心管理策略，在达到同一目标的情况下改善了系统效率。Chubby的设计目标基于以下几点： 高可用性、高可靠性、支持粗粒度的建议性锁服务、支持小规模文件直接存储。这些当然是用高性能与存储能力折中而来的。图33是Google论文中描述的Chubby的整体架构，可以容易地看出Chubby共有5台服务器，其中一个是主服务器，客户端与服务器之间使用RPC交互。那么，其他服务器是干什么的？它们纯粹是作为主服务器不可用后的替代品。而ZooKeeper的多余服务器均是提供就近服务的，也就是服务器会根据地理位置与网络情况来选择对哪些客户端给予服务。
图33Chubby整体架构
Chubby单元中的主服务器由所有服务器选举推出，但是并非从始至终一直都由其担任这一角色，它是有任期的，即Master Lease，一般长达几秒。如果无故障发生，一般系统尽量将租约交给原先的主服务器，否则可以通过重新选举得到一个新的全局管理服务器，这样就实现了主服务器的自动切换。客户端通过嵌入的库程序，利用RPC通信和服务器进行交互，对Chubby的读写请求都由主服务器负责。主服务器遇到数据更新请求后会更改在内存中维护的管理数据，通过改造的Paxos协议通知其他备份服务器对相应的数据进行更新操作，并保证在多副本环境下的数据一致性； 当多数备份服务器确认更新完成后，主服务器可以认为本次更新操作正确完成。其他所有备份服务器只是同步管理数据到本地，保持数据和主服务器完全一致。通信协议如图34所示。
图34Client与Chubby的通信
KeepAlive是周期性发送的一种消息，它有两方面的功能： 延长租约有效期，携带事件信息告诉客户端更新。事件包括文件内容的修改、子节点的增删改、Master出错等。在正常情况下，租约会由KeepAlive一直不断延长。如果C1在未用完租约期时发现还需使用，便发送锁请求给Master，Master给它LeaseM1； C2在过了租约期后，发送锁请求给Master，可是未收到Master的回答。其实此刻Master已经挂了，于是Chubby进入宽限期，在这期间Chubby要选举出新的Master。Google论文里对于这段时期有一个更形象的名字Grace Period。在选举出Master后，新的主服务器下令前主服务器发的Lease失效，大家必须申请一份新的。然后C2获得了LeaseM2。C3又恢复到正常情况。在图34中4、5、6、7、8是通过Paxos算法选举Master的颤抖期。在此期间最有可能产生问题，Amazon的分布式服务就曾因此宕机，导致很长时间服务不可用。3.3.2ZooKeeperZooKeeper是Yahoo！公司开发的一套开源高吞吐分布式协同系统，目前已经在各种NoSQL数据库及诸多开源软件中获得广泛使用。分布式应用中的各节点可以通过ZooKeeper这个第三方来确保双方的同步，比如一个节点是发送，另一个节点是接收，但发送节点需要确认接收节点成功收到这个消息，因而就可以通过与一个可靠的第三方交互来获取接收节点的消息接收状态。ZooKeeper也是由多台同构服务器构成的一个集群，共用信息存储在集群系统中。共用信息采用树形结构来存储，用户可以将其看作一个文件系统，只是这些文件是一直存放在内存中的，文件存储容量受到内存的限制。既然ZooKeeper可以被看作一个文件系统，那么它就具有文件系统相应的功能，只是在ZooKeeper和文件系统中功能的叫法不同。ZooKeeper提供创建节点、删除节点、创建子节点、获取节点内容等功能。ZooKeeper服务由若干台服务器构成，每台服务器内存中维护相同的树形数据结构。其中的一台通过ZAB原子广播协议选举作为主服务器，其他的作为从服务器。客户端可以通过TCP协议连接任意一台服务器，如果是读操作请求，任意一个服务器都可以直接响应请求； 如果是写数据操作请求，则只能由主服务器来协调更新操作。Chubby在这一点上与ZooKeeper不同，所有的读写操作都由主服务器完成，从服务器只是用于提高整个协调系统的可用性。在带来高吞吐量的同时，ZooKeeper的这种做法也带来了潜在的问题： 客户端可能读到过期的数据。因为即使主服务器已经更新了某个内存数据，但是ZAB协议还未能将其广播到从服务器。为了解决这一问题，在ZooKeeper的接口API函数中提供了Sync操作，应用可以根据需要在读数据前调用该操作，其含义是接收到Sync命令的从服务器从主服务器同步状态信息，保证两者完全一致。3.3.3阿里云女娲协同系统女娲Nuwa系统为飞天提供高可用的协调服务Coordination Service，是构建各类分布式应用的核心服务，它的作用是采用类似文件系统的树形命名空间来让分布式进程互相协同工作。例如，当集群变更导致特定的服务被迫改变物理运行位置时，如服务器或者网络故障、配置调整或者扩容时，借助女娲系统可以使其他程序快速定位到该服务新的接入点，从而保证了整个平台的高可靠性和高可用性。女娲系统基于类Paxos协议，由多个女娲Server以类似文件系统的树形结构存储数据，提供高可用、高并发用户请求的处理能力。女娲系统的目录表示一个包含文件的集合。与UNIX中的文件路径一样，女娲中的路径是以分割的，根目录Root entry的名字是，所有目录的名字都是以结尾的。与UNIX文件路径的不同之处在于： 女娲系统中的所有文件或目录都必须使用从根目录开始的绝对路径。由于女娲系统的设计目的是提供协调服务，而不是存储大量数据，所以每个文件的内容Value的大小被限制在1MB以内。在女娲系统中，每个文件或目录都保存有创建者的信息。一旦某个路径被用户创建，其他用户就可以访问和修改这个路径的值即文件内容或目录包含的文件名。女娲系统支持PublishSubscribe模式，其中一个发布者、多个订阅者One PublisherMany Subscriber的模式提供了基本的订阅功能； 另外，还可用通过多个发布者、多个订阅者Many PublisherMany Subscriber的模式提供分布式选举Distributed Election和分布式锁的功能。另外一个使用女娲系统来实现负载均衡的例子： 提供某一服务的多个节点，在服务启动的时候在女娲系统的同一目录下创建文件，例如server1创建文件nuwa：clustermyserviceserver1，server2在同一目录下创建nuwa：clustermyserviceserver2。当客户端使用远程过程调用时首先列举女娲系统服务中nuwa：clustermyservice目录下的文件，这样就可以获得server1和server2，客户端随后可以从中选择一个节点发出自己的请求，从而实现负载均衡。3.3.4ZooKeeper在HDFS高可用方案中的使用HDFS由3个模块构成，分别包括Client、NameNode和DataNode。NameNode负责管理所有的DataNode节点，保存block和DataNode之间的对应信息，Client读取文件和写入文件都需要NameNode节点的参与，因此NameNode发挥着至关重要的作用。在当前设计中，NameNode是单节点方式，存在单点故障问题，即NameNode节点宕机之后HDFS无法再对外提供数据存储服务，需要设计一种HDFS NameNode节点的高可用方法。总体来讲，维护HDFS高可用基于以下两个目的：（1） 在出现NameNode节点故障时HDFS仍然可以对外提供数据的读取和写入服务。（2） HDFS会出现版本的更新迭代，以保证HDFS在更新过程中仍然可以对外提供服务。HDFS为了实现上述目的，采用的方式是再提供一个额外的NameNode节点，以此达到HDFS的高可用目的。在使用过程中部署两个NameNode节点，一个NameNode节点为Active节点，另一个NameNode节点是Standby节点。在正常情况下，Active的NameNode节点服务正常的请求，一旦出现Active NameNode节点故障，则Standby NameNode节点切换变成Active节点，然后这个新的Active NameNode继续提供NameNode的功能，使HDFS可以继续正常工作。但是为了保证上述过程正常运行，需要解决以下问题：（1） Standby如何知道Active节点出现故障无法正常服务，需要探测系统何时出现故障。（2） 当出现Active NameNode节点故障时，多个Standby NameNode节点如何选择一个新的Active NameNode节点。一种解决上述问题的HDFS高可用方法是采用ZK Failover Controller的方法，具体结构如图35所示。
图35基于ZooKeeper的HDFS高可用方法
采用ZKZooKeeper设计HDFS高可用方案基于以下几点：1 ZooKeeper提供了小规模的任意数据信息的强一致性。2 可以在ZooKeeper集群中创建一个临时znode节点，当创建该znode节点的Client失效时，该临时znode节点会自动删除。3 能够监控ZooKeeper集群中的一个znode节点的状态发生改变，并被异步通知。上述设计的基于ZK的HDFS高可用方法由ZKFC、HealthMonitor、ActiveStandbyElector几个主要部分组成。（1） HealthMonitor是一个线程，用于监控本地NameNode的状态信息，维持一个状态信息的视图，监控采用RPC方式。当状态信息发生改变时，通过callback接口方式发送消息给ZKFC。（2） ActiveStandbyElector主要用于和ZooKeeper进行协调，ZKFC与它通信主要由两个函数调用，分别是joinElection和quitElection。（3） ZKFailoverController订阅来自ActiveStandbyElector和HealthMonitor的消息，同时管理NameNode的状态。整体运行过程如下： 启动的时候初始化HealthMonitor去监控本地NameNode节点，同时用ZooKeeper信息来初始化ActiveStandbyElector，不立即把该NameNode节点加入选举。同时，随着ActiveStandbyElector和HealthMonitor状态的改变，ZKFC做出对应的响应。3.4习题1. 简述数据编码传输的好处。2. 简要介绍Snappy压缩库，包括功能和数据格式。3. 简要介绍Chubby的工作原理。4. 简述ZooKeeper在HDFS高可用方案中发挥作用的理由。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
