<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>简单之美 &#187; Tag &#187; Hadoop</title>
	<atom:link href="http://shiyanjun.cn/archives/tag/hadoop/feed" rel="self" type="application/rss+xml" />
	<link>http://shiyanjun.cn</link>
	<description>简单之美，难得简单，享受简单的唯美。</description>
	<lastBuildDate>Wed, 04 Mar 2026 07:04:53 +0000</lastBuildDate>
	<language>zh-CN</language>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.9.2</generator>
	<item>
		<title>CDH-5.7.0：基于Parcels方式离线安装配置</title>
		<link>http://shiyanjun.cn/archives/1728.html</link>
		<comments>http://shiyanjun.cn/archives/1728.html#comments</comments>
		<pubDate>Thu, 28 Sep 2017 08:04:10 +0000</pubDate>
		<dc:creator><![CDATA[Yanjun]]></dc:creator>
				<category><![CDATA[Hadoop/Hive/ZooKeeper]]></category>
		<category><![CDATA[开源技术]]></category>
		<category><![CDATA[CDH]]></category>
		<category><![CDATA[Hadoop]]></category>

		<guid isPermaLink="false">http://shiyanjun.cn/?p=1728</guid>
		<description><![CDATA[<p>CDH是Cloudera公司提供的Hadoop发行版，它在原生开源的Apache Hadoop基础之上，针对特定版本的Hadoop以及Hadoop相关的软件，如Zookeeper、HBase、Flume、Sqoop等做了兼容性开发，我们在安装CDH发行版的Hadoop时就无需进行额外繁琐的兼容性测试。
以往安装配置使用Apache Hadoop时，完全需要手动在服务器上，通过命令和脚本进行安装配置，比较复杂而繁琐。使用CDH，我们可以通过Cloudera提供的CM（Cloudera Manager）来进行安装，CM是一个面向Hadoop相关软件的强大SCM工具，它提供了通过Web界面向导的方式进行软件的安装配置，此外还提供了比较基础、友好的监控、预警功能，通过Web UI展示各种已安装软件的资源使用情况、系统运行状态等等。
如果使用CM来管理CDH平台，因为CM使用了监控管理、运行状态数据采集、预警等等很多服务，所以在集群服务器资源使用方面也会比通常的Apache Hadoop版本多很多，如果所需要的Hadoop集群规模超大，比如成百上千个节点，使用CM来安装管理CDH集群能够节省大量时间，而且节省了对整个集群基本的监控的配置管理；如果集群规模比较小，</p>]]></description>
	<p>CDH是Cloudera公司提供的Hadoop发行版，它在原生开源的Apache Hadoop基础之上，针对特定版本的Hadoop以及Hadoop相关的软件，如Zookeeper、HBase、Flume、Sqoop等做了兼容性开发，我们在安装CDH发行版的Hadoop时就无需进行额外繁琐的兼容性测试。
以往安装配置使用Apache Hadoop时，完全需要手动在服务器上，通过命令和脚本进行安装配置，比较复杂而繁琐。使用CDH，我们可以通过Cloudera提供的CM（Cloudera Manager）来进行安装，CM是一个面向Hadoop相关软件的强大SCM工具，它提供了通过Web界面向导的方式进行软件的安装配置，此外还提供了比较基础、友好的监控、预警功能，通过Web UI展示各种已安装软件的资源使用情况、系统运行状态等等。
如果使用CM来管理CDH平台，因为CM使用了监控管理、运行状态数据采集、预警等等很多服务，所以在集群服务器资源使用方面也会比通常的Apache Hadoop版本多很多，如果所需要的Hadoop集群规模超大，比如成百上千个节点，使用CM来安装管理CDH集群能够节省大量时间，而且节省了对整个集群基本的监控的配置管理；如果集群规模比较小，</p>			<content:encoded><![CDATA[<p>CDH是Cloudera公司提供的Hadoop发行版，它在原生开源的Apache Hadoop基础之上，针对特定版本的Hadoop以及Hadoop相关的软件，如Zookeeper、HBase、Flume、Sqoop等做了兼容性开发，我们在安装CDH发行版的Hadoop时就无需进行额外繁琐的兼容性测试。
以往安装配置使用Apache Hadoop时，完全需要手动在服务器上，通过命令和脚本进行安装配置，比较复杂而繁琐。使用CDH，我们可以通过Cloudera提供的CM（Cloudera Manager）来进行安装，CM是一个面向Hadoop相关软件的强大SCM工具，它提供了通过Web界面向导的方式进行软件的安装配置，此外还提供了比较基础、友好的监控、预警功能，通过Web UI展示各种已安装软件的资源使用情况、系统运行状态等等。
如果使用CM来管理CDH平台，因为CM使用了监控管理、运行状态数据采集、预警等等很多服务，所以在集群服务器资源使用方面也会比通常的Apache Hadoop版本多很多，如果所需要的Hadoop集群规模超大，比如成百上千个节点，使用CM来安装管理CDH集群能够节省大量时间，而且节省了对整个集群基本的监控的配置管理；如果集群规模比较小，</p>]]></content:encoded>
			<wfw:commentRss>http://shiyanjun.cn/archives/1728.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>PB 级海量数据服务平台架构设计实践</title>
		<link>http://shiyanjun.cn/archives/1702.html</link>
		<comments>http://shiyanjun.cn/archives/1702.html#comments</comments>
		<pubDate>Tue, 29 Aug 2017 00:10:57 +0000</pubDate>
		<dc:creator><![CDATA[Yanjun]]></dc:creator>
				<category><![CDATA[开源技术]]></category>
		<category><![CDATA[架构]]></category>
		<category><![CDATA[Hadoop]]></category>
		<category><![CDATA[Spark]]></category>

		<guid isPermaLink="false">http://shiyanjun.cn/?p=1702</guid>
		<description><![CDATA[<p>基于 PB 级海量数据实现数据服务平台，需要从各个不同的角度去权衡，主要包括实践背景、技术选型、架构设计，我们基于这三个方面进行了架构实践，下面分别从这三个方面进行详细分析讨论：
实践背景
该数据服务平台架构设计之初，实践的背景可以从三个维度来进行说明：当前现状、业务需求、架构需求，分别如下所示：
当前现状
收集了当前已有数据、分工、团队的一些基本情况，如下所示：

数据收集和基础数据加工有专门的 Team 在做，我们是基于收集后并进行过初步加工的基础数据，结合不同行业针对特定数据的需求进行二次加工的。
数据二次加工，会集成基础数据之外的其它有业务属性的数据，比如引入第三方 POI 数据等。
原始数据每天增量大约 30~40TB 左右。
计算集群采用 Spark on YARN 部署模式，大约 400 个节点。
所有数据各种属性、行为信息，都是围绕大约 40亿+ 的移动设备 ID 进行很多倍膨胀，比如每天使用微信 App 的设备的行为信息。
参与该平台的研发人员，对实际数据业务需求了解不会非常深入，因为跨多个行业及其不同数据需求的变化较快。

业务需求
另</p>]]></description>
	<p>基于 PB 级海量数据实现数据服务平台，需要从各个不同的角度去权衡，主要包括实践背景、技术选型、架构设计，我们基于这三个方面进行了架构实践，下面分别从这三个方面进行详细分析讨论：
实践背景
该数据服务平台架构设计之初，实践的背景可以从三个维度来进行说明：当前现状、业务需求、架构需求，分别如下所示：
当前现状
收集了当前已有数据、分工、团队的一些基本情况，如下所示：

数据收集和基础数据加工有专门的 Team 在做，我们是基于收集后并进行过初步加工的基础数据，结合不同行业针对特定数据的需求进行二次加工的。
数据二次加工，会集成基础数据之外的其它有业务属性的数据，比如引入第三方 POI 数据等。
原始数据每天增量大约 30~40TB 左右。
计算集群采用 Spark on YARN 部署模式，大约 400 个节点。
所有数据各种属性、行为信息，都是围绕大约 40亿+ 的移动设备 ID 进行很多倍膨胀，比如每天使用微信 App 的设备的行为信息。
参与该平台的研发人员，对实际数据业务需求了解不会非常深入，因为跨多个行业及其不同数据需求的变化较快。

业务需求
另</p>			<content:encoded><![CDATA[<p>基于 PB 级海量数据实现数据服务平台，需要从各个不同的角度去权衡，主要包括实践背景、技术选型、架构设计，我们基于这三个方面进行了架构实践，下面分别从这三个方面进行详细分析讨论：
实践背景
该数据服务平台架构设计之初，实践的背景可以从三个维度来进行说明：当前现状、业务需求、架构需求，分别如下所示：
当前现状
收集了当前已有数据、分工、团队的一些基本情况，如下所示：

数据收集和基础数据加工有专门的 Team 在做，我们是基于收集后并进行过初步加工的基础数据，结合不同行业针对特定数据的需求进行二次加工的。
数据二次加工，会集成基础数据之外的其它有业务属性的数据，比如引入第三方 POI 数据等。
原始数据每天增量大约 30~40TB 左右。
计算集群采用 Spark on YARN 部署模式，大约 400 个节点。
所有数据各种属性、行为信息，都是围绕大约 40亿+ 的移动设备 ID 进行很多倍膨胀，比如每天使用微信 App 的设备的行为信息。
参与该平台的研发人员，对实际数据业务需求了解不会非常深入，因为跨多个行业及其不同数据需求的变化较快。

业务需求
另</p>]]></content:encoded>
			<wfw:commentRss>http://shiyanjun.cn/archives/1702.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>MapReduce V1：MapTask执行流程分析</title>
		<link>http://shiyanjun.cn/archives/1457.html</link>
		<comments>http://shiyanjun.cn/archives/1457.html#comments</comments>
		<pubDate>Tue, 02 Feb 2016 09:42:38 +0000</pubDate>
		<dc:creator><![CDATA[Yanjun]]></dc:creator>
				<category><![CDATA[Hadoop/Hive/ZooKeeper]]></category>
		<category><![CDATA[开源技术]]></category>
		<category><![CDATA[Hadoop]]></category>
		<category><![CDATA[Hadoop-1.2.1]]></category>
		<category><![CDATA[MapReduce]]></category>

		<guid isPermaLink="false">http://shiyanjun.cn/?p=1457</guid>
		<description><![CDATA[<p>我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程。
在文章《MapReduce V1：TaskTracker设计要点概要分析》中我们已经了解了org.apache.hadoop.mapred.Child启动的基本流程，在Child VM启动的过程中会运行MapTask，实际是运行用户编写的MapReduce程序中的map方法中的处理逻辑，我们首先看一下，在Child类中，Child基于TaskUmbilicalProtocol协议与TaskTracker通信，获取到该Child VM需要加载的Task相关数据，包括Task本身，代码如下所示：
上面代码中，JvmTask中就包含了一个Task，也就是task，它可能是MapTask或ReduceTask。
看一下在org.apache.hadoop.mapred.Child中运行Task的基本代码，如下所示：
我们关注执行MapTask，上面，通过调用MapTask的run方法，来实际启动MapTask的运行。
MapTask整体执行流程
MapTask运行的整体流程，如下图所示：

上面流程比较直观，我们结合MapTask的run方法的代码，来进行分析，代码如下所示：
上面代码中，run方法的参数TaskUmbilicalProtocol umbilical表示一个RPC代理对象，通过该对象可以与TaskTracker进行通信，从而在</p>]]></description>
	<p>我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程。
在文章《MapReduce V1：TaskTracker设计要点概要分析》中我们已经了解了org.apache.hadoop.mapred.Child启动的基本流程，在Child VM启动的过程中会运行MapTask，实际是运行用户编写的MapReduce程序中的map方法中的处理逻辑，我们首先看一下，在Child类中，Child基于TaskUmbilicalProtocol协议与TaskTracker通信，获取到该Child VM需要加载的Task相关数据，包括Task本身，代码如下所示：

    final TaskUmbilicalProtocol umbilical =
      taskOwner.doAs(new PrivilegedExceptionAction&lt;TaskUmbilicalProtocol&gt;() {
        @Override
        public TaskUmbilicalProtocol run() throws Exception { // 建立Child到TaskTracker的RPC连接
          return (TaskUmbilicalProtocol)RPC.getProxy(TaskUmbilicalProtocol.class,
              TaskUmbilicalProtocol.versionID,
              address,
              defaultConf);
        }
    });
... ...
    JvmContext context </p>			<content:encoded><![CDATA[<p>我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程。
在文章《MapReduce V1：TaskTracker设计要点概要分析》中我们已经了解了org.apache.hadoop.mapred.Child启动的基本流程，在Child VM启动的过程中会运行MapTask，实际是运行用户编写的MapReduce程序中的map方法中的处理逻辑，我们首先看一下，在Child类中，Child基于TaskUmbilicalProtocol协议与TaskTracker通信，获取到该Child VM需要加载的Task相关数据，包括Task本身，代码如下所示：
上面代码中，JvmTask中就包含了一个Task，也就是task，它可能是MapTask或ReduceTask。
看一下在org.apache.hadoop.mapred.Child中运行Task的基本代码，如下所示：
我们关注执行MapTask，上面，通过调用MapTask的run方法，来实际启动MapTask的运行。
MapTask整体执行流程
MapTask运行的整体流程，如下图所示：

上面流程比较直观，我们结合MapTask的run方法的代码，来进行分析，代码如下所示：
上面代码中，run方法的参数TaskUmbilicalProtocol umbilical表示一个RPC代理对象，通过该对象可以与TaskTracker进行通信，从而在</p>]]></content:encoded>
			<wfw:commentRss>http://shiyanjun.cn/archives/1457.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>MapReduce V1：TaskTracker端启动Task流程分析</title>
		<link>http://shiyanjun.cn/archives/1418.html</link>
		<comments>http://shiyanjun.cn/archives/1418.html#comments</comments>
		<pubDate>Sun, 20 Dec 2015 11:59:17 +0000</pubDate>
		<dc:creator><![CDATA[Yanjun]]></dc:creator>
				<category><![CDATA[Hadoop/Hive/ZooKeeper]]></category>
		<category><![CDATA[开源技术]]></category>
		<category><![CDATA[Hadoop]]></category>
		<category><![CDATA[Hadoop-1.2.1]]></category>
		<category><![CDATA[MapReduce]]></category>

		<guid isPermaLink="false">http://shiyanjun.cn/?p=1418</guid>
		<description><![CDATA[<p>我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程。
TaskTracker周期性地向JobTracker发送心跳报告，在RPC调用返回结果后，解析结果得到JobTracker下发的运行Task的指令，即LaunchTaskAction，就会在TaskTracker节点上准备运行这个Task。Task的运行是在一个与TaskTracker进程隔离的JVM实例中执行，该JVM实例是通过org.apache.hadoop.mapred.Child来创建的，所以在创建Child VM实例之前，需要做大量的准备工作来启动Task运行。一个Task的启动过程，如下序列图所示：

通过上图，结合源码，我们将一个Task启动的过程，分为下面3个主要的步骤：

初始化跟踪Task运行的相关数据结构
准备Task运行所共享的Job资源
启动Task

下面，我们详细分析上面3个步骤的流程：
初始化跟踪Task运行的相关数据结构
如果是LaunchTaskAction，则TaskTracker会将该指令加入到一个启动Task的队列中，进行一步加载处理，如下所示：
根据Task的类型，分别加入到对应类型的TaskLauncher的队列中。这里需要了解一下TaskLauncher线程类，在TaskTracker中创建了2个TaskLauncher线程，一个是为</p>]]></description>
	<p>我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程。
TaskTracker周期性地向JobTracker发送心跳报告，在RPC调用返回结果后，解析结果得到JobTracker下发的运行Task的指令，即LaunchTaskAction，就会在TaskTracker节点上准备运行这个Task。Task的运行是在一个与TaskTracker进程隔离的JVM实例中执行，该JVM实例是通过org.apache.hadoop.mapred.Child来创建的，所以在创建Child VM实例之前，需要做大量的准备工作来启动Task运行。一个Task的启动过程，如下序列图所示：

通过上图，结合源码，我们将一个Task启动的过程，分为下面3个主要的步骤：

初始化跟踪Task运行的相关数据结构
准备Task运行所共享的Job资源
启动Task

下面，我们详细分析上面3个步骤的流程：
初始化跟踪Task运行的相关数据结构
如果是LaunchTaskAction，则TaskTracker会将该指令加入到一个启动Task的队列中，进行一步加载处理，如下所示：

  private void addToTaskQueue(LaunchTaskAction action) {
    if (action.getTask().isMapTask()) {
      mapLauncher.addToTaskQueue(action);</p>			<content:encoded><![CDATA[<p>我们基于Hadoop 1.2.1源码分析MapReduce V1的处理流程。
TaskTracker周期性地向JobTracker发送心跳报告，在RPC调用返回结果后，解析结果得到JobTracker下发的运行Task的指令，即LaunchTaskAction，就会在TaskTracker节点上准备运行这个Task。Task的运行是在一个与TaskTracker进程隔离的JVM实例中执行，该JVM实例是通过org.apache.hadoop.mapred.Child来创建的，所以在创建Child VM实例之前，需要做大量的准备工作来启动Task运行。一个Task的启动过程，如下序列图所示：

通过上图，结合源码，我们将一个Task启动的过程，分为下面3个主要的步骤：

初始化跟踪Task运行的相关数据结构
准备Task运行所共享的Job资源
启动Task

下面，我们详细分析上面3个步骤的流程：
初始化跟踪Task运行的相关数据结构
如果是LaunchTaskAction，则TaskTracker会将该指令加入到一个启动Task的队列中，进行一步加载处理，如下所示：
根据Task的类型，分别加入到对应类型的TaskLauncher的队列中。这里需要了解一下TaskLauncher线程类，在TaskTracker中创建了2个TaskLauncher线程，一个是为</p>]]></content:encoded>
			<wfw:commentRss>http://shiyanjun.cn/archives/1418.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
