大資料不就是寫SQL嗎？
【原創】
應屆生小祖參加了個需求分析會回來後跟我說被產品懟了一句：
"不就是寫SQL嗎，要那麼久嗎"
欺負我小弟，這我肯定不能忍呀，於是我寫了一篇文章發在了公司的wiki
原文如下，省略了一些敏感的內容。
在哪裡寫SQL？
這個問題高階點的問法是用哪種SQL引擎？
SparkSQL、Hive、Phoenix、Drill、Impala、Presto、Druid、Kylin （這裡的SQL引擎是廣義的，大家不必鑽牛角尖）
我用一句話概括下這幾個東西，先不管你們現在看不看得懂：
- Hive：把sql解析後用MapReduce跑
- SparkSQL：把sql解析後用Spark跑，比hive快點
- Phoenix：一個繞過了MapReduce執行在HBase上的SQL框架
- Drill/Impala/Presto 互動式查詢,都是類似google Dremel的東西，區別這裡就不說了
- Druid/Kylin olap預計算系統
這就涉及到更多的問題了，對這些元件不熟悉的同學可能調研過程就得花上一個多月。
比如需求是實時計算還是離線分析？
資料是增量資料還是靜態資料？
資料量有多大？
能容忍多長的響應時間？
總之，功能、效能、穩定性、運維難度、開發難度這些都是要考慮的
對哪裡的資料執行SQL？
你以為選完引擎就可以開寫了？too naive！
上面提到的大部分工具都僅僅是查詢引擎，儲存呢？
“啥，為啥還要管儲存？”
不管儲存，那是要把PB級的資料存在mysql是吧...
關係型資料庫像mysql這種，查詢引擎和儲存是緊耦合的，這其實是有助於優化效能的，你不能把它們拆分開來。
而大資料系統SQL引擎一般都是獨立於資料儲存系統，獲得了更大的靈活性。這都是出於資料量和效能的考慮。
這涉及到的問題就更多了。先要搞清楚引擎支援對接哪些儲存，怎麼存查詢起來方便高效。
可以對接的持久化儲存我截個圖，感受一下（這還只是一小部分）
用哪種語法寫SQL？
你以為儲存和查詢搞定就可以開寫了？你以為全天下的sql都是一樣的？並不是！
並不是所有的引擎都支援join；
並不是所有的distinct都是精準計算的
並不是所有的引擎都支援limit分頁；
還有，如果處理複雜的場景經常會需要自定義sql方法，那如何自定義呢，寫程式碼呀。
舉幾個簡單而常見的栗子：
見過這樣的sql嗎？
select `user`["user_id"] from tbl_test ;見過這種操作嗎？
insert overwrite table tbl_test select * from tbl_test where id>0; 臥槽，這不會鎖死嗎？hive裡不會，但是不建議這樣做。
還能這麼寫
from tbl_test insert overwrite table tbl_test select * where id>0; 怎麼用更高效的方式寫SQL？
好了，全都搞定了，終於可以開始愉快地寫SQL了。
寫SQL的過程我用小祖剛來公司時的一句話來總結：
“臥槽，這條SQL有100多行！”
事實表，維表的資料各種join反覆join，這還不算完還要再join不同時間的資料，還要$#@%^$#^...
不說了，寫過的人一定知道有多噁心
（此處省略100多行字）
終於寫完了，千辛萬苦來到這一步，滿心歡喜敲下回車...
時間過去1分鐘...
10分鐘...
30分鐘...
1小時...
2小時...
......
別等了，這樣下去是不會有結果的。
老實看日誌吧，看日誌也是一門很大的學問。
首先你得搞清楚這個sql是怎麼執行，底層是mapReduce還是spark還是解析成了其他應用的put、get等介面;
然後得搞清楚資料是怎麼走的，有沒有發生資料傾斜，怎麼優化。
同時你還得注意資源，cpu、記憶體、io等
怎麼樣，看完之後有什麼感想，知道大資料的SQL來之不易了吧，大資料寫SQL只是一方面，我們跳出SQL這個圈，從本質看看大資料到底要學些什麼？
思維導圖
下面的是我之前整理的一張思維導圖，內容分成幾大塊，包括了分散式計算與查詢，分散式排程與管理，持久化儲存，大資料常用的程式語言等等內容，每個大類下有很多的開源工具，想知道要學些什麼的同學，告訴你一個“壞訊息”，這些就是作為大資料程式猿又愛又恨折騰得死去活來而你想要成為大資料大牛又必須要學習的東西了。
大資料需要的語言
Java
java可以說是大資料最基礎的程式語言，據我這些年的經驗，我接觸的很大一部分的大資料開發都是從Jave Web開發轉崗過來的（當然也不是絕對我甚至見過產品轉崗大資料開發的，逆了個天）。
- 一是因為大資料的本質無非就是海量資料的計算，查詢與儲存，後臺開發很容易接觸到大資料量存取的應用場景
- 二就是java語言本事了，天然的優勢，因為大資料的元件很多都是用java開發的像HDFS,Yarn,Hbase,MR,Zookeeper等等，想要深入學習，填上生產環境中踩到的各種坑，必須得先學會java然後去啃原始碼。
說到啃原始碼順便說一句，開始的時候肯定是會很難，需要對元件本身和開發語言都有比較深入的理解，熟能生巧慢慢來，等你過了這個階段，習慣了看原始碼解決問題的時候你會發現原始碼真香。
Scala
scala和java很相似都是在jvm執行的語言，在開發過程中是可以無縫互相呼叫的。Scala在大資料領域的影響力大部分都是來自社群中的明星Spark和kafka,這兩個東西大家應該都知道（後面我會有文章多維度介紹它們），它們的強勢發展直接帶動了Scala在這個領域的流行。
Python和Shell
shell應該不用過多的介紹非常的常用，屬於程式猿必備的通用技能。python更多的是用在資料探勘領域以及寫一些複雜的且shell難以實現的日常指令碼。
分散式計算
什麼是分散式計算？分散式計算研究的是如何把一個需要非常巨大的計算能力才能解決的問題分成許多小的部分，然後把這些部分分配給許多伺服器進行處理，最後把這些計算結果綜合起來得到最終的結果。
舉個栗子，就像是組長把一個大專案拆分，讓組員每個人開發一部分，最後將所有人程式碼merge，大專案完成。聽起來好像很簡單，但是真正參與過大專案開發的人一定知道中間涉及的內容可不少。
比如：
- 這個大專案如何拆分？
- 任務如何分配？
- 每個人手頭已有工作怎麼辦？
- 每個人能力不一樣怎麼辦？
- 每個人開發進度不一樣怎麼辦？
- 開發過程中組員生病要請長假他手頭的工作怎麼辦？
- 指揮督促大家幹活的組長請假了怎麼辦？
- 最後程式碼合併過程出現問題怎麼辦？
- 專案延期怎麼辦？
- 專案最後黃了怎麼辦？
仔細想想上面的奪命十連問，其實每一條都是對應了分散式計算可能會出現的問題，具體怎麼對應大家思考吧我就不多說了，其實已經是非常明顯了。也許有人覺得這些問題其實在多人開發的時候都不重要不需要特別去考慮怎麼辦，但是在分散式計算系統中不一樣，每一個都是非常嚴重並且非常基礎的問題，需要有很好的解決方案。
最後提一下，分散式計算目前流行的工具有：
- 離線工具Spark，MapReduce等
- 實時工具Spark Streaming，Storm，Flink等
這幾個東西的區別和各自的應用場景我們之後再聊。
分散式儲存
傳統的網路儲存系統採用的是集中的儲存伺服器存放所有資料，單臺儲存伺服器的io能力是有限的，這成為了系統性能的瓶頸，同時伺服器的可靠性和安全性也不能滿足需求，尤其是大規模的儲存應用。
分散式儲存系統，是將資料分散儲存在多臺獨立的裝置上。採用的是可擴充套件的系統結構，利用多臺儲存伺服器分擔儲存負荷，利用位置伺服器定位儲存資訊，它不但提高了系統的可靠性、可用性和存取效率，還易於擴充套件。
上圖是hdfs的儲存架構圖，hdfs作為分散式檔案系統，兼備了可靠性和擴充套件性，資料儲存3份在不同機器上（兩份存在同一機架，一份存在其他機架）保證資料不丟失。由NameNode統一管理元資料，可以任意擴充套件叢集。
主流的分散式資料庫有很多hbase，mongoDB，GreenPlum，redis等等等等，沒有孰好孰壞之分，只有合不合適，每個資料庫的應用場景都不同，其實直接比較是沒有意義的，後續我也會有文章一個個講解它們的應用場景原理架構等。
分散式排程與管理
現在人們好像都很熱衷於談"去中心化"，也許是區塊鏈帶起的這個潮流。但是"中心化"在大資料領域還是很重要的，至少目前來說是的。
- 分散式的叢集管理需要有個元件去分配排程資源給各個節點，這個東西叫yarn;
- 需要有個元件來解決在分散式環境下"鎖"的問題，這個東西叫zookeeper；
- 需要有個元件來記錄任務的依賴關係並定時排程任務，這個東西叫azkaban。
當然這些“東西”並不是唯一的，其實都是有很多替代品的，我這裡只舉了幾個比較常用的例子。
以上非常粗略地講了下大資料的幾個方面的內容，沒有涵蓋的東西還有很多。大資料是一條很長的路，無論你是新入門的菜鳥還是大廠架構師想要保持競爭力都不能停止學習的腳步，你停了你就會看見有很多人從你身後走到你身前，這是作為程式猿最苦的地方，但是也是最有趣的，因為努力就會有希望。
