分布式系统中的关键概念及Hadoop的起源、架构、搭建

引 言 单机系统 --> 分布式系统（上个世纪七八十年代） 互联网时代，分布式系统大放异彩，尤其是Google更是把分布式 系统运用到了极致。比如 Borg、MapReduce、BigTable等等 Apache软件基金会旗下的Hadoop生态圈、资源调度系统Mesos 等分布式系统，让更多企业客户体会到了分布式系统的便利，原 本只在大公司使用的分布式处理技术“飞入寻常百姓家”。

分布式系统的特点（一） 分布式系统对服务器硬件要求很低 对服务器硬件可靠性不做要求，允许服务器硬件发生故障，由软件来容 错。 对服务器的性能不做要求，不要求使用高频CPU、大容量内存、高性能 存储等等 互联网企业在生产环境中，一般使用普通的刀片式服务器来搭建分布式 系统

分布式系统的特点（二） 分布式系统强调横向可扩展性 横向可扩展性是指通过增加服务器数量来提升集群整体性能； 纵向可扩展性是指提升每台服务器性能进而提升集群整体性能。 横向可扩展性的上限空间比较大，相对来说，集群增加服务器更加方便可 行。一个有效的分布式系统会尽可能保证横向扩展带来集群整体性能的 （准）线性提升。（10  100） 衡量分布式系统优劣的一个重要指标就是是否可以更加方便的添加节点和 可管理节点的数量。Google的数据中心由数万台服务器组成。一般认为， Hadoop系统最多可管理3k到4k个节点。

分布式系统的特点（三） 分布式系统不允许单点失效（No Single Point Failure） 单点失效是指，集群中一个节点出现故障，导致整个集群服务不可用。例如， 假如我们把所有数据都存在集群中的某一台服务器上，那一旦这台服务器坏 了，数据都不可访问，集群服务不可用。 分布式系统默认每台服务器随时都可能发生故障。为提供高可靠的服务，分 布式系统里运行的每个应用服务都有多个运行实例跑在多个不同节点上，每 个数据块都有多个备份存在不同的节点上，有效防止单点失效。 通常情况，不要让服务器满负荷运行，尽可能把负载均摊到所有服务器上， 让每台服务器的负载都不高，保证集群整体稳定性。

分布式系统的特点（四） 分布式系统尽可能减少节点间通讯开销 分布式系统的整体性能瓶颈在于内部网络开销。 目前网络传输的速度还赶不上CPU读取内存或硬盘的速度，所以减少网络 通讯开销，让CPU尽可能处理内存的数据或本地硬盘的数据，能显著提高分 布式系统的性能。典型的例子就是MapReduce，移动计算，而不是移动数 据，避免在网络上传输大量数据。

分布式系统的特点（五） 分布式系统应用服务最好做成无状态的 应用服务的状态是指运行时程序因为处理服务请求而在内存中保存的数据。 应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而 挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服 务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上，这样 应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后 恢复应用服务。

分布式系统CAP理论（背景） 分布式系统的本质--多个组件分布在不同的节点上，通过网络协 同工作才可以完成某项工作。 分布式系统设计实现中必须面对的三大问题： 集群中不同节点的数据一致性问题 集群中节点故障导致的服务不可用问题 集群中网络故障导致的服务不可用问题

分布式系统CAP理论 Consistency 更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完 全一致 Availability  读和写操作都能成功 Partition tolerance    再出现网络故障导致分布式节点间不能通信时，系统能否继续服务

分布式系统CAP理论 在分布式系统的设计中， 没有一种设计可以同时 满足一致性，可用性， 分区容错性 3个特性 分布式系统中必须满足 分区容错性

分布式系统CAP理论（选择权衡） 选择的关键点取决于业务场景（C、A、P） 以对数据一致性有要求场景举个例子： 强一致性场景（银行业务）—— ACID  传统数据库常用的设计理念 弱一致性场景（大部分的互联网需求）—— BASE(Basically Available, Soft State, Eventual Consistency  基本可用、软状态、最终一致性) 对 CAP AP理论的延伸, Redis等众多系统构建与这个理论之上

Hadoop起源和发展（缘起篇） Google，搜索引擎世界巨头，面对海量数据处理挑战，提出了一整套基于分 布式并行集群方式的基础架构技术 分布式资源管理系统Borg —— “Large-scale clustermanagement at Google with Borg” 针对Google应用程序的特点提出的MapReduce 编程模式 —— 大规模数据集的并行运算 Google文件系统（GFS）——大型的分布式文件系统，提供海量存储功能 分布式的锁机制Chubby —— 解决了分布式系统的一致性问题 大规模分布式数据库BigTable —— 弱一致性要求的大规模“数据库系统”

Hadoop起源和发展（发展篇一） Doug Cutting主导的Apache Nutch项目是Hadoop软件的源头，该项 目始于2002年，是Apache Lucene 的子项目之一。 Google在2003年于SOSP上发表了分布式文件系统的论文“The Google File System”--> 2004年，Nutch的分布式文件系统(NDFS)开 始开发。 2004年，Google在OSDI上发表了题为“MapReduce: Simplified Data Processing on Large Clusters”的论文Doug Cutting等人开始 实现MapReduce计算框架并与NDFS（Nutch Distributed File System） 结合起来，共同支持Nutch的主要算法。

Hadoop起源和发展（发展篇二） 2006年，它逐渐成为一套完整而独立的软件，已经到Yahoo!工作的 Doug Cutting将这套大数据处理软件命名为Hadoop。 2008年初，Hadoop成为Apache的顶级项目，除Yahoo!之外在众多互联 网企业中得到应用。此时的Hadoop系统又称为Hadoop v1，主要由两个 核心组件构成：HDFS和MapReduce。 一些围绕在Hadoop周围的开源项目，为完善大数据处理的全生命周期提供了必要的 配套和补充。这些软件常用的有ZooKeeper、Hive、Pig、HBase、Storm、Kafka、 Flume、Sqoop、Oozie、Mahout等。

Hadoop起源和发展（发展篇三） 2012年5月，Hadoop v2的alpha版本发布，其中最重要的变化是在 Hadoop核心组件中增加了YARN（Yet Another Resource Negotiator）。YARN的出现是为了把计算框架与资源管理彻底分离开， 解决Hadoop v1由此带来的扩展性差、单点故障和不能同时支持多种计 算框架的问题。YARN对标的恰好就是Google的Borg系统。至此， Hadoop方才能够与Google的大数据平台比肩。 Hadoop也成为自Linux以来最成功的开源软件，没有之一。 2013年出现了Spark，在全面兼容Hadoop原有组件的基础上，Spark通 过更多的利用内存处理大幅提高系统性能。（Apache Flink）

Hadoop系统整体架构

Hadoop系统的三种安装模式 单机模式（默认） 伪分布式 完全分布式 Hadoop系统默认启动运行模式，仅作体验MapReduce使用。 使用多个守护线程模拟分布的伪分布运行模式 完全分布式 就是真正多台机器来搭建分布式集群

Hadoop系统的三种安装模式（单机模式） 此时的Hadoop系统仅仅是一个独立的Java进程 不需要与其他节点交互，单机模式就不使用HDFS，也不加载任何其他 Hadoop的守护进程 该模式主要用于开发调试MapReduce程序的应用逻辑

Hadoop系统的三种安装模式（伪分布式模式） 该模式在单机模式之上增加了代码调试功能，允许你检查内存使 用情况，HDFS输入输出，以及其他的守护进程交互。

Hadoop系统的三种安装模式（完全分布式模式） 几个重要的配置文件： core-site.xml  配置HDFS节点名称和地址 hdfs-site.xml  配置HDFS存储目录，复制数量 mapred-site.xml    配置mapreduce的jobtracker地址

Q&A