作为网络老砖家（自封），唐老师本对大数据是一窍不通，在看完一系列《大数据从入门到放弃》丛书后，顿悟了一丢丢，跟大家分享下学习心得。

1       现有大数据资料仍有不足

    当前网上的大数据资料一大把，但是对小白真的不友好。基本都是一上来就给你说怎么统计一个文本文件里面不同单词的出现次数（经典的wordcount）。我一个Go语言老砖家（再次自封）就纳闷了，单词统计不就我HelloWorld函数稍微润色下就可以做的事么。。

                        所以让唐老师来给你讲个听得懂的故事~

2       挑一个现实中的故事

假设我们要造鞋子：拿些原材料，加上几道工序：粘鞋底，粘鞋面，穿鞋带等。

这么一件事情，你一个人就可以搞定。

对应现实生活中，就是假设你拥有一个网站。现在每天有人来你网站购物，然后，你在第二天得统计：前一天，各个牌子的手机销量；以及哪些牌子最热门。

这里原材料就是：所有的订单记录 + 实际销售记录 + 浏览记录 + 搜索记录 这些日志，或者数据库记录等。

操作员（你的程序）干的活就是：各种统计方法。比如统计产品热度时，搜索+1分，浏览+3分，下单+6分，买单+10分。

然后每天，操作员干的活就是：处理这些原材料，并给出最终结果。

好了，让我们回到制鞋这件事情上来。

3       为什么工厂需要流水线？

然后某一天，突然来了一笔鞋子订单，量稍微大了点，限时一天交货：那么你的制鞋师傅怎么办？显然，想到的就是让制鞋的人提升性能呗。于是：

（A）     换个手脚快的员工，（什么用Go语言重写，替换原来的Java啦）

（B）      换些麻利的工具，（更换新的高性能主机啊）

（C）      优化制鞋流程，（App性能提升优化专项小组啦）

程序猿们忙的不亦乐乎~

然后，你老板的生意太好了，供不应求，都开始抢购了。于是某一天，老板把巨量的原材料“哗啦啦”的倒给你，让你一天后交货。并且告诉你，以后每天都需要生产这么大的量。

首先明确的是，你的程序，哦不，你家制鞋师傅，除非手速超频到光速，不然一天内，无论如何都处理不了这么多原材料。

所以你的选择只有：招更多的人组队干活。

4       分工是提升效率的关键

如何组队也是门学问，是单纯员工复制堆人头，还是上分工式的流水线呢？

嗯，《国富论》说分工是提升效率的关键，所以流水线赢一分。事实上，堆人头复制的话，对全局信息的处理也不好。比如一批鞋子全部完成后，老板问你，40码的总共有几双？你就只能干瞪眼。

分工协作 + 流水线，是现代大型工厂的特色。所以上这种，不会错的。

5       大规模制鞋开动

分工协作确定好后，流水线就可以开动了。大批量的材料就可以快速的被加工处理。

至于流水线里面的什么Map啊，Reduce之类的东西，基本就是你手里做完后怎么分配给下一道工序的问题，如：

上一道工序（a）做完，下一道工序（b）有好多人等着，你就得分一分发给他们。

或者好几道工序（a）（b）都做完，才汇总到工序（c）那里处理。

6       大数据划重点：取上游半成品

批量式处理嘛，每个工人只做自己的工序，做完后，是先放到自己的小篮筐里面的。等集满一筐了，再传给下一个环节去继续处理的。

所以下一道工序的工人，想要干活，得去上一拨工人的篮筐里面取过来。

敲黑板： 自取，也就“拿半成品”这件事可讲究了。

啊，这个篮筐呢，放的近，前后两个人拿取都很方便，那整个工人流水线效率就很高。

这个篮筐呢，放的远；或者存取不方便呢，整个流水进度就受影响。

注意啊，前后2个环节可能不止一个人的哦。

这个就是大数据里面所谓的 Shuffle 过程，“取上一步的半成品” 这个动作非常影响整体效率。造某些工序比较多的高端鞋子，shuffle会很多，有时候可以占到整个流程的2/3时间。也就是大家基本都在搬半成品，真正干活的时间很少。

7       原材料仓库vs半成品篮筐

所以，现在整个制鞋工厂基本清楚了：

仓库（原材料）---》工人流水线（干活）---》仓库（成品）。

那这里，我们其实不关心仓库长什么样。什么HDFS牌仓库啦，还是对象存储S3牌子仓库，都可以。然后，原材料仓库，和制成品仓库想不一样？当然也可以啊。

这里注意：仓库和篮筐的区别。

即：每道工序做完，都得从仓库中转一次。这样效率肯定比较低。就近放一个小篮筐，前后2个人都能够得到，效率就会快很多，对吧。

这就是为什么大数据一定要用【高速本地存储】的原因。当然，你也可以把半成品往远端的仓库放，这样整个制鞋过程照样能运转，只是整体进度变慢了而已。

8      那Spark和Flink在干啥咧？

上面那个【中转篮筐】，就是Spark的特色。批量处理嘛，非得等一小波原材料处理完，攒一攒满一筐了，然后再一筐一筐的往后传递，给下一个工人。你想，比较原始的工作作坊是不是这样子的？三大姑家做完鞋底，送到四大妈家继续做鞋面。

那有没有更高效的方式呢？当然有了，那就是【真.流水式】生产线。一道工序干完，马上放入传输带，传给下一个人。中间不需要篮筐来中转。

一想到现代化的高科技自动流水线都长这样，所以感觉【真.流水式】就比Spark那种作坊式高级一丢丢。因为脱离的对本地高速篮筐的强依赖，只要工人够快够多，再多原材料都分分钟在流水线上处理干干净净。

而且，生产线扩容也方便，哪个环节慢了，加大这个环节的员工数量就行。上一环节往后面送货的时候，考虑分发得均匀些就成。这个大概就是为什么 Flink 比较香的原因吧。

9      当前大数据工厂的问题

作为一个高端的流水线工厂，应该对操作工人没有太多要求才对。按理来说，找个人往工位上一插，他就负责完成该环节的任务就完了，管他自己长得高矮胖瘦呢。

嗯，然而现在的Spark工厂和Flink工厂，还是不够先进。因为它们挑人，不姓Java的员工，都不一定能把材料送你手上。你要是敢姓Go，那工厂都别想进了。

也许流水线工位上面怎么拧螺丝，这个动作，还没有标准化定义吧。

10  关键术语翻译

大数据框架（比如Spark，和Flink）是自动化流水线，但是怎么操作材料还得老板重新设计。这也就是为什么要还写Spark应用/Flink应用的原因。你得定义原材料怎么操作呀，Flink框架只是负责【传输带】和【流水线工位】管理这些工厂层面的事情，比如很方便的扩展出新的工位。

反压，很好理解。你下一环节那个工人说，他忙不过来了，需要给他那个环节加派人手。所以每个环节都可以扩缩容，这也是一个流水线工厂应该具备的功能。

Plan执行计划，额，这个就好比工厂流水线设计图了。所以你看Flink代码，不管前面怎么写，只有最后调用execute函数，才是丢到工厂里面去开动~

可靠性。像Spark这种，只要上一步的篮筐里面有东西，那么上一位员工离开上个厕所都无所谓啦（毕竟你取货还是能取到）。像Flink这种，如果员工挂了，就得把累积未处理的材料，给新来的员工重新发一遍。

11  结语

一点学习心得，不足之处多多指正。毕竟网络老砖家嘛 ~