大數據 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. 結語

脫坑的方式其實有不少種，可是重點仍是要看我的的自驅力，本身是否是真的在推進本身去脫坑了，仍是隻是停留在口頭的抱怨。

另外，以前有幾個童鞋問過我有沒有數據挖掘入門的視頻課程，不知道還有沒有須要的童鞋，有的話就關注下公衆號【大叔據】唄，人數的多話我去幫你們找找，找個高質量的過幾天發出來。

以爲有價值請關注 ：公衆號「大叔據」