从第三方数据到第一方数据的技术变革

大家好，我是诸葛io的CEO孔淼，今天很高兴能和各位前辈一起交流，我是晚辈，如果我分享的一些内容如果以偏概全，也希望大家能够指正。

诸葛io是一款精细化的数据分析产品，以覆盖Android、iOS、JS/H5、服务端API等多种数据采集方式，帮助企业整合分析用户行为，并且提供强大的后台驱动产品、运营、业务等方面的决策，具体可以登录zhugeio.com或者关注诸葛io公众号进行了解。

言归正传，今天咱们就来闲聊下我过去接触过的数据分析领域，因为我是连续创业者，所以我更多的还是聚焦在解决问题和业务场景上。如果把我在数据分析的经验划分的话，刚好也就是我所经历的两次创业阶段，第一阶段是“第三方数据分析”，第二阶段是“第一方数据分析”。所以今天咱们就来漫谈下第三方到第一方数据分析。

先聊聊“第三方数据分析”，这个主要结缘于我给开复做微博数据挖掘开始。

起因：给开复做“微博推荐”

我之前有段时间给开复做实习生，也是微博刚刚火起来的时候，大家发现开复曾经一段时间内都是微博top1，很多人会在想，开复每天没事儿做都在刷微博吗？或者开复的微博是不是有个庞大的运营团队？

我可以给你答案，其实基本上都是开复自己处理的，但是有一点的确是痛点，开复每天都很忙，没有时间看那么多微博，所以我们玩了个“trick”，目的就是通过程序自动化微博推荐，“揪出”可能会成为爆点或者有意义的微博。开复提了个算法，就是抓取了开复关注的人，和关注人的关注作为种子，然后首先将这些人的微博转发历史建立一个“历史档案”，每个人理论上都会计算出一个时间与转发量的相关曲线，然后我们会监控这些人发布微博，如果微博在某个时刻超出历史档案一定倍数，我们就会认为这是可被推荐的微博，所以开复每天都是看经过筛选后的微博，在这个过程中，其实赶上微博增长爆发的时候，所以在计算历史档案的效率上，我们用了连续信号的时序抽样相关算法，减少计算复杂度，并且也会去调整倍数的参数，同时我们也每天会手动添加一些新的有价值的种子用户。

转承：微博数据挖掘到第三方数据挖掘

所以包括我们上家创业公司（37degree）、Admaster和Talkingdata都做了DMP，数据源不一样，但是都会基于各种数据进行清洗，然后计算标签，比如网页有不同类型的网站，应用也有不同的分类，当然实际的算法会比这个复杂多了。

我来聊聊我做的第三方数据的一些点。

先说说数据抓取，也就是爬虫：

这个爬虫不是简单的发个请求，解析一下DOM就可以了，实战中主要从以下方面去解决：

先说说第一个问题：

爬虫的第一点一定是要巧，因为可能节省的就是指数级的时间，很多人希望盲目的就去爬取网页，找到合适的接口是第一步，举个例子，假如要抓取微博用户的profile，其实有好几种办法：

同样的业务，这些终端都有，所以我们要找的当然是逻辑最简单的，并且限制最少的，然后就是找接口，对于PC网站，很多人之前都会被一些Javascript异步加载，也就是需要点击交互才能触发的接口卡住，所以喜欢用模拟浏览器的库去处理，这种做法小打小闹还可以，大规模处理就会遇到性能等各方面的问题，一般来讲，其实用Chrome的调试工具，看network，必要时要点下preserve log，防止日志在重定向时清掉。对于移动端，可以用Charles或者Fiddler2设置终端代理，然后抓包网络请求，你就可以看到很多请求数据了，然后找到自己需要的。这种做法是我一般用的最多的，因为移动端的API几乎都是结构化的数据，不像网页还需要解析。

然后说说第二个问题，突破限制：

模拟请求肯定是第一步，你要熟知Http协议，简单的比如UA、Referer，又比如Cookie在请求头哪儿设置的，还有的就是一些常用的协议，比如XAuth协议，OAuth2.0协议，我们当时对于爬虫的同事都是在原理级需要贯通的。

绕过验证码，简单的用一些OCR的库，比如早期的12306很简单，复杂的就只能找漏洞了。

登录验证，一般来讲其实最主要的有两个，一个是需要连续请求，中间涉及到添加了一些cookie或者参数传递都得完整跟踪模拟，第二个就是弄清楚加密的机制，比如早期新浪微博是二次SHA1加密还加salt，后来是RSA加密。对于PC网页弄清楚加密原理比较简单，就是要学会阅读Javascript的代码。然后就是需要有足够多的账号，然后来伪造身份，有的时候也可以不用模拟登陆，用OAuth的一些授权来做，道理也类似，就是要模拟拿到access_token，中间也有一些很有意思的，就比如说我看了OAuth2.0的RFC协议，然后找到了授权一个隐藏的漏洞。

网络代理就得看实际情况了。有的请求是http，有的请求是https的，我们当时是抓了大部分网络公开的代理网站，然后结合不同的抓取域名，验证这些代理的有效性，然后定时保证大量可用的代理库，包括http和https的。

最后一个问题就是效率，爬虫还是一个很大而工程，举个简单的例子，我要抓取微博用户的个人资料、关注关系、微博内容，微博内容和关注关系还需要分页，如果是3亿的微博账号，平均一个人5个请求，也就是需要15亿请求，一天是86400秒，所以可想而知抓一遍压力还是很大的。

我们当时的框架主要分为三种，都是自己写的:

分布式其实一个很重要的就是消息通信，爬虫框架核心还是URL调度，解析的调度，所以本身如果是分布式解析的话，那么爬下来的内容也会占用带宽，所以多网卡的时候，一般内网网卡是千兆，外网带宽是百兆，通信走内网ip，抓取走外网，影响不大，但是如果是单网卡就不一样了，所以单网卡时，基本上就会减少解析调度，主要信息通信还是URL的调度，利用好网络资源，解析是异步的。

爬虫这块儿详细的可以看看我之前写的两篇爬虫入门文章。

算法分析

接下来说说算法分析这块。抓取数据只是一部分，其实更大的挑战还是算法分析这块，诸如用户画像、标签计算，以及机器学习应用里面的聚类分类等等。

• 首先说说影响力算法

有个很有意思的就是之前我们对于微博用户影响力的计算，我们用的就是pagerank相关的算法，因为用户之前的关注关系很类似网页之间的链接关系，所以我们当时抓去了所有用户的关注关系，用pagerank的算法来计算了这些人的影响力排名。

• 消费能力计算

微博用户有发布微博的设备列表，有加V认证的类型，并且还有关注关系，所以我们结合这些维度计算了消费能力。

标签计算我们是预先标注了一些标签库，然后将用户的微博进行分词词频统计，然后找到对应标签然后统计权重，标签库就是主要来源于垂直网站的抓取训练。其实计算影响力和消费能力也是很大的挑战，就是这种都是算法应用，还是一样效率有很大的挑战，比如1秒计算100个人，一天也只能计算800多万个用户，算完所有用户也要一个月，所以我们做了很多性能优化，降维，牺牲一定准确性换取效率。另外比如pagerank这种算法还是迭代性的，用hadoop的话其实不是很适合，后来我们又尝试了graphlab

除了微博数据的分析，我们其实还有很多数据分析处理，大体其实主要是两种，一种是非结构化数据，一种是结构化的数据。

微博抓下来的大多都是人口属性和json，都属于结构化数据，但是微博内容又属于非结构化的。

简历数据的匹配

简历和职位要求匹配就是非结构化数据处理，用的主要还是聚类分类的算法。简历匹配的场景主要是，用于很多公司需要去在茫茫简历中找到和自己职位相关性最高的简历。或者一个应聘者需要快速找到和自己相关度最高的职位，因为即使是java工程师，其实也有很多类型，传统通过目录索引方式很难匹配，不同公司取的名称也不一样，也必须要看详细的职位要求。

机器学习其实主要分为两种，无监督和有监督的学习，我们当时运用的就是无监督的LDA算法，这个在广告领域应用较多，核心原理你可以认为我们想要聚类分类的就是一些方向，每一个文本行可以是一堆向量，向量有长度和方向，最终我们找到这些向量的相似性。

解释下，比如一个简历认为是一个处理单元，我们预先准备好职位相关的词库，然后这些词可以认为就是方向，我们将简历TF-IDF算法处理后，去除无关词汇，其实就是一些词和词频的组合，可以认为是向量和向量的长度，然后再进行聚类，因为是无监督，所以我们需要去预估大概有多少个分类，然后不停去调配参数。最终得到一些聚类。

用户画像其实就是像上述一样，我们会设计好很多人口特征的维度，也会根据我们的数据源去找到可以潜在推测的维度，那么这些维度就可能构成人物的画像，例如影响力，消费能力，兴趣能力，品牌标签等等，又结合应用领域的不一样，标签往往要从细分领域提取，所以就提到要去抓取垂直网站的语料，然后抽取训练，最后给用户打标签，或者给用户聚类分类。我们建立了庞大的用户数据库，一直服务于广告营销等行业。

但是在做这个过程中，我们深深感受到的是当今企业内分析能力的不足，以及过多的分析需求聚焦于“流量获取”上，总想从外部拿到数据匹配用户的标签，但是自己的业务数据分析处理很薄弱，另外一方面也是不关心用户的engagement，所以才想到要做第一方数据分析工具，帮助更多企业从内容数据处理优化做起。接下来来聊聊第一方数据分析。

第一方数据分析

第一方数据简单来理解就是自有数据，大多数公司的自有数据就是数据库里面的用户产生的业务数据，数据分析意识高一点的公司在此之外，可能会尝试通过日志收集一些用户的行为数据。所谓行为数据就是包括进入产品，浏览等一系列的使用行为，或者收藏，关注，购买搜索等一系列的业务行为。

对于大多数初期小公司而言，都没有自己的数据分析平台，所以大多数时候的第一方数据分析，是依赖于工程写脚本，根据需求查数据库去计算。

很多时候时间都浪费在了沟通，确认需求，写脚本，等待结果运算上，我相信很多公司一定有共鸣。

对于很多有一定能力的互联网公司，公司内部也开始构建自己的数据分析平台，并且已经开始收集用户的行为数据进行分析，但是大多数对于行为的数据利用还是限制于两种：

第一种做法还是传统BI，基于Oracle等关系型数据库或者基于Hadoop的统计分析，一般来讲就是设计好数据仓库的模型，包括待分析的一些维度，然后基于维度进行汇总统计，比如在产品领域，就是去统计一些关键行为的发生次数，常见的就是计算页面访问量，独立用户数，留存率等指标，简而言之也就是用于统计结果了。

第二种做法就是利用行为数据进行个性化的数据推荐。这个还是比较make sense的，从早期的亚马逊的推荐到Facebook的相关推荐，这个是我比较推崇的不做结果，而是优化过程的数据运用。

个性化推荐现在常用的就是协同过滤了，基本也是分为两种，一个是基于热度，一个是基于兴趣的，前者是user-based，后者是item-based，如果你想打造一个兴趣社区，那么一定要避免根据统计结果，进行热门推荐，而兴趣推荐的一个重点就是要预设一些标签。

综合两类公司的做法来看，其实用户的产品互动行为数据基本上始终被当做一个黑盒子来看，推荐算法虽然对这些数据利用的比较好但是只是一个对单用户纵深的分析做法，而横向的用户分析最终止于高度汇总的报表，并不能探索和验证用户在产品上的行为如何影响了公司的业务指标。一个典型的现象就是很多产品的迭代决策靠的是猜测或者直觉。

所以基于这些考虑，我们就想怎么才能打造一个更加有意义的第一方数据分析平台，而不只是多维交叉汇总结果。

于是就想到了做诸葛io，那诸葛io和过去的第一方数据运用有什么区别呢？我们先从业务来看

两张图，一个核心，就是以用户为中心，所以“流量时代”关注的是用户数量结果，BI关注的是维度聚合结果，而我们关心的是用户。

我们过去看到一些dashboard的图表，上升下降可能很难找到原因，因为一开始分析的基础就是维度汇总的数据。

但是如果所有的数据以独立的用户跟踪为基础就不一样了，假若我们看到新增的这些数字，或者汇总分布的结果，我们可以找到每个delta数字背后的人，能还原这些用户的丰富业务标签和维度，亦然可以做更多的比较和深入分析了。

所以用户的行为数据在个性化推荐之外，之前每次业务的交互，也都是这些用户丰富的标签，比如知乎“关注了XX话题”、“关注了XX用户”、“点赞了XX内容”、“分享XX文章”，这些行为是非常丰富的标签，组合起来亦然，比之前说的第三方数据计算出标签意义更大，因为后续还以为着你分析的结果是能反馈到这些用户的，例如换回流失，精准推送等等

再从技术上来讲讲，主要其实还是lambda架构。

我们以Kafka为消息中心，利用多层生产者与消费者的概念，对数据进行多种运用，例如实时计算、打标签、导入数据仓库、备份等等

数据存储，也用了SQL和NoSQL，但即使是SQL也是用的列式存储数据库，NoSQL诸如Elasticsearch进行索引，承载一些快速查询的场景，关系型主要用于复杂计算，因为我们不止是用户、事件两个主题，我们还有会话，所以复杂度很高，中间我们也用了一些小trick，以后有机会和大家分享一下：

Q&A

问题1：大数据开发和数据分析师的具体职能和区别

问题2：大数据数据质量有哪些保障措施？

问题3：基于hadoop的爬虫思路是什么？？是属于分布式爬虫？

问题4：请问，诸葛IO分析细化到单用户粒度，最主要的3个实际应用场景是什么？

以上内容均为2016年4月7日大数据群分享记录。 还想获得这些干到不能再干的分享内容？赶快关注我们“大数据杂谈”公众号，点击“加群学习”，更多纯技术分享等着你！