经常觉得很奇怪怎么辣么多数据分析师的广告，字节的峰池大佬是觉得未来该岗位可能消亡（康康大佬怎么说的同时了解下这个岗位，本文不代表本人观点，请客观理性看待=。=）。

突然想起拿了京东算法岗ssp的上财学姐大佬聊天记录，真就啥都要会呀（我太菜了）：

本文转自字节跳动推荐算法工程师（知乎ID：峰池）

这不意味着这份工作本身不重要，而是说这份工作本身可能会转化为产品运营的一些必备技能，而不再需要单独特设人力去做这件事。或者说，不是再需要你学习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部分的主要卖点。包括但不限于，怎么处理异常值，怎么从一些原始的数据中，得到我们想要的数据。这些数据分析课程通常会把自己的python应用吹得神乎其技，好像付出学了python才能成为一个合格的数据分析师。

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

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

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

数据可视化 — Tableau

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

现在有更先进的套路了。

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

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

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

统计分析

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

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

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

其他数据相关的工作

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

数据报告

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

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

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

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

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

对于那些已经在从事数据分析师岗位的同学来说，建议不要把心思全部投入到数据分析的本职工作上，以完成任务为核心KPI。而是不要给自己设置边界，多从用户的角度思考问题，不要因为是产品运营的工作就不去做了。数据分析师这个职业发展到这个阶段，要么做更加底层的数据建设，要么拥抱业务，最大化的发掘数据背后背后的价值。不要再死守着数据分析的“固有技能”沾沾自喜了。

数据本身的价值是无穷的，作为数据分析师，你们已经先人一步的掌握它了，要有先发优势。你们最接近数据的人，是最可能发现用户的宝藏的人。

文章来源: andyguo.blog.csdn.net，作者：山顶夕景，版权归原作者所有，如需转载，请联系作者。

原文链接：andyguo.blog.csdn.net/article/details/118872281