不可否認的是 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. 結語
脫坑的方式其實有很多種，但是重點還是要看個人的自驅力，自己是不是真的在推動自己去脫坑了，還是隻是停留在口頭的抱怨。
另外，之前有幾個童鞋問過我有沒有資料探勘入門的視訊課程，不知道還有沒有需要的童鞋，有的話就關注下公眾號【大叔據】唄，人數的多話我去幫大家找找，找個高質量的過幾天發出來。
覺得有價值請關注 ：公眾號「大叔據」
