spark sql简单查询千亿级库表导致的问题

一、问题现象

今天有客户咨询到我们，他们利用spark sql查询简单的sql：

select * from datetable limit 5; //假设表名是datetable

结果报错内存溢出：

客户反馈spark sql简单查询内存溢出

报错详情

根据常理判断，简单的 select * limit 不会造成内存溢出的。因此，我们用hive原生sql查询，发现不存在这个问题。

二、排查问题

经过分析，发现被查询的表数据量特别大，整个表有1000多亿行数据。一般这种海量数据大型数据表，往往是做了多重分区的。

经过查看，发现被查询的数据表是双重分区表（也就是有两个分区字段）。dt是第一个分区字段，表示天； hour是第二个分区字段，表示小时。数据表存储在HDFS的目录结构也是：

/${hive-warehouse}/dbname/tablename/dt=xxx/hour=xxx/files

根据之前使用spark sql的经验、以及逛社区查找的信息，最终找到原因如下：

因为 datetable 这个表是一个双重分区表，即使进行 select * limit 也至少会进行第一重分区的完整数据扫描。因此，对于双重分区表，需要加上双重分区条件（或者至少加上第一重分区条件），然后再进行 select * limit 查询。比如：

select * from datetable where dt='2018-11-14' and hour='07' limit 5;

或者至少把第一重分区条件加上：

select * from datetable where dt='2018-11-14' limit 5;

不能直接用 ：

select * from datetable limit 5;

这种语句spark sql至少会扫描一个完整的第一重分区的数据，当数据量很大的时候，因此往往会出现内存不足。因为datetable有1000亿行数据，单个的第一重分区的数据量往往也是超过TB级别的。因此，如果全量扫描TB级别数据到有限数量的excutor内存里面去，肯定会出现内存不足。

三、验证结论

1、首先我们直接用spark sql查询：

select * from datetable limit 5;

从日志可以查看出excutor在疯狂地扫描HDFS的文件：

而且这些被扫描的HDFS文件，确实属于表的某个第一重分区的目录。日志证明刚才的推断是正确的。

2、加上第一重分区条件：

select * from datetable where dt='2018-11-14' limit 5;

很快就返回结果。

3、加上第一重和第二重分区条件：

select * from datetable where dt='2018-11-14' and hour='07' limit 5;

毫秒级就出结果。

因此，经过验证，上述分析完全正确。