本文授權轉載自有關SQL
禁止二次轉載
作為一名電影愛好者，我閱片無數，有些片子還經常翻來覆去看個好幾遍。小時候因為這事兒，沒少被我媽抓耳朵，「看過的片子為啥還要倒二遍？」我也說不上來，就是單純的愛看。
男人愛看的電影，以武俠，動作，科技為多，也認識了一幫明星，比如尼古拉斯凱奇，史泰龍，李小龍，成龍，李連杰，甄子丹等等。這些人很猛，有男人氣。只要是他們的片兒，肯定不落下。在我眼裡，他們就是好片代名詞。
不知幾何時，電影上開始出現一些不認識的男明星了，比如張翰，韓庚，鹿晗等等。看著這些人主演的片子，真是……哎，能不睡著就算是對得起票錢了。
後來我從半佛那裡才知道，啥叫鮮肉，啥叫老阿姨審美。假如看到有更嫩的男演員，不用問了，老阿姨審美又變了。註定又是一部爛片。
那麼，審美可以變，審詞呢？
比如這幾年，媒體一直在炒作的大數據，用前衛的詞兒來說，Big Data. 聽得人耳朵老繭都漲了一層。那麼 大家是真把它當做有效的工具呢，還是固執的認為又是換湯不換藥的營銷噱頭呢？
為弄清楚這個問題，我查了很多資料，中文的，外文的，百度文庫的， Google 論文。期間的所見所聞可以寫 3 部小說還不止。
令我印象最深的還屬這件事：
《紐約時報》將 1851 - 1922 之間的 1100 多萬篇文章，在24小時內花費3000美金，轉成 PDF 供大眾搜索查看。
資料背景指出，這些文章已經做好了 TIFF 圖檔格式，要解決的本質問題就是將 TIFF 轉換成 PDF.這件事情，工作量非常大。單純寫代碼轉換，可行，但對完工時間不好把握。
此時有個工程師，僅憑一人之力完成了這項工作，整個過程，他只做了 4 件事情：
1） 首先他是資深編程愛好者。平常閱讀技術Blog,知道 AWS, S3,EC2 等雲計算概念，還熟悉 Google 的 MapReduce 論文，並且知道 Hadoop 的功能。
2）於是他自己在他的個人電腦上，搭建了Hadoop，玩起大數據，利用 MapReduce 來試著完成 TIFF 到 PDF 的轉換；
3）接著在 Amazon 上申請 4 臺 EC2 的主機，搭建了 Hadoop 集群，跑了一批 TIFF 到 PDF 轉換程序。發現居然可行。
4）大規模實施批量轉換，用了 24 個小時，3000 美金，最終將 1100 萬文章的影音圖像，轉成了 PDF，並對外提供服務。
再舉一些經過報導的大數據應用案例：
Yahoo!使用4000節點的集群運行 Hadoop, 支持廣告系統和 Web 搜索;
Facebook 使用 1000 節點運行 Hadoop, 存儲日誌數據，支持其上的數據分析和機器學習；
百度使用 Hadoop 處理每周 200TB 的數據，進行搜索日誌分析和網頁數據挖掘工作；
中移動基於 Hadoop 開發了 BigCloud 系統，提供對內外的數據支持；
淘寶的 Hadoop 則處理電子商務交易數據。
初學者要入門大數據，最好的方式，從了解具體的應用開始。掌握大數據能做哪些事情，完成哪些小數據做不到的功能，學著才有意思。只有學著有意思，才會繼續往下學。越學越想學，越學越開心，自然也就學好了。
接下來，我整理一些大數據已經發揮它真正作用的應用場景，如果你要做大數據項目，肯定離不開這7個範疇。
因此，你說大數據離我們遠嗎，我說肯定很近。不管你信不信，反正我信了。
項目一：數據整合
說到數據整合，我們做數據的人，一般想到的是數據倉庫。
image當我們有很多應用，比如 MES, ERP, HR, SALES AND Marketing, CRM 等，每個應用都是一些獨立的數據島，每個使用這些應用的人，都可以從這些應用裡面找到自己想要的數據和答案，如果找不到也可以找IT幫你做報表。
但是當我們需要的數據，是整條完整的數據鏈，這些系統就顯得無力了。比如我們要分析每個 ERP 的成本中心，到底分攤到每個車間，每道工序，有多少成本時，僅僅靠ERP就無能為力了，必須將 MES 的數據導入ERP，綜合起來分析。此時，ERP數據就會整合部分的MES數據。但本身ERP是排斥這些MES數據的，過於詳細，對BOM,PP等的支持粒度不夠，需要重新寫代碼完善。
那麼與其把這些數據都導入ERP，再重新編碼，那還不如將MES,ERP的數據整合到一個資料庫裡面，重新出完整的數據字典，供財務或者運營去做分析。這就是數據倉庫的作用了。
如果HR也想要從數據中，得到招聘人員的產出，同樣也需要整合HR系統。CRM的分析師，可能想知道某個客戶的利潤，是否與生產成正相關，總不能讓利潤最少的客戶長期霸佔工廠的資源吧。因此CRM也可以接入到數據倉庫來。
當數據倉庫數據量超額時，比如 Oracle 成本已經很高，且計算能力也達不到旺盛的分析需求時，就需要考慮 Hadoop 了。因此 Hadoop 在這裡扮演的角色就是數據倉庫的落地數據存儲和計算。
從傳統的數據倉庫架構擴展而來，此時企業的數據倉庫又多了一層大數據，如下圖：
image但是也有可能，Hadoop 的離線應用完成了聚合，分析師需要從原有的RDBMS獲取，那麼我們就需要回寫到RDBMS裡面來，方便分析師的調用。這裡需要說明下為什麼要回寫關係資料庫（SQL類資料庫），很多分析師還在使用 Excel 和 Tableau 做數據分析，而這類工具最搭配的便是 RDBMS， SQL 的學習成本放在那裡，Excel 的易用性擺在那裡，還有 Tableau 漂亮的UI。而從 Hadoop 這類分布式數據系統中，取數分析，需要新型的作戰武器， Zepplin 或者 IPython Notebook , 當然這類工具，SQL還是必不可少。
總之，數據整合是 Hadoop 的最基礎應用，扮演的可能是最終存儲，也有可能是整條數據鏈上的一環，也就是ETL中的任一角色。
在正式的報告中（官方文檔或者公司知識庫），大家會採用"企業級數據中心"或者"數據湖"來表示 Hadoop 的這類應用。
為什麼要用 Hadoop 而不是傳統的 Teradata 和 Netezza 呢？
很大的原因，Teradata， Netezza 的成本不是一般的高，如果用來存儲一些非交易性的數據，造成很大的資源成本。比如評論，用戶行為，這些完全可以存儲在 Hadoop 的低成本集群中
項目二：專業分析
在《Spark高級數據分析》這本書裡講到一個實例，就是:
Estimating Financial Risk Through Monte Carlo Simulation
這本書電子版我放在微信公眾號【有關SQL】裡頭，關注並回復【1024】便可下載。
蒙特卡洛模擬分析，用來預測和監控銀行流動性風險。這類專業應用，一般的軟體公司並不會去考慮如何兼容，如何做的性能更優，比如數據量巨大的情況下，R有什麼特別好的方法去處理，T-SQL會怎麼處理，恐怕都無能為力？
針對有限的數據量，上述兩個工具會 有不錯的效果，但如今的數據量堆積下，要將原本一臺單機提供的算力，複製到成千上百臺計算機，傳統的RDBMS和分析工具都會失效。
此時，Hadoop 配合 Spark 的組合，就有用武之地了！
眾所周知，Yahoo!已有4000個Hadoop節點，用這4000個節點去計算一次聚合統計，比如有4億的訂單，需要核算每個訂單的總金額，成本，和利潤，那分配到4000個節點上，每個節點平均處理10萬訂單，之後匯總即可。
所以 Hadoop 可以處理更多的量，而 Spark 則在更快的計算上滿足了需求。
拿 Spark 舉個例子，比如推薦系統。喜愛音樂的朋友會用網易雲音樂，喜歡看書的朋友經常會去亞馬遜。不難發現的事情是，當你打開這些 App 的時候，會有很多音樂或者書推薦給你，你打開這些推薦的音樂或者書，可能還會覺得很好，正是自己喜歡或者需要的。這就是推薦系統。
推薦系統最大的難點在於實時性。我們可以用 Hadoop 聚合全部人的喜好，進一步去做實時推薦。而 Hadoop 的計算框架，要搭配 MapReduce 程序使用，這類程序最大的弱點是中間結果集存檔，而不是存在內存，那麼對於推薦中經常使用的 ALS(Alternating Least Squares )算法就不友好了。這類訓練算法需要無數次回頭重讀中間結果集，每次從硬碟讀取結果（有可能還要重算），就會浪費極大的時間。
Spark 就是在解決這個問題。
它將所有的數據集封裝在 RDD(Resilient Distributed Dataset)中，這個結果集天然就帶著分布式特性，也就是每個Spark節點上都有一個小的RDD，針對RDD的計算都會分攤到這些小的RDD上，同步計算。這個特性滿足了分布式並行計算的需求，RDD還有個特性就是Cache操作，將RDD的結果緩存到內存保存，之後可以復用RDD結果集。這是Spark區別於MapReduce的重要特點,簡單說來，就是整個計算過程變快了，使得實時推薦也變成了可能。
image看上去，我們只提交了一個Spark Job,完成對輸入數據的處理，並且輸出結果。沒有特別厲害的地方。但背後做了很大的工作，它均衡地在每個數據節點上分配處理算子(Executor)，做本地處理，之後將這些中間結果集緩存起來，以提供給其他子程序使用。
項目三：大數據作為服務
通常企業足夠大，就會自建 Hadoop 集群用來滿足數據整合或者專業分析的需求。當企業擁有自主開發 Hadoop 實力之後，會有多餘的計算資源可以分享給其他企業用戶，那麼這時可以把 Hadoop 作為服務開放給市場。
這就是雲計算的力量。
國外的案例有 GCP(Google Cloud Platform), Amazon, Microsoft Azure, 而國內出色的供應商則是HTA(華為雲，騰訊雲和阿里雲).
要說明的是，Hadoop 作為雲服務的一種，需要很強的技術性。針對創業型或資源短缺性的中小企業，則可以付費使用大公司提供的服務，大家各得其所。
雲計算：基本概念
雲計算目前可分為 IAAS,SAAS,PAAS，這三者在使用上有很大區別。
都說雲計算有不可替代的成本優勢，那麼成本到底優化在哪裡？
比如公司如果內建一個運維團隊，包括硬體，軟體與人員，配套的基礎設施有機房，辦公樓。再簡單一些，這團隊由一個人，一臺伺服器，一個辦公室組成，軟體全部由這個人來編寫，採用的全部是開源技術，一年的費用算50萬。
而這些採用雲計算，這個人負責編程沒變，但是可以在咖啡館，圖書館，高鐵，飛機，任何只要有網線的地方即可，這樣就省去辦公樓，硬體與軟體的採購費用，主要成本都在雲上和應用的開發人員身上。雲上有專業的Devops團隊，有DBA專業人員保障基礎設施，還有可靠的機房雙災備，一切後顧之憂都交給了雲服務商。按照騰訊雲最新的企業雲伺服器，一年下來就3，500千塊。
即買即用，部署極速
某天公司需要使用 Hadoop 的離線大容量存儲來容納日誌，並且用 MapReduce 負責超大規模的計算，那麼自建一個大數據團隊，負責裝機，配置和搭建，可能要花去1個月左右的時間，同時還需要進行業務的梳理和代碼的編寫，等到系統完畢，上線調試，這樣大半時間下去了，效果還出不來。
而使用雲計算，接口調試好，今天就可以導入數據，極大節約了時間成本。
如果雲服務商對於每次查詢都需要結算，而大數據又是公司避不可避的戰略，那麼內建也不是大問題。但往往公司業務還沒成熟呢，就急著去部署大數據系統是不划算的。
雲計算：IAAS, SAAS, PAAS 的區別：
通過NYT(NewYorkTimes)的4T TIFF圖片數據轉PDF的事件，我們來說明這三者的區別，就很容易了：
詳細案例:https://t.zsxq.com/QrBmeaY
這個案例中，作者通過購買Amazon EC2 的100臺伺服器，將S3的4T文件轉成PDF,並最終提供給大眾搜索。
正好將IAAS,SAAS都涉及到了。比如 EC2，S3就是典型的IAAS，提供伺服器作業系統，存儲，網絡，就是典型的IAAS應用；而最終開發的PDF搜索就是SAAS應用；如果作者不是自己寫MapReduce來轉換PDF，而是使用AWS提供的編輯軟體，且使用了AWS的Hadoop, Spark作業接口實現了轉換，那麼PAAS也就被用到了。可能當時AWS並沒有提供這樣整套的開發環境。
如果你是微信小程序開發者，不難理解，小程序的開發就是在PAAS平臺上完成的。
項目四：流分析
流和流式計算一直存在於應用場景中，但在大數據未出現之前，一直做的不好。之前業界一直使用低延遲來對流進行處理，但是流的實時性，低延遲編程方法就顯得笨拙了。
之前我有文章對流處理做過詳細的科普，可以看這裡：
http://dwz.win/uCZ
此時雖然看起來與Hadoop沒有啥關係了，主要擔任重責的是 Storm, Flink, Spark, 但最終落地數據的，還是Hadoop.
舉兩個實時流分析的例子：
銀行風控：如果依據模型檢測到有大量小額連續的取款，那麼就有可能是洗錢。此時應當場凍結帳戶，而不是等到整個取款過程結束，通過跑批次去檢測某帳戶洗錢，再進行追溯，凍結。無論是低延遲還是分批處理，都不足以彌補帳戶的損失，只有實時流分析才可以解決這個場景應用。
庫存管控：比如雙11，雙12的在線秒殺，如果2萬件iPhone11半折秒，瘋搶的人數達到2000萬，那麼對於實時庫存就要計算很精確。就像有些公司搞的飢餓營銷，不到1s，上百萬手機一搶而空，造成假象，帶給消費者的印象就low了。
以上只是流分析的冰山一角，只要有需求存在就有流分析存在。但也不是所有場景都需要流分析來處理，有些歷史統計或者預測分析，還是通過跑批的方式，成本會更小。
項目五：複雜的事件處理
事件有兩個維度的屬性，時間與時長。
在時間線上保持連續不斷發生的事件，形成一個流，就像是水龍頭出來的水一樣，只有積累多了才能派上用場，針對這類數據做處理，我們稱之為流式處理；孤立這段時間，選取當前時間點發生的事件，做單獨的處理，那就是實時處理。
這類項目裡，複雜度就是針對時間點的細化，可以是 millisecond(毫秒), nanosecond(納秒:十億分之一秒), picosecond(皮秒：一萬億分之一秒).
有的領域，比如郵件的收發，評論的發布，在秒級實現是可以接受的。而有些領域，比如量化交易，需要在更精細粒度時間上做掛單和撤單，時間差加上大資金量，能夠獲得很好的受益。
實際上，我們發評論時，在點擊發布到獲得顯示這段時間，哪怕是1-2秒，中間也可做很多處理，比如限流，關鍵字與輿情評判，內容分發。
綜上，在時間維度上做實時處理，是件複雜的事情。
之前，處理這類實時數據，最有效的方法是加緩存，加消息隊列，其原理是假定消息處理不完，就先緩存起來，經由處理方慢慢處理。現在這類需求也可以這樣處理，藉助 Redis, MessageQ, Kafka 等軟體，做到低延遲處理。
但在如今數據呈井噴式暴漲的網際網路，使用隊列處理顯得明顯低效，還可能導致數據大量積壓而無法處理。所以增加10倍，100倍，甚至1000倍機器來並行處理，變成了當今唯一可解決的方法。
比如在交通燈處，增加傳感器，增加攝像頭，使用 Spark, Storm, Flink, Apex Project 來實時傳導Iot數據，使得交管局可以實時監控路面擁堵情況，違規行為甚至犯罪行為等。
項目六：流式ETL
這是一種特殊的數據整合方法，與傳統的批次處理不一樣的是，在時間的時長維度上做了無限流的處理。除了做數據的分包轉發之外，流式ETL還可以做專業分析，並將分析結果再分包轉發。
從宏觀來看，ETL既可以有跑批的步驟，還能包含流式計算的步驟。
上述的5種項目中，都可以涉及到這種項目的設計。
image網際網路時代，慢，正在成為用戶流失的重大因素。在每個數據接口實現流式ETL變得非常有必要，實現數據流動無斷點，建立 Streaming Platform 變得越來越重要。
最適合用來搭建流式ETL的工具，Kafka.
一旦消息入庫（Kafka）,我們要做的事情就像是從水庫接水一樣，接入管道即可。
imageNetFlix公司在Kafka實時流式處理方面有前衛的探索，在這裡一窺究竟：
image項目七：可視化分析
市面上很多統計分析軟體都比較昂貴，他們獨有的算法搭配內建的可視化展現組件，經過多年市場檢驗，越磨越好用。但成本上就是下不去，比如 SAS.
但如今大數據量的市場下，這些傳統供應商顯得不夠友好，因此催生了iPython Notebook, Zeppelin 等一系列可直接用於大數據的可視化分析工具。尤其Python,Spark社群在機器學習，深度學習軟體庫上的開發，使得整個大數據統計分析生態日臻完美，不僅對數據挖掘算法有友好的支持，對數據可視化組件也提供了開箱即用的軟體包。
以上項目中所參考的書目，論文，材料，我已經列好電子書，放在個人微信【jjxksa888】中,掃碼即可添加，備註：讀者。
image以上來自 Andrew C. Oliver 的文章《the 7 most common Hadoop and Spark projects》以及其他百度文庫參考資料 - https://www.javaworld.com/article/2972303/the-7-most-common-hadoop-and-spark-projects.html
Oliver 就是《7周7程式語言》的作者 https://www.techworld.com.au/article/455387/epic_codefest_7_programming_languages_7_days/