我谈谈对大数据分析的理解，这要从什么是大数据讲起。
因为从事这一方向，经常会有人问我什么是大数据？我一直都回答不好。在最近的几个月，我对这一概念思考的更多一些，结合看过的一些书籍（如《大数据时代》、《数学之美》第二版等）和实际的经历，算是有了一些认识，今天我就从大数据的概念开始讲起，试图给大家讲清楚什么是大数据分析。
首先，我来谈谈我对大数据的理解，分为大数据概念和大数据思维。
我把大数据的概念总结为四个字：大、全、细、时。
我们先来看一组数据：
百度每天采集的用户行为数据有1.5PB以上
全国各地级市今天的苹果价格数据有2MB
1998年Google抓取的互联网页面共有47GB（压缩后）
一台风力发电机每天产生的振动数据有50GB
百度每天的行为数据1.5个PB够大吧？我们毫无怀疑这是大数据。但全国各个地级市今天的苹果价格只有2MB大小，是典型的小数据吧？但如果我们基于这个数据，做一个苹果分销的智能调度系统，这就是个牛逼的大数据应用了。Google在刚成立的时候，佩奇和布林下载了整个互联网的页面，在压缩后也就47GB大小，现在一个U盘都能装的下，但Google搜索显然是个大数据的应用。如果再来看一台风机每天的振动数据可能都有50GB，但这个数据只是针对这一台风机的，并不能从覆盖面上，起到多大的作用，这我认为不能叫大数据。
这里就是在强调大，是Big不是Large，我们强调的是抽象意义的大。
我们再来看关于美国大选的三次事件：
2012年Nate Silver通过互联网采集社交、新闻数据，预测大选结果
《文学文摘》所收集的问卷有240万，绝对是够大的，但为什么预测错误了呢？当时《文学文摘》是通过电话调查的，能够装电话的就是一类富人，这类人本身就有不同的政治倾向，调查的结果本身就是偏的。而盖洛普只收集了5万人的意见，但是他采用按照社会人群按照比例抽样，然后汇集总体结果，反而预测正确了。因为这次预测，盖洛普一炮而红，现在成了一个著名的调研公司。当然，后来盖洛普也有预测失败的时候。到了2012年，一个名不见经传的人物Nate Silver通过采集网上的社交、新闻数据，这是他预测的情况和真实的情况：
两者是惊人的接近的。
从这点我是想强调要全量而不是抽样，大数据时代有了更好的数据采集手段，让获取全量数据成为可能。
在2013年9月，百度知道发布了一份《中国十大吃货省市排行榜》，在关于“××能吃吗？”的问题中，宁夏网友最关心“螃蟹能吃吗？”内蒙古、新疆和西藏的人最关心“蘑菇能吃吗？”浙江、广东、福建、四川等地网友问得最多的是“××虫能吃吗？”而江苏以及上海、北京等地则最爱问“××的皮能不能吃？”。下图是全国各地关心的食物：
用户在问什么能吃吗的时候，并不会说“我来自宁夏，我想知道螃蟹能吃吗”，而是会问“螃蟹能吃吗”，但是服务器采集到了用户的IP地址，而通过IP地址就能知道他所在的省份。这就是数据多维度的威力，如果没有IP这个维度，这个分析就不好办了。而现有的采集手段，能够让我们从多个维度获取数据，再进行后续分析的时候，就能对这些维度加以利用，就是“细”。
我们现在对CPI已经不再陌生，是居民消费价格指数（consumer price index）的简称。我们努力工作，起码要跑过CPI。
那你有了解过CPI是怎么统计的吗？这里包括两个阶段，一个是收集商品价格数据，一个是分析并发布数据。我从百度百科上了解到，中国CPI采样500多个市县，采价调查点6.3万个，近4000名采价员，次月中旬发布报告。我还曾找国家统计局的朋友确认了这个事情。
而在美国有一家创业公司叫Premise Data。它通过众包方式，25000个采价员（学生、收银员、司机等），使用手机APP采集数据，每条6~40美分，比美国政府数据提前4~6周发布。
这就是“时”，强调实时收集数据和实时分析数据。当然，在CPI的例子中，我们可以让价格上报更智能一些，不需要人工的方式。
从上面的大、全、细、时四个字，我们就可以对大数据的概念有个较为清晰的认识。这四点主要强调的数据的获取和规模上，和以往传统数据时代的差异。有了这个基础，我们还要看怎么对大数据加以利用。这里就要看看大数据思维。我们也来看两个例子。
85前应该都用过智能ABC，一种古老的输入法，打起来特别慢。到了2002年左右，出了一个叫紫光的输入法，当时我就震惊了。真的输入很快，仿佛你的按键还没按下去，字就已经跳出来了。但渐渐的发现紫光拼音有个问题是许多新的词汇它没有。后来有了搜狗输入法，直接基于搜索的用户搜索记录，去抽取新的词库，准实时的更新用户本地的词库数据，因为有了大量的输入数据，就能直接识别出最可能的组合。
我们以前都用纸质的地图，每年还要买新的，旧的地址可能会过时，看着地图你绝对不知道哪里堵车。但有了百度地图就不一样了，我们上面搜索的地址都是及时更新的，虽然偶尔也会有被带到沟里的情况，但毕竟是少数。可以实时的看到路面堵车情况，并且可以规划防拥堵路线。
我们想想这种做事方式和以前有和不同？
我们发现不是在拍脑袋做决定了，不是通过因果关系或者规则来决定该怎么办了，而是直接通过数据要答案。我们获取的数据越全面，越能消除更多的不确定性。也就是用数据说话，数据驱动。
在百度文化的29条中，我第二认可的一条就是“用数据说话”，数据有时候也会欺骗人，但大部分时候它还是客观冷静的，不带有感情色彩。据说在硅谷用数据说话都是一种很自然的工作习惯，但你放眼望去你周围，你会发现许多没有数据的例子，拍脑袋的，拼嗓门的，拼关系的，拼职位的，这一点都不科学。
那我们再来看看互联网领域的数据驱动。许多公司的情况是这样的：
不管是运营、产品、市场、老板，都通过数据工程师老王获取数据，老王忙的痛不欲生。但数据需求方都对数据获取的速度很不满意，有的等不及，还是决定拍脑袋了。这样极大的阻碍的迭代的速度。
还有的公司情况是这样的：
对老板来说，有个仪表盘还不错，终于知道公司的总体运营情况了，可以基于总体情况做决策了。但如果发现某天的销售额下跌了20%，肯定是要安排下面的人追查的。对于实际干活的运营、产品同学来说，光看一个宏观的指标是不够的，解决不了问题，还要想办法对数据进行多维度的分析，细粒度的下钻，这是仪表盘解决不了的。
那么理想的数据驱动应该是什么样子的？应该是人人都能够自助式（Self-Service）的数据分析，每个业务人员和数据之间，有一个强大的工具，而不是苦逼的老王。或者只是能看到数据的冰山一角。在数据源头上，又可以获取到全面的数据。
我们接下来看看现有的解决方案上，离真正的数据驱动还有多远的距离。
常见的方案有三种：
我们先来看看第三方统计服务，目前国内用的比较多的有三家，友盟、百度统计和TalkingData，他们都类似Google Analytics（简称GA，谷歌分析）。
这些工具的优势是使用简单，并且免费。
是有以下几点：
数据源：只能覆盖前端JS/APP SDK记录的数据，无法覆盖服务
端和业务数据库的数据；
分析能力：只能覆盖宏观通用分析，使用后还需要数据团队满足
运营/产品的各类定制化的需求；
第二种是使用数据库写SQL，这种在创业公司用的比较多：
