微博传播数量和传播深度的预测--基于pyspark和某个回归算法

8-28决定参加一下这个千万条的数据处理任务,因为场景和自己做过的一个回归分析预测差不多,第一天开始在小规模的数据上做准备工作。

 

第二次大修改版本

date 20160829 星期一

原始数据处理,得到用户粉丝关系,微博转发在每个时间段的量,微博转发的总体深度 下一阶段目标,建立模型,实现基于时间序列的预测

 

第三次大修改版本

date 20160830 星期二

将这些运算转移到Linux平台上,因为有的迭代完全让我的电脑的内存受不了 这次版本的主要的目的是计算出某个微博的深度的时间序列的变化

 

第四次大修改版本

date 20160831 星期三

从原始数据提取出随着时间变化的序列的深度和转发的次数的测试工作完成了 本次修改两个任务:第一将函数按照两个部分分别整合起来; 第二将采样数据替换成原始测试数据跑一遍,完成基本的数据处理 下一次版本的主要目的是,通过这些已知的关系,搭建数据预测的模型,用训练数据训练,用测试数据测试,然后修正参数,得到最好的模型

 

第五次大修改版本

date 20160901 星期四

今天上午遇到的严重的问题是内存不够,因为我把计算过程中,尤其是初始数据的RDD也缓存起来了,这很大,所以不够用了。 更改只缓存重要的结果,例如,时间序列的,转发次数和转发深度这一些RDD,这样程序差不多能完全执行下来。 只是第二个计算深度的版本还是有些问题,需要在以后用到的时候进一步修改,尤其是针对特定的时间段,谁在转发,转发的人最大的粉丝个数。

这个版本主要解决的问题是将计算的结果保存到文件中,方便回归模型调用文件中处理好的数据进行训练和预测。 首先计划实现某一个时间段的预测,其他的整体的预测还是以后再做。

 

第六次大修改版本

date 20160901 星期四

今天下午最大的收货是看到了曙光

但是成功距离我以前想的还是有一段距离的 本次版本将完整计算出所有需要的数据,保存到文件中,希望今天能完成

 

第七次大修改版本

date 20160902 星期五

今天多计算了几个需要的参数,并且优化了深度和广度的生成方式。 但是有一个参数生成失败,而且深度获取有严重的bug是算法的问题。这个还没想到好的方法改。 今天还是没能下手做第一个预测。

 

第八次大修改版本

date 20160905星期一

今天做了一个小突破,覆盖人数算出来了 今天剩下的目标是,重新抹平生成的数据 然后用这个程序跑测试集

 

第九次大修改版本

date 20160906 星期二

把程序简化了很多,函数关系互相的顺序调用,这样关系清楚了,也减少不必要的计算量。 对训练集和测试机分别生成四类文件,微博id对应的粉丝数,微博id对应的转发量,微博id对应的深度,微博id对应的覆盖人数

 

第十次大修改版本

date 20160907 星期三

昨天有一些需要的数据没完全生成,因为vsphere中的ubuntu磁盘不够了,还没搞明白怎么扩展。任务丢失就失败。 但是部分的数据生成了。够用。

今天首先根据时段15预测时间段16的时候的数据,遇到一个致命的问题,特征向量和label加一起用labeledpoint时候得到超出数组错误。 因为模型需要的是sprasevector而我传入的是densevector,而这个转换现在spark好像不支持。 从mllib转向新的ml中的模型,还是这个错误。label是非负数,但是却出现了负值索引的数组。这一个预测做不出来,就没法批量下手呀。。

 

第十一次大修改版本

date 20160908 星期四

给虚拟机扩了30G但是交换区好像要手动启动了,否则会很慢。。 仔细研究了一下模型对数据的请求,打算吧特征向量转化为libsvm格式,方便模型自己加label。

 

第十二次大修改版本

date 20160909 星期五

第一次做出来时间段15的转发次数,下面想办法做延伸,怎么搞292个时间段的预测。

 

第十三次大修改版本

date 201609012 星期一

委屈求全的求出了所有时段的预测结果。现在特征向量有点匮乏。解决了两个主要的问题:

第一:k-v分裂之后,想在zip的时候发现zip有两个要求不仅长度相等,分区也相同才可以。所以迂回一下,首先分别zipWithIndex然后翻转k-v然后pire RDD取join再将values()map出k-v就可以了。

第二个:拼接字符串,看似很简单,加上循环就比较操蛋了。学会了一个join函数,python的join函数可以对数组批量连接。

 

第十四次大修改版本

date 20160913 星期二

不管其他问题首先计算出第一版的结果:

用生成的预测结果文件取出来加上key然后join太费劲,288个迭代起来,没完没了。 以

前就是因为这个弊端,选择了生成单独的文件。

所以捣鼓一上午之后选择shell脚本生成需要的结果。 将表头和数据分别黏贴起来。修改了几个小小的bug。 最终提交了一个版本的结果。

现在的问题:

原始数据有改动,但是这个影响不大。

预测结果排序有问题,这个可以解决,当时没解决。

还有一个比较困难的问题是深度生成的算法还是有硬伤,后面时段的深度可能比前面的时段的深度浅。

 

 

待续

posted @ 2016-09-02 07:17  kongchung  阅读(1375)  评论(1编辑  收藏  举报