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