Alex的个人Blog

作为数据分析中经常进行的join 操作，传统DBMS 数据库已经将各种算法优化到了极致，而对于hadoop 使用的mapreduce 所进行的join 操作，去年开始也是有各种不同的算法论文出现，讨论各种算法的适用场景和取舍条件，本文讨论hive 中出现的几种join 优化，然后讨论其他算法实现，希望能给使用hadoop 做数据分析的开发人员提供一点帮助.

Facebook 今年在yahoo 的hadoop summit 大会上做了一个关于最近两个版本的hive 上所做的一些join 的优化，其中主要涉及到hive 的几个关键特性: 值分区 , hash 分区 , map join , index ,

Common Join

最为普通的join策略，不受数据量的大小影响，也可以叫做reduce side join ,最没效率的一种join 方式. 它由一个mapreduce job 完成.

首先将大表和小表分别进行map 操作, 在map shuffle 的阶段每一个map output key 变成了table_name_tag_prefix + join_column_value , 但是在进行partition 的时候它仍然只使用join_column_value 进行hash.

每一个reduce 接受所有的map 传过来的split , 在reducce 的shuffle 阶段，它将map output key 前面的table_name_tag_prefix 给舍弃掉进行比较. 因为reduce 的个数可以由小表的大小进行决定，所以对于每一个节点的reduce 一定可以将小表的split 放入内存变成hashtable. 然后将大表的每一条记录进行一条一条的比较.

阅读全文…

Cloudera 的Hadoop World上看到的这个PPT: Hadoop and Performance,介绍了一些现在0.20 和0.23 版本性能优化的技巧，这里做个笔记

Hadoop 性能误区

• Java 很慢 Hadoop 主要的瓶颈在磁盘IO 或者网络传输上，不是cpu

在cpu 热点上，我们可以使用JNI 或者sun.misc.Unsafe

• Java 没有提供足够的系统底层的支持 JNI 跟C一样可以容许我们调用任何系统调用

我们能够集成汇编代码

• Hadoop IO 有太多层了 Linux IO调度器，ext4,XFS 的开发人员的确比我们更了解系统底层IO

每个系统都会有IO调度和文件层，那些绕开操作系统的（比如DBMS)都是为了实现移植性

阅读全文…

Facebook 在2010年4月发表了一篇在Hadoop 里面实现列储存的论文: RCFile: A Fast and Space efficient Data Placement Structure in MapReduce based Warehouse Systems.

CSDN 上面有这篇文章的一部分翻译, 它当时提出这个设想其实就是想做一个列数据库，而实现列数据库的第一步就是实现列储存，本文主要介绍当时Hive 的RCFile 的实现环境与限制，下一代Hadoop的架构对新的RCFile 产生的影响以及将来可能出现的Hadoop 列数据库计算模型的一些相关问题.

RCFile 在实现的时候主要需要满足facebook 在以下4个方面的需求:

最近一直在使用mapr版本的hadoop, 然后用的karmasphere 的eclipse plugin . 突然想找一个eclipse IDE 连接一下Cloudera 版本的方便一下操作，结果就悲剧了.

首先是各个版本的eclipse plugin 不兼容. 网上找的各种编译好的，自己编译的都是家家有本难念的经啊.什么Apache Hadoop 0.20.2 , Apache Hadoop 0.20.3 ,Apache Hadoop 0.20.5 ，Cloudera CDH CDH3 , CDHu1 , CDHu2 , eclipse 的各个版本不兼容. 花了几天的时间查看了网上的各种解决方法之后终于搞明白了到底每个版本怎么回事了.

首先，无论你的服务器上Hadoop 使用的是什么版本，你都需要下载对应的这个版本的源代码包进行编译. 你是Apache Hadoop 0.20.2 就去Apache 下0.20.2 的，你是Apache 0.21 版本的就去下0.21 版本的. 你是Cloudera CHDu.x 版本的，就去Cloudera 网站上下它的CDHu.x  版本对应的tar 包. 确保你要连接的服务器版本和你打算编译的eclipse-plugin版本是一致的.

在自己编译eclipse-plugin之前，你需要apache-ant, apache-maven, apache-ivy如果你打算编译整个包括hadoop的服务器版本并生成二进制包，你还需要apache-forrest 用来输出文档. ant,maven,forrest 的安装跟java 的安装没有区别，解压，然后添加对应的bin目录到path 变量. ivy 的安装就是添加一个apache-ivy-xxx.jar 到你的ant  安装目录下的lib 目录. 这些前提工具就算安装好了.

然后从命令行进入你解压的$hadoop_home 源代码目录, 执行ant compile-core , 这个会编译基础的hadoop-core 包. 注意如果你是在linux 下这个命令不会报错，但是如果你是windows 会报can’t run  program mvn , 在对应的build.xml 文件的42 行，你需要进入$Hadoop_home/build.xml 文件的42行，修改

         <exec  executable="mvn"  xxxxxxxxxxxxxxxxxxxxx

改成 <exec  executable="mvn.bat"  xxxxxxxxxxxxxxxxxx

如果你打算编译整个包的话对应的1230  行里面的forrest 在windows 下同样会出现这个错误.

阅读全文…

这篇文章介绍一下几个数据库的Hadoop 适配器的资料：

AsterData 和 Greenplum 虽然在2008年8月期间都宣布自己是第一个在数据库层面实现MapReduce 的厂商，但是之后双方走的路线却不尽相同. AsterData 之后走的路线还是将MapReduce层面的东西交给Hadoop 来做，并在一年之后的2009年10月宣布跟Cloudera 合作推出了第一个Hadoop 连接器. 这个连接器主要有如下特点：

• 双向连接：Hadoop 和 AsterData 互相能够保持数据的同步传输.
• SQL-MapReduce : 通过sql 可以直接调用后面的手写的mapreduce 端代码
• MapReduce 执行的时候会占用尽可能多的内存，尤其是保证中间结果尽量不写入到磁盘.

Greenplum 在今年9月的时候完成了它的第一个Hadoop 适配器，也是和Cloudera 合作开发, 不过它是单向的从HDFS 往Greenplum 导数据，仍然是通过所有集群节点并行加载. 它主要利用了机器的优势装载, 本身技术上并没有优化太多, 速度还算可以. 另外一个特点是它的适配器集成了它的Chorus , 作为数据生命周期管理的一个重要特性.

Vertica 在2009年10月与Cloudera  合作开发出了Vertica-Hadoop 集成适配器，它当时只实现了从Vertica 往Hadoop 导入数据的功能，一年之后它增强了从Hadoop 的HDFS 往Vertica 导数据的功能，从而实现了Vertica 与 Hadoop 的双向连接功能，值得一提的是，Vertica 的适配器有两个很变态的功能，一个是能从在vertica 的客户端通过sql 直接指定sql运行在hadoop 集群上, 这个跟AsterData 的SQL-MapReduce 差不多，这个过程是透明的, 他后台的适配器能自动把SQL 翻译成HiveQL 然后执行返回. 另外一个特性是它的Hadoop 连接器是直接读Vertica 的文件格式和元数据，对，数据只存储一份，不像其他的连接器实际上是数据存两份要你自己确保两份数据是同步的. (更准确的说法应该是Vertica 里面的数据是可以配置mirror的，用来提高IO并行能力和数据高可用性，Hadoop 的HDFS 的其中1到2个复制备份是直接依赖与Vertica 文件系统的, 而不像行数据库Greenplum,AsterData 那样数据在DBMS 里面和Hadoop 里面是完全不同的备份)

阅读全文…

    随着Microsoft 也加入Hadoop 阵营，Hadoop 已经完全变成了DBMS 的好朋友了 , 2年之前的SIGMOD组织提出的“A Comparison of Approaches to Large-Scale Data Analysis”引发了关于并行数据库和MapReduce模型的讨论， 双方唇枪舌剑之后发现两个系统根本就是各有所长, DBMS 目前有些处理好的领域和商业支持，Hadoop 也有自己的优势和使用案例.

    就如前一篇TDWI 所说的3个V 问题，新一代Hadoop MapReduce 主要解决的是数据容量和多种类型的数据（结构化，半结构化，非结构化）. 而传统的MPP DBMS 解决的主要还是速度，低延迟，实时性的问题.

阅读全文…