2018-2-10 --实习工作总结

今天是春节前的最后一个周六,一晃又过了一个年头,本周也经历了关于人事与技术方面的挑战,先说人事吧,自己比较大大咧咧,说话时候爱夸张,正话反说,热闹了德高望重的“前辈”,导致他对我也很不客气,有意见,虽然最后和解了,但还是要吸取教训,告诫自己:你要知道并不是所有人都能接纳你这种大大咧咧说话比较逗的人,对于那些稍微严肃的人,就应当学会收敛点,要知道切换自己的交流模式;再说一下技术方面的吧:本周主要是将我们前期三个人做的特征提取的表进行合并,大致流程是:每个人先将自己的多个子表进行合并成一个大表,然后再将每个人的大表进行最终合并,这里涉及到左表:刚开始用的是3000多万公司的全库数据,后来发现跑不出来,黄又给出了一个建议,运用涉及到每个特征子表的那些公司作为子表,经理说他那有,数据量为800多万,一下子减少了很多数据量,觉得应当能跑出来了,可是还是没有结果,这期间挪空间挪了3次,给到200多G的磁盘空间,但运行到最后一个节点,在写数据的时候均失败了;后来经过将我们每个人的最终的大表以及左表进行检查是否含有重复行,发现均存在,于是进行去重,但是在期间还有一个比较诡异的现象:在合羽叔的那张表的时候,左表无重复,右表一个一个检查,将那个basic涉及到code重复的那个去重之后,均无重复后,再left join发现了最终结果竟然有重复的,其中有_c0(200行),假日酒店XX公司(100多行),得出的可能原因:数据在挪动过程中,由远程挪到本地,再由本地挪到远程,其每一个partition含有字段名,读取header的时候,如果True和False不统一,会导致将_c0这种字段名读到数据中,导致left join后加倍;解决方案是,再进行去重,最终左表也进行了去重,右表也进行了去重,再进行leftjoin,花了几十秒的时间,最终就得到了终表,终表中label为null的情况,有可能公司本来就不存在吊销与正常这种标签,还有就是属于这两类之外的其他类型。

总结一下自己特征提取时候的一个问题:特征提取后出现了一个公司多行记录,是先用SQL语句进行了统计,然后再collect出来,用python一行一行地读取出来进行处理,就出现了这种情况,但是,特征提取最终形式是一个公司为一行,一行里面显示所有特征,因此,解决方案就是:用sql语句进行group by处理,再每一个字段取max,这样就保证了一行;另外还涉及到对一列例如行政处罚:警告、罚款等拆分为特征列:是否警告,是否罚款等这种语句思路:先定一个关于:warn=u"警告",的定义语句,然后再定一个映射语句:is_warning : warn,(映射对应就是字典,用:)其它类型如此,,然后,运用rdd语句进行读取,map(),(lamda:_: get_keys(b),a)再加一个flatmap,即可实现;另外;自己的业务常识积累太少:错误把诸如失信等不同平台的数据定义为不同的事件,其实有可能是不同平台对同一个公司失信的一个报道,因此不能算做累加次数,应该以年份相间隔,然后在定义为累加(默认不同年份的失信事件为不同的事件,可以累加);

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值