近期成为月入两万的数据分析师的广告遍地都是，可能会对一些未入行的同学造成错觉。我个人感觉数据分析师这个岗位，可能近几年会消亡。
这不意味着这份工作本身不重要，而是说这份工作本身可能会转化为产品运营的一些必备技能，而不再需要单独特设人力去做这件事。或者说，不是再需要你学习SQL或者学习python，只是为了成为一名数据分析师。作为一名数据分析师，职业自身的壁垒正在不断消减，更加主动的拥抱业务，解决真正的产品和用户需求，或将成为未来的发展趋势。
数据分析师的日常工作<br>
我们来看下预设中的分析师的一些工作场景，看看数据分析师核心的工作价值。
取数<br>
数据清洗<br>
数据可视化<br>
统计分析<br>
数据方向建设和规划<br>
数据报告<br>
取数 — SQL<br>
很多人对数据分析师的预设是SQL达人，包括现在很多数据分析师的核心工作其实就是进行SQL取数。
这项工作的痛点和难点在于，我们为了得到一个结果，通常需要join很多的数据集，然后整个SQL语句就会写的特别长，而且可能会出现一些问题：比如join的表可能会出现key是重复的情况，造成最终的SQL结果因为重复而变得不可用。所以我们需要专人去专门维护各种各样的数据集，他们知道每张表应该怎么用。
但这个其实是关系型数据库遗留下来的产物——我们完全可以不需要join那么多的表。现在的分布式计算的框架，已经完全可以支持我们只保留一张大宽表，有需要的所有字段，然后所有的操作都在这张大宽表上进行，而且可以保证查询速度。这样数据分析最大的痛点已经没有了。至于你说大宽表里面存了很多重复的数据，是不是很浪费资源(关系型数据库之所以不用大宽表就是从存储空间和性能的trade-off角度考虑的)：放心，分布式存储本身是不贵的，而计算效率则是由分布式计算框架进行专门优化的。现在的计算框架计算的响应速度，已经可以在大宽表上可以很快的得到结果了。相比之下，多次join操作反而可能会更慢一些。
同时，现在很多公司的NB框架，其实都已经支持拖拽取数了，也根本不需要写SQL了。
此外，不得不说的一点是，SQL语句本身真的不难。可能如果你自己静下心来想学，一个周末的时间肯定能搞定。而资历老的数据分析师，并不会比资历轻的数据分析师，在SQL语句的写作上有什么本质的区别。以前可能还有一些小表join大表的trick，但现在计算框架大多都已经优化过这些了。所以即使是需要写SQL的场景，本身也是没有什么难度的。
所以，通过大宽表来解放数据分析工作的生产力。即使在一定要写SQL做join操作的时候，本身也不是一件壁垒特别高的事情。取数这件事儿，对于其他岗位的同学，就已经没那么复杂了。