曲线救己的fighter

转载 Facebook unveils Presto engine for querying 250 PB data warehouse

SUMMARY:As Facebook’s user base swells larger and larger, data about users is growing much faster, and the social networking giant has developed a faster way to analyze it all with its Presto quer

转载 Understanding GC pauses in JVM, HotSpot's minor GC.

Understanding GC pauses in JVM, HotSpot's minor GC.Stop the world pauses of JVM due to work of garbage collector are known foes of java based application. HotSpot JVM has a set of very advanced

转载 In-Stream Big Data Processing

The shortcomings and drawbacks of batch-oriented data processing were widely recognized by the Big Data community quite a long time ago. It became clear that real-time query processing and in-stream p

转载 In-Stream大数据处理模式

来自In-Stream Big Data Processing一文总结了当前大数据实时处理的通用设计和模式，主要是Storm, Cassandra, Kafka组合，也包括LinkedIn的Samza。有关批数据处理(batch-oriented data processing:以Hadoop为基础的Hive或Pig等 )的问题和缺点大家已经意识到了，实践中需要实时查询和in-stre

转载 CAP理论十二年回顾："规则"变了

编者按：由InfoQ主办的全球架构师峰会将于2012年8月10日-12日在深圳举行，为了更好地诠释架构的意义、方法和实践，InfoQ中文站近期会集中发布一批与架构相关的文章，本篇即为其中之一。InfoQ也欢迎读者亲身参与到本次全球架构师峰会中，与来自国内外的顶尖架构师进行面对面的交流。报名参会请点击这里。本文首发于  Computer 杂志，由InfoQ和IEEE呈现给您。CA

转载 nosql hash算法优化

http://blog.reverberate.org/2012/01/state-of-hash-functions-2012.html

转载 Java IO流学习总结

Java IO流学习总结Java流操作有关的类或接口：Java流类图结构： 流的概念和作用流是一组有顺序的，有起点和终点的字节集合，是对数据传输的总称或抽象。即数据在两设备间的传输称为流，流的本质是数据传输，根据数据传输特性将流抽象为各种类，方便更直观的进行数据操作。 IO流的分类根据处理数据类型的不同分为：字符流和字节流根据数据

转载 java 字节流与字符流的区别

java 字节流与字符流的区别字节流与和字符流的使用非常相似，两者除了操作代码上的不同之外，是否还有其他的不同呢？实际上字节流在操作时本身不会用到缓冲区（内存），是文件本身直接操作的，而字符流在操作时使用了缓冲区，通过缓冲区再操作文件，如图12-6所示。下面以两个写文件的操作为主进行比较，但是在操作时字节流和字符流的操作完成之后都不关闭输出流。范例：

转载 MapReduce源码分析总结

参考： 1 caibinbupt的源代码分析http://caibinbupt.javaeye.com2 coderplay的avaeye http://coderplay.javaeye.com/blog/295097http://coderplay.javaeye.com/blog/318602 3 Javen-Studio 咖啡小屋http://www.cppblog

转载 Map-Reduce的过程解析

文转载自“觉先”的博客《Hadoop学习总结之四：Map-Reduce的过程解析》一、客户端Map-Reduce的过程首先是由客户端提交一个任务开始的。提交任务主要是通过JobClient.runJob(JobConf)静态函数实现的：public static RunningJob runJob(JobConf job)

转载 HDFS中的SecondaryNameNode节点解析

大家都知道，在HDFS的集群中有三类节点：NameNode、SecondaryNameNode和DataNode，同时在集群中只有一个NameNode节点，一个SecondaryNameNode节点，剩余的就都是DataNode节点(当然，集群中也可以同时存在多个SecondaryNameNode节点，但这没多大必要，反而会增加NameNode节点的压力，使其忙于元数据的传输与接收、日志的传输与切

转载 Job的map任务分配

在前面的博文中，我介绍了Job的调度以及Job的任务分解，但对于Job的调度我只是从宏观的角度作了详细的说明，而关于JobInProgress具体是如何给TaskTracker分配本地Map Task和非本地MapTask的，将是本文将要讲解的重点。      先来看看JobInProgress是如何定义本地Map Task的。在前面的博文：Job的任务分解中，我自己给出了一个关于“预分配

转载 Job的任务分解

在前面的博文JobTracker任务调度器之JobQueueTaskScheduler中，我讲述Job任务调度的时候简单地讲述了一下Job任务的分解，也就是将一个作业Job切分为一个个相对独立的map任务，以及后面的reduce任务。那么，Hadoop的Mapreduce，确切的说是JobTracker是如何来分解作业Job的呢？当然，在JobTracker中并不把这个动作叫做作业分解，而是叫做“

转载 Hadoop中Map任务的执行框架

在前面的一片博文中，我重点讲述了Task被TaskTracker调度执行的原理及过程，但是在详细的介绍执行Task的过程细节之前，我想先来认真的讨论一下Map Task和Reduce Task的执行框架。当然本文主要集中在Map Task上，至于Reduce Task的相关内容，我会在下一篇博文中谈到。在这篇文章中，我将尽量给出一个最抽象的Map模型     在Hadoop的MapRduc

转载 Hadoop公平调度器算法解析

1. 目的本文描述了hadoop中的公平调度的实现算法，公平调度器是由facebook贡献的，适合于多用户共享集群的环境的调度器，其吞吐率高于FIFO，论文参见参考资料[1]。本文分析的Hadoop版本是0.20.2，在新版本（0.21.0）中，公平调度算法已经有了改进与增强。本文组织结构如下：1）目的    2）公平调度介绍  3）公平调度算法分析 4）新版hadoop中公平调度器的新特

转载 Job的提交——JobTracker

在上一篇博文中，我着重谈到了客户端的JobClient对一个作业的提交所做的工作，那么在本文，我就要好好的谈一谈JobTracker为作业的提交到底干了那些个事情——一.为作业生成一个Job；二.接受该作业。      通过上一篇博文，我们都知道，客户端的JobClient把作业的所有相关信息都保存到了JobTracker的系统目录下(当然是HDFS了)，这样做的一个最大的好处就是客户端干

转载 Job的提交—客户端

转载 JobTracker任务调度器之JobQueueTaskScheduler

在客户端把作业提交给JobTracker节点之后，JobTracker节点就可以使用任务调度器TaskScheduler将这个Job的任务分配给那些合适的TaskTracker节点来执行。当然在JobTracker调度该Job之前，必须要确保该Job的JobInProgress被初始化了，即将Job划分为若干个map任务和reduce任务。在JobTracker中有一个基于优先级的FIFO任务调度

转载 由浅入深理解索引的实现(1)

本文转自：http://www.mysqlops.com/2011/11/24/understanding_index.html00 – 背景知识- B-Tree & B+Tree  http://en.wikipedia.org/wiki/B%2B_tree  http://en.wikipedia.org/wiki/B-tree- 折半查找(Bina

转载 作业在map-reduce过程中的文件编码/解码

Hadoop为HDFS和Map-Reduce提供了一整套的数据编码/解码系统，同时还为用户开放了公共的自定义接口，这样用户就可以根据不同的数据类型自定义或者设置不同的数据压缩算法。在Hadoop中对数据进行压缩处理会对系统的整体性能有一定的提高，至于具体提高多少，由于条件所限，笔者在这里并没有进行详细地测试。为什么会这么说呢？很明显，对数据进行压缩，就会减少数据的存储容量，这样的话网络I/O也会随

转载 map任务执行中的Spill/Meger/Combiner

记得在以前的博文中已经比较详细地讲述了map在TaskTracker上的执行过程，但那只是我为了简化这种处理流程而假设map任务在理想情况下执行的，这种理想的假设条件是：TaskTracker是内存足够大，而能完全存储该map的任务的输出。很显然，这种情况在理想情况下是不太有可能的，但话又说回来，如果我们在TaskTracker上为Map Slot配置足够的内存，在某些作业的执行过程中上述的理想情

转载 Job的处理结果输出格式化器——OutputFormat

在前面的博文中，我已经详细的讲述了MapReduce是如何格式化一个作业的输入数据的，也就是用户应该如何来定义作业的输入数据的key-value类型，即如何读取输入数据，并把它们包装成一个个key-value对，最后来交给map函数来处理。那么对应的，本文将主要重点介绍如何格式化保存作业的最后输出结果，很明显，作业的最后输出结果实际上就是reduce函数的输出：key-value。因此，这个问题的

转载 Job的数据输入格式化器—InputFormat

Hadoop被设计用来处理海量数据，这种数据可以是结构化的，半结构化的，甚至是一些无结构化的文本数据(这些数据可能存储在HDFS文件中，也可能存放在DB中)。它处理数据的核心就是map-reduce模型，但是，无论是map还是reduce，它们的输入输出数据都是key-value对的形式，这种key-value对的形式我们可以看做是结构化的数据。同时，对于reduce的输入，当然就是map的输出，

转载 Hadoop中的RPC实现——客户端通信组件

在Hadoop中为了方便集群中各个组件之间的通信，它采用了RPC，当然为了提高组件之间的通信效率以及考虑到组件自身的负载等情况，Hadoop在其内部实现了一个基于IPC模型的RPC。关于这个RPC组件的整体情况我已绍经在前面的博文中介绍过了。而在本文，我将结合源代码详细地介绍它在客户端的实现。    先来看看与RPC客户端相关联的一些类吧！1.Client类

转载 Reduce任务的Map输出复制器—ReduceCopier

在前面介绍Hadoop的Reduce任务执行框架的时候说过，作业的每一个Map任务被执行完之后，它们的输出结果均保存在各自执行节点的本地磁盘上，当reduce任务执行的时候，它需要自己去到所有的Map节点上取回属于自己的map输出，直到属于自己的所有map输出copy到本地，reduce任务才开始接下来的工作。那么，Reduce是如何从Map节点取回自己的输入数据呢？这就是本文即将要详细讲述的内容

转载 Hadoop中Reduce任务的执行框架

在前面的一系列文章中我主要围绕Hadoop对Map任务执行框架的设计与实现展开了详细的讨论，记得在博文Hadoop中Map任务的执行框架中说过还要为大家详细地描述Hadoop对Reduce任务执行框架的设计，那么在本文，我将兑现这个承诺。     其实，Hadoop中Reduce任务执行框架跟它的Map任务执行框架大致是很相似的，唯一的不同之处就是他们的数据输入来源、数据输出目的地不一样而

转载 Map执行时的RecordWriter实现之NewOutputCollector

在前面的一系列文章中我不断的提到了记录写入器RecordWriter，它是一个抽象类，在map任务执行中的根本作用就是向某个文件系统的文件中写入map任务的输出结果——key-value集。所以，本文将主要讨论MapTask对记录写入器RecordWriter的一个具体实现类——NewOutputCollector，来好好的看看这个NewOutputCollector对map任务的输出key-va

转载 Hadoop中的排序器/组合器/合并器

目前，海量数据处理主要存在二个问题：大规模计算(cpu+mem)、海量数据存储(disk)，而Hadoop被专门设计用来针对海量数据的处理，它通过分布式文件系统解决海量数据的存储问题，组织成千上万个计算节点来共同完成一个任务解决了大规模计算问题。Hadoop的核心是MapReduce，而不是分布式文件系统HDFS，这是因为MapRduce所依赖的存储系统并不依赖于任何一个文件系统，甚至是分布式文件

转载 MapFile和BloomMapFile文件

MapFile和BloomMapFile文件分类： H-MapReduce源码解析2012-07-24 11:04 433人阅读 评论(0) 收藏 举报存储目录(?)[+]一. MapFile文件   前面说过，SequenceFile文件是用来存储key-value数据的，但它并不保证这些存储的key-value是有序的，而MapF

转载 Hadoop下join操作的几点优化意见

1. 概述       在传统数据库（如：MYSQL）中，JOIN操作是非常常见且非常耗时的。而在HADOOP中进行JOIN操作，同样常见且耗时，由于Hadoop的独特设计思想，当进行JOIN操作时，有一些特殊的技巧。本文首先介绍了Hadoop上通常的JOIN实现方法，然后给出了几种针对不同输入数据集的优化方法。    2. 常见的join方法介绍      假设要进行jo

转载 SequenceFile文件

SequenceFile文件是Hadoop用来存储二进制形式的key-value对而设计的一种平面文件(Flat File)。目前，也有不少人在该文件的基础之上提出了一些HDFS中小文件存储的解决方案，他们的基本思路就是将小文件进行合并成一个大文件，同时对这些小文件的位置信息构建索引。不过，这类解决方案还涉及到Hadoop的另一种文件格式——MapFile文件。SequenceFile文件并不保证

转载 java Class类

Class类（在java.lang包中，Instances of the class Classrepresent classes and interfaces in a running Javaapplication）：   在Java中，每个class都有一个相应的Class对象。也就是说，当我们编写一个类，编译完成后，在生成的.class文件中，就会产生一个Class对象，用于表示这个类

转载 linux exec

Linux中exec命令相关:exec和source都属于bash内部命令(builtins commands)，在bash下输入man exec或man source可以查看所有的内部命令信息。　　bash shell的命令分为两类：外部命令和内部命令。外部命令是通过系统调用或独立的程序实现的，如sed、awk等等。内部命令是由特殊的文件格式(.def)所实现，如cd、his

转载 log4j 日志文件配置

Log4j说明1 log4j.rootCategory=INFO, stdout , R此句为将等级为INFO的日志信息输出到stdout和R这两个目的地，stdout和R的定义在下面的代码，可以任意起名。等级可分为OFF、 FATAL、ERROR、WARN、INFO、DEBUG、ALL，如果配置OFF则不打出任何信息，如果配置为INFO这样只显示INFO, WARN, ERROR

转载 hadoop基准性能测试

1、1TB（或1分钟）排序的冠军 作为分布式数据处理的框架，集群的数据处理能力究竟有多快？或许1TB排序可以作为衡量的标准之一。 1TB排序，就是对1TB（1024GB，大约100亿行数据）的数据进行排序。2008年，Hadoop赢得1TB排序基准评估第一名，排序1TB数据耗时209秒。后来，1TB排序被1分钟排序所取代，1分钟排序指的是在一分钟内尽可能多的排序。2009年，在一个14

转载 mapreduce官方文档中文版

先决条件请先确认Hadoop被正确安装、配置和正常运行中。更多信息见：Hadoop快速入门对初次使用者。Hadoop集群搭建对大规模分布式集群。概述Hadoop Map/Reduce是一个使用简易的软件框架，基于它写出来的应用程序能够运行在由上千个商用机器组成的大型集群上，并以一种可靠容错的方式并行处理上T级别的数据集。一个Map/Reduce 作业（job） 

转载 分布式数据库概述

一、前言　　随着传统的数据库技术日趋成熟、计算机网络技术的飞速发展和应用范围的扩充，数据库应用已经普遍建立于计算机网络之上。这时集中式数据库系统表现出它的不足：数据按实际需要已在网络上分布存储，再采用集中式处理，势必造成通信开销大；应用程序集中在一台计算机上运行，一旦该计算机发生故障，则整个系统受到影响，可靠性不高；集中式处理引起系统的规模和配置都不够灵活，系统的可扩充性差。在这种形势下，

转载 数据库索引的基础知识

一、理解索引的结构　　索引在数据库中的作用类似于目录在书籍中的作用，用来提高查找信息的速度。使用索引查找数据，无需对整表进行扫描，可以快速找到所需数据。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。　　SQL Server 中数

转载 不可忽略的数据库缓存重建

本文的主要内容来源于MongoDB官方博客，由NoSQLFan补充说明，本文对传统的分布式Cache系统进行了分析，指出了其在缓存重建中会对数据库产生巨大压力的问题。并分析了MongoDB的mmap方案是如何规避这一问题的。　　如下图的架构，在数据库前端加上分布式的Cache（比如我们常用的Memcached），让客户端在访问时先查找Cache，Cache不命中再读数据库并将结

转载 Twitter首席工程师：如何“打败”CAP定理

英文原文：How to beat the CAP theoremCAP 定理是数据系统设计的基本理论，目前几乎所有的数据系统的设计都遵循了这个定理。但 CAP 定理给目前的数据系统带来了许多复杂的、不可控的问题，使得数据系统的设计越来越复杂。Twitter 首席工程师、Storm 的作者 Nathan Marz 在本文中通过避开 CAP 定理带来的诸多复杂问题，展示了一个不同于以往