用户导向一直以来都是企业发展的重中之重，但是由于种种限制，企业无法对用户及需求识别进行细分、了解用户真实的偏好与意愿。随着大数据时代的到来，数据分析以及机器学习等技术的进步，企业可以通过选择合适的用户数据，搭建模型，最后得出想要的结果，并用数据可视化的方式解读。
今天我们邀请了诸葛io创始人&CEO孔淼给大家分享他工作中所遇到的大数据分析与用户画像的业务场景与技术实现。
以下是分享正文：
今天咱们就来闲聊下我过去接触过的数据分析领域，因为我是连续创业者，所以我更多的注意力还是聚焦在解决问题和业务场景上。
如果把我在数据分析领域的经验进行划分的话，刚好就是我所经历的两次创业阶段，第一阶段是“第三方数据分析”，第二阶段是“第一方数据分析”。所以今天咱们就从这两点来谈谈数据分析。
1起因：给开复做“微博推荐”先聊聊“第三方数据分析”，这个主要结缘于我给开复做微博数据挖掘。
微博刚刚火起来的时候，大家发现开复曾经一段时间内都是微博的Top1，很多人会在想，开复每天都在刷微博吗？或者开复的微博是不是有个庞大的运营团队？
我可以给你答案，其实基本上都是开复自己处理的。但是开复每天都很忙，没有时间看那么多微博，所以我们玩了个“trick”，通过程序自动化微博推荐，“揪出”可能会成为爆点或者有意义的微博。
开复提了个算法，就是抓取自己关注的人，以及关注人的关注作为种子。首先将这些人的微博转发历史建立一个“历史档案”，理论上每个人都可以计算出一个时间与转发量的相关函数曲线，然后通过监控这些人的微博。
如果在某个时刻，微博的发布超出历史档案一定倍数，我们就会认为这是可被推荐的微博，所以开复每天看的都是经过筛选后的微博。
在这个过程中，赶上了微博增长的爆发阶段。所以在计算历史档案的效率上，我们用了连续信号的时序抽样相关算法，减少计算复杂度，并且也会去调整倍数的参数，同时我们每天也会在数据库里手动添加一些新的有价值的种子用户。
2微博数据挖掘到第三方数据挖掘刚刚讲了一些故事，其实跟着开复还做了很多关于微博数据的挖掘，后来其演变成了一款产品叫“脉搏网”，包括微博转发的可视化监控，找出KOL（意见领袖）分析爆点原因等等。“脉搏网”虽然表面是微博工具，但是其本质是一群精英爬虫。
谈到今天的话题，第三方数据，就不得不说爬虫。其实我在做第三方数据分析的时候，所有的用户数据都来自于网络公开的数据抓取，比如微博、豆瓣、人人、知乎等等，所有的标签数据来自于垂直网站的抓取，例如汽车品类就是汽车之家，旅游就是旅游网站等等。
所谓第三方数据分析，其实相对于数据使用方的自有数据（第一方数据）而言的。对于数据提供方的数据来源也大概分为几种：
类似“脉搏网”这种的爬虫专业户
类似Admaster这样的广告监控，Cookie跟踪用户页面访问记录等等
Talkingdata这种数据分析平台，用户的应用列表数据等等
所以包括我们上家创业公司（37degree）、Admaster和Talkingdata都做了DMP（Datamanagementplatform）。虽然大家的数据源不一样，但是都会基于各种数据进行清洗，然后计算标签，比如网页有不同类型的网站，应用也有不同的分类，当然实际的算法会比这个复杂多了。
来聊聊我做的第三方数据的一些经验：
先说说数据抓取，也就是爬虫。
这个爬虫不是简单的发个请求，解析一下DOM就可以了，实战中主要从以下方面去解决：
找到合适的接口，包括移动端抓包、PC网站、Wap站、Ajax异步请求
突破限制和验证，包括模拟请求，绕过验证码，登录验证，网络代理
效率问题
第一个问题，爬虫的第一要点一定是巧取。
很多人盲目的去爬取所有能爬到的网页接口，这样做是不对的。找到合适的接口是做爬虫的第一步，这样节省的时间可能是指数级的。举个例子，假如要抓取微博用户的profile，有以下几种办法：
网页
客户端，iOS、Android、平板等等
Wap网站
同样的业务，各个终端都有。我们所要作的就是在其中找逻辑最简单的，并且限制最少的接口去做爬取。
对于PC网站，很多人之前都会被一些Javascript异步加载，也就是需要点击交互才能触发的接口卡住，所以喜欢用模拟浏览器的库去处理，这种做法小打小闹还可以，大规模处理就会遇到性能等各方面的问题。一般来讲，用Chrome的调试工具，看Network，必要时要点下PreserveLog，防止日志在重定向时清掉。
对于移动端，可以用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秒，所以可想而知抓一遍压力还是很大的。
我们当时的框架主要分为三种，都是自己写的:
基于Hadoop的爬虫
基于Celery的单网卡
基于Celery的多网卡分布式
分布式其实一个很重要的特性就是消息通信，爬虫框架核心是频繁的URL调度和解析的调度。
如果是用分布式解析的方法来解析站点的话，那么爬下来的内容会占用非常多的带宽。
在多网卡环境下，一般内网千兆，外网百兆，通信走内网，抓取走外网，这样对带宽影响不大。但是如果是单网卡环境时就不一样了，所以单网卡时，基本上就会相应减少解析调度，主要的信息通信依然是URL的调度，通过异步解析的方式来最大程度的利用好网络资源。
爬虫这块想了解更多的话，可以看看我之前写的两篇爬虫入门文章。
《爬虫入门上篇》
https://zhuanlan.zhihu.com/p/20334680
《爬虫入门下篇》
https://zhuanlan.zhihu.com/p/20336750
接下来说说算法分析这块。
抓取数据只是一部分，其实更大的挑战还是算法分析，诸如用户画像、标签计算，以及机器学习应用里面的聚类分类等等。
影响力算法
我们对微博用户影响力的计算用的就是Pagerank相关的算法，因为用户之前的关注关系很类似网页之间的链接关系，所以我们当时抓取了所有用户的关注关系，用Pagerank的算法来计算这些人的影响力排名。
消费能力计算
微博用户有发布微博的设备列表，有加V认证的类型，并且还有关注关系，所以我们结合这些维度计算了消费能力。
标签计算
预先标注一些标签库，然后将用户的微博进行分词词频统计，然后找到对应标签统计权重，标签库主要来源于垂直网站的抓取训练。
其实计算影响力和消费能力是很大的挑战，虽然这些事情都是通过算法去实现，但效率上还是有很大的挑战，比如1秒计算100个人，一天也只能计算800多万个用户，算完所有用户也要一个月。所以我们做了很多算法和性能的优化，甚至牺牲一定准确性换取效率。
最开始我们用过Pagerank，后来尝试了Hadoop也不是很理想，计算量太大。最后我们优化了算法，换了Graphlab的计算引擎。
在对微博数据进行上面提到的计算分析之前，我们其实还做了很多数据处理的工作。
大家都知道，数据大体可以分为两种，一种是非结构化数据，一种是结构化的数据。
比方说：微博抓下来的大多都是人口属性和Json，这些属于结构化数据；同时，大家发的140个字的微博内容，这些就属于非结构化的数据。
而在简历数据匹配的项目里，简历内容和职位要求也大多是非结构化的。对于非结构话数据的匹配分析，就要用聚类分类的算法了。
简历匹配的场景，主要适用于在茫茫简历中找到和企业自身职位相关性最高的简历，或者一个应聘者需要快速找到和自己相关度最高的职位。
这个时候，为结构化数据准备的传统的目录索引的方式就很难满足需求了。举个例子，即便都是Java工程师，不同公司给这个岗位取的名称可能不一样（Java工程师、后端工程师等等）。这个时候就要看详细的职位要求，通过对非结构的“岗位描述”信息进行聚类分析来实现匹配。
机器学习主要分为两种，无监督学习和有监督的学习。
我们做简历的项目运用的就是无监督的LDA算法，这个在广告领域应用较多。核心原理你可以认为我们想要聚类分类的就是一些方向，每一个文本行可以是一堆向量，向量有长度和方向，最终我们通过比较找到这些向量的相似性。
再解释下，比如一个简历认为是一个处理单元，我们预先准备好职位相关的词库，然后这些词可以认为就是方向，我们将简历TF-IDF算法处理后，去除无关词汇，其实就是一些词和词频的组合，可以认为是向量和向量的长度，然后再进行聚类，因为是无监督，所以我们需要去预估大概有多少个分类，然后不停去调配参数，最终得到一些聚类。
用户画像其实就是像上述一样，我们会设计好很多人口特征的维度，也会根据我们的数据源去找到可以潜在推测的维度，那么这些维度就可能构成人物的画像，例如影响力，消费能力，兴趣能力，品牌标签等等。
又结合应用领域的不一样，标签往往要从细分领域提取，所以就提到要去抓取垂直网站的语料，然后抽取训练，最后给用户打标签，或者给用户聚类分类。
3第一方数据分析。我们建立了庞大的用户数据库，一直服务于广告营销等行业。但是在做这个过程中，我们深深感受到的是当今企业内分析能力的不足，以及过多的分析需求聚焦于“流量获取”上，总想从外部拿到数据匹配用户的标签，但是自己的业务数据分析处理很薄弱。
另外一方面也是不关心用户的engagement，所以我才想到要做第一方数据分析工具，帮助更多企业从内容数据处理优化做起。
第一方数据简单来理解就是自有数据，大多数公司的自有数据就是数据库里用户产生的业务数据，数据分析意识高一点的公司可能会尝试通过日志收集一些用户的行为数据。
所谓行为数据就是包括进入产品、浏览等一系列的使用行为，或者收藏、关注、购买、搜索等一系列的业务行为。
对于大多数初期小公司而言，都没有自己的数据分析平台，所以多数时候的第一方数据分析是依赖于工程师写脚本，根据需求去查数据库。
大量的时间都浪费在沟通、确认需求、写脚本、等待结果运算这些流程中。
对于很多有一定能力的互联网公司，公司内部也开始构建自己的数据分析平台，并且已经开始收集用户的行为数据进行分析，但是大多数对于行为的数据利用还是限制于两种：
第一种做法还是传统BI，基于Oracle等关系型数据库或者基于Hadoop的统计分析。
一般来讲就是设计好数据仓库的模型，包括待分析的一些维度，然后基于维度进行汇总统计，比如在产品领域，就是去统计一些关键行为的发生次数，常见的就是计算页面访问量、独立用户数、留存率等指标，简而言之也就是用于统计结果。
第二种做法就是利用行为数据进行个性化的数据推荐。
这个还是比较MakeSense的，从早期亚马逊的推荐到Facebook的相关推荐，这个是我比较推崇的：不只计算结果，而是运用数据优化业务。
个性化推荐现在常用的就是协同过滤。基本也是分为两种，一个是基于热度，一个是基于兴趣。
前者是user-based，后者是item-based，如果你想打造一个兴趣社区，那么一定要避免根据统计结果，进行热门推荐，而兴趣推荐的一个重点就是要预设一些标签。
综合以上两类公司的做法来看，其实用户的产品互动行为数据基本上始终被当做一个黑盒子来看，推荐算法虽然对这些数据利用的比较好但是只是一个对单用户纵深的分析做法，而横向的用户分析最终止于高度汇总的报表，并不能探索和验证用户在产品上的行为如何影响了公司的业务指标。
一个典型的现象就是很多产品的迭代决策靠的是猜测或者直觉。
所以基于这些考虑，我们就想怎么才能打造一个更加有意义的第一方数据分析平台，而不只是多维交叉汇总结果。于是就想到了做诸葛io，那诸葛io和过去的第一方数据运用有什么区别呢？
我们先从业务来看就是以用户为中心，所以“流量时代”关注的是用户数量结果，BI关注的是维度聚合结果，而我们关心的是用户。
诸葛io目前已经在青云QingCloud应用中心上线，欢迎各位青云的用户前去使用。
我们过去看到一些Dashboard的图表，上升下降可能很难找到原因，因为一开始分析的基础就是维度汇总的数据。
但是如果所有的数据以独立的用户跟踪为基础就不一样了，假若我们看到新增的这些数字，或者汇总分布的结果，我们可以找到每个具体数字背后的人，能还原这些用户的丰富业务标签和维度，亦然可以做更多的比较和分析了，可以说“行为即标签”。
用户的行为数据、之前每次的交互行为等，都可以构成丰富的业务标签。
举“知乎”这个社区为例，“关注了XX话题”、“关注了XX用户”、“点赞了XX内容”、“分享XX文章”，这些行为本身就是非常丰富且有用的标签，组合起来亦然。
基于用户在产品内的行为所构建的标签体系，比之前说的第三方数据计算出标签意义更大。因为基于行为设定的标签，后续是能反作用于用户的，我们可以为不同行为标签下的用户群设定更精准的运营策略，例如内容推荐、活动促销、精准推送等等。
最后，再从技术上来讲讲，主要使用的其实还是lambda架构。我们以Kafka为消息中心，利用多层生产者与消费者的概念，对数据进行运用，例如实时计算、打标签、导入数据仓库、备份等等。
数据存储，也用了SQL和NoSQL，但SQL也是用的列式存储数据库，NoSQL诸如对Elasticsearch进行索引，承载一些快速查询的场景，关系型主要用于复杂计算，因为我们不止是用户、事件两个主题，还有会话，所以复杂度很高，中间我们也用了一些小trick，以后有机会和大家分享一下。
