YARN是开源项目Hadoop的一个资源管理系统，最初设计是为了解决Hadoop中MapReduce计算框架中的资源管理问题，但是现在它已经是一个更加通用的资源管理系统，可以把MapReduce计算框架作为一个应用程序运行在YARN系统之上，通过YARN来管理资源。如果你的应用程序也需要借助YARN的资源管理功能，你也可以实现YARN提供的编程API，将你的应用程序运行于YARN之上，将资源的分配与回收统一交给YARN去管理，可以大大简化资源管理功能的开发。当前，也有很多应用程序已经可以构建于YARN之上，如Storm、Spark等计算框架。 YARN整体架构 YARN是基于Master/Slave模式的分布式架构，我们先看一下，YARN的架构设计，如图所示（来自官网文档）： 上图，从逻辑上定义了YARN系统的核心组件和主要交互流程，各个组件说明如下： YARN Client YARN Client提交Application到RM，它会首先创建一个Application上下文件对象，并设置AM必需的资源请求信息，然后提交到RM。YARN Client也可以与RM通信，获取到一个已经提交并运行的Application的状态信息等，具体详见后面ApplicationClientPro
按分类浏览文章: 开源技术
Spark-1.3.1与Hive整合实现查询分析
在大数据应用场景下，使用过Hive做查询统计分析的应该知道，计算的延迟性非常大，可能一个非常复杂的统计分析需求，需要运行1个小时以上，但是比之于使用MySQL之类关系数据库做分析，执行速度快很多很多。使用HiveQL写类似SQL的查询分析语句，最终经过Hive查询解析器，翻译成Hadoop平台上的MapReduce程序进行运行，这也是MapReduce计算引擎的特点带来的延迟问题：Map中间结果写文件。如果一个HiveQL语句非常复杂，会被翻译成多个MapReduce Job，那么就会有很多的Map输出中间结果数据到文件中，基本没有数据的共享。 如果使用Spark计算平台，基于Spark RDD数据集模型计算，可以减少计算过程中产生中间结果数据写文件的开销，Spark会把数据直接放到内存中供后续操作共享数据，减少了读写磁盘I/O操作带来的延时。另外，如果基于Spark on YARN部署模式，可以充分利用数据在Hadoop集群DataNode节点的本地性（Locality）特点，减少数据传输的通信开销。 软件准备 我把使用的相关软件的版本在这里列出来，以便测试验证，如下所示： CentOS-6.6 (Final) JDK-1.7.0_25 Maven
Kafka+Spark Streaming+Redis实时计算整合实践
基于Spark通用计算平台，可以很好地扩展各种计算类型的应用，尤其是Spark提供了内建的计算库支持，像Spark Streaming、Spark SQL、MLlib、GraphX，这些内建库都提供了高级抽象，可以用非常简洁的代码实现复杂的计算逻辑、这也得益于Scala编程语言的简洁性。这里，我们基于1.3.0版本的Spark搭建了计算平台，实现基于Spark Streaming的实时计算。 我们的应用场景是分析用户使用手机App的行为，描述如下所示： 手机客户端会收集用户的行为事件（我们以点击事件为例），将数据发送到数据服务器，我们假设这里直接进入到Kafka消息队列 后端的实时服务会从Kafka消费数据，将数据读出来并进行实时分析，这里选择Spark Streaming，因为Spark Streaming提供了与Kafka整合的内置支持 经过Spark Streaming实时计算程序分析，将结果写入Redis，可以实时获取用户的行为数据，并可以导出进行离线综合统计分析 Spark Streaming介绍 Spark Streaming提供了一个叫做DStream（Discretized Stream）的高级抽象，DStream表示一个持续不断输入的数据流，可以基于Kafka、TCP Socket、Flu
基于Dubbo框架构建分布式服务
Dubbo是Alibaba开源的分布式服务框架，我们可以非常容易地通过Dubbo来构建分布式服务，并根据自己实际业务应用场景来选择合适的集群容错模式，这个对于很多应用都是迫切希望的，只需要通过简单的配置就能够实现分布式服务调用，也就是说服务提供方（Provider）发布的服务可以天然就是集群服务，比如，在实时性要求很高的应用场景下，可能希望来自消费方（Consumer）的调用响应时间最短，只需要选择Dubbo的Forking Cluster模式配置，就可以对一个调用请求并行发送到多台对等的提供方（Provider）服务所在的节点上，只选择最快一个返回响应的，然后将调用结果返回给服务消费方（Consumer），显然这种方式是以冗余服务为基础的，需要消耗更多的资源，但是能够满足高实时应用的需求。 有关Dubbo服务框架的简单使用，可以参考我的其他两篇文章（《基于Dubbo的Hessian协议实现远程调用》，《Dubbo实现RPC调用使用入门》，后面参考链接中已给出链接），这里主要围绕Dubbo分布式服务相关配置的使用来说明与实践。 Dubbo服务集群容错 假设我们使用的是单机模式的Dubbo服务，如
Apache Crunch：简化编写MapReduce Pipeline程序
Apache Crunch提供了一套Java API，能够简化编写、测试、运行MapReduce Pipeline程序。Crunch的基本思想是隐藏编写MapReduce程序的细节，基于函数式编程的思想，定义了一套函数式编程接口，因为Java并不支持函数式编程，只能通过回调的方式来实现，虽然写起来代码不够美观简洁，但是编写MapReduce程序的思路是非常清晰的，而且比编写原生的MapReduce程序要容易地多。如果直接使用MapReduce API编写一个复杂的Pipeline程序，可能需要考虑好每个Job的细节（Map和Reduce的实现内容），而使用Crunch变成库来编写，只需要清晰地控制好要实现的业务逻辑处理的操作流程，调用Crunch提供的接口（类似函数操作的算子、如union、join、filter、groupBy、sort等等）。 下面，我们简单说明一下Crunch提供的一些功能或内容： Crunch集合及操作 我们看一下Crunch提供的用来在处理分布式数据集的集合类型的抽象定义，如下面类图所示： 上面，我给出了集合类对应的方法签名，其中具有相同名称签名的方法还具有重载的其他方法签名（参数列表不同），Crunch集合类型的高层抽象就包含
JStorm-0.9.6.2安装配置
JStorm是由Alibaba开源的实时计算系统，它使用Java重写了Apache Storm（使用Clojure+Java混编），而且在原来的基础上做了很多改进的地方。使用Java重写，对于使用Java的开发人员来说，可以通过阅读源码来了解JStorm内部的原理和实现，而且可以根据运行错误日志来排查错误。 下面通过安装配置，以及简单使用的验证，来说明JStorm宏观上与Apache Storm的不同之处。 安装配置JStorm Server 首先，要保证JDK成功安装配置，然后在一个节点上下载、安装、配置JStorm。例如，我在hadoop1节点上，下载并解压缩： wget http://42.121.19.155/jstorm/jstorm-0.9.6.2.zip unzip jstorm-0.9.6.2.zip cd jstorm-0.9.6.2 修改配置文件conf/storm.yaml，内容修改如下： ########### These MUST be filled in for a storm configuration storm.zookeeper.servers: - "10.10.4.128" - "10.10.4.129" - "10.10.4.130" storm.zookeeper.root: "/jstorm" # %JSTORM_HOME% is the jstorm home directory s
Hue安装配置实践
Hue是一个开源的Apache Hadoop UI系统，最早是由Cloudera Desktop演化而来，由Cloudera贡献给开源社区，它是基于Python Web框架Django实现的。通过使用Hue我们可以在浏览器端的Web控制台上与Hadoop集群进行交互来分析处理数据，例如操作HDFS上的数据，运行MapReduce Job等等。很早以前就听说过Hue的便利与强大，一直没能亲自尝试使用，下面先通过官网给出的特性，通过翻译原文简单了解一下Hue所支持的功能特性集合： 默认基于轻量级sqlite数据库管理会话数据，用户认证和授权，可以自定义为MySQL、Postgresql，以及Oracle 基于文件浏览器（File Browser）访问HDFS 基于Hive编辑器来开发和运行Hive查询 支持基于Solr进行搜索的应用，并提供可视化的数据视图，以及仪表板（Dashboard） 支持基于Impala的应用进行交互式查询 支持Spark编辑器和仪表板（Dashboard） 支持Pig编辑器，并能够提交脚本任务 支持Oozie编辑器，可以通过仪表板提交和监控Workflow、Coordinator和Bundle 支持HBase浏览器，能够可视化数据、查询数据、修改HBase表 支持Metastore浏览器，可以访问
基于Hadoop SLA认证机制实现权限控制
Hadoop集群上存储数据，同时基于MapReduce计算框架可以实现计算任务，那么无论是从数据保护的角度，还是从提交计算任务占用资源的角度来看，都需要存在一种权限管理与分配机制，能够很好地限制哪些人可以在HDFS上存储数据，哪些人可以利用集群的资源来处理特定的计算任务。当然，如果能够非常完美地解决这些问题是最好的。当前Hadoop本身提供的权限管理功能还不能满足普遍的需要，或者我们从Hadoop已有的一些简单或复杂的认证机制选择适合自己所在组织机构需要的，或者我们在外围开发一些权限管理系统与Hadoop整合作为补充。 对比Kerberos认证（Authentication）配置方式与SLA授权（Service Level Authorization）方式，Kerberos配置相当复杂，而且还要依赖于外部的密钥分发中心KDC（Key Distribution Center）服务器，如果KDC出现问题，那么就会导致依赖于KDC认证的整个Hadoop集群无法使用，鉴于此，对于一些相对小的开发团队来说还是更倾向于粗粒度的Hadoop SLA授权机制。 Hadoop SLA基于Hadoop的各种服务（基于协议来划分）与Linux系统的用户、用户组来实现。Had
Storm实时计算：流操作入门编程实践
Storm是一个分布式是实时计算系统，它设计了一种对流和计算的抽象，概念比较简单，实际编程开发起来相对容易。下面，简单介绍编程实践过程中需要理解的Storm中的几个概念： Topology Storm中Topology的概念类似于Hadoop中的MapReduce Job，是一个用来编排、容纳一组计算逻辑组件（Spout、Bolt）的对象（Hadoop MapReduce中一个Job包含一组Map Task、Reduce Task），这一组计算组件可以按照DAG图的方式编排起来（通过选择Stream Groupings来控制数据流分发流向），从而组合成一个计算逻辑更加负责的对象，那就是Topology。一个Topology运行以后就不能停止，它会无限地运行下去，除非手动干预（显式执行bin/storm kill ）或意外故障（如停机、整个Storm集群挂掉）让它终止。 Spout Storm中Spout是一个Topology的消息生产的源头，Spout应该是一个持续不断生产消息的组件，例如，它可以是一个Socket Server在监听外部Client连接并发送消息，可以是一个消息队列（MQ）的消费者、可以是用来接收Flume Agent的Sink所发送消息的服务，等等。Spout生产的消息在Storm中被抽
HDFS读文件过程分析：读取文件的Block数据
我们可以从java.io.InputStream类中看到，抽象出一个read方法，用来读取已经打开的InputStream实例中的字节，每次调用read方法，会读取一个字节数据，该方法抽象定义，如下所示： public abstract int read() throws IOException; Hadoop的DFSClient.DFSInputStream类实现了该抽象逻辑，如果我们清楚了如何从HDFS中读取一个文件的一个block的一个字节的原理，更加抽象的顶层只需要迭代即可获取到该文件的全部数据。 从HDFS读文件过程分析：获取文件对应的Block列表（http://shiyanjun.cn/archives/925.html）中，我们已经获取到一个文件对应的Block列表信息，打开一个文件，接下来就要读取实际的物理块数据，我们从下面的几个方面来详细说明读取数据的过程。 Client从Datanode读取文件的一个字节 下面，我们通过分析DFSClient.DFSInputStream中实现的代码，读取HDFS上文件的内容。首先从下面的方法开始： @Override public synchronized int read() throws IOException { int ret = read( oneByteBuf, 0, 1 ); return ( ret <= 0 ) ? -
HDFS 写文件过程分析
HDFS 是一个分布式文件系统，在 HDFS 上写文件的过程与我们平时使用的单机文件系统非常不同，从宏观上来看，在 HDFS 文件系统上创建并写一个文件，流程如下图（来自《Hadoop：The Definitive Guide》一书）所示： 具体过程描述如下： Client 调用 DistributedFileSystem 对象的 create 方法，创建一个文件输出流（FSDataOutputStream）对象 通过 DistributedFileSystem 对象与 Hadoop 集群的 NameNode 进行一次 RPC 远程调用，在 HDFS 的 Namespace 中创建一个文件条目（Entry），该条目没有任何的 Block 通过 FSDataOutputStream 对象，向 DataNode 写入数据，数据首先被写入 FSDataOutputStream 对象内部的 Buffer 中，然后数据被分割成一个个 Packet 数据包 以 Packet 最小单位，基于 Socket 连接发送到按特定算法选择的 HDFS 集群中一组 DataNode（正常是 3 个，可能大于等于 1）中的一个节点上，在这组 DataNode 组成的 Pipeline 上依次传输 Packet 这组 DataNode 组成的 Pipeline 反方向上，发送 ack，最终由 Pipeline 中第一个 DataNode 节点将 Pipeline a
Kafka+Storm+HDFS整合实践
在基于Hadoop平台的很多应用场景中，我们需要对数据进行离线和实时分析，离线分析可以很容易地借助于Hive来实现统计分析，但是对于实时的需求Hive就不合适了。实时应用场景可以使用Storm，它是一个实时处理系统，它为实时处理类应用提供了一个计算模型，可以很容易地进行编程处理。为了统一离线和实时计算，一般情况下，我们都希望将离线和实时计算的数据源的集合统一起来作为输入，然后将数据的流向分别经由实时系统和离线分析系统，分别进行分析处理，这时我们可以考虑将数据源（如使用Flume收集日志）直接连接一个消息中间件，如Kafka，可以整合Flume+Kafka，Flume作为消息的Producer，生产的消息数据（日志数据、业务请求数据等等）发布到Kafka中，然后通过订阅的方式，使用Storm的Topology作为消息的Consumer，在Storm集群中分别进行如下两个需求场景的处理： 直接使用Storm的Topology对数据进行实时分析处理 整合Storm+HDFS，将消息处理后写入HDFS进行离线分析处理 实时处理，只要开发满足业务需要的Topology即可，不做过多说明。这里，我们主要从安装配置K