大数据 SQL Boy 脱坑指南

不可否认的是 SQL 是一个伟大的发明,它让增删改查的操作更加地便捷化,而且 SQL 的学习成本相对其他编程语言来说较低,被逼到会写 SQL 的运营和产品我都见过不少。。。

大数据 SQL Boy 脱坑指南

大数据行业跟 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. 结语

脱坑的方式其实有很多种,但是重点还是要看个人的自驱力,自己是不是真的在推动自己去脱坑了,还是只是停留在口头的抱怨。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyzpgd.html