使用ApacheHadoop、Impala和MySQL进行数据分析_MySQL

Apache Hadoop是目前被大家广泛使用的数据分析平台，它可靠、高效、可伸缩。Percona公司的Alexander Rubin最近发表了一篇博客文章介绍了他是如何将一个表从MySQL导出到Hadoop然后将数据加载到Cloudera Impala并在这上面运行报告的。

在Alexander Rubin的这个测试示例中他使用的集群包含6个数据节点。下面是具体的规格：

数据导出

有很多方法可以将数据从MySQL导出到Hadoop。在Rubin的这个示例中，他简单地将ontime表导出到了一个文本文件中：

select*intooutfile '/tmp/ontime.psv'
FIELDS TERMINATED BY ','
fromontime;

你可以使用“|”或者任何其他的符号作为分隔符。当然，还可以使用下面这段简单的脚本直接从www.transtats.bts.gov上下载数据。

foryin{1988..2013}
do
foriin{1..12}
do
u="http://www.transtats.bts.gov/Download/On_Time_On_Time_Performance_${y}_${i}.zip"
wget $u -o ontime.log
unzipOn_Time_On_Time_Performance_${y}_${i}.zip
done
done

载入Hadoop HDFS

Rubin首先将数据载入到了HDFS中作为一组文件。Hive或者Impala将会使用导入数据的那个目录，连接该目录下的所有文件。在Rubin的示例中，他在HDFS上创建了/data/ontime/目录，然后将本地所有匹配On_Time_On_Time_Performance_*.csv模式的文件复制到了该目录下。

$ hdfs dfs -mkdir /data/ontime/
$ hdfs -v dfs -copyFromLocalOn_Time_On_Time_Performance_*.csv /data/ontime/

在Impala中创建外部表

当所有数据文件都被载入之后接下来需要创建一个外部表：

CREATE EXTERNAL TABLE ontime_csv (
YearDint,
Quartertinyint ,
MonthDtinyint ,
DayofMonthtinyint ,
DayOfWeektinyint ,
FlightDatestring,
UniqueCarrierstring,
AirlineIDint,
Carrierstring,
TailNumstring,
FlightNumstring,
OriginAirportIDint,
OriginAirportSeqIDint,
OriginCityMarketIDint,
Originstring,
OriginCityNamestring,
OriginStatestring,
OriginStateFipsstring,
OriginStateNamestring,
OriginWacint,
DestAirportIDint,
DestAirportSeqIDint,
DestCityMarketIDint,
Deststring,
...
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
STORED AS TEXTFILE
LOCATION '/data/ontime';

注意“EXTERNAL”关键词和LOCATION，后者指向HDFS中的一个目录而不是文件。Impala仅会创建元信息，不会修改表。创建之后就能立即查询该表，在Rubin的这个示例中执行的SQL是：

>selectyeard, count(*)fromontime_psv groupbyyeard;

该SQL耗时131.38秒。注意GROUP BY并不会对行进行排序，这一点不同于MySQL，如果要排序需要添加 ORDER BY yeard语句。另外通过执行计划我们能够发现Impala需要扫描大小约为45.68GB的文件。

Impala使用面向列的格式和压缩

Impala最大的好处就是它支持面向列的格式和压缩。Rubin尝试了新的使用Snappy压缩算法的Parquet格式。因为这个例子使用的表非常大，所以最好使用基于列的格式。为了使用Parquet格式，首先需要载入数据，这在Impala中已经有表、HDFS中已经有文件的情况下是非常容易实现的。本示例大约使用了729秒的时间导入了约1亿5千万条记录，导入之后使用新表再次执行同一个查询所耗费的时间只有4.17秒，扫描的数据量也小了很多，压缩之后的数据只有3.95GB。

Impala复杂查询示例

select
min(yeard), max(yeard),Carrier, count(*)ascnt,
sum(if(ArrDelayMinutes>30, 1, 0))asflights_delayed,
round(sum(if(ArrDelayMinutes>30, 1, 0))/count(*),2)asrate
FROM ontime_parquet_snappy
WHERE
DayOfWeeknotin(6,7)andOriginStatenotin('AK', 'HI', 'PR', 'VI')
andDestStatenotin('AK', 'HI', 'PR', 'VI')
andflightdate <'2010-01-01'
GROUPbycarrier
HAVING cnt > 100000andmax(yeard) > 1990
ORDERbyrate DESC
LIMIT 1000;

注意：以上查询不支持sum(ArrDelayMinutes>30)语法，需要使用sum(if(ArrDelayMinutes>30, 1, 0) 代替。另外查询故意被设计为不使用索引：大部分条件仅会过滤掉不到30%的数据。

该查询耗时15.28秒比最初的MySQL结果（非并行执行时15分56.40秒，并行执行时5分47秒）要快很多。当然，它们之间并不是一个“对等的比较”：

• MySQL将扫描45GB的数据而使用Parquet的Impala仅会扫描3.5GB的数据
• MySQL运行在一台服务器上，而Hadoop和Impala则并行运行在6台服务器上

尽管如此，Hadoop和Impala在性能方面的表现依然令人印象深刻，同时还能够支持扩展，因此在大数据分析场景中它能为我们提供很多帮助。

感谢崔康对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。