使用 Apache Hadoop、Impala 和 MySQL 进行数据分析

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

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

用途

服务器规格

NameNode、DataNode、Hive 元数据存储等

2x PowerEdge 2950, 2x L5335 CPU @ 2.00GHz, 8 cores, 16GB RAM, 使用 8 个 SAS 驱动器的 RAID 10

仅做数据节点

4x PowerEdge SC1425, 2x Xeon CPU @ 3.00GHz, 2 cores, 8GB RAM, 单个 4TB 驱动器

数据导出

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

select * into outfile ‘/tmp/ontime.psv’
FIELDS TERMINATED BY ‘,’
from ontime;

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

for y in {1988…2013}
do
for i in {1…12}
do
u=“ http://www.transtats.bts.gov/Download/On_Time_On_Time_Performance_${y}_${i}.zip ”
wget $u -o ontime.log
unzip On_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 -copyFromLocal On_Time_On_Time_Performance_*.csv /data/ontime/

在Impala中创建外部表

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

CREATE EXTERNAL TABLE ontime_csv (
YearD int ,
Quarter tinyint ,
MonthD tinyint ,
DayofMonth tinyint ,
DayOfWeek tinyint ,
FlightDate string ,
UniqueCarrier string ,
AirlineID int ,
Carrier string ,
TailNum string ,
FlightNum string ,
OriginAirportID int ,
OriginAirportSeqID int ,
OriginCityMarketID int ,
Origin string ,
OriginCityName string ,
OriginState string ,
OriginStateFips string ,
OriginStateName string ,
OriginWac int ,
DestAirportID int ,
DestAirportSeqID int ,
DestCityMarketID int ,
Dest string ,
…
ROW FORMAT DELIMITED FIELDS TERMINATED BY ‘,’
STORED AS TEXTFILE
LOCATION ‘/data/ontime’;

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

> select yeard, count(*) from ontime_psv group by yeard;

该 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(*) as cnt,
sum(if(ArrDelayMinutes>30, 1, 0)) as flights_delayed,
round(sum(if(ArrDelayMinutes>30, 1, 0))/count(*),2) as rate
FROM ontime_parquet_snappy
WHERE
DayOfWeek not in (6,7) and OriginState not in (‘AK’, ‘HI’, ‘PR’, ‘VI’)
and DestState not in (‘AK’, ‘HI’, ‘PR’, ‘VI’)
and flightdate < ‘2010-01-01’
GROUP by carrier
HAVING cnt > 100000 and max(yeard) > 1990
ORDER by rate 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 ）关注我们，并与我们的编辑和其他读者朋友交流。