0.背景与原因

由于多种扯淡的原因我决定给我的专栏写第一篇文章（也许是最后一篇），本来说好一起写专栏的小伙伴也被业务需求淹没了。（心情就这一句，下面开始讲有用的）

要讲的主题是关于数据这个行业，或者你愿意叫大数据也可以，一些我看到的行业现状，并不涉及技术细节。因为我在来之前的想法和实际情况完全不一样。

计划针对的目标人群，是对这个行业没有基本了解的新人，转行的同学或者学生。

目的是希望读者能够对这个行业获得一些基本的但是真实的信息（我认为），并由此辅助他们针对自身情况进行决策。

背景与局限：关于我，是一个新入行的应届毕业生的数据新人，目前在一家头部互联网公司打杂。在我的新人期，主管使用了一种非常有收获的landing方式，就是轮岗，让我轮了几乎所有和数据相关的岗位，以便我发现自己的兴趣所在。所以我对行业的长远发展可能有自身认知局限，但是目前来讲我还是接触到了这个行业中的大部分角色。读者应当有足够的辨别力来认识到其中的局限。

1.由一个数据体系开始看角色分工

从一个业务开始，一个数据体系应该是什么样的呢？这里如果读过企业如何搭建数据仓库体系的书，就可以不用往下看了。如果你还没读过但是很感兴趣，推荐《阿里巴巴-大数据之路》，我日常工作中就和这本书上讲的内容几乎一模一样，但是这本书除了大量宣传了福厂的工具和业务场景之外，本身对技术和技术思维的提高其实不太多，可以作为了解互联网业务和数据仓库体系的入门。除此之外，对于没有参与过工作的新人，推荐Designing Data-Intensive Applications.这本书从一个数据系统的基本概念讲起，直至用分布式系统处理大规模数据来龙去脉讲得十分清楚，省去了大量得搜集数据和入门学习的时间。

我们说的一个业务程序，一个业务应用，在互联网风靡的今天，其本质很大程度上是一个以信息为核心的流转系统。从数据的产生，到加工，分析，应用，有一条很长的链路，并催生了诸多岗位和工具。并因为它的性质，和几乎所有的程序员职位都能沾上一点边。

在开始讲整个流程之前，我要先从数据需求开始谈起。在企业日常的数据需求中，大概可以分为以下几种。

1.业务逻辑本身需要的批数据处理，需要高吞吐量，但是对延迟要求不高或者不那么高。比如，社交关系中的好友推荐，搜索中的海量数据更新等等。连spring都有batch功能，虽然我不太清楚有没有人用。我自己没见过

2.企业需要一个数据体系，来对数据进行分析，从而辅助决策，乃至进一步产生价值。这种体系一般从一个数据仓库体系开始，然后走向复杂的数据应用。

首先从数据的收集开始，数据的来源主要有两种，一种是内部，一种是外部。越是复杂的业务，内部数据越是占据了大量的份额。我95%的时间都在和内部数据打交道。内部数据通常是和工程紧密联系在一起的。来源主要包括以下几种，页面埋点（前端/移动端），后端接口调用日志（HTTP接口，RPC接口，工具内部日志等），后端数据流转体系中的信息捕获（这个应该是正在随着微服务的发展被前一种吞并，但是考虑到业界现状，dto会在流转的时候根据需要写入消息队列或者离线日志落盘），后端数据库读取（关系型，非关系型，读库，读从库，抽log，全量，增量等）。另一种是外部数据，主要来源是爬虫，爬取的对象一般是竞对或者网络内容，这中间涉及了信息抓取，前端，移动端，后端接口，策略对抗等等。

接下来的流程其实是数据的处理，通过各种手段将原始数据同步进入数据仓库之后，需要对业务逻辑进行数据仓库建模，在这过程中伴随了数据的清洗转化加载等。这其中应用的技术栈主要是sql和一门脚本语言（Python，Perl，shell均可），这也是为什么很多人看到的大数据开发岗位都是要求这个技术栈，也有很多人将其称为sql boy的原因。

在完整的数据体系建立之后，就会在这个数据体系上挖掘价值。数据开发工程师会根据业务开发一些数据应用，来做业务赋能。数据挖掘工程师，算法工程师，都会基于这些数据做挖掘或者算法应用。BI会基于这些数据进行提数据和跑数据，来完成一些非标的和临时的数据需求。

在这过程中，使用了大量的大数据工具，主要是Hadoop生态中的，同时也有一些Nosql数据库和消息队列。基础架构方向的大数据开发工程师，中间件工程师，java开发工程师都是做这些工具开发从而服务数据开发工程师的。他们持续优化提升工具性能和进行配套开发提升工具易用性。

大数据需要在集群中进行存储和运算，需要运维工程师。

2.岗位角色

在实际过程中的数据分工，边界非常模糊，不同岗位可能做的事有很大重合。但是我根据主流的分工大概分一下。

先说四个和数据域算是擦边的

后端开发工程师：我前面提到的那些从工程中进行数据同步的，在工程中的部分通常由后端开发工程师来完成。除此之外，如果产品本身逻辑就需要大规模数据批处理，一般也会分给后端开发工程师，所以近年来工作里的要求从消息队列中间件，Nosql数据库，渐渐出现了要求会用某个大数据计算引擎（Spark和Flink应该是比较多的）。除此之外，很多数据服务对内使用接口形势透出，需要后端开发工程师来搭建服务，不过一般对内工具的qps都不怎么高，挑战一般。

前端开发工程师：前端工程中的埋点，一般都由前端工程师来完成。除此之外，大数据的数据应用最后要面向没有技术的业务同学，需要前端资源进行可视化，。由于前端本身的特性和大数据的热门，目前身兼两种技能的工程师相对是比较抢手的。

移动端工程师：还是埋点。

运维工程师：运维数据的存储计算集群的，保证工程稳定性，现在有理想的运维工程师都是开发运维工具，然后甩给数据开发自己去运维。帮忙排查一些问题。离数据域其实也比较远。

下面就是联系比较紧密的了。

算法工程师：目前算法工程师是比较热门的，除了机器学习的三驾马车（搜索，推荐和广告），很多业务都希望借助算法的力量给自己的领域带来深刻的变革，创造红利。算法工程师本身就需要使用数据，所以有很多时间花在数据上，而很多时候数据服务/数据挖掘和算法之间的界限也是模糊的，需要用算法的时候数据开发也会直接上。

数据挖掘工程师：和算法工程师的界限比较模糊，一般来说算法工程师偏发现，数据发掘工程师偏分析。这个我也不太知道怎么用语言来表达。

ETL-建模的数据仓库工程师：搭建一个数据体系是个技术活，尤其在业务逻辑复杂的情况下，优秀的数据建模工程师非常抢手。但是据我所见，只要业务复杂起来，绝大多数数据仓库怎么搭都会有人骂，生起气来连自己都骂。所以这个优秀的定义非常模糊。主要技术栈就是sql

离线数据服务开发工程师：基于数仓，根据业务的不同数据需求进行开发，一般能够固化的常用数据需求会被离线开发成报表，每天呈现。不能固化的临时查询被称为ad-hoc查询，一般会根据ad-hoc的类型选择不同的olap系统来承接这种需求。从预设最少性能最差的hive，到spark，到MPP类型的olap数据库，到使用cube的olap系统都有。主要技术栈就是sql

实时数据服务开发工程师：实时展示数据有助于及时决策，但是也有很多新的挑战。一般会使用一种流式框架进行开发，Flink和spark应该是比较多的，storm已经进入淘汰阶段了，Google的dataflow国内用的应该不太多。这东西也能变成sql，基础设施完善的大厂，流式开发也是用sql开发的。

BA/BI：数据分析，数据分析日常主要工作是为决策层的想法提供数据。除此之外的价值主要体现在，他们会做一些主动的分析来为决策提供建议。

基础架构类的大数据工程师：进行工具研发，提升工具性能，更重要得是提升工具的易用性，把这些工具的使用门槛降低，使用体验提升。是比较接近造轮子的工程师。有时候会承接运维的工作。

以上是我认为在数据科学过程中可能会出现的角色。其中有很技术的，也有很多偏业务方向的，大家可以根据自身做出定位。

3.推荐书籍与技能

我本来想写点技能知识的，写了很多发现自己只是把书上的知识复制过来，没什么意义。那么改为资料推荐，希望大家对这些知识和用途有个体感。

前面推了两本了，除此之外各个工具文档都是很好的资料。

下面这些资料根本不是全都要会的，很多职位都只需要会其中的一部分，甚至于目前工作的人，很多也达不到这个要求，我提起这些只是希望尽量全得让人了解到可能用到什么工具，可能学到什么知识，而不是面试不会这么多就会挂。

—————————————-通用技能——————————————–

首先要会sql，但是大数据里面的sql都是DQL，剩下的都少用。和通用sql语法也有点区别，尤其是数据仓库的sql底层调优和rdbms也不太一样，没啥书可以推荐，随便学学就行了，也比较简单。好像有个sql必知必会，我没看过，读者自行判断。

Hive：主流的开源数仓，是数据仓库，所有工作都要打交道的基础。对于所有岗位都要知道的，也就是HiveQL了。

脚本语言，但凡有点编程语言基础的，学个python，API不懂直接查就行了，这个也没啥推荐。自己找个教程。

就靠这俩就能应付一个数据开发的日常需求了，毕竟是sql boy。

—————————————–工程技能——————————————–

工程语言，java首选，scala次之，远远压倒了其他，需要做工程开发的学一下这俩。java的推荐书已经很多了，因为我是先学了java才看书的，我觉得那些书写得再好也是基础。很多人推荐Thinking in Java，这本书我全读了，它就是一个把基础讲得很细的基础书，里面示例代码用了很多设计模式，没有大量的工程实践经验看设计模式很难理解它的意义，所以除了初入门时间很多的纯小白想打一个好基础之外，别人我都不推荐，太浪费时间了。想提高设计模式可以有经验之后自己去看相关的书。scala我没推荐的书，它和java的区别除了一些语法糖，主要是函数式编程的思想，可以自己找书看。学完了有一本书叫java8 in action，随便翻一下会用java8的语法就得了。但是不要靠看这本来学scala，会把人带进坑。

Spring框架，做应用开发的要学，目前用的比较多的是spring boot。但是我在不会spring的情况下，我写不出来代码，所以我是看了spring in action入门的，有时间可以搞明白severlet是怎么回事，能解答很多疑惑，实在没时间就算了。后面spring boot没有单独学，看别人代码摸索出来的。

一种统计机器学习框架：算法数据挖掘同学的工程技能，spark的MLlib是比较推荐的，flink也有一个，但是我没用过。大量数据处理需要分布式框架。只会sklearn也可以，可以写pyspark。那点性能损失，大部分时候还好。

一种深度学习框架：算法同学的工程技能，现在TensorFlow应该是最流行的，但是企业里pytorch也很多。

前端：前端一般来说是不该需要的，但是很多公司里面前端资源都很紧，有时候不得不自己上。一种模板类型开发就可以，不用从js开始。优先级非常低

—————————————–分析技能——————————————–

算法/数据挖掘：要会一点机器学习。其实目前企业里面是统计机器学习用得比较多的，深度学习玩得火热。这个推荐资料特别多，很多人推荐吴恩达那个课，那个课我不是很喜欢，他为了能让大家都听懂阉割了好多东西，几乎抛弃了所有数学。这个水平肯定是不行，但是纯小白入门可以尝试一下，我没有什么经验。

数学：如果有条件（虽然我觉得看我这个文章的很难），我建议有条件的同学补一些统计基础，也不是很难，看看大学教材就行。一来是，就算不是算法，也经常需要一些统计知识，BI同学，数据开发同学，数仓同学，要设计指标体系，要把结果解释给别人听得，最基本的统计知识要有。另外对于算法同学，算法落地的方向不是只有推荐搜索和广告的，很多时候需要预测一些东西，要解释给业务听。对业务来说，模型的可解释性和机器学习的可解释性不一样，以我的经验，超过线性回归的模型=不可解释，给出一个特征重要性排序，会有业务challenge你的结果怎么得出来的，这时候没点统计很难解释。不做算法可以不用补概率向量啥的。高数也可以不用。

python\excel\BI工具中数据处理：BI同学，算法同学，学一下。pandas其实不那么重要，起码我觉得是，pandas的功能基本拿sql都能实现。主要是matplotlib要用得好，我提这个能力主要是非标可视化的能力。BI工具我不会，不瞎推荐了，execl太难了我也不会，需要的自己学吧。

——————————————-技术技能—————————————–

Hadoop生态中的工具，对于数据开发同学来说要会用，略懂原理，对于底层开发同学要深入。

Hive的理解：知道咋回事的，不然有个数据倾斜连执行计划都看不懂，优化处理bug都谈不上了。听说有本Hive Definitive Guide，我没读过，但是这个系列应该都还行，这个东西的逻辑在了解hadoop的基础上，还挺好理解的，可以不看书。

Hadoop：如果只是开发，看看调度框架Yarn，明白怎么调度的。因为经常要排查错误，需要直接接触。然后是hdfs，现在直接用hdfs是比较少的，都是读hive里的结构化数据，所以数据开发可以先不急着看。MapReduce，其实是大数据计算的基础，应该好好学原理的，但是现在在hive下，MapReduce逻辑基本被屏蔽了，而且替代工具特别多，对于新手有时间的建议从MR入门。强推 Hadoop Definitive Guide，在原理和应用之间把握了一个比较好的度，部分深入但是不琐碎。

Spark：目前比较主流和火热的分布式计算框架，有一本动物书，spark快速大数据分析，这本我全本看过，这本书过时有点久了，里面sparkSQL还当个新奇来讲，但是现在都很主流了。可以看看，这本书深度不够，只有应用原理很少，给做数据开发的同学看一下也只是勉强。看看官网文档挺好的。我觉得目前绝大多数需求应该都能在hive和spark中解决。

Presto/clickhouse/GreenPlum/impala: 常见的olap引擎，在TB级数据下可以实现秒级乃至毫秒级的响应。熟悉其中的至少一个，在业务中可以满足一定程度的交互式分析和报表的快速查询的需求。

Mysql/PostgreSQL和Hbase:多种数据库，应用场景是，当数据量不大时，可能会同步进rdbms或者hbase（比如大量点查），以实现更快的响应和业务需求。学习的话，读高性能MySQL压力有点大而且没必要，但是这本书写的很好。sql必知必会可以看一下吧，但是我没看过。我看过那本innodb引擎，写得挺好的，但是数据同学不需要这么深入，只是用作一个快速的查询数据库而已。

Flink：我看培训班视频和文档学的，离线思路和所有离线框架都很像，实时的部分值得关注，是很主流的一种实时框架。有实时需求的业务可以选择了解。

Kylin和Druid：同样是olap，但是原理和上面的有很大不同，了解其特点，在合适场景下进行技术选型即可。可选。

4.结语

其实也没有一个很棒的思路来组织这篇文章，也许会根据反馈修改一下吧，就先写这么多。感谢阅读