在很多领域都需要用数据来说话，整个数据的采集过程也是对思维方式的一次考验。本篇文章作者介绍了自己的一次爬虫经历，其中也讲述了自己是如何通过转换思维的方式使得整个过程更加流畅。

说明：我不是技术人员，整个过程并没有涉及到一定需要技术的地方。

不过，非技术人员去抓取数据，岂不是更有意思的一件事情？

前几天，在看B站时，突然想，是不是可以抓取数据分析一下？

曾抓取过B站番剧的数据，用于建立一个番剧排行榜，这次是投稿，难度比抓取简单的静态页面要大。

一、精益思维，第二桌面

看着电脑屏幕，遇到了第一个困难：爬虫中很多步骤很耗费资源，笔记本日常要用，我需要第二台电脑。

灵机一动，服务器是不是可以做第二个桌面呢？刚好双11各大云服务器商都在做活动，云服务器除了linux系统外，还有windows系统。

没有用过windows系统的服务器，是否该买一个呢？

想到了精益思维，我需要逐步验证来确定最适合的选项。

一步步的改变配置，来验证最适合自己的配置，从CPU核心数到内存到带宽，云服务器商都提供了按需使用的选项，可以在测试后立刻释放服务器。

在进行了多次测试后，我陷入了一个新的困惑之中：真的需要第二台电脑吗？

这真的是一个必要的选择吗？

甚至爬取数据进行分析真的是一个有意义的事情吗？

我正在整理收藏，还有大量的文章没有归档，因此耽误了计划，是否值得？

还没有开始，就已经引发思维碰撞了，这一定会是一次有趣的经历，我决定立刻行动。

此时，确认了需要第二台电脑，我面临两个选择：是选2核心4G还是选4核心8G的机子，在测试中，我使用的是2核心4G，是可以满足运行几个软件的需求的，测试中使用的带宽是3-4M，过程中并未出现卡顿情形，这说明3M绝对足够；

最终选择了4核8G2M的华为云机器，选择时，还不知道我将面临什么，在真正使用时，我将为这个选择骄傲。

选择4核8G2M的机子，在满足了我的需求的同时，也多了一个月的使用期限，腾讯云4核心8G10M，155块2个月，华为云4核心8G2M，155块3个月；

选择2M带宽，基于对服务器基本信息的了解，服务器带宽限制是上行，而不是下行，这跟日常使用的家庭网络完全相反，个人使用则主要使用下行带宽；

这次选择服务器的经历，也让一个基本原则得以完善：不做非必要的选择，如果做出了选择，则需避免过度为未知考虑造成过度冗余。

二、开始抓取，研究工具

曾用过一个简单的抓取工具八爪鱼，但只做过最基本的页面元素抓取， B站投稿页面并不是简单的静态页面；

为了避免出现意外，我开始全面研究八爪鱼的基本信息，尤其是跟功能限制有关的信息，准备升级为收费版，以便增加可导出的数据量，从1万增加到10万；

在权衡后，判断不需要升级，要导出10万级别的数据量，采集所需要的时间会很大，我并没有准备花费如此长的时间；

在了解服务器端桌面与家庭桌面的区别时，发现A站采集两端一致，B站采集则家庭桌面占优；我做出了发挥各自优点的选择：本地运行B站采集任务，服务器端运行A站采集任务；

研究工具信息后，得知可以同时运行两个任务，但一个账号只可以同时保持一个在线；为了在服务器端运行程序，我注册了一个新的账号，然后准备使用程序的任务导出导入功能连接两个账号；

在本地测试完毕后，导出任务，然后导入到服务器端，开始运行；

免费版只有1万的数据导出量，这决定了这将是一次数据量严重不足的采集，为了缓解这个问题的影响，在生成链接时，我使用了随机数，生成带有随机数字的链接。生成链接使用的是Excel的基本的组合公式，首先生成一组随机的数字，因为B站A站链接都是以数字为基础的，比如B站的AV号、A站的AC号。

在生成后链接后，需要导入审查工具进行监测。审查工具是为了检测生成后的链接是否可以打开，不能打开的链接无法采集也会让采集报错。

为了加快检测速度，需要多个审查工具并行，我找到一个多开工具，这个工具在后面发挥了更大的作用，帮助我快速审查了B站的100万链接。

这时，开始进入测试，为了迎接大批链接的到来，我需要对采集流程做初步的优化。

先行验证与优化，并不需要大量的链接，只需要两个链接即可，这一步是为了保证采集数据的正确性，采集的慢没有关系，数据一定是自己需要的。

在真正采集B站时遇到了困难，B站的评论并非是同步加载的，需要等待数据出现，才可以加载出评论数，这限制了采集速度。

在进行了多轮优化后，B站的数据增加了清晰度的选择，这可以让我了解一下视频平均清晰度，为了研究投稿者粉丝数对其他数据的影响，增加了投稿者粉丝数的采集。

链接审查完毕后，我将链接分为两个任务同时进行。

又发生了意外，采集到部分数据后，会中断，必须使用更加精准的采集方式，才能解决问题的同时保证采集速度，等待时间、判断条件都需要重新设定。

曾注意到的一个工具使用中的问题：很难做到边用边研究，基本到一个使用水平段就会开始停止，在这次采集中我要避免这个问题，我要边用刀边磨刀。

中间有几次实在是有些想放弃，开始认为自己不可能解决问题，但随着去研究工具的功能及问题可能的原因，最终所有问题都得到了解决。

在这个过程中，我告诫自己：要相信逻辑带来的精准，而不要寄望于概率的宽容；解决问题要理清逻辑对症下药，不能胡乱尝试，更不能在毫无根据的抱有美好的幻想。

采集速度也随着流程的优化而变快，我贯彻了在实践中变强的理念，每次错误都是一次再次进化的机会，最终B站的采集速度从一分钟两个增加到了四个，A站的采集速度从一分钟13个增加到了20个。

边优化边运行，导致一个新的情况出现：有一个旧的任务在运行，有一个新的优化后的任务在运行。旧流程没问题，但是比较慢，新的流程经过测试也没问题，更快。

旧的任务已经抓取了2千多个，如果停止，重新开始就要重新抓取，这变成一个数学题：A在B前2000米，A跑步的速度是2米每分，B跑步的速度是4米每分，问：B需要多久才能追上A？

答案是1000分钟后，A又跑了2000米，B跑了4000米，假如总里程是8000米，应该立刻停止A，使用B的流程，假如总里程是3000米，就应该让两个任务同时进行。

不过，第一次做出的选择通常不是最优的选择，最优选择是停止旧的任务，将已经采集的数据导出，去除已采集的链接，在新的任务中只采集未采集的链接。

三、转换思维，导入数据库

将数据导出后，有了第一个真正的数据表，我该如何处理数据？是不是需要将数据可视化呢？

由于缺乏数据分析的基础经验，我开始陷入迷茫。

前几天，偶遇一个百度的可视化工具（https://sugar.baidu.com），当时试用了一下，没有成功；再次打开，准备解决上次遇到的问题：数据库没有连接成功；在修改了服务器的放行端口后，问题解决。

但这个工具只可以从数据库中获取数据，不能提交excel格式的数据，我手头是Excel。

准备弃用工具时，我转换了思维，想到一个解决方案：把excel导入mysql不就行了。

搜索后发现phpmyadmin是可以导入csv格式的数据的，将excel格式另存为csv后，导入了数据库。

这是我第一次使用phpmyadmin，第一次在数据库内建表，遇到了很多尴尬，按照excel中的列的顺序确认了表的字段以及属性后，提交成功了，导入数据也成功了。

然后惊喜的发现，phpmyadmin自带一款基本的可视化工具：

可是，有可视化工具又能如何？数据根本无法使用，这个数据就不具备任何结构和逻辑，这不是有意义的数据。

我需要的并不是工具，而是能够使用工具的数据逻辑；首先要做的是理清数据的基本逻辑，再寻找适合的工具，工具应该是逻辑的延伸。

四、回归数据，边等采集边研究

话又说回来，一定要去外面找工具吗？Excel不行吗？

返回excel再次去看这一大堆混乱的数据，该如何理清头绪呢？

我需要一个突破口，那么什么能作为突破口呢？

我想到了用户的分层概念，数据也可以用此概念进行分层；要分层，就需要基准维度，选哪个维度对数据进行初始化呢？

我选择了播放量，然后根据播放量的大小对数据做了十几个分类，数据开始清晰鲜活。

这时，我根据分类的过程总结了一句话：不做出有意义的分类，就无法做出有意义的洞察。

播放量本身属于一个基本指标，单独观察并无意义，通过与其他数据指标进行组合，却可以形成很多有意义的新的数据指标。

我对数据进行了整理，数据成为了可被使用的数据：

开始统计，并进行计算，在此过程中，我全面使用了自动化的思维：凡是需要手动重复两次的操作，全部寻求自动化实现。

自动化实现执行的很顺畅，直到出现新的情况：为了算平均数，需要生成一堆公式，但是公式一旦生成，就会立刻生效，根本无法复制使用。

在各种尝试中，不停的报错：

这个不停弹出的报错窗口，反而给了我启发：是否可以生成一个错误的公式，让其不生效，生成后复制到相应的位置后，再批量改为正确的公式，让其生效。

经过测试，在所有公式前加一个字符导致其失效确实可行。

复制后得到了第一份数据：

这个故事告诉了我两个道理：

1. 错误本身也是信息；
2. 永远不缺意外，但只要沉着应对，不轻易放弃，不局限于已有的知识经验，一定能找到解决方案。

为了观察播放量与各个数据的关系，我又建立了几个新的数据指标：播放量/弹幕、播放量/评论等，这些组合指标表明了多少分子指标对应一个分母指标；

数据显示：平均 301次播放对应一个弹幕，136次播放对应一次赞，300次播放对应一个投币，171次播放对应一次收藏，232次播放对应一个评论。

根据对应关系，可以判断获取的难度为：赞<收藏<评论<投币<弹幕。

此时，原始数据表中还有一个分区数据没有使用，我希望能找出其意义，以便充分使用数据；

分区出现的频率，可以用来判断其热度，做一个排行来看最热门的B站分区；我找到一个公式，对其进行了统计，得出了一个分区热度统计：

分区排行与原数据表组合成了新的数据表：

似乎还缺了点什么？一直以来都很佩服B站用户的参与度，如今有了机会，何不制定一个新的数据指标来进行观察呢？

我定义了一个新的数据指标：互动指数，由互动行为除以播放量得出：互动指数=（弹幕+投币+评论+收藏+赞）/播放量。

将小数点定义为3位，得出了每千次的互动量：

最终得到的平均互动指数是0.024，也就是每千次有24次互动。

这些数据分析及结果都基于试验用的数据，精确性很有问题，但是这次试验性的研究为大量数据的研究打下了基础，在全部采集完毕后，全部采集数据的处理很快完成了，这是最终的数据表：

终得到的互动指数为0.044，每千次44次互动，由于采集的数据样本仍然相对过少，所以这个数据只能参考。

一般的非社区型产品互动指数小于千分之一（依据我曾参与过的非社区型产品），每千次PV对应不足一次互动行为，B站互动指数是非社区型产品的50倍以上。

从上面数据中可以发现，试验数据与最终数据得出的结论差别很大，根据B站的数据量，至少需要分析100-1000万数据才能得到有可信度的数据；

接下来就是分析A站数据，大致步骤也是一样的，这是最后的数据表：

分析A站数据时，发现了一些异常数据，我将其中过于异常的数据删除了，比如100万播放，一个评论都没有的视频。

从A站播放量的分布中可以看出A站跟B站的播放量分布有一定的区别：数据显示A站播放量在1千-3千的视频占比在60%以上，一半以上的视频获得了超过1000次的浏览。

后面还会计算A站与B站的日均新增视频数，日均新增量的明显差别可能是原因之一。

在审查链接时，发现有一些链接是失效的，这个失效数据背后说明了什么？

傅盛说现象即规律，放在数据分析中可以说数据即意义，我需要找到数据背后的意义；失效代表了异常，包括但不限于未审核通过、UP主删除、被删除等等情况。

我为此定义了一个新的数据指标：异常系数，用来判断每个网站在前端真实的视频比例。

准备看一下A站与B站在2018年每个月的日均新增视频数据，做一个对比，异常系数可以用于排除异常数据；

根据数字（B站AV号、A站AC号）增加1即是增加一个视频的基本原理，可以算出每个月日均新增数字，是未排除异常的数据；

我使用的方法是先找出每个月特定时间点附近的数字：

相减后除以当月的天数，得到了每个月未去异常的日均新增视频数据：

为了使异常系数更加精确，需要尽量多的数据参与计算，最终我选择B站100万数据，A站45万数据，为了保证分散，B站链接仍然是在2018年的视频里进行随机生成。

多开工具立下了很大的功劳，在服务器端的桌面上，并行5个以上的审查工具，如果当初我选择了2核心4G的服务器，最多只能并行2-3个审查工具。

全部审查完毕后，我进行了计算：异常系数=（总数据-正常数据）/总数据；A站总数据：449228，正常数据：277694，异常系数：0.38。

B站总数据：966753，正常数据：705888，异常系数：0.27。

有了各自的异常系数，就可以计算A站和B站日均新增的净值了，公式：净值=（1-异常系数）x全部数据；以下是日均新增净值：

A站在2018年前十个月内日均净新增1060个视频，B站日均净新增41312个视频。

这时，又想到了可视化数据，为了对比更为直观，我选择以下三个数据：

1. 各类播放量视频占比对比：

2. 互动指数对比：

3. 日均新增视频数对比：

• 日均新增全部数据对比（含异常数据）：

• 均新增净值对比：

后记

当看到B站清晰度数据时还是惊呆了，B站2018年新增视频平均清晰度超过了800P，如果没有这些数据支持，我不可能想到。

抓取数据及进行基础分析的过程到此已经结束了，过程中用到的部分工具及知识，我分享在了这里：https://open.skyfollowsnow.pro/?thread-55.htm。

整个采集过程，我使用了很多思维，比如精益思维、逆向思维、自动化思维，但印象最深的还是灵性思维。

在使用excel时，我全面使用了自动化思维，节省了很多时间，后面开始事事都要找到自动化的实现方式，在某个数据生成时，使用自动化时遇到了一点困难，这个数据其实并不需要自动化执行，使用excel自带的填充功能也有很好的执行效率。

当时我想起了最近一直在研究的半本能半理性的工作方式，为了让行动充满灵性，必须不断思考出发的原因。

我很快醒悟了过来，自动化思维是为了快速执行我的想法，而我的想法快速执行却不一定非要自动化思维，事事自动化反而让自己受到了局限。

这次实践，让我对灵性有了更深的理解：带着目的地去旅行，不仅不会迷路，还可以脱离具体路径的限制。

大道万千，意，当为形先！

作者：天下雪，公众号：skyfollowsnow

本文由 @天下雪 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash ，基于 CC0 协议