～技术宅真可怕～#1 - 2018-2-11 18:17
windrises (一个纠结的面瘫伪宅)
本工具是利用现有爬取的条目历史打分数据，模拟条目各个时期的评分和排名数据等。
访问地址 油猴脚本 代码和原始数据
照例先上截图
脚本安装后的使用效果
主要功能：
1、可以查看条目的分数，名次，标记数走势
2、可以指定多个条目查询，并进行比对
3、可以指定日期和名次来查找条目
4、可以查看指定日期的排行榜
5、提供api
Bangumi采取的应该是imdb的排名计算方式，这个已经在别的帖子里得到证实了。
imdb公式是weighted rank = (v ÷ (v + m)) × R + (m ÷ (v + m)) × C 其中v是投票数，m是最小投票数（动画区是51，别的区是21），R是该条目的算术平均分，C是此时所有动画/书籍...的平均分（动画区现在大概是7.2）
我在模拟时也严格按照这个公式来计算，计算结果我也与Wayback Machine简单对比过，吻合的还不错。可能会出现轻微偏差的原因一个是bgm在计算排名时可能还有别的考量，一个是可能有少量用户后来改变打分了。
这是我做的第三个Bangumi小工具了，这三个工具其实互有联系，很多数据都可以复用。你可以在网站顶部栏找到前两个，这次我也顺便对它们做了一些改进。数据库也重构了，并且从sqlite迁移到了mysql。如果说做前两个工具是为了学习，那这次就纯粹是因为兴趣和好奇了。
做这个时光机最大的困难是在数据上。用户页和条目评分页加起来需要爬取210万个页面，我用我的小本子爬了一天半，最后得到1个G的json数据。（当然是爬的镜像网站，在此灰常感谢@MagicFish1990一边吃草一边。如果爬主站，速度肯定得调小，可能得爬一个多星期
)此外，对于这么大的数据量，怎样处理也是个难题，特别是我寒假回家后身边只有一个小笔记本。为了能在有限条件下尽快算出结果同时减小对我的笔记本硬盘的伤害，我在优化计算方式中下了不少功夫，以尽量减少执行sql语句的次数。
这次花的时间比较长，中间也经历过多次重爬数据，数据库清空等绝望的时刻。也闪出过不少点子，但最终展示出来的就是这些，还有不少想法因为各种各样的原因流产了（但也可能等之后有时间了再加上），比如：
条目全年代统计图，包括分数分布，平均分走势等等；
用户全年代统计图，包括注册数量增长，用户活跃时长分布，阅历天梯榜等等；
个人的统计数据和分析，包括经常活跃的时间点，在动画里一共花了多长时间的人生，兴趣爱好点，动画推荐，好友推荐等等；
条目分数预测，我感觉bgm可以拿来训练的有用数据不够多，所以也考虑过直接来个简单的时间序列分析（这个功能很有趣，但是想要做好我觉得比较难，欢迎指教）；
自定义排名规则，比如不同阅历的用户打分权重不同等等，可惜这个计算量太大，最多我提前预设好几个选项；
恶意刷分检测，这个做起来是很容易的，我做好一半后还是觉得这个有点鸡肋而且很引战，于是放弃了；
等等...
如果以后有时间的话，我可能会再做个用户个性化方面的工具。（可能，请不要过度期待
）
如果有人还有别的有意思的点子欢迎提出来。或者你在实现你的想法的时候懒的爬数据，但是刚好可以用到我爬好的数据或者api的时候，上面的链接或许能帮到你。我之后也可能会不定期更新数据。
展示的数据可能会由于上面提到的原因与实际数据有轻微偏差，仅起参考作用。
虽然我也做过很多检查和测试，但是毕竟时间匆忙水平有限，如果你遇到了bug或者发现数据出了问题，或者有什么建议和意见，请告诉我，非常感谢。
访问地址 油猴脚本 代码和原始数据
照例先上截图
脚本安装后的使用效果
主要功能：
1、可以查看条目的分数，名次，标记数走势
2、可以指定多个条目查询，并进行比对
3、可以指定日期和名次来查找条目
4、可以查看指定日期的排行榜
5、提供api
Bangumi采取的应该是imdb的排名计算方式，这个已经在别的帖子里得到证实了。
imdb公式是weighted rank = (v ÷ (v + m)) × R + (m ÷ (v + m)) × C 其中v是投票数，m是最小投票数（动画区是51，别的区是21），R是该条目的算术平均分，C是此时所有动画/书籍...的平均分（动画区现在大概是7.2）
我在模拟时也严格按照这个公式来计算，计算结果我也与Wayback Machine简单对比过，吻合的还不错。可能会出现轻微偏差的原因一个是bgm在计算排名时可能还有别的考量，一个是可能有少量用户后来改变打分了。
这是我做的第三个Bangumi小工具了，这三个工具其实互有联系，很多数据都可以复用。你可以在网站顶部栏找到前两个，这次我也顺便对它们做了一些改进。数据库也重构了，并且从sqlite迁移到了mysql。如果说做前两个工具是为了学习，那这次就纯粹是因为兴趣和好奇了。
做这个时光机最大的困难是在数据上。用户页和条目评分页加起来需要爬取210万个页面，我用我的小本子爬了一天半，最后得到1个G的json数据。（当然是爬的镜像网站，在此灰常感谢@MagicFish1990一边吃草一边。如果爬主站，速度肯定得调小，可能得爬一个多星期
)此外，对于这么大的数据量，怎样处理也是个难题，特别是我寒假回家后身边只有一个小笔记本。为了能在有限条件下尽快算出结果同时减小对我的笔记本硬盘的伤害，我在优化计算方式中下了不少功夫，以尽量减少执行sql语句的次数。这次花的时间比较长，中间也经历过多次重爬数据，数据库清空等绝望的时刻。也闪出过不少点子，但最终展示出来的就是这些，还有不少想法因为各种各样的原因流产了（但也可能等之后有时间了再加上），比如：
条目全年代统计图，包括分数分布，平均分走势等等；
用户全年代统计图，包括注册数量增长，用户活跃时长分布，阅历天梯榜等等；
个人的统计数据和分析，包括经常活跃的时间点，在动画里一共花了多长时间的人生，兴趣爱好点，动画推荐，好友推荐等等；
条目分数预测，我感觉bgm可以拿来训练的有用数据不够多，所以也考虑过直接来个简单的时间序列分析（这个功能很有趣，但是想要做好我觉得比较难，欢迎指教）；
自定义排名规则，比如不同阅历的用户打分权重不同等等，可惜这个计算量太大，最多我提前预设好几个选项；
恶意刷分检测，这个做起来是很容易的，我做好一半后还是觉得这个有点鸡肋而且很引战，于是放弃了；
等等...
如果以后有时间的话，我可能会再做个用户个性化方面的工具。（可能，请不要过度期待
）如果有人还有别的有意思的点子欢迎提出来。或者你在实现你的想法的时候懒的爬数据，但是刚好可以用到我爬好的数据或者api的时候，上面的链接或许能帮到你。我之后也可能会不定期更新数据。
展示的数据可能会由于上面提到的原因与实际数据有轻微偏差，仅起参考作用。
虽然我也做过很多检查和测试，但是毕竟时间匆忙水平有限，如果你遇到了bug或者发现数据出了问题，或者有什么建议和意见，请告诉我，非常感谢。
api很好写，我写好了再回复你
另外历史排行榜我点月份的时候好像有点错误，你看一下？
直接爬主站的话，我线程都不能开多了，而且还经常爬着爬着就无限连接超时了，怀疑是被ban了
这个可能与补番观众受到舆论影响有关？猜想是：有一小部分的动画会在完结后被精确的推荐到喜爱这类动画的观众那里，因此这些补番观众会给出比追番观众更高的评分；这种推荐的方式很可能是“看到续集特意找前作”，也可能是“爱好者之间的神作口碑”等等
发现几个小幅涨的，要么是当初黑的太厉害，比如夏洛特，要么是完全不过时，后续口碑，比如冰菓
如果是用的油猴脚本，更新一下就好了
有https://github.com/windrises/bgmtools/tree/master/api可以返回json数据，其实与表格差不太多。
你可以点图左上角（单个条目）或正下方（多个条目对比）的图例名字来展示或隐藏某个数据，也可以在右侧的 时间段 输入框输入你想要查看的数据所在的时间段。
标记确实可以拆解，我在数据库中也记录了每个标记的类型，但是最后展示的时候只展示了标记总数，因为我觉得分类展示不是非常必要，大多数的标记其实都来自于“已看”
一开始没注意有展示隐藏的功能orz
我提到分类其实主要是因为好奇动画在不同时期的想看/在看/抛弃/看过的人数会怎么变化，但是刚想起来这个爬数据的原理没法得到这种数据，因为“想看”与“在看”的用户们应该早就已经“看过”了，所以现在爬出来的数据应该很多都被“看过”覆盖掉了... 我们的数据是静态的，除非定期爬下来保存，否则我们是没办法这类动态的数据的
212279
或者
https://bgm.tv/subject/212279
https://windrises.net/bgmtools/review?id=110467
我记得白箱有很长一段时间都排第10，但是这个模拟的结果显示一直都是11？
站内的排名更新也有延迟的毛病，也许这个更真实一些
误差确实是存在的，这个无能为力
因为这个原因采集的数据数据在时间维度上没有意义，说不好听这个工具到底有多大真实性要打很大折扣。
不过那个工程量就太大了
实际上这个api提供的数据还是挺少的，而且也不能与bgm实时同步，但是如果你还需要别的数据的话，我也可以找时间写一写。
对，就是京紫……https://windrises.net/bgmtools/review?id=183878
而且我刚才看隔壁的帖子https://bgm.tv/group/topic/346147 这个netaba做的挺好的，应该是每天爬一遍评分并记录下来，这个就要准确得多而且还很及时
上面不就有么。。。
不过看着和这个没啥关系 不然我发张图在下面
这个回复怎么上传本地图片 我用本地链接好像不行
会不会是你装的别的脚本与这个冲突了