为教师开展大数据课程教学提供全方位、一站式服务

Presentation on theme: "为教师开展大数据课程教学提供全方位、一站式服务"— Presentation transcript:

1 为教师开展大数据课程教学提供全方位、一站式服务
中国高校大数据课程公共服务平台 “大数据课程教师服务站” 为教师开展大数据课程教学提供全方位、一站式服务 扫一扫访问教师服务站 Hadoop架构再探讨 林子雨 博士/助理教授 厦门大学计算机科学系 厦门大学云计算与大数据研究中心 海峡云计算与大数据应用研究中心 主页： 厦门大学计算机科学系 年新版

2 提纲 Hadoop版本和生态系统组件 Hadoop集群配置 从Hadoop1.0到Hadoop2.0 YARN
HDFS HA和Federation Hadoop在企业中的应用 企业实战案例 本PPT是如下教材的配套讲义： 21世纪高等教育计算机规划教材 《大数据技术原理与应用 ——概念、存储、处理、分析与应用》 （2015年6月第1版） 厦门大学 林子雨 编著，人民邮电出版社 ISBN: 欢迎访问《大数据技术原理与应用》教材官方网站：

3 Hadoop版本介绍

4 Hadoop平台的比较

5 Hadoop常用的生态系统组件

6 Hadoop常用的生态系统组件

7 Hadoop整体架构

8 Hadoop集群配置 公司业务需求 线上集群介绍 集群系统结构 集群规划 硬件配置 操作系统 环境部署 集群配置 CPU配置 内存配置
文件配置 Hadoop集群管理

9 公司业务需求

10 Hadoop线上集群介绍

11 Hadoop线上集群介绍

12 集群规划

13 集群规划

14 硬件配置

15 Master介绍

16 datanode&tasktracker

17 网络配置

18 操作系统

19 环境部署

20 集群配置

21 CPU配置

22 内存配置

23 文件配置

24 Hadoop集群管理

25 集群节点的委任

26 执行balance

27 集群节点删除

28 Hadoop的局限与不足 MapReduce存在以下局限，使用起来比较困难： 抽象层次低，需要手工编写代码来完成，使用上难以上手
一个Job只有Map和Reduce两个阶段（Phase），复杂的计算需要大量的Job完成，Job之间的依赖关系是由开发者自己管理的 处理逻辑隐藏在代码细节中，没有整体逻辑 中间结果也放在HDFS文件系统中 Reduce任务需要等待所有Map任务都完成后才可以开始 时延高，只适用批数据处理，对于交互式数据处理，实时数据处理的支持不够 对于迭代式数据处理性能比较差 因此，在Hadoop推出之后，出现了很多相关的技术对其中的局限进行改进，如Pig，Cascading，JAQL，OOzie，Tez，Spark等。

29 Apache Pig Apache Pig也是Hadoop框架中的一部分，Pig提供类SQL语言（Pig Latin）通过MapReduce来处理大规模半结构化数据。而Pig Latin是更高级的过程语言，通过将MapReduce中的设计模式抽象为操作，如Filter，GroupBy，Join，OrderBy，由这些操作组成有向无环图（DAG）。例如如下程序： visits = load ‘/data/visits’ as (user, url, time); gVisits = group visits by url; visitCounts = foreach gVisits generate url, count(visits); urlInfo = load ‘/data/urlInfo’ as (url, category, pRank); visitCounts = join visitCounts by url, urlInfo by url; gCategories = group visitCounts by category; topUrls = foreach gCategories generate top(visitCounts,10); store topUrls into ‘/data/topUrls’; 描述了数据处理的整个过程。 而Pig Latin又是通过编译为MapReduce，在Hadoop集群上执行的。上述程序被编译成MapReduce时，会产生如下图所示的Map和Reduce：

30 Apache Pig

31 Apache Tez Tez是Apache最新开源的支持DAG作业的计算框架，它直接源于MapReduce框架，核心思想是将Map和Reduce两个操作进一步拆分，即Map被拆分成Input、Processor、Sort、Merge和Output， Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等，这样，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的DAG作业。 以如下SQL为例： SELECT a.state, COUNT(*), AVERAGE(c.price) FROM a JOIN b ON (a.id = b.id) JOIN c ON (a.itemId = c.itemId) GROUP BY a.state

32 Apache Tez 途中蓝色方块表示Map，绿色方块表示Reduce，云状表示写屏障（write barrier，一种内核机制，可以理解为持久的写），Tez的优化主要体现在： 去除了连续两个作业之间的写屏障 去除了每个工作流中多余的Map阶段（Stage） 通过提供DAG语义和操作，提供了整体的逻辑，通过减少不必要的操作，Tez提升了数据处理的执行性能 Tez已被Hortonworks用于Hive引擎的优化，经测试，性能提升约100倍

33 Apache Tez (Tez+Hive)与Impala、Dremel和Drill的区别？
(Tez+Hive)与Impala、Dremel和Drill均可用于解决Hive/Pig延迟大、性能低效的问题，Impala、Dremel和Drill的出发点是抛弃MapReduce计算框架，不再将SQL或者PIG语句翻译成MR程序，而是采用传统数据数据库的方式，直接从DataNode上存取数据，而(Tez+Hive)则不同，(Tez+Hive)仍采用MapReduce计算框架，但对DAG的作业依赖关系进行了裁剪，并将多个小作业合并成一个大作业，这样，不仅计算量减少，而且写HDFS次数也会大大减少。 Tez计算框架的引入，至少可以解决现有MR框架在迭代计算（如PageRank计算）和交互式计算方面（如Hive和Pig，当前Hortonworks已将Tez用到了Hive DAG优化中）的不足，此外，Tez是基于YARN的，可以与原有的MR共存，至此，YARN已经支持两种计算框架：Tez和MR，随着时间的推移，YARN上会出现越来越多的计算框架，而YARN这种资源统一管理系统必将越来越成熟、稳定。

34 Hadoop1.0的局限与不足

35 Hadoop版本演化 Apache Hadoop版本分为两代，我们将第一代Hadoop称为Hadoop 1.0，第二代Hadoop称为Hadoop 2.0 第一代Hadoop包含三个大版本，分别是0.20.x，0.21.x和0.22.x，其中，0.20.x最后演化成1.0.x，变成了稳定版，而0.21.x和0.22.x则增加了NameNode HA等新的重大特性 第二代Hadoop包含两个版本，分别是0.23.x和2.x，它们完全不同于Hadoop 1.0，是一套全新的架构，均包含HDFS Federation和YARN两个系统，相比于0.23.x，2.x增加了NameNode HA和Wire-compatibility两个重大特性

36 从Hadoop1.0到Hadoop2.0

37 从Hadoop1.0到Hadoop2.0

38 MapReduce框架的缺陷 从上图中可以清楚的看出原 MapReduce 程序的流程及设计思路：
首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作 TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况 TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程

39 MapReduce框架的缺陷

40 YARN 为从根本上解决旧 MapReduce 框架的性能瓶颈，促进 Hadoop 框架的更长远发展，从 版本开始，Hadoop 的 MapReduce 框架完全重构，发生了根本的变化。新的 Hadoop MapReduce 框架命名为 MapReduceV2 或者叫 Yarn

41 YARN

42 YARN

43 YARN ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM） 调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态等，也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务，这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。 应用程序管理器 负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

44 YARN ApplicationMaster（AM） 用户提交的每个应用程序均包含一个AM，主要功能包括：
与RM调度器协商以获取资源（用Container表示）； 将得到的任务进一步分配给内部的任务(资源的二次分配)； 与NM通信以启动/停止任务； 监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向调度器汇报。一方面，它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自AM的Container启动/停止等各种请求。

45 YARN

46 YARN

47 新旧 Hadoop MapReduce 框架比对
Yarn 框架相对于老的 MapReduce 框架而言，具有以下优势： Yarn的设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中 对于资源的表示以内存为单位 ，比之前以剩余 slot 数目更合理 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启 Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况

48 YARN的背景和目标 资源统一管理/调度系统
在公司和机构中，服务器往往会因为业务逻辑被拆分为多个集群，基于数据密集型的处理框架也是不断涌现，比如支持离线处理的MapReduce、支持在线处理的Storm及Impala、支持迭代计算的Spark及流处理框架S4，它们诞生于不同的实验室，并各有所长。网页索引采用MapReduce框架，自然语言处理和数据挖掘采用Spark，对性能要求很高的数据挖掘算法采用MPI。为了减少管理成本，提升资源的利用率，一个共同的想法产生——让这些框架运行在同一个集群上；因此，就有了当下众多的资源统一管理/调度系统，比如Google的Borg、Apache的YARN、Twitter的Mesos（已贡献给Apache基金会）、腾讯搜搜的Torca、 Facebook Corona（开源） YARN产生的背景：运维成本和数据共享问题。如果采用“一个框架一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运营成本，而共享模式通常需要少数管理员，即可完成多个框架的统一管理。随着数据量的暴增，跨集群间的数据移动不仅要花费更长的时间，且硬件成本也会大大增加，而共享集群模式可以让多种框架共享数据和硬件资源，将大大减少数据移动带来的成本。

49 YARN的背景和目标

50 HDFS新特性：HA和Federation
相比于Hadoop1.0，Hadoop 2.0中的HDFS增加了两个重大特性，HA和Federaion。 HA即为High Availability，用于解决NameNode单点故障问题，该特性通过热备的方式为主NameNode提供一个备用者，一旦主NameNode出现故障，可以迅速切换至备NameNode，从而实现不间断对外提供服务。 Federation即为“联邦”，该特性允许一个HDFS集群中存在多个NameNode同时对外提供服务，这些NameNode分管一部分目录（水平切分），彼此之间相互隔离，但共享底层的DataNode存储资源。

51 HDFS HA 在一个典型的HDFS HA场景中，通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外提供服务，仅同步active namenode的状态，以便能够在它失败时快速进行切换 为了能够实时同步Active和Standby两个NameNode的元数据信息（实际上editlog），需提供一个共享存储系统，可以是NFS、QJM（Quorum Journal Manager）或者Zookeeper，Active NameNode将数据写入共享存储系统，而Standby监听该系统，一旦发现有新数据写入，则读取这些数据，并加载到自己内存中，以保证自己内存状态与Active NameNode保持基本一致，如此这般，在紧急情况下standby便可快速切为active NameNode

52 HDFS HA

53 HDFS HA 为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。  对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，JNs必须确保同一时刻只有一个NameNode可以向自己写数据。 

54 HDFS HA

55 HDFS Federation

56 Hadoop在企业中的实际应用

57 Hadoop在企业中的实际应用

58 Hadoop在企业中的实际应用

59 Hadoop在企业中的实际应用

60 大数据应用场景

61 离线分析

62 海量数据准实时架构

63 流计算——Storm

64 内存计算——Spark

65 企业实战案例 某企业，2013年中期，随着业务高速发展，越来越多的移动设备侧数据被各个不同的业务平台收集。那么这些数据除了提供不同业务所需要的业务指标，是否还蕴藏着更多的价值？为了更好地挖掘数据潜在价值，该企业决定建造自己的数据中心，将各业务平台的数据汇集到一起，对覆盖设备的相关数据进行加工、分析和挖掘，从而探索数据的价值。初期数据中心主要功能设置如下所示： 1. 跨市场聚合的安卓应用排名； 2. 基于用户兴趣的应用推荐。

66 企业实战案例 基于当时的技术掌握程度和功能需求，数据中心所采用的技术架构如图1。

67 企业实战案例 整个系统构建基于Hadoop 2.0（Cloudera CDH4.3），采用了最原始的大数据计算架构。通过日志汇集程序，将不同业务平台的日志汇集到数据中心，并通过ETL将数据进行格式化处理，储存到HDFS。其中，排名和推荐算法的实现都采用了MapReduce，系统中只存在离线批量计算，并通过基于Azkaban的调度系统进行离线任务的调度。

68 企业实战案例 第一个版本的数据中心架构基本上是以满足“最基本的数据利用”这一目的进行设计的。然而，随着对数据价值探索的逐渐加深，越来越多的实时分析需求被提出。与此同时，更多的机器学习算法也亟需添加，以便支持不同的数据挖掘需求。对于实时数据分析，显然不能通过“对每个分析需求单独开发MapReduce任务”来完成，因此引入Hive 是一个简单而直接的选择。 鉴于传统的MapReduce模型并不能很好地支持迭代计算，我们需要一个更好的并行计算框架来支持机器学习算法。而这些正是我们一直在密切关注的Spark所擅长的领域——凭借其对迭代计算的友好支持，Spark理所当然地成为了不二之选。2013年9月底，随着Spark 0.8.0发布，我们决定对最初的架构进行演进，引入Hive作为即时查询的基础，同时引入Spark计算框架来支持机器学习类型的计算，并且验证Spark这个新的计算框架是否能够全面替代传统的以MapReduce为基础的计算框架。图2为整个系统的架构演变。

69 企业实战案例

70 企业实战案例 在这个架构中，我们将Spark 0.8.1部署在YARN上，通过分Queue，来隔离基于Spark的机器学习任务，计算排名的日常MapReduce任务和基于Hive的即时分析任务。 想要引入Spark，第一步需要做的就是要取得支持我们Hadoop环境的Spark包。我们的Hadoop环境是Cloudera发布的CDH 4.3，默认的Spark发布包并不包含支持CDH 4.3的版本，因此只能自己编译。Spark官方文档推荐用Maven进行编译，可是编译却不如想象中顺利。各种包依赖由于众所周知的原因，不能顺利地从某些依赖中心库下载。于是我们采取了最简单直接的绕开办法，利用AWS云主机进行编译。 在编译成功所需要的Spark包后，部署和在Hadoop环境中运行Spark则是非常简单的事情。将编译好的Spark目录打包压缩后，在可以运行Hadoop Client的机器上解压缩，就可以运行Spark了。

71 企业实战案例 完成Spark部署之后，剩下的就是开发基于Spark的程序了。虽然Spark支持Java、Python，但最合适开发Spark程序的语言还是Scala。经过一段时间的摸索实践，我们掌握了Scala语言的函数式编程语言特点后，终于体会了利用Scala开发Spark应用的巨大好处。同样的功能，用MapReduce几百行才能实现的计算，在Spark中，Scala通过短短的数十行代码就能完成。而在运行时，同样的计算功能，Spark上执行则比MapReduce有数十倍的提高。对于需要迭代的机器学习算法来讲，Spark的RDD模型相比MapReduce的优势则更是明显，更何况还有基本的MLlib的支持。经过几个月的实践，数据挖掘相关工作被完全迁移到Spark，并且在Spark上实现了适合我们数据集的更高效的LR等等算法。

72 企业实战案例 基于YARN和Spark，我们开始重新架构数据中心依赖的大数据平台。整个新的数据平台应该能够承载：
1. 准实时的数据汇集和ETL； 2. 支持流式的数据加工； 3. 更高效的离线计算能力； 4. 高速的多维分析能力； 5. 更高效的即时分析能力； 6. 高效的机器学习能力； 7. 统一的数据访问接口； 8. 统一的数据视图； 9. 灵活的任务调度.

73 企业实战案例 整个新的架构充分地利用YARN和Spark，并且融合公司的一些技术积累，架构如图所示。

74 企业实战案例 在新的架构中，引入了Kafka作为日志汇集的通道。几个业务系统收集的移动设备侧的日志，实时地写入到Kafka 中，从而方便后续的数据消费。 利用Spark Streaming，可以方便地对Kafka中的数据进行消费处理。在整个架构中，Spark Streaming主要完成了以下工作。 1. 原始日志的保存。将Kafka中的原始日志以JSON格式无损的保存在HDFS中。 2. 数据清洗和转换，清洗和标准化之后，转变为Parquet格式，存储在HDFS中，方便后续的各种数据计算任务。 3. 定义好的流式计算任务，比如基于频次规则的标签加工等等，计算结果直接存储在MongoDB中。

75 企业实战案例 排名计算任务则在Spark上做了重新实现，借力Spark带来的性能提高，以及Parquet列式存储带来的高效数据访问。同样的计算任务，在数据量提高到原来3倍的情况下，时间开销只有原来的1/6。 同时，在利用Spark和Parquet列式存储带来的性能提升之外，曾经很难满足业务需求的即时多维度数据分析终于成为了可能。曾经利用Hive需要小时级别才能完成日尺度的多维度即时分析，在新架构上，只需要2分钟就能够顺利完成。而周尺度上也不过十分钟就能够算出结果。曾经在Hive上无法完成的月尺度多维度分析计算，则在两个小时内也可以算出结果。另外Spark SQL的逐渐完善也降低了开发的难度。 利用YARN提供的资源管理能力，用于多维度分析，自主研发的Bitmap引擎也被迁移到了YARN上。对于已经确定好的维度，可以预先创建Bitmap索引。而多维度的分析，如果所需要的维度已经预先建立了Bitmap索引，则通过Bitmap引擎由Bitmap计算来实现，从而可以提供实时的多维度的分析能力。 在新的架构中，为了更方便地管理数据，我们引入了基于HCatalog的元数据管理系统，数据的定义、存储、访问都通过元数据管理系统，从而实现了数据的统一视图，方便了数据资产的管理。

76 企业实战案例 基于围绕YARN和Spark的新的架构，一个针对数据业务部门的自服务大数据平台得以实现，数据业务部门可以方便地利用这个平台对进行多维度的分析、数据的抽取，以及进行自定义的标签加工。自服务系统提高了数据利用的能力，同时也大大提高了数据利用的效率。

77 基于Flume的美团日志收集系统 美团日志收集系统架构
美团的日志收集系统负责美团的所有业务日志的收集，并分别给Hadoop平台提供离线数据和Storm平台提供实时数据流。美团的日志收集系统基于Flume设计和搭建而成。目前每天收集和处理约TB级别的日志数据。 HDFS负责永久地存储所有日志；Kafka存储最新的7天日志，并给Storm系统提供实时日志流；Bypass负责给其它服务器和应用提供实时日志流。

78 附录：主讲教师简介 主讲教师：林子雨 单位：厦门大学计算机科学系 个人网页： 数据库实验室网站： 扫一扫访问个人主页 林子雨，男，1978年出生，博士（毕业于北京大学），现为厦门大学计算机科学系助理教授（讲师），曾任厦门大学信息科学与技术学院院长助理、晋江市发展和改革局副局长。厦门大学数据库实验室负责人，厦门大学云计算与大数据研究中心主要建设者和骨干成员，2013年度厦门大学奖教金获得者。主要研究方向为数据库、数据仓库、数据挖掘、大数据、云计算和物联网。中国高校首个“数字教师”提出者和建设者，自2009年从事教师职业以来，“数字教师”大平台累计免费网络发布超过100万字高价值教学和科研资料，累计网络浏览量超过100万次。编著出版中国高校第一本系统介绍大数据知识的专业教材《大数据技术原理与应用》，并建设了中国高校首个大数据课程公共服务平台。主讲厦门大学计算机系本科生课程《数据库系统原理》和研究生课程《分布式数据库》《大数据技术基础》。具有丰富的政府和企业信息化培训经验，曾先后给中国移动通信集团公司、福建龙岩卷烟厂、福州马尾区政府、福建省物联网科学研究院、石狮市物流协会、厦门市物流协会、泉州中小企业等多家单位和企业开展信息化培训，累计培训人数达2000人以上。

79 附录：大数据学习教材推荐 《大数据技术原理与应用——概念、存储、处理、分析与应用》，由厦门大学计算机科学系林子雨博士编著，是中国高校第一本系统介绍大数据知识的专业教材。 全书共有13章，系统地论述了大数据的基本概念、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据 库HBase、NoSQL数据库、云数据库、分布式并行编程模型MapReduce、流计算、图计算、数据可视化以及大数据在互联网、生物医学和物流等各个领域的应用。在Hadoop、HDFS、HBase和MapReduce等重要章节，安排了入门级的实践操作，让读者更好地学习和掌握大数据关键技术。 本书可以作为高等院校计算机专业、信息管理等相关专业的大数据课程教材，也可供相关技术人员参考、学习、培训之用。 扫一扫访问教材官网 欢迎访问《大数据技术原理与应用——概念、存储、处理、分析与应用》教材官方网站：

80 附录：中国高校大数据课程公共服务平台 扫一扫访问平台主页 扫一扫观看3分钟FLASH动画宣传片

81 Department of Computer Science, Xiamen University, Jan, 2016