节假日最适合做的事，是从日常事务里跳出来，尝试做一些抽象思考，例如说，纷繁复杂的互联网数据工作，大体是怎样一个架构，通俗地说，也就是内部结构和具体工作分布。
作为类比，先看看已经被布道好多年的，相对成熟的互联网产品流程：
需求产生的环节在业务，比如财务、市场，包括内外部；
需求翻译到用例的环节是售前，产品，测试；
用例进入开发流程以后，对产品流程来说进入一个黑盒，围绕实现，辅助职能分布在进度控制，性能优化，基础运维，需大概了解；
需求实现以后，逆向走开发-测试-产品-业务去核验和优化，循环这个过程，形成工作流。
互联网数据工作流也可以这样分，如下图。概括一下职能分布，1是技术，2是业务模式，3是商业智能，4是学术。
1的环节是外部爬虫和内部埋点
表面上看，这是一个”上帝说，要有光，于是就有了光“的业务步骤，实际这是一个纯粹技术的领域，例如爬虫的资源调度，埋点的性能平衡，后台海量存储等等。
（创业公司基本都用第三方，因为自己做太奢侈了，有理想/有机会的大司CTO都会自己搭，很锻炼团队，同时大团队会有人出去创业，形成技术溢出，福泽没有能力的中小网站。）
为了方便表达，插一个例子，假如我们用温度计测水温，温度计本身是凉的，那么测出的水温就可能偏低一丁点（量子力学里更有所谓，看一眼，用来观察的粒子影响被观察粒子，状态就变化的测不准原理。）
与此类似，互联网数据最好玩的地方是，为了通过数据观察一个应用的各方面表现，取数方法本身也是一个应用，因此如上所述的”观察方法对观察结果的干扰“就特别大。
我们经常听到互联网数据讲座里，花n小时说ga的老版本js和新版本ua有什么不同，或者各种tag manage工具的数据对接坑，做互联网数据的人对此是习以为常的，你可以完全不知道如何写代码，但你必须知道一堆的同步异步，cookie、uuid的术语。
具有讽刺意味的是，步骤1里的工程师往往不知道提数据需求的人到底想做什么（有时候是真的没人知道，埋着当买保险），他们接下去会在没有使命感的情况下，烦恼性能和如何在混乱的版本合并里保持一切井井有条，而没有使命感，对于代码质量经常有致命的负面影响。（因为代码质量无法用传统方法qa，纯靠良知操守和使命感）
小结一下，1的环节是纯粹技术的、门槛很高的环节（索性有大量现成第三方，这也是为什么说现在数据的时代来临了，之前很痛苦），所有非技术的、要用到数据的同学都必须有1的基本知识，在下一步的数据清洗，异常识别和指标排障里有很大用处。
2的环节是把源数据洗干净，变成可以看的指标
按道理2是技术环节（比如cookie传值和uv的对应规则），但是因为互联网广告的高度发达（都是烧钱烧太多搞出来的），这方面已经有很成熟的用来解释和优化烧钱的数据指标体系，实际上2已经是纯业务的环节。（例如，由于pv、uv、visit过于有知名度，很多人会忘记这些也只是一些自定义指标而已。）
这个步骤往往由业务部门的分析师进行，主要工作概括起来，是使常人能够理解数据，将原始日志/数据集，翻译成一些比如转化率，比如独立访客带来的收入之类直观的数字，进而形成一些简单报表，基于对这些报表的使用，来支持拍脑袋（也叫决策）。
在水平较成熟的团队里，会看到大量自定义指标，这些指标的建立原则很简单，针对kpi，或者更时髦的okr（模糊版的kpi），比如视频来说，基本的访问量和播放量之外，可以有播放中拉条快进的比例（不要想歪）之类，来细致考察用户感兴趣的程度。
这个”解释和使用数据“的环节，是市面上绝大多数所谓做数据的人的日常工作（比如广告公司，比如传统公司市场部、信息部、电商部，第三方运营等等），虽然门槛很低，但由于大部分企业现在数据意识刚刚觉醒，需求大的惊人，完全供不应求。
3的环节开始小众，是所谓用大数据解决实际问题
还是举例，比如一个OTA经过1和2的步骤，有了客人预订各区域酒店的数据，有了订单量流量转化率，也有自己的成本，有该区域的资源分布情况，以及爬虫获取的对手的大致资源情况-无非是价格啊库存啊覆盖啊，或许还有点评之类。
那我们要解决问题，比如我希望将市场区域分成咨询公司常说的各种动物的分类，不同分类对应不同竞争阶段（或动物），不同阶段有不同增长预期，同时可以辅助各渠道预算分配，和2不同的是，2只要有个报表参考，3可以给出基于一定概率的结果。
3的环节是商业智能BI出场的时候（遗憾的是大部分BI还在2的世界里，甚至1的世界里）。
这里主要的任务和1很像，克服性能瓶颈。只不过不是爬虫和埋点的性能，我们这次并不会爬的竞争对手网站瘫痪，或者搞得用户在app点击下一步的时候为了传输他选的增值产品而卡死在中间，这次可能卡死的是后续的分析模型，为了能反复迭代，必须在进入挖掘之前，找出少数主要特征。
传统经验模式，讲究靠老师傅从几千个可能出问题的地方指出最可能的几个，数据规约就是通过对几千个指标的相似度/信息量/不确定性的计算，来将这类老师傅经验变成一个可复用的函数。
举例子来说，如果研究肥胖，有四个数据，一是每天吃几顿饭，二是每顿吃几碗，三是每天摄入的卡路里量，四是每天运动消耗卡路里量。老师傅会说，你傻啊，前三个可以合并一个，而数据规约是通过指标选择算法（比如lasso）给重复指标打很大的惩罚分，也可以得到前三个指标只需留一个的结论。
3的世界是反反复复和业务方（2的人们）聊需求到底是什么，目标是翻译成数学语言；同时反反复复和数据来源方（1的人们）聊异常值，目标是理性对待奇怪的看似是误差的数据，不要为了预测而预测（过度拟合和拟合不足）。
在充分了解的基础上，下面就可以把数据往聚合分类、多阶（说人话，比如斜率）等各种复合方向，套业务需求形成二次计算过的专门指标，尽可能减少数据维数（好吧用人话来说，就是列数），只留下最关键的优化过的复合维度，并且尽可能合理地处理（或解释）源数据的瑕疵。
这时会发现当一切准备好以后（花了95%的时间），现成的一堆模型和验证打分工具，直接去跑，对比结果就好了。后续整合发布到生产（实时推荐之类）等等的工作，已经不算数据工作流，而是进入传统互联网产品流程，双方对彼此来说都是黑盒。
回过神来，你可能会说，那这些现成的模型靠谱么？
我们进入4的世界，桃花源里的学术世界
学术世界的仙人们其实和1一样，远离整个数据工作的对于企业来说的初衷，他们既不考虑数据怎么来的，也不考虑某种生活现象为什么要服从某种分布，这里只关心模型本身的数学特征（和流派），对123世界的凡尘俗世的人来说，也许刚毕业的时候还期待大数据应该是玩4，工作一段时间以后才发现2才是真相。
只有很少的人能一直留在学术道路上，虽然统计学是数学里很low的分支，但是却是最接地气的分支，比如，你能把图片的模糊和精细，往颜色值的矩联想么?统计学家会告诉你这是常识，根本不用解释。可见概率的思考方式，会导致比程序员思考模式更大地有异与常人。
那么图上4为啥能回到1呢?
我们回到3的BI工程师队伍里，如果建模以后，发现运气不太好，无论参数怎么调，匹配的程度都并不好，那么有两个方向：
一个是比较PR比较酷的方向，例如不断尝试学术世界4的新模型，或者干脆搞kaggle这样的数据大赛，征集学生的突发奇想，避免数据规约中的"历史经验‘’路径依赖，时髦的说法叫产学研联动；
另一个更契合实际的方向，是把匹配失败的例子抽样出来，看看是不是漏掉特征，没洗干净，或者需要额外维度之类，总之去步骤2和步骤1里补，这个方向很苦，一点也不酷。
注意大部分PR文章说的大数据”不需要理解为什么，只需扔进去所有数据，然后看结果“，就是指预期的匹配失败，反而发现一些意外结果的情况。
实际上绝大多数进入建模分析的都是精挑细选过的维度，是经过反复认真的调研和理解的，只是结果有偶然发现而已。不可能是随意乱看，性能不允许。
这样一来，4就回到了1，经过这样一个循环，越来越多的数据被采集，被指标化，和被用来建立老师傅经验函数，以解决实际问题（而且老师傅函数可以嵌套迭代，这对现实世界的老师傅来说就有难度了）。
作为结尾
全局看工作流可能并不解决实际问题，但是经常定位自己和周边，是不错的习惯。
而且这个简单的圆圈1234图也可以作为一个所谓职业规划的大体方向，毕竟现在查询如何转行大数据的关键字流量是越来越高了。
谢谢阅读。
