python有哪些职位知乎_数据分析师这个岗位，可能近几年会消亡

原标题：数据分析师这个岗位，可能近几年会消亡

近期成为月入两万的数据分析师的广告遍地都是，可能会对一些未入行的同学造成错觉。我感觉数据分析师这个岗位，可能近几年会消亡。

这不意味着这份工作本身不重要，而是说这份工作本身可能会转化为产品运营的一些必备技能，而不再需要单独特设人力去做这件事。或者说，不是再需要你学习SQL或者学习python，只是为了成为一名数据分析师。

我们来看下预设中的分析师的一些工作场景，看看数据分析师核心的工作价值。

取数

数据清洗

数据可视化

统计分析

数据方向建设和规划

数据报告

取数 — SQL

很多人对数据分析师的预设是SQL达人，包括现在很多数据分析师的核心工作其实就是进行SQL取数。

这项工作的痛点和难点在于，我们为了得到一个结果，通常需要join很多的数据集，然后整个SQL语句就会写的特别长，而且可能会出现一些问题：比如join的表可能会出现key是重复的情况，造成最终的SQL结果因为重复而变得不可用。所以我们需要专人去专门维护各种各样的数据集，他们知道每张表应该怎么用。

但这个其实是关系型数据库遗留下来的产物——我们完全可以不需要join那么多的表。现在的分布式计算的框架，已经完全可以支持我们只保留一张大宽表，有需要的所有字段，然后所有的操作都在这张大宽表上进行，而且可以保证查询速度。这样数据分析最大的痛点已经没有了。至于你说大宽表里面存了很多重复的数据，是不是很浪费资源(关系型数据库之所以不用大宽表就是从存储空间和性能的trade-off角度考虑的)：放心，分布式存储本身是不贵的，而计算效率则是由分布式计算框架进行专门优化的。现在的计算框架计算的响应速度，已经可以在大宽表上可以很快的得到结果了。相比之下，多次join操作反而可能会更慢一些。

同时，现在很多公司的NB框架，其实都已经支持拖拽取数了，也根本不需要写SQL了。

此外，不得不说的一点是，SQL语句本身真的不难。可能如果你自己静下心来想学，一个周末的时间肯定能搞定。而资历老的数据分析师，并不会比资历轻的数据分析师，在SQL语句的写作上有什么本质的区别。以前可能还有一些小表join大表的trick，但现在计算框架大多都已经优化过这些了。所以即使是需要写SQL的场景，本身也是没有什么难度的。

所以，通过大宽表来解放数据分析工作的生产力。即使在一定要写SQL做join操作的时候，本身也不是一件壁垒特别高的事情。取数这件事儿，对于其他岗位的同学，就已经没那么复杂了。

数据清洗 — Python

数据清洗其实是很多强调python进行数据分析课程中，python部分的主要卖点。包括但不限于，怎么处理异常值，怎么从一些原始的数据中，得到我们想要的数据。

在日常产品需求过程中，这种需求的场景其实很小。因为数据大部分都是自己产生的，很少会出现没有预设到的极端值或者异常情况。如果有的话，一般就是生产数据的同学代码写的有bug，这种发现了之后修复代码bug就行。

数据清洗在工作场景的应用在于落表——就是把原始数据变成上面提到的，可以通过SQL提取的hive表。这个工作是需要懂代码的同学去支持的，他们负责数据的产出，包括数据的准确性，数据的延时性(不能太晚产出)等等。前文提到的生成大宽表，其实也可以是他们的工作。这其中就涉及到一些代码的效率优化问题，这个就不是简单懂一点python可以搞定的了，可能涉及到一些数据压缩格式的转化，比如Json/Proto buffer到hive表的转化，还有一些计算框架层面的调优，比如spark设置什么样的参数，以及怎么样存储可以更好的提升查询速度。

所以这部分工作一般是由懂代码的同学完成的。可能数据团队会有比较少数的同学，管理支持全公司的基础表的生成。

数据可视化 — Tableau

很多之前在数据分析做实习的同学，主要的工作内容就是在一个商业化的软件(比如Tableau)上，做一些统计报表。这样可以通过这些数据报表，可以很方便的查看到所属业务的一些关键指标。这些商业软件通常都比较难用，比如可能需要先预计算一下才能输出结果；而且不太好做自定义功能的开发。稍微复杂一点的需求场景，可能就需要一个专门的同学捣鼓一阵，才能输出最终的统计报表。

现在有更先进的套路了。

首先可视化。很多公司打通了前端和后端的数据，这样就可以通过网页查询原始的数据库得到数据结果。而现在很多优秀的前端可视化插件，已经可以提供非常丰富的统计图形的支持。而且因为代码是开源的，可以根据公司的需求场景进行针对性的开发，公司可以再辅以配置一些更加用户友好的操作界面，这样一些复杂需求也有了简单拖拽实现的可能。而且这些前端js代码都是免费的！对于公司来说也能省去一笔商业公司的采买成本。

其次很多商业软件，都是针对小数据集场景设计的。在一些大数据集的场景，一般需要先预计算一些中间表。而如果自己公司定制化开发的前端展示结果，就可以根据需要自主设置计算逻辑和配置计算资源，先在后端进行预计算，前端最终只是作为一个结果展示模块，把结果展示和需要的预计算进行解耦。这样就省去了很多中间表的产出，也会更加快速的得到想要的业务指标，快速迭代。

所以可视化数据的工作量也会大大减少。而且会变成一个人人都可以操作，快速得到结果的场景。

统计分析

对于一名数据分析师而言，统计学分析可能是一块知识性的壁垒。尤其是在现在ab实验成为互联网公司迭代标配的今天。需要把实验设计的那套理论应用起来：比如ab实验进行后的显著性检验，多少样本量的数据才能让这个结论有效可信呢。

但是，你我都知道，经典的统计分析其实是一个非常套路性的工作。其实就是套公式，对应到代码层面，可能也就一两行就搞定了。这个代码的统计分析结果可以作为ab平台的指标展示在最终的ab结果上，大家看一眼就能明白。即使是对那些可能不知道显著性是什么意思的人，你可以跟他简单说，显著了才有效，不显著就别管。

这么一想是不是其实不怎么需要投入额外的人力进行分析？

其他数据相关的工作

数据层面的规划和设计。移动互联网刚刚兴起的时候，可能那时候数据分析师需要对每一个数据怎么来设计一套方案，包括原始的埋点怎么样，又要怎么统计出想要的结果。但现在大部分已经过了快速迭代的时代了，新产品的埋点添加可以参考老产品，这就意味着形成套路了。而一旦形成套路，其实就意味着可以通过程序直接完成或者辅助完成。

数据报告。那就真的是一件人人都能做的事情了，试想谁没在大学期间做过数据报告呢？以前只是因为数据都是从分析师产出的，而如果人人都能取到数据的话，数据报告是不是也不是一个真需求呢？

在我看来，数据分析师这个岗位的天花板和其他岗位相对来说是有点低的。可能工作一两年之后，从岗位本身就已经学不到什么额外的工作知识了。主要的工作内容技术含量不是特别高，技能性的更多的是一些可以简单上手的东西，而且做的时间长了，在这些技能性的事情上得到的积累并不是很多。

数据分析师更像是一个在时代变迁过程中的一个中间岗位：我们从一个基本没有数据的时代，突然进入了一个数据极大丰富的时代，在这个过程中，我们都知道重视数据。那怎么能够利用这个数据呢？可能之前的那一帮人并没有太多的经验，于是老板就招一些人专门来研究一下它，同时做一些底层数据的优化。

经过多年的迭代，现在互联网行业的每个人都知道数据的价值，也大概知道了什么样的数据是重要的，怎样可以更好的挖掘数据背后的价值。同时底层的基础设施也已经支持可以让一个之前没有经验的同学可以快速的上手得到自己想要的关键数据。这时候对于一个职业数据分析师来说，他的任务就已经完成了。就如同当人人都会讲英语的时候，翻译其实也就没有存在的价值了。

此后的数据分析工作，可能不再是一些单独的人做的工作。它会变成一个产品和运营的基础工具，而且足够简单，没有取数的门槛。只是产品运营怎么样可以更好的认识数据，通过数据本身更好的配合产品运营的工作，这已经超脱我们一般理解的数据分析师的工作了，而是一个产品运营分内的工作。

对于那些已经在从事数据分析师岗位的同学来说，建议不要把心思全部投入到数据分析的本职工作上，以完成任务为核心KPI。而是不要给自己设置边界，多从用户的角度思考问题，不要因为是产品运营的工作就不去做了。数据本身的价值是无穷的，你们已经先人一步的掌握它了，要有先发优势。你们最接近数据的人，是最可能发现用户的宝藏的人。

以下为知乎网友评论

知乎网友一：

我平静一点的评论一下你的回答哈，我是一名数据分析师，确实日常有很多工作是没有很技术性的，比如取数和可视化这些工作。但是如果因为日常工作就否定了数据分析师的价值，认为数据分析师将会淘汰，那么世界上有无数的工作都是可以取代的。而从我自身工作经验来看，有一些工作是非统计专业人员无法做出来的。比如说：数据如何收集才是真正随机的，数据如何清洗才能保留了最大信息并去除冗余信息，数据的分析如何真正准确的归纳信息，数据的建模如何精确的预测未来，数据的报告是否可以让同事快速的理解，数据的发现如何真正落地推动进而带来利润。数据建模部分可能需要进行复杂的建模，运用到机器学习和深度学习的算法。同时自己主动去推动领导和业务去执行自己在数据上的发现。真正为公司带来收入。一个成熟的数据分析师，基本上可以兼职做运营，做算法。我认为很多人对于数分这个职业的认知太过狭隘，毕竟太多非统计专业的人从事这个职业，并且觉得会对数据做一些统计的描述性分析，画个图就自称会数据分析了，而又把复杂的数据建模归类到算法工程师的工作。当然，这是客观上数据分析师面临的困境，所有人都看低我们，我们需要自证价值。

作者回答：

嗯嗯你说的对。的确数据真正的价值必须要懂数据明白数据的人来发现。我想表达的是，数据分析"纯技术"的门槛正在消减，变得让更多的人使用数据。其实其实这也让数据分析师更加快速的分析和产出数据，更快的产出价值。数据的价值毋庸置疑。其实对任何行业来说，一些原来的技术难点可能都会随着时间的推移变得不再那么困难。拥抱业务，在业务中体现出自己模块的价值，都是一种必然趋势。

知乎网友二：

数据分析这个岗位核心终究还是要价值落地，数据分析师主要的技能在于数据处理和一些简单可视化和分析总结。根据我的自学的经历以及实际去应聘和对行业的一些了解，数据分析师这个岗位确实“技术门槛”较低，而更多的区分可能在于分析思维上，但这本身也比较难量化，或者说同质化竞争也比较严重。大部分数据分析师只是做描述统计的分析，并没有什么不可代替性，大数据时代，高质量数据获取才是核心。想要往上走还是要接触大数据处理的相关工具，去做一些项目的落地，偏技术方向走，才会在职场有相对好的发展。最后，现在数据分析师的营销氛围太重，实际并没有那么美好。

知乎网友三：

按你这么说很多算法工程师也要消亡了？

调参，调包大家都会，没什么技术门槛，甚至有些模型可以直接在平台上拖拽。早晚要被后端取代？但是你有没有想过，一个岗位的出现正是因为工作细分的结果。如果一个人这么万能，那还需要多岗位干啥。而且分析师的工作永远不是取数和可视化，而是为业务提供价值。

作者回答：

非杠，现实是只会调参和调包的算法工程师现在确实已经没有市场了。

同意职业细分过程，也认同数据分析师对业务产生的价值。我这篇文章主要是在说数据分析师职业本身的门槛在降低，不知道你是否认同。

门槛降低会导致一些结果，我的观点是我心中推演的一种结果，当然你也可以推演出你自己的结果。结果本身可能没那么重要，因为影响结果的因素有很多，比如我会认为业务能力不应该属于数据分析师这个职位最开始的职位要求，而应该属于业务部门比如产品或者运营，而你显然是这么认为的。重要的是推演的过程，只抓着结果那就是吵架了。

知乎网友四：

作为一名数据分析师来讲，看到上面的消息会有一些同感，但是目前来看数据分析还是替代不了：首先运营、技术他们都是站在自己的立场想问题，从运营提出数据需求(技术想的是如何快速提取数据，数据分析想的是提取数据的目的是否达到，数据是否真实可靠，是否要做处理，如果运营的人员来做的话，就要懂得底层数据架构，如何清洗数据，如何确信数据准确)，然后到数据分析挖掘(技术可不给你们分析挖掘数据、运营真的能分析挖掘出有用的信息出来吗，且不说工作多忙，就说运营会把所有业务串联起来分析嘛，会专门去学习数据分析相关的新技能和工具包嘛)，到最后数据展现(数据如何展现的好看，如何搭配达成看板分析目的，如何配置数据更新预警机制、如何规划数据联动等等)如果反过来说，数据分析做运营/技术，是否更合适呢，同样的都不行，术业有专攻，还是本领强，一身兼多职

知乎网友五：

我有同感，不过这个职位应该还在，只不过可替代性比较强。如果拉一个新人培训三个月就能慢慢上手，六个月就能做全套，那么这个职位就是可替代性比较强的。大宽表这个问题，我自己也有感触，但是和你不一样。虽然大宽表的确去除了join的需求，但是同时也抹去了表的业务意义。换句话说表的结构不单单是为了工程，同时也有业务上的意义。所以我个人的感觉是，大宽表的确因为工程上的原因需要保留，但是对于各项业务还是需要分表，这时候还是需要数据建模，只不过和之前的Domensional不一样了。拖拽实现取数，其实数据分析部门可以考虑自己做一个，一方面自己最熟悉各类需求，另一方面学学编程也算是拓展技能。反正内部系统嘛，也不用考虑什么高并发之类的难题，能用就行了。也算是简历上多了一笔。总体来说我觉得数据分析的确是一个比较初级的岗位，必须要往不同的方向走出去。喜欢数学，就往数据挖掘、数据科学的方向走；喜欢业务，就往运营经理或者业务部门的经理走；喜欢工程，就往数据建模、数据工程的方向走。总体来说的确不能一直做数据分析的一线人员，哪怕是senior。

知乎网友六：

曾经在互联网做过偏技术的数据挖掘，现在在传统行业做偏业务的经营分析。大概能理解作者说的意思，而且现在同组的很多同事也并不是数学或者统计学出身，偏业务向的数据分析是会出现文中的情况，毕竟现在sql和可视化这些自学门槛不高，也有很多工具辅助。我自身的体会是，不同技术背景，在做数据分析的时候看问题的角度是会不一样的，当拥有一定的技术能力，是能把偏业务性的东西结合专业知识一起去看。毕竟你做数据挖掘也要有场景落地才能体现最终价值。

写在最后

我是某一天在逛知乎看到这篇文章的，找了原作者，请求说是否可以转载。我很早在其他文章，提到了风控建模岗位为企业创造的价值，是否对得起企业给予的工资，以及是否当策略和模型这一系列的东西天花板很容易被触及。但是我想表达的是，文章不是来告诉大家数据分析师没有用，只是想表达，在职业道路上，不断学习，不断提升，才是让自己适应社会工作的重要的一部分。返回搜狐，查看更多

责任编辑：