互联网数据岗位定位与分工

）《大数据知识体系大全》，简单的罗列了大数据涉及到的工作模块，并按照模块给出了一些岗位描述。但笔者总感觉分工不够具象，对于大厂的数据人来说，很多level不算太高的初级分析师并不能也不需要一下子接触到大数据的全貌，而对于小厂的数据人来说，很有可能并没有见过也无法想象诸如SPARK、数据平台、数据仓库等大数据相关应用。那么自然而然，关于架构师、工程师、数据PM、可视化等等一系列称谓，也只能存在于概念中，并不能给数据人很好的指明方向和界限；

基于以上，笔者尝试分享一下自己关于这方面的思考，如有不妥，欢迎指正；

一、梳理数据工作逻辑

要理解互联网数据岗位的分工，我建议我们首先为自己梳理一下数据支撑业务的基本逻辑，在这里我将其分为业务流和架构模型：

1.业务流：

所谓业务流，就是我们在工作中数据支持具体业务的基本工作流程，相信绝大部分公司数据对业务的支撑主要都是提供数据（包括分析数据和业务系统接入数据）和提供业务分析报告；

我们常常看到的场景是这样的（业务分析报告的产出）：

业务方：分析师，我们计划搞一次促销活动，你可否看一下靠不靠谱，预期怎么样？

分析师（拿出业务需求文档）：工程师，麻烦帮我跑个数，巴拉巴拉。。。。

工程师：哒哒哒哒（写代码中）；

分析师（拿出PPT）：数据显示，我们之前做的促销活动转化率基本在X到Y之间波动，相比非促销期间平均提升Z个百分点。同时如果我们按人群特性分组，会发现A人群的转化率巴拉巴拉。。。。

我们也常常遇到这样的场景（数据提供）：

业务方：分析师，我们可能有一个长期的策略要搞一搞，你这里记得帮我们定期做好数据监控；

分析师（拿出业务需求文档）：数据PM，我们最近有个长期的策略要搞，所以要上一个报表和一些仪表盘，大概想看这些数据；

数据PM（数据PRD）：工程师，我们最近要上一个报表和一些仪表盘，基本的交互和数据逻辑是这样的；底层数据我们可能要做一些运算和存储，方便业务方快速回溯和查询，数据来源和加工逻辑是这样的；

工程师：哒哒哒哒（写代码中）；

我们可以把以上业务流简单的抽象一下，就是下面这个流程：

2.架构模型：

所谓架构模型，就是在企业中，数据从采集到呈现所要经过的基本流程以及流程涉及的相关技术；这方面涉及比较深的技术内容，笔者本身属于非技术出身，对于大数据相关技术，目前也仅停留在了解甚至听说阶段，在此不便做过多解释；

我们可以看下当下主流企业的架构模型：

这样的：

或者这样的：

实际上，各个公司根据自身的特点或者规模，具体采用的技术千差万别。大厂一般基于Spark+hadoop进行计算，但在实际的ETL加工中，有些直接使用的第三方成熟ETL套件如Congos、Kettle等，有些则是直接将sql建表语句定时化充当ETL使用；而很多创业公司则是干脆没有数据仓库，直接每天从业务库把数据100%copy到本地，然后再利用定制化脚本输出为表格呈现；亦或者自己即不做数据本地存储也不写定制脚本，直接利用第三方工具如growingIO、神策等系统采集并分析数据；

但我们对这些看似形态各异、技术选型不一的数据架构剥丝去茧，实际发现，整个数据从采集到应用的过程，无非就是下面几个环节：

二、明确具体分工

梳理了数据工作逻辑，我们便可以从业务流和架构模型上明确各个岗位的分工：

1.业务流

业务需求——数据分析师：一般在业务序列下，为业务服务，负责根据业务方的业务逻辑，确定业务指标，产出业务需求文档，给到数据PM；拿到数据后，还要负责根据数据输出数据分析报告；

数据（产品）需求—— 数据PM：一般在企业的数据部门下，是数据部门的需求和项目接口，拿到分析师给的业务需求文档后，会将业务需求转换为数据或者产品需求文档（相比分析师产出的业务需求，数据PM一般还需要考虑数据的底层逻辑、报表的前端交互等偏逻辑细节上的东西），给到数据开发；

技术实现—— 数据开发：拿到数据PM的数据需求文档或数据PRD后，用代码提取数据或将数据产品实现；

2.架构模型

数据采集层，一般涉及三类岗位：

数据产品经理：负责提出数据采集的需求，比如数据采集中最基本的埋点需求；

前/后端工程师：负责实施数据产品经理提出的埋点需求；

大数据架构师：几乎贯穿了整个数据架构的角色，埋点发送机制、数据接收机制、数据接收后的运算存储机制，都在架构师的掌控之内；

数据存储和加工层，一般涉及四类岗位：

数据产品经理：负责设计和提出支撑业务及产品的数据加工需求（可以理解为ETL）；

大数据架构师：数据的加工本质是数据在大数据架构中的计算过程，架构师需要保证架构性能能够支撑这种需求；

ETL工程师：负责用代码实现数据产品经理输出的数据加工需求；

数据挖掘：有一些数据加工需求本身就是数据挖掘，或者需要调用部分数据挖掘的算法，这些需求现在有一部分从数据库管理员转型过来的ETL工程师是暂时无法实现的；同时有相当一部分的数据挖掘工程师本身技能树可能是R和python比较强势而数据库语言偏弱；所以出现了一些公司数据挖掘和ETL工程师搭档工作的情况；

数据应用层，一般涉及三类岗位：

数据产品经理：负责前端数据产品的需求梳理，比如报表平台、仪表盘的PRD输出；

数据分析师：负责业务方的常规数据支持，业务数据梳理和数据分析；

数据可视化工程师：负责前端数据产品的开发；

三、特别说明

需要说明的是，虽然我们在前文按照业务流和架构模型将数据岗位的职责和界限做了貌似比较明确的界限，但在实际工作的过程中，这些界限更多的是内容的划分，而不是岗位的划分；

实际在大部分的公司，哪怕是有明确不同title的大厂，岗位之间有界限，但是界限也不一定是按照笔者所述的方式划分，以下列举几种常见的情况：

1.数据分析师在业务流上一人解决所有问题的情况：

在很多初创企业，数据基础设施偏弱，但是老板和业务方的数据意识都还不错，这个时候往往会有数据分析师一个人把业务流上所有事情都负责的情况，有些企业不一定叫数据分析师，比如笔者现在的数据运营其实就有点这种味道；这样的企业，数据分析师也不需要梳理什么业务需求文档，牛逼的分析师自己就能撰写数据提取脚本（sql、python）从本地或线上业务库提取数据，然后输出数据分析报告； 一般的分析师则会直接与数据开发沟通，由开发代为提取数据，最后根据数据输出分析报告；

2.业务人员充当分析师的情况：

不管大厂还是小厂，都有业务人员直接充当分析师的情况；笔者之前的一家公司，数据基础极为完善，业务发展迅猛，很多时候业务组自己的分析师并不能满足快速发展的业务需求，迫使业务组运营及产品人员人人自带sql技能。于是在开展项目过程中，也就时常会出现业务人员自行撰写业务需求文档与数据PM对接、业务人员自行撰写数据提取脚本完成数据分析工作的情况；

3.业务流上，数据开发充当数据分析师的情况：

这种情况一般出现在初创企业（笔者没见过哪个大厂有这种情况）。这类企业的业务人员通常不会将业务需求转化为数据需求再与开发对接，通常直接向数据开发提出业务需求，然后开发根据自己对业务的理解，将业务数据化之后，进行数据提取。部分企业的数据开发在这个流中可能还是只做数据提取工作，但也有少部分企业会要求数据开发输出数据分析报告，承担数据监控的责任；

4.架构模型上，数据开发充当数据产品经理的情况：

数据产品经理（数据PM）实质是近一两年才大规模出现的title，通常现在是大厂才会明确定义该职位的界限。多数企业的报表开发、仪表盘开发、ETL需求设计等现在偏数据产品类的工作，早先一般根据公司不同会被划分到数据分析师或者数据开发的职责范畴；目前了解到初创企业一般是归在数据开发名下。

5.架构模型上，分析师充当数据挖掘的情况：

事实上，高阶的数据分析师一般都具备数据挖掘的能力，低配工具一般是SPSS，标配得会R，高配的会python\sas。很多数据分析师在进行分析和撰写报告时，会直接应用挖掘算法输出结论。

综上各种特别情况，笔者只是将数据工作的内容进行了比较粗糙的模块化，并做了一定职位上的关联，便于我们去定位自己更喜欢和倾向于哪个模块，重点在于通过事去明确自己的定位，然后在某个点上去做更深的专研，而不是让大家根据自己现在的title去给自己设限。

四、能力模型要求

1.分析师：

事实上，就算从具体研究方向上，分析师也可以基本分成两类：数据分析师、商业分析师；

数据分析师：最常见的分析师，主要服务于业务部门，分析方向以业务和项目研究为主；能力上要求有很强的业务sense，能够快速理解业务，找到业务中的关键指标，明确分析思路；技能上一般是微软套件、sql；

商业分析师：业务分析师高阶版，企业内一般服务于战略层，分析方向以企业战略和市场为主；能力上除了数据分析师的必要能力外，还需要有足够的行业视野和商业敏感度；技能上一般是微软套件、tableau、R；举个和数据分析师的区别——一般商业分析师都会看统计年鉴，数据分析师可能不需要；

2.数据PM：

一般由一定阶段的数据分析师成长而来，笔者目前没有见过没做过数据分析的数据PM，基本上根据架构模型分三个方向：可视化、数据仓库、大数据；

可视化：与传统产品经理最接近的数据产品经理，做过基本的数据分析工作，掌握基本的产品方法论，了解数据从存储层到应用层的运算逻辑；技能上一般是微软套件、sql、流程图、Axure等原型工具；

数据仓库：做过基本的数据分析工作，对于数据生产的整个流程足够了解，数据库语言肯定要比一般的分析师要强，了解大数据和数据挖掘，懂主流的商业智能和数据仓库相关理论；技能上一般是微软套件、sql、流程图、R、sas；

大数据产品经理：笔者见过的大数据产品经理一般都是数据开发出身，所以理解该岗位可能还是偏技术向。因为笔者技术功底较弱，不便评价；

3.数据开发：

基本可以归结为三大类：数据挖掘、可视化工程师、架构师（在很多企业同时担当ETL工程师的角色）；

本身因为专业原因，对数据挖掘还知晓一二，明确sql、R、python等皆属于刚需技能，同时还需要一定的业务理解能力，行业上对于主流的资源库要有了解。

至于其他开发岗位，碍于当前专业素养和能力限制，了解不够，不便评价；

关于逻辑能力。。。如果逻辑思维能力差的话，真的不适合做数据，随便数据啥都不适合。

四、总结
数据类岗位随着互联网的兴起而兴起，伴着互联网下半场的到来，精细化运营对数据的依赖，加速了岗位的专业化进程；笔者尤记得2012年毕业时在大街网上搜索数据岗位，数据分析师都不算多，作为国家统计局直属院校统计专业毕业生，笔者的同学大部分不是进了银行就是考了各级统计局。笔者一人悻悻然从西安跑到北京，入职的第一个title是商品专员（依赖数据对商品进行管理）；那时数据更多的还是属于运营人员的某项加分技能而存在；等到2013年，数据分析师已经基本成了互联网企业的一个独立岗位。之后莫名的一堆技术向的数据岗位映入眼帘，再之后突然又冒出了商业分析师、数据产品经理等一系列概念，昭示着数据工作确实在越来越精细化和专业化，从统计走向分析，分析又衍生出产品；
产品、运营、技术在中国的互联网史上也并不是一开始就分工明确的。我们知道OICQ最早就是小马哥自己即做产品又写代码还要负责陪聊做运营；后来三者分离，而内部也在分工，比如产品就分前端产品、供应链产品；运营又分用户运营和产品运营；技术更是根据支撑环节不同早已界限明确。数据最早是作为产品和运营的支撑角色出现的，而如今但凡有点规模的企业中早已是个独立的岗位，那么之后数据内部的专业化和精细化具体会怎么分化呢？以上，是我的总结和思考，欢迎大家共同讨论和指正；