大数据 SQL Boy 脱坑指南

不能否认的是 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. 结语

脱坑的方式其实有不少种，可是重点仍是要看我的的自驱力，本身是否是真的在推进本身去脱坑了，仍是只是停留在口头的抱怨。

另外，以前有几个童鞋问过我有没有数据挖掘入门的视频课程，不知道还有没有须要的童鞋，有的话就关注下公众号【大叔据】呗，人数的多话我去帮你们找找，找个高质量的过几天发出来。

以为有价值请关注 ：公众号「大叔据」