Hive 本地模式

by:leotse

我们都知道,Hive是通过将HiveQL转化为MR job进行数据查询和处理。当然,不是全部的HQL语句都需要转为MR,比如我们常见的:
SELECT * FROM access_log;
这时候,Hive Shell能很快地返回给我们结果,这是因为这里用到的是Hive的本地模式
Hive查询耗时太长,一直都是大家吐槽的对象,在数据量大的情况下,当然微不足道,但是当我们的查询量很小亦即查询数据很少的时候,Hive启动的耗时将会显得非常刺眼,因此在0.7版本以后,Hive开始支持本地模式。

除了上面的示例使用到了本地模式,如果WHERE语句中只是分区字段这种情况,也是无需使用MR job的:
SELECT * FROM access_log
WHERE dt='20150916'
LIMIT 10;
这是因为分区字段在HDFS中保存实际上是目录结构,这些都是不用通过计算获取的(包含LIMIT)。

FastDFS概览

by:leotse

Definition

FastDFS是C语言实现的、开源的、轻量级的应用级分布式文件系统,开发者为淘宝开发平台部资深架构师余庆。它提供了负载均衡、冗余备份机制,是一个可扩展、高可用、高性能的分布式文件系统。

Architecture

FastDFS一共由三部分组成:
TrackerServer:负责负载均衡和调度。是整个FastDFS的中心,它将StorageServer的分组信息以及状态信息保存在内存中;
StorageServer:存储文件和文件meta信息。直接使用操作系统的文件系统管理DFS上的文件;
Client:使用者与请求发起方。通过专有接口,使用TCP/IP协议与跟踪器服务器或存储节点进行数据交互;

HDFS文件系统命名空间

by:leotse

HDFS Namespace

在HDFS中,我们知道NameNode负责管理文件系统的命名空间,那么NameNode到底怎么管理HDFS的命名空间,又有哪些内容需要管理呢?我们接下来将讨论到这两个问题。

作为HDFS的Master,NameNode掌握着整个HDFS的文件目录树及其目录与文件,这些信息会以文件的形式永久地存储在本地磁盘。我们可以在$HADOOP_HOME/tmp/dfs/name/current下找到这些文件:fsimage以及edits。

fsimage:保存了最新的元数据检查点;
edits:保存了HDFS中自最新的元数据检查点后的命名空间变化记录;

为了防止edits中保存的最新变更记录过大,HDFS会定期合并fsimage和edits文件形成新的fsimage文件,然后重新记录edits文件。由于NameNode存在单点问题(Hadoop2.0以前版本),因此为了减少NameNode的压力,HDFS把fsimage和edits的合并的工作放到SecondaryNameNode上,然后将合并后的文件返回给NameNode。但是,这也会造成一个新的问题,当NameNode宕机,那么NameNode中edits的记录就会丢失。也就是说,NameNode中的命名空间信息有可能发生丢失。

你真的懂单链表吗

by:leotse

引子

首先,上一道开胃菜:怎么判断两个单链表是否相交?

我们假设两个单链表分别是A(有m个结点)和B(有n个结点),当然,最容易想到的肯定是两层循环,遍历A中的元素,然后分别与B中的元素进行比较,但是这样做的时间复杂度达到了O(m*n),那么有没有更简单的办法呢?肯定有!

我们来看看单链表的性质:每个结点只通过一个指针指向后继结点。那么是不是意味着两个单链表如若相交,它们就只能是Y形相交,而不可能是X形相交,亦即从第一个相同的结点开始,后面的结点全部一样。如果能想到这个,后面的就简单明了了:只要A链表和B链表的最后一个结点值相等,则证明A链表和B链表相交。该算法的时间复杂度也下降到O(m+n)。

我们进一步来思考:怎么找到第一个相交的元素呢?

Hadoop集群部署(RedHat)

by:leotse

概述

安装环境:Red Hat 4.8.3-9
Hadoop版本:Apache Hadoop 2.6.0
Java版本:1.8.0
Master:172.16.10.136
Slave1:172.16.10.137
用户:xiefeng
安装目录:/home/xiefeng/dependencies

主要部署步骤:
1.SSH免密码登录设置;
2.环境变量设置(Java以及Hadoop);
3.Master部署;
4.Slave部署;
5.启动集群;

接下来我们对每一步进行详细介绍。

MooseFS概览

by:leotse

Intro

MooseFS,是一种容错的网络分布式文件系统。它提供了FUSE接口的客户端,挂载后和读写本地磁盘上的文件无异,是替代NFS的理想选择。
用户访问MooseFs系统中不同机器上的数据没有差异,对用户来说,只有一个源。

Architecture

MooseFS主要由四部分组成:

Master Server(元数据服务器)

管理整个MooseFS系统的单点,保存了MooseFS中每个文件的元数据,包括文件的大小、属性、文件位置等等;我们的元数据信息同时保存在Master的内存和磁盘里。

Metalogger Server(元数据日志服务器)

存储元数据服务器的变更日志,用以恢复Master Server,它也会周期性下载MasterServer的元数据文件,服务器数量不定。我们也可以在Master Server宕掉后使用Metalogger Server作为我们的MasterServer;