由Kaggle竞赛wiki文章流量预测引起的pandas内存优化过程分享

pandas内存优化分享

原因

最近在作Kaggle上的wiki文章流量预测项目，这里因为我的电脑配置问题，我一直都是用的Kaggle的kernel，可是咱们知道kernel的内存限制是16G，以下：

在处理数据过程当中发现会超出，虽然咱们都知道对于大数据的处理有诸如spark等分布式处理框架，可是依然存在下面的问题：

1. 对于我的来讲，没有足够的资源让这些框架发挥其优点；
2. 从处理数据的库丰富程度上，仍是pandas等更具备优点；
3. 不少时候并非pandas没法处理，只是数据未经优化；

因此这里仍是考虑针对数据进行内存方面的优化，以达到减小内存占用，并在kernel上正常运行为最终目的；

整个尝试的过程

只加载当前用到的

这个不用多说，虽然通常为了省事，都是开头一块儿load到内存中，可是特殊状况下，这里仍是要注意的，以下：

能够看到，虽然可用数据文件不少，可是因为当前处理须要的仅仅是train2.csv，因此只加载其便可，不要小看这一步，这里每一个文件加载过来都是几百M的；

类型转换

这里是在预处理部分能作的对内存影响最大的一部分，基本思路以下：

1. object考虑是否须要转换为category；
2. numeric，即各类数值类型，是否在容许范围内下降类型，例如假如某一列为整型且最大值为100，那么就是用用int8类型来描述；
3. 对于日期类型，能够先不着急转为datetime64，咱们直到datetime类型占用内存是比object还多的，能够先考虑转为category，后续处理完释放了没用对象后再转回来便可（这种方式比较少用，可是对于这个项目仍是挺有用的，由于最终内存峰值也就在那几G上）；

以下是未作转换前的DataFrame信息：

以下是我对原始数据各字段的类型转换以及转换后的DataFrame信息：

看到内存占用直接降了一半，不要小看这几百M，在DataFrame进行各类apply、groupby运算时，临时占用的内存是很是多的，也很容易超过峰值致使kernel重启；

PS：固然，这里若是直接加载时指定数据类型也是能够的，我这边为了展现转换先后效果，因此直接指定，实时上更常见的作法时，先直接加载，info或者describe看数据信息，而后判断数据应该的类型，修改代码为直接指定；

使用union_categoricals代替pd.concat实现表的链接

作过期序数据预测的朋友应该直到，时序数据构建时，一个特色是须要链接训练和测试数据，而后同时针对这些数据作时序上的延迟特征、各类维度的统计特征等等，所以这里就涉及到数据链接，必定要注意要用union_categoricals代替pd.concat，若是直接使用concat，那么category类型的列会被转为object，那么在链接的过程当中，内存就会超过峰值，致使kernel重启，那就悲剧了。。。。

以下，是对数据作reshape的操做，这个是该竞赛数据的一个特色，因为其把每一天对应的访问数据都放到了一块儿，也就是一行中包含了一篇文章的每一天的访问量，而这是不利于后续作延迟特征构建的，须要将每一天的信息单独做为一行，所以须要reshape：

以下这种链接、即时销毁的方式虽然看着丑，可是效果仍是能够的：

以下是采起这种方式连接后的DataFrame信息，其实难点不在于DataFrame多大，而是它在运算过程当中的内存峰值会超过限制：

注意

1. 即时del掉不用的对象；
2. 对于category列的链接，使用union_categoricals；
3. 在不一样类型的列链接时，结果类型会取大的那个，好比int8链接int64，那么结果就都是int64；
4. 关于category类型，不只能够下降内存占用，并且还能加快运算速度，关键在于特征的取值可能数量是否远小于行数；

Kaggle竞赛连接

https://www.kaggle.com/c/web-traffic-time-series-forecasting

Kaggle kernel连接，该kernel已经设置为public，你们能够随意copy

https://www.kaggle.com/holoong9291/web-traffic-time-series-forecasting

最后

你们能够到个人Github上看看有没有其余须要的东西，目前主要是本身作的机器学习项目、Python各类脚本工具、数据分析挖掘项目以及Follow的大佬、Fork的项目等：
https://github.com/NemoHoHaloAi