一、梳理数据工作逻辑

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

1.业务流：

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

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

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，高配的会pythonsas。很多数据分析师在进行分析和撰写报告时，会直接应用挖掘算法输出结论。

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

四、能力模型要求

1.分析师：

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

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

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

2.数据PM：

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

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

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

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

3.数据开发：

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

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

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

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