Hive导入10G数据的测试

作者：张丹

本文由 粉丝日志博客张丹 授权发布，版权所有归作者，转载请联系作者！

让Hadoop跑在云端系列文章，介绍了如何整合虚拟化和Hadoop，让Hadoop集群跑在VPS虚拟主机上，通过云向用户提供存储和计算的服务。

现在硬件越来越便宜，一台非品牌服务器，2颗24核CPU，配48G内存，2T的硬盘，已经降到2万块人民币以下了。这种配置如果简单地放几个web应用，显然是奢侈的浪费。就算是用来实现单节点的hadoop，对计算资源浪费也是非常高的。对于这么高性能的计算机，如何有效利用计算资源，就成为成本控制的一项重要议题了。

通过虚拟化技术，我们可以将一台服务器，拆分成12台VPS，每台2核CPU，4G内存，40G硬盘，并且支持资源重新分配。多么伟大的技术啊!现在我们有了12个节点的hadoop集群， 让Hadoop跑在云端，让世界加速。

前言

Hadoop和Hive的环境已经搭建起来了，开始导入数据进行测试。我的数据1G大概对应500W行，MySQL的查询500W行大概3.29秒，用hive同样的查询大概30秒。如果我们把数据增加到10G，100G，让我们来看看Hive的表现吧。

1. 导出MySQL数据

下面是我的表，每天会产生一新表，用日期的方式命名。今天是2013年7月19日，对应的表是cb_hft，记录数646W条记录。

快速复制表：

由于这个表是离线系统的，没有线上应用，我重命名表cb_hft为cb_hft_20130719，再复制表结构。

导出表到csv

查看数据文件

2. 导入到Hive

登陆c1.wtmart.com机器，下载数据文件

在hive上建表

当数据被加载至表中时，不会对数据进行任何转换。Load操作只是将数据复制至Hive表对应的位置，这个表只有一个文件，文件没有切分成多份。

3. 优化导入过程Hive Bucket

第二步导入，我们要把刚才的一个大文件切分成多少小文件，大概按照64M一个block的要求。我们设置做16个Bucket。

新建数据表t_hft_day，并定义CLUSTERED BY,SORTED BY,16 BUCKETS

从t_hft_tmp临时数据表导入到t_hft_day数据表

导入操作累计CPU时间是8分05秒，8*60+5=485秒。由于有4个Map并行，16个Reduce并行，所以实际消耗时间是172秒。

我们再看一下新表的文件是否被分片：

一共16个分片。

4. 执行查询

当前1G的文件，使用Hive执行一个简单的查询：34.974秒

MySQL执行同样的查询，在开始时我已经测试过3.29秒。

相差了10倍的时间，不过只有1G的数据量，是发挥不出hadoop的优势的。

接下来，按照上面的方法，我们把十几天的数据都导入到hive里面，然后再进行比较。

查看已导入hive的数据集

在MySQL中，对5张表进行查询。(5G数据量)

在Hive中，对同样的5张表进行查询。(5G数据量)

我们看到hadoop对以G为单位量级的数据增长是不敏感的，多了3倍的数据(15G)，执行查询的时间是原来(5G)的两倍。而MySQL数据增长到5G，查询时间几乎是不可忍受的。

1G以下的数据是单机可以处理的，MySQL会非常好的完成查询任务。Hadoop只有在数据量大的情况下才能发挥出优势，当数据量到达10G时，MySQL的单表查询就显得就会性能不足。如果数据量到达了100G，MySQL就已经解决不了了，要通过各种优化的程序才能完成查询。

测试过程已经描述的很清楚了，我们接下来的工作就是把过程自动化。

End.