【持续更新】工单常见问题看这里！可能会有你想知道的！

• 如何获得比赛数据

原始数据是在赛题数据来源项目里的（具体查看方式见http://bbs.aliyun.com/read/250256.html?spm=5176.bbsl254.0.0.bVYjqO），可以用sql拷贝到自己的project里，比如：
（新浪微博大赛）
create table weibo_blog_data_train as select * from tianchi_weibo.weibo_blog_data_train;
（资金流入流出大赛）
create table  user_balance_table as select * from tianchi_finance.user_balance_table;

• MR/UDF

开发文档总入口（页面底部含常见问题和报错解答）：http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.liavtv&file=MrUdfLocalDev
1.warehouse配置：http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.liavtv&file=MrUdfLocalDev#1-4-1
2.配置文件：http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.liavtv&file=MrUdfLocalDev#1-4-3
3.ODPS文档：http://docs.aliyun.com/?spm=5176.775975630.2.4.QdbspO#/pub/odps
4.FAQ:http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.liavtv&file=MrUdfLocalDev#1-6
5.常见报错：http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.liavtv&file=MrUdfLocalDev#1-7
   关于token：http://bbs.aliyun.com/read/259978.html
   关于新建mavenproject的问题：http://bbs.aliyun.com/read/244295.html?spm=5176.bbsl254.0.0.qPugTV
   maven项目本地运行找不到主类：http://bbs.aliyun.com/read/259818.html?spm=5176.bbsl254.0.0.EFkSPK
6. MapReduce: http://docs.aliyun.com/?spm=5176.775975630.2.4.QdbspO#/pub/odps/MapReduce/summary&mr
7.如何设置worker的个数：http://bbs.aliyun.com/read/264310.html?spm=5176.bbsl254.0.0.OuB7Dp



    

• ODPS相关

1、关于报错“No task resources left in the project.”
1）一个队伍内同时运行的task不能超过3个；
2）task 申请的inst资源不能超过800；
3）不能超出分配的CPU和内存资源
4）查看：可以通过show p来查看正在运行的task，每个人只能看到自己的，队友的需要队友来查看
5）杀任务：如果发现某些instance是要关闭的，可以通过kill  ** 来杀掉，其中**为instanceid。



2、关于报错资源不足   Project resource cost exceeds restriction setting
1）关于资源限制： 每支队伍可使用的资源有上限，请合理使用。 在项目首页可以查看到资源使用及剩余情况。
2）task 申请的inst资源不能超过800；

3）查看：可以通过show p来查看正在运行的task，每个人只能看到自己的，队友的需要队友来查看
4）杀任务：如果发现某些instance是要关闭的，可以通过kill  ** 来杀掉，其中**为instanceid。


3、ODPS最大能有多少列：2000列。目前PAI某些算法支持输入列的字段最大总长度20480位，可以先暂时减少字段名长度。


4、WorkerRestart errCode:xxx
这个报错是因为超时导致的。分布式的odps如果子节点计算超过10分钟没和主节点发心跳的话，会被认为已经死了然后被杀掉，导致任务失败。
SQL:一般sql里出现这个问题是因为sql里存在笛卡尔积的情况（或者因为长尾数据导致的类似笛卡尔积的情况），请优化代码/对长尾数据做特殊处理
MR:一般MR里在Reduce阶段出现这个问题的可能性比较大。可以优化您的代码，使reduce里的工作减少，另外还有一个办法就是手工发心跳，就是context.progress();不过不建议发得太频繁，否则会导致性能问题。
PAI：目前简单这个问题是在GBDT算法里。目前由于算法的特殊性，GBDT是一个实例跑一棵树，如果一棵树里的数据太多会导致这个问题，需要调整算法参数。

• ODPS里分区和分区列的区别

ODPS里的分区表需要设置至少1个分区列，分区列和普通列对应。是表的结构上的概念。
分区是分区列的值等于特定的某个值的一个情况。
举个例子：日志表，根据日期按天分区，那么分区字段ds是分区列，ds=20150101是一个分区，ds=20150102是另外一个分区。

• 算法相关

请根据对应的算法查看对应的文档：http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.AjlmKa&file=SuanFaPingTai#1        
FAQ:http://www.yushanfang.com/portal/help/doc.html?spm=0.0.0.0.AjlmKa&file=SuanFaPingTai#1-2


有时候预测任务跑很慢，日志里一直在刷
predict: 2015-11-09 01:02:03 Predict_job:xxx/0/xxx[0%]
类 似格式的日志，可以这样排查：
先检查任务能否跑起来。先弄一两条数据跑一下预测，看有没有报错，任务能不能跑好。 如果一条数据都跑不起来，可以判断是集群的负载过高。有报错针对报错处理。
如果一条数据能跑起来，那可能是预测工作量太大导致任务一直在跑但是没跑好。比较常见的是一个多树算法，比如随机森林。可以检查：
1. 在满足需求的前提尽量减少任务的输入的数据条数（毕竟测过数据就一两条的时候能跑的）      
2. 减少模型的复杂度：          
2.1 比如减少训练的时候的树的深度
2.2 也见到一些用户使用double类型当成离散的feature来对待。这样会把出现的每个值作为一个分支，最后模型会非常大。预测的时候也要走到每个分支，导致预测非常慢。曾经见过十几万个节点的一棵树，那预测起来就超慢了。      
3.减少模型里DappendColNames里所涉及的列的个数。如果设置了DappendColNames，这些列的数据是要从源表copy到预测结果表的，如果源表很大比如有上亿行，那么这个开销是非常大的。appendColNames不是feature，是说在结果表中附加哪些列，便于方便对比。