失败的sparkSql使用问题记录

问题1、为什么很大的表，最里层的map只用1094个task呢？导致一直gc,   最后失败。

问题2，用row获取数据的时候，在sql中聚合的结果到底是integer还是long呢，总报数据类型转换错误，全改成Integer不对，全改成long也不对，后来单独把一段列设置一样的sql拿出来，用df.show(2)执行，df.printSchema()打印结构，在log的stdout看到结构。

但是也了解到一点小窍门，比如上面每个stage到底执行什么不知道，把不同的sql数据量变小（limit100），看对应task数目就知道哪个对应哪个了。之后在初步知道rdd的对应关系后，根据每阶段的输入输出大小对应，就知道哪几个阶段属于一个sql了，上图红色属于一个sql,绿色属于一个sql.

结构：

问题3.可能因为union时有同名的列，解析异常，。。。

问题4. 整个job有两次存临时表的操作，检测不到第一次临时表需要上游操作。。。

问题5.发现从dataframe中getDouble会极大的加长操作时间，也可能是加多几个字段，就多个getObject操作就会加很长时间；所以没用的字段最好不要加。

加上的速度：

第一行32000task的stage,29min执行6338；如果不加无用的列和getDouble,速度快很多，3.6分钟12000个task：

不加的速度：

而且在dataframe拼新row的时候，插新的常量代替某些特殊情况也会很慢，比如当某种情况下插一个长整形常量1，task速度大大变慢，因为写val似乎会让executor有oom错误，导致

本来应该14min内32000个task都运行完成。

插的代码如下：

把以上常量从定义val变成直接在用的地方写-1L就速度就恢复了。

问题6.容易犯：之前跑过，即使失败的新建表格程序，没填进去数据可是表格源数据已经有了，修改源数据再用同样名字表格插入就会不匹配，比如类型不匹配，找原先源数据多出来的数据项之类的错误。所以改了源数据后要先加一句sqlContext.sql("DROP TABLE IF EXISTS TABLENAME"),新表建好后再注释掉这一句。

错误log示例：

matcherror,arrayoutofindex