转自：大叔据
不可否认的是 SQL 是一个伟大的发明，它让增删改查的操作更加地便捷化，而且 SQL 的学习成本相对其他编程语言来说较低，被逼到会写 SQL 的运营和产品我都见过不少。。。
大数据行业跟 SQL 更是有不解之缘，可谓“万物皆可 SQL 化”，从Hive/SparkSQL等最原始的最普及的 SQL 查询引擎，到 Impala/Presto/ClickHouse/Kylin/Phoenix 等等 OLAP 引擎，再到流式的 Structured Streaming/Flink SQL/Kafka SQL，可见想彻底摆脱 SQL 是不可能的了，相比各式各样的接口，复杂的规则，SQL 化成了一个简单化的标志，因为默认IT界人人都会 SQL，那就约等于人人都会使用这些复杂的工具，多美好。我想强调的是 SQL 是大数据从业者的必备工作技能，但是工作必须不能全是 SQL 。
1. 自动化
专职 SQL Boy 其实就像是在工厂里工作的流水线工人，需求来了，噼里啪啦一顿操作把SQL跑起来，把结果再丢给下游，再来个需求，再噼里啪啦。。。如此循环往复。不知道大家有没有感同身受，如果有的话我就问一句：工厂都知道要自动化，为什么你还不明白呢？
取数需求是永无止境的且无趣的，而且很多都是重复的，运营产品等需求方大佬们有时候要看这个产品今天的数据，就风风火火来了个紧急需求，看完之后发现哦不对，今天还没过完嘛，应该要看昨天的才对......
我：“*&*#@%！！”。
比这个还弱智的翻工原因估计还有很多，难道就这样任由大佬们蹂躏吗？你有没有想过这种需求其实是可以抽象的，SQL 语句写来写去就那么几个词，做这种需求就相当于是把自然语言人工翻译成SQL语言，那么这个翻译的过程是不是能够让代码来代替呢。
简单地给个建议，搞一套 OLAP 引擎，配合一个拖拽式的前端页面，就可以丢给运营们去慢慢玩了。三言两语说得很轻松，但是这其中的工作量是很大的，你需要花很多的时间在数仓的建设上，在平台的选型/搭建/测试/运维上，在接口开发/调试/对接上，最后因为自助分析不能够覆盖所有的需求，所有整个流程需要不停地优化和迭代，当然那些那些需要写几百行SQL才能解决的需求，可能还得你再想想办法。
在建设这一套自助分析系统过程中，你不可避免地会接触到更多的东西，元数据管理，数据治理，数据建模，Hadoop运维等等等等，恭喜你此刻你成功脱了SQL Boy的坑了，你需要把时间更多地花在上面说的那些事情中，虽然有点不道德但是你可以把 SQL Boy 这个荣誉称号让给新来的同事，可以把成百上千行的祖传 SQL 传递给他们了。
2. 数据驱动
这个时候应该有人会想说“老子就是那个接了祖传 SQL 的人”。。。别急，接着往下看。
如果你的 SQL 真的有成百上千行，那你应该要考虑你的数据仓库建设的合理性了，如果你也刚好是个数据仓库工程师，那应该是避免不了写 SQL 的了，但是我的理解是这里的 SQL 并不是上面提到的取数需求这种无趣无意义的 SQL，数仓的建设更多需要的是业务层面的理解，需要考虑更多的是如何能把数据的价值体现出来，很多业务方的需求其实是拍脑袋想出来的，要知道你是离数据最近的人，你也应当是对数据最熟悉的人，你应该是最能判断数据如何展示是有意义的，以及如何让自己的数据去发挥出最大的价值。
“数据驱动”是我很喜欢的一个词，如果能真正地做到数据驱动业务，那你写的SQL没白写，你是个SQL King，但真正能做到这样的人是少之又少，这其实是技术与业务的一个结合，这个方向上不仅仅对技术有要求，更重要的是需要培养对业务的理解能力。
3. 数据挖掘
其实很多的大数据开发，大数据分析，都是想往数据挖掘的方向发展的，但很多人都觉得门槛太高，被自己吓住了，不敢迈出尝试的第一步，虽然说数据挖掘入门会有一点门槛，但是其实并没有大家想象得那么难，高等数据，概率论，这些课程大家在大学应该都学过，大部分忘了没事，基本的概念记得即可，但是重点是你得耐得住漫长学习过程的寂寞。
另外，算法的工程落地是需要做很多开发类工作的，数据准备，接口开发等等，据我所知很多公司这些活都还是由数据挖掘的人来做的，所以也许数据挖掘师在算法上很强，但是你在工程上是有优势的，前两天看了木东居士老师的一篇文章，印象最深刻的一句话是“错位竞争”，转行做数据挖掘的想在学术上和别人硬碰硬是很难的，但是你有你的长处，你要把它发挥出来。
4. 结语
脱坑的方式其实有很多种，但是重点还是要看个人的自驱力，自己是不是真的在推动自己去脱坑了，还是只是停留在口头的抱怨。
