从日志统计到大数据分析（八）——五代

在上一篇的最后，我把数据处理分成五个阶段，分别是数据采集、数据传输、数据建模/存储、数据统计/分析/挖掘、数据可视化/反馈。这篇主要讲解第一个环节数据采集相关的内容。

如果看过前面几篇，就会体会到我对数据源的重视程度是超乎想象的，认为数据源整好了，数据处理就搞定了一半。如果源头没有整好，后续用再复杂的算法，也不能解决数据缺失和错误所带来的问题，并且会花费许多倍的工作量去解决源头不好的后遗症。那么什么叫数据源整好了呢我总结为两个字：“全”和“细”。

上篇我在讲解大数据的概念时，总结了四个字：“大”、“全”、“细”、“时”。其中的“大”是一种抽象的概念，很大程度取决于业务规模，对于一些初创公司来说，完全没有这方面的顾虑。而“时”可以说是一种基本要求，我们在数据获取手段上，因为在线的原因越来越实时。那么，对于大数据来说，剩下的就是“全”和“细”了。可能有人也会提出数据源的准确性也很重要，但我认为这点就像写代码不能有Bug一样，是基本的要求，没必要单独强调。

“全”和“细”

首先，我们来看“全”。就好比我们要去开采一座矿山，这座矿山有半截露在地表以外，还有半截在地表以下。如果你只把地上的部分进行开采，那地下部分所蕴含的矿物成份就没办法后续使用了。或者你只是把地上部分的南山部分给开采了，但是北山没有，这都不够全。你可能会问那不显然都开采一下吗有谁会只开采一部分但在数据采集这一环节上，经常会看到只通过JS/APP SDK采集了客户端的数据源，但是服务端(包括数据库)中的数据源没有采集，比如库存信息就只存在于服务端，那如果后续你想针对客户端的数据源去分析库存相关的数据，那显然不可能的。还有一种情况是对数据源进行了抽样，那可能就无法精确的表明用户行为的真实情况，有可能把用户的一些行为给丢掉了，造成不连贯。甚至因为你用JS SDK进行采集，就像开了个露天车厢的卡车运矿物，因为网络的不稳定，本身就会丢失一部分客户端的数据。在08年左右百度前端的同事做过测试，一般会丢失7%左右。我们自己的官网也用百度统计、Google Analytics做了测试，存在20%左右的丢失(当然，因为访问量少，不足以作为精确依据)。

其次是“细”。这里我强调的是多维度，比如IP、时间、URL都是维度，要一个个的切分好搜集下来。我不建议的是作为一个字符串使用空格或者其他特殊服务来进行区分，这样后续解析极易出错，解析效率也很低，我在之前的文章里有过详细的讲解，这里就不多说了。有些维度你可能不确定要不要打印出来，这种时候我的原则是进行多的打。只有打细了，后面想围绕这个维度进行分析，才会有可能。比如一个创业公司如果通过业务数据库中的数据，能够进行每日订单总量的统计，但某一天PM提出想看看不同浏览器版本的用户在订单上的分布，RD就傻眼了，在设计数据库的时候可没想着要记录浏览器这个维度，只能升级系统来满足了。

写到这里，不知道你意识到没有我强调的尽量全和细的把数据源收集下来，然后按需进行分析，数据都是现成的。而不是每来一个需求，都专门为这一个需求做数据采集，再来一个需求，又要重新做一遍类似的事，总是有填不完的坑。在一些城市铺设线路，就会出现类似的情况，今年电力公司挖了一条沟，明年电信集团又挖了一条沟，就不能挖一次可预期的一段时间内都解决了。这种需求驱动的模式会产生极大的资源浪费和时间成本。

数据记录的“全”和“细”了会不会带来资源上的巨大开销一是存储空间是不是占用的多了感谢摩尔定律，现在磁盘这么便宜，你就放心大胆的存吧。二是写磁盘操作会不会影响性能因为是顺序写入并且有page cache，写入对系统性能的影响是非常有限的，这点我带的团队都做了多年的实际应用了，我就不拿数据了。

数据格式

我在楚汉争霸一篇中，详细讲解了文本非结构化方式所存在的问题，也介绍了Protocol Buffer(PB)这种结构化方式的好处。但对于初创公司来说，使用PB这种格式太重了，配套需要开发的东西太多。除PB之外，常见的结构化方式的技术有：

XML——写出来是***这种效果，读起来很清晰，就是字符占用太多。

JSON——比如{“name”: “liudehua”}这种效果，前后端开发者都熟，也比较好理解。

Thrift——由Facebook开源的一套开发框架和数据格式，相比PB，在解析效率上低点，但周边组件比较完善。

Avro——由Hadoop创始人Doug Cutting主导开发的，使用接口上和Thrift类似，有客户公司在使用。

以上四种在解析效率上，都比不上PB，但易用性我觉得都超过了PB。在压缩效果上，PB、Thrift、Avro这些相当，比JSON、XML要好很多。这里补充一点，PB并不是严格意义的压缩，而是一种更高效的编码方式，比如数字300，在存储上只需要占两个字节，对于字符串，PB并没有做特别的处理，也就是没有压缩效果，有兴趣研究的可以看这里。在百度内部的某较大产品线，使用PB格式后，比原文本非结构化格式要减少30%的存储量，如果再在PB上进行LZO压缩，可以再减少20%。在我现在的创业项目中，并没有使用PB这种最高效的，还是要考虑客户的学习成本，我们选择的JSON作为接口，至于进入系统之后，可以采用其他更高效的存储方式。对初创公司来说，我同样建议使用JSON作为数据生成的格式，而不是文本非结构化方式。

可能说了半天你还不知道啥叫结构化数据一句话就是带有Schema的。啥是Schema就是数据的字段描述。比如一张数据表的表结构定义(各个字段表示什么)，或者一个Excel的表头。在一些大数据著作中，都会强调大量非结构化、半结构化这一特征，在我看来，为了方便处理，如果能在源头结构化了，就别后续在非结构化接触上使蛮力。

数据类型

这么多的互联网创业公司，所拥有的数据千差万别，但大面上只有两种：行为数据和业务数据。行为数据是用户使用产品所产生的行为，是我这一系列文章中主要描述的数据类型。业务数据是也产品强相关的业务支撑所必须的数据类型，如用户、订单、库存，对百度搜索来说，有网页库，对淘宝来说，有每件商品的SKU信息。我们所说的数据分析，就是针对这两类数据的处理。

针对用户型的产品，我们可以把用户行为和用户属性进行抽象。用户行为可以抽象成行为类型、行为属性(操作系统、应用版本、是否WIFI、屏幕尺寸、设备型号、商品ID、商品价格等)、用户ID这一统一格式。我在前面有过描述。用户属性也可以按照统一的格式(如性别、出生日期、婚姻状况、注册时间、收入级别、是否有小孩等)。在这类数据的分析上，各个客户的需求在我看来是可以统一的，也是我目前创业的立足点。

对于业务数据，真的是差异非常大，不可能把各家的数据库直接同步到数据仓库中直接去使用，而是要进行抽象。目前我还没有想到一个好的办法能直接打通所有互联网产品的的业务数据，只能是按行业进行共性抽象。另外，对于一些业务数据的分析，可以转化为行为数据的分析。比如销售额，就是把支付成功的行为的支付金额属性进行一个汇总。

数据采集点

互联网产品都是C/S或B/S架构，原则上能够从客户端和服务端都能采集到许多行为数据。但在这里我还是推荐从服务端来进行采集，好处是数据更准确和全面，并且一个地方采集，可以覆盖多种客户端。但有人会觉得开发代价大，愿意用客户端嵌入第三方SDK的方式。需要提醒的是这种方式存在丢失数据，采集的字段不够全的问题。看似省事了，但也限制了数据分析的潜在能力。

如果使用前端打印的方式，需要考虑压缩、批量、加密等问题，使用第三方SDK的话，一般都会解决了这些问题。

对于数据采集，还有其他的一些方面，我这里就不多说了。总的来说这是一件非常有挑战的事情，“全”和“细”说起来很简单，从随便的打印到领悟到这一点需要一个过程，从领悟到这一点到真正用好这也是一个过程，需要踩几个坑才行。当然，和专业的数据团队合作，能够少走弯路。

上面我主要介绍了数据采集相关的内容，采集的数据分成三类：客户端数据、服务端日志、数据库数据。对于客户端的数据，我们可以通过SDK实时或不定期上传到服务器上，也就是和服务端日志是类似的。那么就归结为服务端日志和数据库数据两类。我们本篇主要讲解如何将这两类数据传输到数据平台。

我们不建议直接在业务服务器上进行数据分析的工作，避免对正常业务产生影响。对于数据库中的数据表，我们可以导出为文件，然后传输到数据平台，这样避免两者有太强的耦合性。这样，我们就把问题简化为如何将数据文件传输到数据平台了。

在前面的文章中，我介绍过在百度最开始使用单机FTP传输以及通过MapReduce任务进行分布式抓取两个阶段。到了2011年，针对实时消息传输，我们团队开发了一套叫Bigpipe的系统，采用Producer-Consumer模式，源头将消息不断塞进Bigpipe中，下游可以订阅消息，为了保证不丢不重，Bigpipe缓存的数据采用3个副本。那个时候需要日志实时传输的需求越来越多，我们决定用Bigpipe解决实时日志传输的问题。随着从批量抓取到Bigpipe切换的日志越来越多，我们发现Bigpipe占用的机器太多了，而日志传输的可靠性还没有到一条不丢不重的水准。

于是，我们又开发了一套叫Minos的传输系统，在每一台源服务器上启动一个Minos-Agent模块，负责将源端的日志实时的写入到HDFS中，在我2015年4月份离职的时候，整个系统已经承载了超过1.5PB/天的传输量。

这里列一下传输系统的三个关注点：

1，时效性：从最开始的天级延迟，到小时级延迟，再到我离职前的准实时延迟(部分传输是秒级的)，可以说是时效性越来越高。但为了达到更高的时效性，系统的复杂度和资源消耗也更高。在实际决策中，还是要根据需求选择实时还是批量传输。

2，可靠性：理想状态我们期望传输过程是不丢不重的，就像银行中的交易一样。但用于数据分析的数据源，有时候并没有这么高的要求。比如我们记录用户的访问量，1000001和1000000对于分析结论并没有本质的影响。不要盲目的追求高可靠性，要考虑成本。

3，扩展性：传输1GB的数据和100TB的数据，对传输系统的要求是不一样的，传输10个数据源和传输1000个数据源，要求也是不同的。这里要考虑业务场景，来做出决定。

对于传输问题，目前开源领域已经有了一系列比较好的方案，最好是拿现有的来用，而不是重新开发一套。

1，FTP：数据量小且时效性要求不高，用FTP是最省事的。

2，Sqoop：用于传统数据库和Hadoop之间的数据传输。

3，Scribe：Facebook开源的一套日志传输系统，将源日志传输到Hadoop等分布式文件系统中。

4，Flume：Cloudera开源的一套日志传输系统，和Scribe类似。我们在百度做的Minos，可以说是和Flume、Scribe类似，那为啥要重复造轮子主要百度的数据源和服务器太多了，需要做许多功能来满足运维管理的问题。

5，Kafka：Linkedin开源的一套消息传输系统，和百度Bigpipe类似。我们Bigpipe开发了一半的时候，Kafka的论文发表了。Bigpipe会做去重，Kafka目前还没有这样的机制，需要自己去实现。两者都通过副本的机制，保证数据不丢。

传输的问题比较标准，有时候难的不是传本身的问题，而是一个运维问题。我曾经还带着团队开发了一套叫Logagent-Keeper的系统，主要是将一些日志配置和状态信息，存放到服务器中而不是本地，就减少了每个月十几次的半夜三更处理问题的麻烦事。兄弟团队还开发了专门的系统控制网络传输的优先级以及通用压缩，以免整个网络被某些任务占满。我经常看到有些公司自己开发了某个分布式系统，说比开源的或Google的某系统性能上好多少，但分布式系统如果在运维性上做的不好，可以说是没有可用性的。而一些境界还没那么高的工程师，喜欢造新轮子，留着让OP或其他工程师填坑。

吴军在《数学之美》中，有一章讲数学模型的重要性，里面讲了一个有趣的例子。坚持地心说模型的托勒密用40个大圆套小圆描述太阳系几大行星围绕地球运转的规律，即使经过1500年，这种模型也只是偏差了10天。放到今天，我们也很少有人能够解40个圆的方程。后来哥白尼和开普勒坚持日心说模型，开普勒根据他的老师第谷观测的大量数据，发现行星围绕太阳运转轨道是椭圆形的，这样只需要6个椭圆就能描述行星运行规律(那个时候海王星都还没发现)。吴军在最后总结到，一个正确的数学模型应当在形式上简单，大量准确的数据对研发很重要。

(图1 地心说和日心说)

同样，在数据分析领域，如果没有对数据进行很好的建模，分析工作将会变的异常复杂。在三国鼎立一节中，我讲了三种常见的数据分析方法，对于使用友盟这样的第三方统计工具，谈不上数据模型，给用户灵活使用的部分很有限。对于基于原始非结构化文本日志，也谈不上数据模型，连数据Schema都没有，只是拼凑出需求所需的结果而已。而对于业务数据库来说，数据就是实体关系模型(Entity-Relationship Model)了。

(图2 某业务数据表设计)

业务数据表是为了满足正常的高并发、小批量的用户请求而设计的，在设计理念上，减少数据字段冗余，为提升性能不惜拆表分库。一个发展一年以上的业务，都会包含70~80张表，表之间有复杂的外键关联关系。可以说只有DBA同学搞的明白，连偏前端的工程师都搞不懂。如果把业务数据库直接抛给数据分析师去使用，他可能花上3个月时间才搞明白数据表之间的关系，结果你改天又告诉他新加了一个字段，他就直接崩溃了。并且直接试用业务数据库进行数据分析，牵涉到多个表之间的Join，查询逻辑非常复杂，且查询性能比较低。

多维数据模型

在这里，我们要引出本篇的主角——多维数据模型(Multi-Dimensional Model)，又叫数据立方体。数据分析和业务响应是两类不同的需求，更合理的方式是构建独立的数据模型去满足数据分析师的分析需求。这种模型要将复杂的业务逻辑抽象为简洁的数据结构，以易于分析师理解和使用。而经过实践验证，在数据仓库领域比较公认的就是多维数据模型了。我在《在多维数据分析模型的路上越走越远》介绍过我在这一模型上的探索过程。这里先介绍一下基本概念。

(图3 多维数据模型)

数据分为维度(Dimention)和指标(Fact 或 Metric)两个核心元素。如上图中，城市、操作系统就是两个维度，城市这个维度有北京、天津、上海这些取值。销售额、注册用户数、成单量这些是指标，是一个数值。通过上面这个模型，我们就可以得到来自上海的且使用iOS操作系统的用户的销售额是多少，完成对数据的切片。当然，维度可以有很多个，指标也可以有很多个。对于互联网领域的数据，我们一般都能做出类似的抽象。是不是很简单

我们再来看一个具体的场景。在互联网产品中，最重要的有两类数据——业务数据和用户行为数据。对于用户行为数据，我们可以讲用户的每一次操作理解为一个事件(Event)，事件有个类型如提交订单、提出问题等，事件发生时有响应的上下文，如使用的操作系统、浏览器版本等系统属性，也有事件特有的如运费、订单价格等属性，这些属性就是一系列的维度，还有一部分是事件发生的用户ID。即：

Event Type + Properties + UserID

这里就形成了一系列的维度，描述的最细粒度的事件现场。通过UserID，我们还会关联到UserID这一维度的详情(User Profile)，包括姓名、出生日期、身高、是否有小孩等。

有了这些维度，我们可以定义几个指标，如事件数、销售额、运费总额、用户数等。

这样，我们就可以分析来自北京的、年龄20-25之间的、女性用户、最近一个月的销售额是多少。这种业务需求，在互联网公司中，非常常见。我们可以在这个多维数据模型的基础上，进行漏斗转化、用户留存这样的高级需求处理。

对多维数据模型想要更多了解的同学，可以看多维数据模型之父Ralph Kimball的著作《》，书中对多维数据模型有详细的讲解，唯一的缺憾是内容偏向于传统企业的数据仓库建模。

数据ETL/存储

前面是从逻辑层面对数据模型进行了讲解，还要落地到具体实施。这里介绍一个在传统数据仓库理论中的一个基本概念——ETL(Extract-Transform-Load)，即对数据进行抽取、变换和加载。在传统数据仓库中，数据源一般来源于各个业务数据库，经过清洗变换后，再装载到数据仓库中。在互联网领域，数据源更多的来自于日志文件及业务数据库，由于互联网产品迭代更新很快，导致这一环节很难控制，不是那么稳定的，我的建议是尽量在数据源上做好，ETL过程尽量简化，甚至自动化。但还是少不了一些字段转换，如IP地址换成所在城市，将多个数据源通过ID连接合并到一起，甚至通过一些策略将手机、PC的用户行为关联到一起。

在数据存储上，根据数据量的不同和使用场景的不同，可以选择单机文件、关系型数据库、Nosql(HBase、MongoDB等)、HDFS等。为了便于其他系统模块使用这些数据，建议还要有元数据管理，这块我再后面会专门讲解。

前面重点讲解了数据源的采集和中间的建模，对于没有从事过数据工作的人来说，可能无法理解为什么要这么做，不是来了需求，然后写个脚本处理就行了吗

问题驱动

在2006年的时候，我看了一篇文章《》，被其中描述的问题驱动模式所吸引，进而决定要加入百度。许多时候是先有了一堆问题，然后我们尝试用最好的方式去解决问题，当问题解决了，我们也就前行了。在做数据这件事上，最直接的模式就是运营、产品同学提出了一个需求(需求是对问题的抽象和解决方法)，数据工程师就来满足这一要求。每个需求的处理都是单独实现的，久而久之，就会发现有许多需求是有同样的套路的。每次来一个需求，这么做下来效率太低了，有没有可能进行抽象，将公共部分抽象出来，减少重复工作。我在百度所做的第一次抽象，就是前面《盘古开天地》所讲的Log平台，这种模式让需求的处理效率得以极大的提升，但也出现了资源消耗过大的问题。

我把Log平台当时的思路归结为“以计算为中心”，每一个需求的处理，都是一个计算的过程，平台的工作是将需求的开发效率和计算效率提升了。但随着计算资源的无限膨胀，我们发现还要做更深层次的抽象，就是“以数据为中心”，先把数据做好预处理，让计算的规模进一步缩小。

数据驱动

我们来总结一下问题驱动模式：提出需求，工程师响应需求，工程师组织数据源并写程序处理。这种模式第一道瓶颈是工程师，如果需求过多，工程师又少的情况下，就会出现需求处理不及时的问题。第二道瓶颈是数据源，数据源组织不好的情况下，工程师在开发前的数据准备工作太多了。如果是反着来，我们把数据准备好了，又提供强大的工具，需求方自行处理数据分析需求，这种模式是不是更好一些这就是我所一直强调的数据驱动。

有了数据，我们就是怎么用数据了。在2009年做了Log平台之后，我把数据分析分成三个层次，分别是统计、分析、挖掘。统计就是要个数，看个报表。分析牵涉到多维度的深层人工分析。挖掘就是强调机器学习部分了。我还乐观的估计，2009年搞定统计，2010年搞定分析，2011年搞定挖掘。但实际情况是直到现在，第二个层次还没有完全搞定。当然，这种分层也不科学，许多时候是这三者并存的。

查询模式

我把数据查询模式分为三类：K-V查询、OLAP查询、Ad Hoc查询。

K-V(Key-Value)查询就是我们给出一个key，然后返回这个key相关的value内容。比如我们通过一个UserID，返回用户的一些画像信息，比如有没有房。再比如，通过UserID返回最近一段时间的详细访问行为序列。这里推荐使用HBase。

OLAP(Online Analytical Processing)查询就是前面讲的多维数据分析，这里不赘述。可以使用的工具有InfoBright、Vertica、Impala、Redshift等。

Ad Hoc查询就是有各种各样的不确定的需求，需要响应。这块可以用Hive，或者Spark SQL来满足，再不行就写程序自己实现吧。

分析模式

对互联网用户产品，最核心的有两件事情：拉新和留存。通过市场运营活动，吸引新用户来使用产品。然后再通过产品迭代和互动，来提升用户的活跃度。这里有两个比较有效的分析模式：漏斗分析和留存分析。

漏斗分析：其实我一直觉得叫“漏斗”是不准确的。我们实际生活中用的漏斗，最后是全部都会从小口出去的。而用户漏斗，一般是一部分人在某一个环节就流失掉了，不会走到下一步。我其实觉得叫“漏筛”更为贴切，但现在整个领域都已经习惯叫漏斗了，只能入乡随俗。我们在百度和优酷都投放了10万的广告，那我们怎么衡量广告产生的效果呢，比如我们可以看他们引过来的流量里，有多少人注册，这些注册的人里，又有多少人提交了订单。这种时候就很适合用漏斗分析。

(图4 漏斗分析)

留存分析：某天搞了次地推活动，我们很想知道这些注册的用户，后续的购买行为如何。如果发现这些人注册当天领了一下礼品，之后再也没有购买过，那说明这次的地推活动是失败的。这种用户后续的行为分析，就是留存分析。

(图5 留存分析)

在如何用数据这件事上，有各种各样的玩法，我这篇也没办法穷举，只能说是列举了一些常见的方式。

数据被建模好，并提供查询接口，接下来就是可视化与反馈了。这里我先要表达两个观点：

(1)数据可视化并不是界面越华丽酷炫就越好，这里一定要明白可视化的目的，是为了让人更方便的读懂数据。如果界面只为好看，但用户无法捕捉到关键点，那是得不偿失的。当然也不能太丑陋，许多时候这些可视化的内容是要给老板或客户看的，面子上还是要过得去，不能给人一眼就是没做过前端的后端工程师开发的页面的效果。

(2)数据的价值有两点，一点是驱动决策，就是帮着你拍板的，A好还是B好，数据可视化就是起到这一点作用。但这点作用只是发挥了数据很少的价值，我认为只有20%甚至更少的价值，更大的价值在于驱动产品。就是将准备好的数据，再反馈到线上去，让产品更智能。就像百度搜索里，根据用户的点击情况，调整搜索结果的排名。

接下来我们分别看一下可视化与反馈

数据可视化

看这篇文章的人相信都用过Excel，其实Excel的可视化功能做的很强大，各种图表形式应有尽有，许多运营/产品/创始人们，喜欢把统计出来的数据，在Excel里画出漂亮的图表来。但这终究是一件很麻烦的事，我们做数据分析平台，目标是要让这类工作自动化。我问过许多人对数据可视化的要求，他们都表达了要一个Web版的Excel的效果，其实这很不容易的。在Web版的可视化工具里，我认为(需要翻墙)是做的最好的，它里面的图表样式非常丰富，显示风格也很专业，但需要提醒的是付费工具，并且不便宜。我曾经考虑过纯粹在数据可视化方向上创业，但评估后感觉Tableau已经把这件事做到极致了，我怎么做都做不过它，就放弃了。

有两套第三方的可视化库做的比较好，和。HighCharts相对比较古老一些，在世界范围内用的比较广，ECharts是百度少有的开源产品，迭代速度非常快，在国内用的比较广。两个产品都提供了线图、柱状图、饼状图、热力图、地域分布图等常用的图形样式，试用起来很简单，调用Lib库就行。

(图6 HighCharts截图)

(图7 Echarts截图)

(图8 Sensors Analytics的截图)

我在刚进入百度时，每天邮箱里都会收到好几封报表邮件，百度知道产品的一些检索量、提问量、回答量等业务数据，都是以表格的形式展示在邮件正文里，那个时候连曲线图都没有。因为每天都是一封新邮件，每到季度末，产品同学都要手工翻历史邮件，把数字拷贝出来，放到Excel里，然后绘制成报表。后来我们做了Log日志统计平台，用Flex(现在很少有人用了)做了曲线图、柱状图、饼状图的支持，可以在平台上查看历史数据曲线了。对于要不要支持把数据还以报表的形式发到邮件组，我们进行了激烈的讨论。那种过时的方式，又没办法看历史数据曲线，并且许多人都不怎么看报表，放在平台上，可以分析用户的查看情况(用户行为分析，调整统计任务的优先级)，进行灵活的权限控制。但公司内部的员工都已经习惯了报表邮件的方式，在各个团队的强烈要求下，我们妥协了。现在创业做的Sensors Analytics，我们故意又没添加报表邮件的功能，想把这种思路坚持到底。

在Log平台之后，我们在公司内部还用过一段Oracle BIEE做数据可视化。单纯从功能来说，BIEE相当强大，不管只展现样式还是专业度，但是实在太难用了，主要是在数据模型配置和表格配置上，非常不人性化，用了一年就放弃了。数据可视化这样的事情说起来技术含量没那么高，但想做好又非常不容易，需要投入很大的工作量。像我带的数据团队，都是后端研发比较多，几乎没有前端开发资源。幸好内部音乐团队做了一套叫CRM的可视化工具，我们就把展示部分用了它。在我离开百度之前，CRM团队也合并到了我的团队里。

数据反馈

我在08年中的时候做百度知道的问题推荐，就是根据用户的历史访问行为，如检索、浏览、回答记录，给用户推荐可能感兴趣的问题，以提升产品的回答量。所谓兴趣推荐，就是根据用户的历史行为，去给用户训练一个兴趣模型，这个模型就是一个向量，比如<刘德华:5，马尔克斯:3>，这里刘德华和马尔克斯是兴趣词，后面的5和3表示兴趣的权重。有用户提问，就会将用户的问题进行自然语言处理，提取出兴趣词，再将兴趣词和用户模型进行一个匹配度计算，如果超过某个阈值，就推荐给这个用户来回答。当时做这个事情很费劲，内部有个叫后羿的项目，对用户的数据通过CookieID进行了记录，但有些业务线没有，我们就没法用。在这些原始数据的基础上，我们进行了拆解，比如提取出访问的URL对应的页面标题，在基于这些内容训练模型。也就是做了大量的基础数据的准备工作。

正是有了这些基础的用户行为数据，我们才可以在这个基础上做一些高级的事情。出了前面说的搜索结果优化、个性化推荐，还有和客服系统对接、风控等。像滴滴打车根据用户经常上车的位置，推荐等车地点，百度地图根据历史数据，做路面拥堵预测。也就是说，基于用户行为数据，我们能做的事情远远超出了看几张数据分析报表的决策支持。这里就要求我们把基础数据建好，然后结合具体业务，实现数据驱动产品。如果仅仅为了看统计报告，把数据引向第三方平台，公司自身无法对数据进行深度利用，这就太得不偿失了，数据是一项重要资产。

结合前面四篇所讲的内容，我们就形成了数据采集到数据可视化/反馈的一条流。整个架构是这个样子：

(图9 数据平台架构)

这个架构的横着的中间环节，就是前面所讲的内容。还有三个子系统：监控、元数据、调度器。监控是为了保证整个系统的正常运转，分布式系统这块都必不可少。元数据和调度器分别是数据平台的心脏和大脑，我会分别拿出来讲。