计算与Plumbing Work

价值

大数据或者计算自身并没有任何价值。数据通过影响最终决策产生价值。最初期所谓大数据或者BI的解决方案通过提供各种漂亮的报表给经营人员，让老板做出更好的决策。

• 源数据 => 结构化建模的数据 => 图表 => 老板决策

另外一种形式的决策是，机器做一些简单的判断，由人工做出最终的动作。这种类型的最常见的是监控告警的应用。

• 源数据 => 统计 => 比对阈值设置 => 告警给人工处理

更复杂的一些告警需要根据历史数据来做出决策，就变成了

• 源数据 => 历史数据挖掘 => 推断出每个时刻正常波动幅度的上下界
• 源数据 => 统计 => 比对根据历史值算出来的上下界 => 告警给人工处理

再后来，就有了各种智能算法，大概的形式都类似于

• 源数据 => 用样本数据训练模型 => 模型
• 源数据 => 无样本自动挖掘模式 => 人工修正得出模型
• 源数据 => 利用模型实时分类，预测，推荐

一开始人们把数据加工成图表，为了让人工可以容易地解读消化，从而产生出有价值的决策。到了今天，人们把数据用机器学习加工成人类已经无法解读的（interpret）的模型，为了让机器更容易地消化模型实时进行准确的决策。在高端客户的销售中，销售代表的平板电脑里可能有这个目标客户的所有背景资料，然后人工去判断决定如何一对一销售。在京东商城的系统里，同样有每一个正在浏览网页的客户的背景资料，只是如何一对一销售变成了一个机器来干的活。机器通过算法决策出给不同的客户以不同的策略销售不同的东西。过去产生推荐商品的决策是机器辅助人工来做的，而今天则变成了人工预先辅助机器（训练），再由机器来实时完成。显然，今天数据能产生的价值，比过去只能给老板展示几个图表要想象空间大得多。

一切皆计算

所谓决策，也可以理解为一种计算。你的输入是所有的背景知识，决策的过程就是把这个背景知识结合手上的问题，计算出一个最优的结果，比如我们大脑皮层收到数亿个像素的图像，然后实时决策是往左走还是往右走。这个过程也可以理解为某种压缩，或者信息提取。从原始的数GB/s的数据提取自视网膜，到经过神经元层层感知之后，压缩成非常小信息量的道路的拓扑结构，到最终决策出几个字节的肌肉信号。

大数据 => 小数据 => 决策

数据量一级一级变小，每浓缩一级就是做一级计算。举另外一个BI的例子。原始的数据可能是服务器打的文本日志，经过模式匹配提取出关键字段，一级级汇总到数据库里变成记录。再经过转换把一批历史记录变成一个json的http请求返回，再由html页面翻译成svg图形。svg图形经由浏览器和显卡变成像素，而像素最后经过光传递到你的视网膜里，感应到大脑皮层得出智慧。最终人脑感应到可能是这样的一个图像

形成的一个概念是这个图里有两坨，数据量只有几个byte。但是每个像素点背后可能都是由海量的数据汇聚而来的。这种把原始数据“压缩”成抽象的意识感知的能力，就是智慧。机器还无法做到通用的智慧，但是在特定问题域下，专用的智慧已经可以超越人类了。

计算与Plumbing Work

计算有三种：
- 为了图表的计算：计算的最终目的是漂亮的图表给人工解读。一般计算逻辑都非常简单，只是简单的“统计”。
- 模型训练：计算的目的是让计算机理解历史数据，建立模型。计算逻辑非常复杂。
- 实时模型使用：计算的目的是使用之前建立的模型，实时做出决策。比如是否买卖一只股票，或者显示哪个推荐商品。决策逻辑可能很简单，也可能很复杂。

大数据计算的问题在于其问题规模超过人普通工具（比如excel）处理的规模，使得人们忙于发明各种各样的工具，以及学习如何使用这些花哨的工具，而不是解决问题。storm已经不再时髦了，那就换spark，同时再考察考察flink或者samza。
带着大数据的标题下的另外一个问题是复杂算法引入带来的分工问题。其实复杂算法和大数据是两个问题。很多用到模型训练的场景并没有什么海量数据的问题，只是计算量超过了单机而已。常见的两个title，data engineer, data scientist。所谓data engineer就是那些发明spark和使用spark框架的人，他们负责搞定计算机。所谓data scientist就是那些发明算法和使用算法的人，他们负责应用数学解决业务问题。

让一个数据团队低效工作的最佳办法就是让他们一周学一个框架，一周换一个数据库。各种不同实现的不同api细节可以消耗掉你所有的热情。无论是spark还是flink，这些工具都是 plumbing work。使用的工具越多，所需要做的 plumbing work 就越多。反复地用不同框架实现类似的功能是没有任何意义的事情。
第二点就是工具都自称是万能的，但是使用者需要警惕。R是很好的数据工具，但是开始琢磨怎么用R做分布式并发网页抓取就需要警惕了。Java是很好的工具，但是Java要到猴年马月才能达到和python/R 那样的api便利程度（随便一个数学模型都有好几个高质量的library实现）。虽然Java/Spark在竭力模仿Data scientist的工具栈（比如新的data frame api），但是目前看来科学家们还是更喜欢matlab/R/python，而且没有理由不让他们继续使用这些高效的工具。
第三点就是避免不同角色之间重复彼此的工作，以及因为角色之间传递工件引入损耗。data scientist用python pandas numpy做模型计算，data enginneer 如何在java storm里实时地使用这些模型？同样的数据清洗工作，data engineer可能已经有工具可以做了，而且做得很好，data scientist们是不是有必要重复地去完成已经被解决过的问题，仅仅因为跨角色沟通成本比较高？

在当下这个时代，每个从业者都希望给自己的简历加上一些spark这样的框架使用经验从而给自己镀金。有更多的其实只是用过几次hbase api，的所谓领域大牛。各种一流的团队忙着给别人造轮子，各种二流的团队忙着把开源的轮子改成自研的轮子，各种三流的团队忙着学习前两个团队搞出来的轮子。到底有多少人只是在做 plumbing work显得很忙，而到底又有多少真正有意思，有商业价值的问题给这么多的从业团队来解决？

当你把一个问题的答案提交给问题提出者的时候，有多少时候得到的是 oh, that is nice 的回应。而又有多少次你挠破头皮搞出的模型真正换来了真金白银的？