1.硬件不足问题，cpu和内存超过90%，是因为系统的架构做了修改（spark和tomcat共享内存，因此造成服务器硬件不足）
2.spark集群配置的session共享问题，导致 用户多进行并发时，部分用户登录失败。
3、两台服务器负载不均衡问题，并发下，两台服务器使用资源相差特别多，运维人员修改了负载均衡的参数搞定此问题。
4、10小时稳定测试中发现的问题如下:
a：服务器的日志级别太低，导致5天跑满了40GB的空间，导致重启。
b： 链接满了，导致断开了一些而失败，因为链接不用后不会立即释放掉，需要隔一段时间再释放。
c：ubantu系统的打开文件数超过了最大值，导致运行4到5个小时候，保存项目功能总是失败，因为保存项目时，需要将数据写入到spark的数据，写入时便需要open文件，
还有一共可能就是open的文件数太多没有close掉。
5、开发写的udf（user defind function）方法，效率太低，导致分析台拖拽字段后的出图时间太慢，因为字段太多时候，每个字段要经过一次udf算法，
通过计算一个null的string类型 警告过udf算法后就要经过1-2s的时间。
6、spark集群数据库的时间类型的字段落地成了string类型，这样拖拽字段时候增加了一个再把string转换成时间类型的过程的参数。
后来开发修改后已经提升了时间类型的字段的拖拽出图时间50%左右。
7.挖掘流程：代码写的有问题。
内进行一个预测功能，就new一个sparksession，这样spark便于mysql数据库连接一次，导致超过链接次数而失败，
现在已经无session改用context，sparkcontext有个队列会自动分配与删除executor(运行计算spark)，一个driver只会有一个sparkcontext示例。
8、7/0版本时候优化数据库添加索引，提升了很多性能问题。。
9、落地2千万的mysql数据库的数据时候，发现spark的任务队列中多了一个show的任务，耗时2分多钟，按道理讲保存项目过程只需要一个save的任务，