从日志统计到大数据分析（六）——三国鼎立

根据数据源的流向不同，我们可以将互联网公司常用的数据分析方法分为三种：

1，通过嵌入SDK直接将数据发送到第三方平台，如使用友盟、百度统计、TalkingData等；
2，直接基于业务数据库，通过写SQL的方式进行数据分析；
3，在应用服务器端打印日志，基于日志写脚本进行分析，在百度的早期主要是这一种。

我们这篇文章逐一来分析这三种方法的优势和不足。

1 第三方统计服务

目前在国内使用比较多的第三方统计服务有友盟、百度统计、TalkingData、CNZZ、Google Analytics等。其中友盟是，CNZZ是。百度统计、CNZZ都是传统Web网站统计发展而来的，而友盟、TalkingData侧重于移动APP统计。Google Analytics（GA）可以说是这一类的访问量统计服务中最好的，其他四家多多少少都借鉴了GA。但GA因为墙的原因，在国内访问并不是很方便。我把这些第三方统计服务称为类GA的产品。关于2007年之前的国内统计产品的发展，推荐看caoz写的《中国互联网网站统计史》，而2007年之后的，就推荐你现在看的这个系列了^_^。

首先，类GA统计产品的优点是简单易用且免费，只要在网站或APP上嵌入一段SDK代码，就能采集到网站的访问情况了。GA本身在量大的时候是要收费的，否则只是提供抽样的统计，当然，对于一些流量型的网站（如门户、新闻媒体等），有个抽样其实也够了，并不需要精确的数据。这些产品能够提供网站/APP总体的访问量、用户数、分地域的访问量等，基本的用户转化、留存等信息。

（图1 Google Analytics截图）

不足之处我认为有四点：

一是数据源上，只能通过JS或APP SDK覆盖客户端的数据收集，但服务器和数据库的数据无法采集到，比如商品的库存信息，这样在数据源上就不够全。我在百度这几年的数据处理心得是，要想把这件事做好，最重要的就是数据源。数据源整好了，后面的事情都好办，数据源要尽量整的全和细。否则你会发现有一半以上的数据分析需求是在这些产品上支持不了的。

二是分析能力上，因为是标准的SaaS，只能提供一些宏观基础的统计分析，一些深度的数据分析是做不到的。如来自北京的年龄到20-25之间的女性用户，最近一个月有十次购买行为，我想分析她们的客单价情况（这个例子在GA上使用一些技巧能够实现）。即使是活跃用户数的定义，可能也是仅基于启动APP的情况。对于一个电商产品来说，可能定义活跃是指购买了超过10元产品的，这在这些产品上无法自定义的。

三是数据安全上，稍大一点规模的公司，不愿意把自己的核心数据放在第三方平台上。特别是和交易钱挂钩的，公司不会愿意放到一个第三方平台上，放在百度统计等于告诉了百度，放在友盟等于告诉了阿里，在中国这种缺乏信任的生态环境下，这种顾虑是很难消除的。

四是数据无法取回。本来这些数据是你的产品产生的，结果传到第三方服务平台后，反而不归自己了，甚至有的公司都不提供数据获取的接口。即使有的公司提供数据导出的接口，但也是以收费的方式。如果你想在这些数据基础上进行二次开发，现在还没有很好的方案。

你可能会有疑问这些公司为什么不把分析能力设计的更加强大一些，我们要从商业模式来看。这类产品通过提供免费的服务，来获取到用户的数据，通过这些数据再进行精准广告或其他方式的变现，这种商业模式决定了他们的出发点，并不是以提供最好的数据工具帮助客户提升价值的。

2 业务数据库写SQL

现在创业公司的产品一般都是LAMP架构，给客户用的是web网页、手机H5页面、IOS/Android APP，在服务端一般通过Linux、Apache/Nginx、MySQL、PHP来搭建，这种模式开发效率高。用户的一些交易、更新行为，都通过MySQL来记录。那么，我们可以通过直接写SQL的方式，从业务数据库中导出数据，然后存放到Excel中或者Tableau、Echarts这样的工具中，进行图形展示。

（图2 业务数据库写SQL）

这种方式相比使用类GA的工具，一个明显的好处是可以分析业务数据（本来就在数据库里放着），数据本身又是准确、实时的。在分析能力上，不受制于GA这些工具本身，SQL的表达能力是很强大的，可以根据需求灵活定制。SQL本身写起来又比较简单直接，所以这种方式比较受欢迎。

当然，不足之处也是比较多的。

首先，我们要弄清楚业务数据库和数据仓库这两个概念。对于数据规模较小的情况下，业务数据库和数据仓库都能通过MySQL/Oracle这样的软件来管理，那么两者是不是等价的？是不是业务数据库就能当成数据仓库来使用？这里我们要看看两者分别是干嘛的。业务数据库是要处理高并发、小批量的请求，一般是对单条数据的增删改查。而数据仓库是用于数据分析的，它是处理小并发、大批量的请求，比如最近一年满足某些筛选条件的数据，但是查询的频次不高。那么在数据存储上，两者就有了本质区别，我们可以用人类进化的一张图来表示。

（图3 业务数据库与数据仓库在存储的内容上的区别）

业务数据库存放的内容就是一个横切面，只记录了现代人的当前状态。而数据仓库记录了古猿到现在人的所有中间状态。理想情况下，我们可以通过数据仓库恢复到业务数据库任一时刻的状态。如果你非要把业务数据库当作数据仓库来使用，那么就带来了这么一些列的问题。

一是许多数据是没有的。比如一个标记用户婚恋状态的属性从未婚到已婚再到未婚，业务数据库只有当前的未婚状态，不能分析状态的变化。比如我想分析不同浏览器版本的用户转化率如何，研发工程师发现开始在数据表设计时根本就没有浏览器版本这个字段。只能变更数据表结构，升级系统。

二是无法与业务数据解耦。为了查询性能或者业务需求对数据库表结构进行了变更，那么之前写的SQL都要改写，否则就会出错。这种维护代价很大。

三是计算能力有限，无法水平扩展。如果单台MySQL能够cover所有业务数据库，那么还好说。但如果业务的增长导致了分库，那么直接写SQL就搞不定了，还要把多台机器的结果再用脚本串到一起去，这就不轻松了。

四是管理SQL、脚本、中间数据、数据可视化的开发，也是一条数据流，维护起来代价不小。

最好的方式还是业务数据库和数据仓库各干各的事。

3 基于日志写统计脚本

日志（log）最初的起源是为了监控系统的运行状态，每次变化都在文件中做一条记录。但逐渐被用来分析有价值的用户行为。并将用于Debug的日志和用户行为分析的两者分离开来。我在前面的章节中，都是在讲解我在百度基于日志进行数据分析的经历。在2008年的时候，就是直接采用这种模式。这种模式以前在BAT这样的公司用的比较多，开始用Perl写，后来用Python更多一些。最开始是通过脚本生成的统计结果直接用Email发送给业务人员，后来演变成将数据插入MySQL，然后用报表展示工具进行可视化。

这种方式最大的好处是和业务数据库解耦了。单独引出一条流来，用于数据分析。即使任务写错了，运行挂了，都不影响正常的业务。业务的变更只要做好日志的变更，就井水不犯河水。

不足之处有以下几点。

一是开发效率比较低，一般是找一个现成的脚本，修改一下，部署到线上，可能一两天就过去了。

二是数据准确性无法保证。这种脚本没有人去Code Review。没有人进行数据Diff，如果是偏差100%以上，那谁都能看出来错了，但是如果只是错误的统计了5%呢？你本来都不知道准确结果是多少，更无法判断是不是准确的了。

三是计算能力有限。如果是单机跑任务，几百GB的原始数据进行排序等操作，可能需要几个小时。当然在Hadoop这样的集群上，就没这个问题了。

四是这本身是件很有门槛的事。打好日志很难，该打印哪些字段以及怎么打，这是需要经验的。管理日志源、脚本、数据可视化，在依赖关系复杂的情况下，不是用crontab能轻松管理好的。

那更好的方案会是什么？我认为是在这已有的三种方案中进行结合改造。下一篇我会介绍将大数据的理念和这些方案结合所带来的效果，也就是我前面提到的数据流的思路。