数据工程(1)：你不需要的大数据

大数据火起来之后，推大数据几乎成为了政治正确，不管什么项目都要把大数据的架构搭建起来，再利用数据分析来做出正确的产品决策。政治正确的意思就是太对了，一点毛病都没有，但是实践起来不是这么一回事，或者要付出巨大的代价。

这里不谈那些把一张Excel表格当大数据的，对于大部分10M

DAU的应用来说，平均每个用户100个行为记录，加上必要信息，每天日志不会超过1TB的数据量，以龟速10MBPS的处理速度，也不过一整天的运算时间，这应该算应不应该加上大数据架构的一个临界点了。如果对于一个快速增长的产品来说，早做准备把大数据架构搭建起来总是没有错的。

但事情的真相没那么简单

首先每天写满一个硬盘的日志真的带来了应有的价值吗？

一般数据处理会产生一些时间切片的数据，一般是某个衡量对象的量，包括用户总量，活跃用户量，发帖数，添加朋友数，阅读时间等指标 ，然后根据用户性别、年龄、地区进行进一步细分。但这些似乎并不需要从海量的日志中去获得，产品数据库里已经有了更加完整的信息。

数据处理还会进行一些时序有关的分析，比如用户在做了动作A之后会做什么。有多少用户在注册第X步的时候退出了。这当然是有用的，但是你上一次看这个数据是多久之前呢？而一次性的对当天日志进行分析，无论技术难度还是时间还是成本都会低非常多。

此外数据处理会提供一些性能的数据，比如多久载入页面，上传头像成功率多少，但很难讲这个信息真的能价值一块硬盘，如果真的重要的性能数据，恐怕每天分析一次是不太够的。

当然，永远可以有这样的反驳：“多存点东西总归是好的，万一哪天用得到呢？”

对此我会亮出奥卡姆剃刀：如非必要，勿增实体。

具体到这个问题就是：现在用不到的就是没必要有的，以后用到了以后再加也来得及，而如果是临时的数据就让它用完就扔。

举个例子，有一天知乎的产品经理想要看看每个用户平均换几次头像，然后根据这个数据来提供产品决策怎么提高换头像的用户体验。所以他要求一个码农把这个数字拿出来，由于记录一个按钮的点击很容易，所以之前就有了，码农写了一个SQL把数据给产品经理看。很显然，不死心的产品经理会提出一个新的要求，比如换头像多的用户和换头像少的用户的活跃性相关分析，这就不是一个简单的SQL能够解决的了。这个故事告诉我们，即便你现在想的很完美，把各种需求都考虑到的日志记录，也是不能满足真实环境中的数据分析需求的。

而知乎可能会很关注每篇文章阅读时间这样的数据，在早期的时候这个日志很可能没有记录过，而随着构架的改变，这个日志记录方式也可能会发生变化，但是这个当需要的时候再收集并没有任何问题，可能延误一两周甚至一两个月的时间，但之前已经延误了一两年时间也没有任何问题。

其次真的有必要上Hadoop之类的计算方式吗？

且不提有人用Hadoop来数总共有多少用户这种事情，大数据计算框架的本质在于用大量的计算能力来解决以前用统计方法来解决的问题。

再也不用Bootstrap这样的统计方式来计算了，直接全部数一遍就可以了。看上去真的很美好，但是也真的很贵啊。除了搭建大数据计算的人力，机器的运维，数据的处理和分析，都引入了大量的人力。而你得到的是，更精确的数据，根据你数据分布和统计对象的不同，大概比抽样5%的精确度高10-20%吧。

如果是计算用户数量这样的数据，由于用户ID本身是均匀分布的，所以抽样统计的结果可能相差无几。对于用户阅读时间这样非常差异的分布，误差可能会大一些。但这种误差并没有让你获得更错误的数据，比如你希望知道的是用户在A设计中阅读时间和B设计中阅读时间的比较，而不是在这个设计中具体需要多少秒时间。如果真的需要这么精确的程度，更改产品需求其实是更加合适的选择，而不是大数据框架就能够解决的问题。

因为一个残酷的事实是，即便日志里的时间戳，都有5%是完全不精确的。比如最简单的问题，很多用户晚上11点半开始阅读，读到12点半熄灯睡觉，这一段是算昨天的还是今天的。当然这个可以把时间分割到凌晨两点或者三点来一定程度避免，但如果你的应用是全球市场的，那么这个问题就继续产生了。

如果是一个手机应用，那么就更惨烈了，由于网络的问题，可能客户端收集的数据和上传的时间相差了非常久。更不用提因为客户端代码没写好，处理上传失败或者重复上传的情况不正确，上传的时间戳不正确等等。

所以精确度不高是系统性的，不是说单纯在处理数据的部分提高一下就能够完善解决的。更重要的是，你根本不需要这个精确度。

最后你真的需要需要专门的数据处理团队和机器吗？

首先这个真的很贵，贵的不是人力，是每个人本心的持续增长的需要。雇来的不是数据处理团队，而是更加复杂的办公室政治。

因为有了数据处理团队，所以大家默认他们是数据分析团队，本来自己随手可以写的SQL也不写了，甚至于收集数据也不管了。但是由于要做产品决定，所以数据处理团队就变成了数据分析团队。这给数据处理团队带了非常多不能产生效益但是很繁琐的日常工作，而他们并不能从产品成功里分享到成果。

由于数据处理团队站在数据处理的立场上，为了证明自己的价值，会做出更加复杂的数据处理系统，这些并没有让公司变得更有效，也没有对产品产生任何直接的作用，但是却需要更多的人手来保持系统的正确运作，解决更多来自产品部门的需要，以及建立更加复杂的系统和实验。

而这种架构应该是低效的，因为数据处理团队并不清楚产品的逻辑，写的数据收集的逻辑最后还是需要产品团队来验证。即便是简单的数据分析，也可能因为产品越来越复杂而必须要产品团队来验证，比如统计一个用户多久修改一次主页，可能就包含点开主页的记录和点击修改，以及点击保存的记录。在早期但仍然有50%占有率的应用版本上，点开主页就是修改；在最新的但是40%占有率的应用版本上，需要点击修改并保存才算。

如果一个资源是免费但有限的时候，大家会倾向于更加大量的索取。比如让数据团队给个数据这个行为对于产品团队来说是免费的，但是由于数据团队人少，所以可能要等很久甚至得不到回复，那么逮到机会就不管需不需要都会让他们统统给你。

如果一个任务对于自己是得不到提升的，或者没有好处的，那么倾向于不做或者捣浆糊。比如数据分析这种事情，如果自己出报告，预见性的提出了什么什么，可能还对升职有点帮助；但如果是为了回答别人问题而做的分析，可能过一个月问你的人自己都不记得有这回事了。

而只有这个事情对自己是必要的，才会用最合适的资源和最积极的态度去完成。比如让产品团队自己去做数据分析，他们就会知道什么问题是该问的，什么问题是没必要问的，也会知道拿一个数字需要怎样的过程，这个学习经验应该是一次性的，而成本也是最低的。

所以该怎么办？

一般中小型的应用可能并不需要一个专职的做数据处理的工程师，一个框架搭好之后，可以用非常久。只需要让所有人都能够非常容易往里面加记录，进行分析就可以了。

我觉得在100M用户之前永远有绕开大数据的解决方案。

当然如果分析数据带来的价值远高于多雇佣5%的工程师，一个良好的大数据架构成本是值得付出的。

至于连SQL都不愿意学的产品经理，我就不知道你为什么还要留着他了。