原創(chuàng)： Lenis 有關(guān)SQL

1

作為一名電影愛好者，我閱片無數(shù)歉备，有些片子還經(jīng)常翻來覆去看個(gè)好幾遍傅是。小時(shí)候因?yàn)檫@事兒，沒少被我媽抓耳朵蕾羊，“看過的片子為啥還要倒二遍喧笔？”我也說不上來，就是單純的愛看龟再。

男人愛看的電影书闸，以武俠，動(dòng)作利凑，科技為多浆劲，也認(rèn)識(shí)了一幫明星嫌术，比如尼古拉斯凱奇，史泰龍牌借，李小龍度气，成龍，李連杰膨报，甄子丹等等磷籍。這些人很猛，有男人氣现柠。只要是他們的片兒院领，肯定不落下。在我眼里够吩，他們就是好片代名詞比然。

不知幾何時(shí)，電影上開始出現(xiàn)一些不認(rèn)識(shí)的男明星了周循，比如張翰强法，韓庚，鹿晗等等鱼鼓∧馓蹋看著這些人主演的片子该编，真是……哎迄本，能不睡著就算是對(duì)得起票錢了。

后來我從半佛那里才知道课竣，啥叫鮮肉嘉赎，啥叫老阿姨審美。假如看到有更嫩的男演員于樟，不用問了公条，老阿姨審美又變了。注定又是一部爛片迂曲。

那么靶橱，審美可以變，審詞呢路捧？

比如這幾年关霸，媒體一直在炒作的大數(shù)據(jù)，用前衛(wèi)的詞兒來說杰扫，Big Data. 聽得人耳朵老繭都漲了一層队寇。那么 大家是真把它當(dāng)做有效的工具呢，還是固執(zhí)的認(rèn)為又是換湯不換藥的營銷噱頭呢章姓？

為弄清楚這個(gè)問題佳遣，我查了很多資料识埋，中文的，外文的零渐，百度文庫的窒舟， Google 論文。期間的所見所聞可以寫 3 部小說還不止相恃。

令我印象最深的還屬這件事：

《紐約時(shí)報(bào)》將 1851 - 1922 之間的 1100 多萬篇文章辜纲，在24小時(shí)內(nèi)花費(fèi)3000美金，轉(zhuǎn)成 PDF 供大眾搜索查看拦耐。

資料背景指出耕腾，這些文章已經(jīng)做好了 TIFF 圖檔格式，要解決的本質(zhì)問題就是將 TIFF 轉(zhuǎn)換成 PDF.這件事情杀糯，工作量非常大扫俺。單純寫代碼轉(zhuǎn)換，可行固翰，但對(duì)完工時(shí)間不好把握狼纬。

此時(shí)有個(gè)工程師，僅憑一人之力完成了這項(xiàng)工作骂际，整個(gè)過程疗琉，他只做了 4 件事情：

1） 首先他是資深編程愛好者。平常閱讀技術(shù)Blog,知道 AWS, S3,EC2 等云計(jì)算概念歉铝，還熟悉 Google 的 MapReduce 論文盈简，并且知道 Hadoop 的功能。

2）于是他自己在他的個(gè)人電腦上太示，搭建了Hadoop柠贤，玩起大數(shù)據(jù)，利用 MapReduce 來試著完成 TIFF 到 PDF 的轉(zhuǎn)換类缤；

3）接著在 Amazon 上申請 4 臺(tái) EC2 的主機(jī)臼勉，搭建了 Hadoop 集群，跑了一批 TIFF 到 PDF 轉(zhuǎn)換程序餐弱。發(fā)現(xiàn)居然可行宴霸。

4）大規(guī)模實(shí)施批量轉(zhuǎn)換，用了 24 個(gè)小時(shí)膏蚓，3000 美金瓢谢，最終將 1100 萬文章的影音圖像，轉(zhuǎn)成了 PDF降允，并對(duì)外提供服務(wù)恩闻。

再舉一些經(jīng)過報(bào)道的大數(shù)據(jù)應(yīng)用案例：

Yahoo!使用4000節(jié)點(diǎn)的集群運(yùn)行 Hadoop, 支持廣告系統(tǒng)和 Web 搜索;

Facebook 使用 1000 節(jié)點(diǎn)運(yùn)行 Hadoop, 存儲(chǔ)日志數(shù)據(jù)，支持其上的數(shù)據(jù)分析和機(jī)器學(xué)習(xí)剧董；

百度使用 Hadoop 處理每周 200TB 的數(shù)據(jù)幢尚，進(jìn)行搜索日志分析和網(wǎng)頁數(shù)據(jù)挖掘工作破停；

中移動(dòng)基于 Hadoop 開發(fā)了 BigCloud 系統(tǒng)，提供對(duì)內(nèi)外的數(shù)據(jù)支持尉剩；

淘寶的 Hadoop 則處理電子商務(wù)交易數(shù)據(jù)真慢。

初學(xué)者要入門大數(shù)據(jù)，最好的方式理茎，從了解具體的應(yīng)用開始黑界。掌握大數(shù)據(jù)能做哪些事情，完成哪些小數(shù)據(jù)做不到的功能皂林，學(xué)著才有意思朗鸠。只有學(xué)著有意思，才會(huì)繼續(xù)往下學(xué)础倍。越學(xué)越想學(xué)烛占，越學(xué)越開心，自然也就學(xué)好了沟启。

接下來忆家，我整理一些大數(shù)據(jù)已經(jīng)發(fā)揮它真正作用的應(yīng)用場景，如果你要做大數(shù)據(jù)項(xiàng)目德迹，肯定離不開這7個(gè)范疇芽卿。

因此，你說大數(shù)據(jù)離我們遠(yuǎn)嗎胳搞，我說肯定很近卸例。不管你信不信，反正我信了流酬。

2

項(xiàng)目一：數(shù)據(jù)整合

說到數(shù)據(jù)整合币厕，我們做數(shù)據(jù)的人列另，一般想到的是數(shù)據(jù)倉庫芽腾。

當(dāng)我們有很多應(yīng)用，比如 MES, ERP, HR, SALES AND Marketing, CRM 等页衙，每個(gè)應(yīng)用都是一些獨(dú)立的數(shù)據(jù)島摊滔，每個(gè)使用這些應(yīng)用的人，都可以從這些應(yīng)用里面找到自己想要的數(shù)據(jù)和答案店乐，如果找不到也可以找IT幫你做報(bào)表艰躺。

但是當(dāng)我們需要的數(shù)據(jù)，是整條完整的數(shù)據(jù)鏈眨八，這些系統(tǒng)就顯得無力了腺兴。比如我們要分析每個(gè) ERP 的成本中心，到底分?jǐn)偟矫總€(gè)車間廉侧，每道工序页响，有多少成本時(shí)篓足，僅僅靠ERP就無能為力了，必須將 MES 的數(shù)據(jù)導(dǎo)入ERP闰蚕，綜合起來分析栈拖。此時(shí)，ERP數(shù)據(jù)就會(huì)整合部分的MES數(shù)據(jù)没陡。但本身ERP是排斥這些MES數(shù)據(jù)的涩哟，過于詳細(xì)，對(duì)BOM,PP等的支持粒度不夠盼玄，需要重新寫代碼完善贴彼。

那么與其把這些數(shù)據(jù)都導(dǎo)入ERP，再重新編碼埃儿，那還不如將MES,ERP的數(shù)據(jù)整合到一個(gè)數(shù)據(jù)庫里面锻弓，重新出完整的數(shù)據(jù)字典，供財(cái)務(wù)或者運(yùn)營去做分析蝌箍。這就是數(shù)據(jù)倉庫的作用了青灼。

如果HR也想要從數(shù)據(jù)中，得到招聘人員的產(chǎn)出妓盲，同樣也需要整合HR系統(tǒng)杂拨。CRM的分析師，可能想知道某個(gè)客戶的利潤悯衬，是否與生產(chǎn)成正相關(guān)弹沽，總不能讓利潤最少的客戶長期霸占工廠的資源吧。因此CRM也可以接入到數(shù)據(jù)倉庫來筋粗。

當(dāng)數(shù)據(jù)倉庫數(shù)據(jù)量超額時(shí)策橘，比如 Oracle 成本已經(jīng)很高，且計(jì)算能力也達(dá)不到旺盛的分析需求時(shí)娜亿，就需要考慮 Hadoop 了丽已。因此 Hadoop 在這里扮演的角色就是數(shù)據(jù)倉庫的落地?cái)?shù)據(jù)存儲(chǔ)和計(jì)算。

從傳統(tǒng)的數(shù)據(jù)倉庫架構(gòu)擴(kuò)展而來买决，此時(shí)企業(yè)的數(shù)據(jù)倉庫又多了一層大數(shù)據(jù)沛婴，如下圖：

（圖來自mastechinfotrellis.com）

但是也有可能，Hadoop 的離線應(yīng)用完成了聚合督赤，分析師需要從原有的RDBMS獲取嘁灯，那么我們就需要回寫到RDBMS里面來，方便分析師的調(diào)用躲舌。這里需要說明下為什么要回寫關(guān)系數(shù)據(jù)庫（SQL類數(shù)據(jù)庫）丑婿，很多分析師還在使用 Excel 和 Tableau 做數(shù)據(jù)分析，而這類工具最搭配的便是 RDBMS， SQL 的學(xué)習(xí)成本放在那里羹奉，Excel 的易用性擺在那里毅贮，還有 Tableau 漂亮的UI。而從 Hadoop 這類分布式數(shù)據(jù)系統(tǒng)中尘奏，取數(shù)分析滩褥，需要新型的作戰(zhàn)武器， Zepplin 或者 IPython Notebook , 當(dāng)然這類工具炫加，SQL還是必不可少瑰煎。

總之，數(shù)據(jù)整合是 Hadoop 的最基礎(chǔ)應(yīng)用俗孝，扮演的可能是最終存儲(chǔ)酒甸，也有可能是整條數(shù)據(jù)鏈上的一環(huán)，也就是ETL中的任一角色赋铝。

在正式的報(bào)告中（官方文檔或者公司知識(shí)庫）嗽冒，大家會(huì)采用"企業(yè)級(jí)數(shù)據(jù)中心"或者"數(shù)據(jù)湖"來表示 Hadoop 的這類應(yīng)用疫诽。

為什么要用 Hadoop 而不是傳統(tǒng)的 Teradata 和 Netezza 呢煮岁？

很大的原因屉符，Teradata， Netezza 的成本不是一般的高良哲，如果用來存儲(chǔ)一些非交易性的數(shù)據(jù)盛卡，造成很大的資源成本。比如評(píng)論筑凫，用戶行為滑沧，這些完全可以存儲(chǔ)在 Hadoop 的低成本集群中

項(xiàng)目二：專業(yè)分析

在《Spark高級(jí)數(shù)據(jù)分析》這本書里講到一個(gè)實(shí)例，就是:

Estimating Financial Risk Through Monte Carlo Simulation

蒙特卡洛模擬分析巍实，用來預(yù)測和監(jiān)控銀行流動(dòng)性風(fēng)險(xiǎn)滓技。這類專業(yè)應(yīng)用，一般的軟件公司并不會(huì)去考慮如何兼容棚潦，如何做的性能更優(yōu)令漂，比如數(shù)據(jù)量巨大的情況下，R有什么特別好的方法去處理瓦盛，T-SQL會(huì)怎么處理洗显，恐怕都無能為力外潜？

針對(duì)有限的數(shù)據(jù)量原环，上述兩個(gè)工具會(huì) 有不錯(cuò)的效果，但如今的數(shù)據(jù)量堆積下处窥，要將原本一臺(tái)單機(jī)提供的算力嘱吗，復(fù)制到成千上百臺(tái)計(jì)算機(jī)，傳統(tǒng)的RDBMS和分析工具都會(huì)失效。

此時(shí)谒麦，Hadoop 配合 Spark 的組合俄讹，就有用武之地了！

眾所周知绕德，Yahoo!已有4000個(gè)Hadoop節(jié)點(diǎn)患膛，用這4000個(gè)節(jié)點(diǎn)去計(jì)算一次聚合統(tǒng)計(jì)，比如有4億的訂單耻蛇，需要核算每個(gè)訂單的總金額踪蹬，成本，和利潤臣咖，那分配到4000個(gè)節(jié)點(diǎn)上跃捣，每個(gè)節(jié)點(diǎn)平均處理10萬訂單，之后匯總即可夺蛇。

所以 Hadoop 可以處理更多的量疚漆，而 Spark 則在更快的計(jì)算上滿足了需求。

拿 Spark 舉個(gè)例子刁赦，比如推薦系統(tǒng)娶聘。喜愛音樂的朋友會(huì)用網(wǎng)易云音樂，喜歡看書的朋友經(jīng)常會(huì)去亞馬遜甚脉。不難發(fā)現(xiàn)的事情是趴荸，當(dāng)你打開這些 App 的時(shí)候，會(huì)有很多音樂或者書推薦給你宦焦，你打開這些推薦的音樂或者書发钝，可能還會(huì)覺得很好，正是自己喜歡或者需要的波闹。這就是推薦系統(tǒng)酝豪。

推薦系統(tǒng)最大的難點(diǎn)在于實(shí)時(shí)性。我們可以用 Hadoop 聚合全部人的喜好精堕，進(jìn)一步去做實(shí)時(shí)推薦孵淘。而 Hadoop 的計(jì)算框架，要搭配 MapReduce 程序使用歹篓，這類程序最大的弱點(diǎn)是中間結(jié)果集存盤瘫证，而不是存在內(nèi)存，那么對(duì)于推薦中經(jīng)常使用的 ALS(Alternating Least Squares )算法就不友好了庄撮。這類訓(xùn)練算法需要無數(shù)次回頭重讀中間結(jié)果集背捌，每次從硬盤讀取結(jié)果（有可能還要重算），就會(huì)浪費(fèi)極大的時(shí)間洞斯。

Spark 就是在解決這個(gè)問題毡庆。

它將所有的數(shù)據(jù)集封裝在 RDD(Resilient Distributed Dataset)中，這個(gè)結(jié)果集天然就帶著分布式特性，也就是每個(gè)Spark節(jié)點(diǎn)上都有一個(gè)小的RDD么抗，針對(duì)RDD的計(jì)算都會(huì)分?jǐn)偟竭@些小的RDD上毅否，同步計(jì)算。這個(gè)特性滿足了分布式并行計(jì)算的需求蝇刀，RDD還有個(gè)特性就是Cache操作螟加，將RDD的結(jié)果緩存到內(nèi)存保存，之后可以復(fù)用RDD結(jié)果集吞琐。這是Spark區(qū)別于MapReduce的重要特點(diǎn),簡單說來仰迁，就是整個(gè)計(jì)算過程變快了，使得實(shí)時(shí)推薦也變成了可能顽分。

看上去徐许，我們只提交了一個(gè)Spark Job,完成對(duì)輸入數(shù)據(jù)的處理，并且輸出結(jié)果卒蘸。沒有特別厲害的地方雌隅。但背后做了很大的工作，它均衡地在每個(gè)數(shù)據(jù)節(jié)點(diǎn)上分配處理算子(Executor)缸沃，做本地處理恰起，之后將這些中間結(jié)果集緩存起來，以提供給其他子程序使用趾牧。

項(xiàng)目三：大數(shù)據(jù)作為服務(wù)

通常企業(yè)足夠大检盼，就會(huì)自建 Hadoop 集群用來滿足數(shù)據(jù)整合或者專業(yè)分析的需求。當(dāng)企業(yè)擁有自主開發(fā) Hadoop 實(shí)力之后翘单，會(huì)有多余的計(jì)算資源可以分享給其他企業(yè)用戶吨枉，那么這時(shí)可以把 Hadoop 作為服務(wù)開放給市場。

這就是云計(jì)算的力量哄芜。

國外的案例有 GCP(Google Cloud Platform), Amazon, Microsoft Azure, 而國內(nèi)出色的供應(yīng)商則是HTA(華為云貌亭，騰訊云和阿里云).

要說明的是，Hadoop 作為云服務(wù)的一種认臊，需要很強(qiáng)的技術(shù)性圃庭。針對(duì)創(chuàng)業(yè)型或資源短缺性的中小企業(yè)，則可以付費(fèi)使用大公司提供的服務(wù)失晴，大家各得其所剧腻。

云計(jì)算：基本概念

云計(jì)算目前可分為 IAAS,SAAS,PAAS，這三者在使用上有很大區(qū)別涂屁。

都說云計(jì)算有不可替代的成本優(yōu)勢书在，那么成本到底優(yōu)化在哪里？

比如公司如果內(nèi)建一個(gè)運(yùn)維團(tuán)隊(duì)胯陋，包括硬件蕊温，軟件與人員袱箱，配套的基礎(chǔ)設(shè)施有機(jī)房遏乔，辦公樓义矛。再簡單一些，這團(tuán)隊(duì)由一個(gè)人盟萨，一臺(tái)服務(wù)器凉翻，一個(gè)辦公室組成，軟件全部由這個(gè)人來編寫捻激，采用的全部是開源技術(shù)制轰，一年的費(fèi)用算50萬。

而這些采用云計(jì)算胞谭，這個(gè)人負(fù)責(zé)編程沒變垃杖，但是可以在咖啡館，圖書館丈屹，高鐵调俘，飛機(jī)，任何只要有網(wǎng)線的地方即可旺垒，這樣就省去辦公樓彩库，硬件與軟件的采購費(fèi)用，主要成本都在云上和應(yīng)用的開發(fā)人員身上先蒋。云上有專業(yè)的Devops團(tuán)隊(duì)骇钦，有DBA專業(yè)人員保障基礎(chǔ)設(shè)施，還有可靠的機(jī)房雙災(zāi)備竞漾，一切后顧之憂都交給了云服務(wù)商眯搭。按照騰訊云最新的企業(yè)云服務(wù)器，一年下來就3业岁，500千塊坦仍。

即買即用，部署極速

某天公司需要使用 Hadoop 的離線大容量存儲(chǔ)來容納日志叨襟，并且用 MapReduce 負(fù)責(zé)超大規(guī)模的計(jì)算繁扎，那么自建一個(gè)大數(shù)據(jù)團(tuán)隊(duì)，負(fù)責(zé)裝機(jī)糊闽，配置和搭建梳玫，可能要花去1個(gè)月左右的時(shí)間，同時(shí)還需要進(jìn)行業(yè)務(wù)的梳理和代碼的編寫右犹，等到系統(tǒng)完畢提澎，上線調(diào)試，這樣大半時(shí)間下去了念链，效果還出不來盼忌。

而使用云計(jì)算积糯，接口調(diào)試好，今天就可以導(dǎo)入數(shù)據(jù)谦纱，極大節(jié)約了時(shí)間成本看成。

如果云服務(wù)商對(duì)于每次查詢都需要結(jié)算，而大數(shù)據(jù)又是公司避不可避的戰(zhàn)略跨嘉，那么內(nèi)建也不是大問題川慌。但往往公司業(yè)務(wù)還沒成熟呢，就急著去部署大數(shù)據(jù)系統(tǒng)是不劃算的祠乃。

云計(jì)算：IAAS, SAAS, PAAS 的區(qū)別：

通過NYT(NewYorkTimes)的4T TIFF圖片數(shù)據(jù)轉(zhuǎn)PDF的事件梦重，我們來說明這三者的區(qū)別，就很容易了：

詳細(xì)案例:https://developer.aliyun.com/article/741504?utm_content=g_1000098468

這個(gè)案例中亮瓷，作者通過購買Amazon EC2 的100臺(tái)服務(wù)器琴拧，將S3的4T文件轉(zhuǎn)成PDF,并最終提供給大眾搜索。

正好將IAAS,SAAS都涉及到了嘱支。比如 EC2蚓胸，S3就是典型的IAAS，提供服務(wù)器操作系統(tǒng)斗塘，存儲(chǔ)赢织，網(wǎng)絡(luò)，就是典型的IAAS應(yīng)用馍盟；而最終開發(fā)的PDF搜索就是SAAS應(yīng)用于置；如果作者不是自己寫MapReduce來轉(zhuǎn)換PDF，而是使用AWS提供的編輯軟件贞岭，且使用了AWS的Hadoop, Spark作業(yè)接口實(shí)現(xiàn)了轉(zhuǎn)換八毯，那么PAAS也就被用到了∶榻埃可能當(dāng)時(shí)AWS并沒有提供這樣整套的開發(fā)環(huán)境话速。

如果你是微信小程序開發(fā)者，不難理解芯侥，小程序的開發(fā)就是在PAAS平臺(tái)上完成的泊交。

項(xiàng)目四：流分析

流和流式計(jì)算一直存在于應(yīng)用場景中，但在大數(shù)據(jù)未出現(xiàn)之前柱查，一直做的不好廓俭。之前業(yè)界一直使用低延遲來對(duì)流進(jìn)行處理，但是流的實(shí)時(shí)性唉工，低延遲編程方法就顯得笨拙了研乒。

之前我有文章對(duì)流處理做過詳細(xì)的科普，可以看這里：

https://developer.aliyun.com/article/741504?utm_content=g_1000098468

此時(shí)雖然看起來與Hadoop沒有啥關(guān)系了淋硝，主要擔(dān)任重責(zé)的是 Storm, Flink, Spark, 但最終落地?cái)?shù)據(jù)的雹熬，還是Hadoop.

舉兩個(gè)實(shí)時(shí)流分析的例子：

銀行風(fēng)控：如果依據(jù)模型檢測到有大量小額連續(xù)的取款宽菜，那么就有可能是洗錢。此時(shí)應(yīng)當(dāng)場凍結(jié)賬戶竿报，而不是等到整個(gè)取款過程結(jié)束铅乡，通過跑批次去檢測某賬戶洗錢，再進(jìn)行追溯仰楚，凍結(jié)隆判。無論是低延遲還是分批處理犬庇，都不足以彌補(bǔ)賬戶的損失僧界，只有實(shí)時(shí)流分析才可以解決這個(gè)場景應(yīng)用。

庫存管控：比如雙11臭挽，雙12的在線秒殺捂襟，如果2萬件iPhone11半折秒，瘋搶的人數(shù)達(dá)到2000萬欢峰，那么對(duì)于實(shí)時(shí)庫存就要計(jì)算很精確葬荷。就像有些公司搞的饑餓營銷，不到1s纽帖，上百萬手機(jī)一搶而空宠漩，造成假象，帶給消費(fèi)者的印象就low了懊直。

以上只是流分析的冰山一角扒吁，只要有需求存在就有流分析存在。但也不是所有場景都需要流分析來處理室囊，有些歷史統(tǒng)計(jì)或者預(yù)測分析雕崩，還是通過跑批的方式，成本會(huì)更小融撞。

項(xiàng)目五：復(fù)雜的事件處理

事件有兩個(gè)維度的屬性盼铁，時(shí)間與時(shí)長。

在時(shí)間線上保持連續(xù)不斷發(fā)生的事件尝偎，形成一個(gè)流饶火，就像是水龍頭出來的水一樣，只有積累多了才能派上用場致扯，針對(duì)這類數(shù)據(jù)做處理肤寝，我們稱之為流式處理；孤立這段時(shí)間急前，選取當(dāng)前時(shí)間點(diǎn)發(fā)生的事件醒陆，做單獨(dú)的處理，那就是實(shí)時(shí)處理裆针。

這類項(xiàng)目里刨摩，復(fù)雜度就是針對(duì)時(shí)間點(diǎn)的細(xì)化寺晌，可以是 millisecond(毫秒), nanosecond(納秒:十億分之一秒), picosecond(皮秒：一萬億分之一秒).

有的領(lǐng)域，比如郵件的收發(fā)澡刹，評(píng)論的發(fā)布呻征，在秒級(jí)實(shí)現(xiàn)是可以接受的。而有些領(lǐng)域罢浇，比如量化交易陆赋，需要在更精細(xì)粒度時(shí)間上做掛單和撤單，時(shí)間差加上大資金量嚷闭，能夠獲得很好的受益攒岛。

實(shí)際上，我們發(fā)評(píng)論時(shí)胞锰，在點(diǎn)擊發(fā)布到獲得顯示這段時(shí)間灾锯，哪怕是1-2秒，中間也可做很多處理嗅榕，比如限流顺饮，關(guān)鍵字與輿情評(píng)判，內(nèi)容分發(fā)凌那。

綜上兼雄，在時(shí)間維度上做實(shí)時(shí)處理，是件復(fù)雜的事情帽蝶。

之前赦肋，處理這類實(shí)時(shí)數(shù)據(jù)，最有效的方法是加緩存嘲碱，加消息隊(duì)列金砍，其原理是假定消息處理不完，就先緩存起來麦锯，經(jīng)由處理方慢慢處理∷〕恚現(xiàn)在這類需求也可以這樣處理，借助 Redis, MessageQ, Kafka 等軟件扶欣，做到低延遲處理鹅巍。

但在如今數(shù)據(jù)呈井噴式暴漲的互聯(lián)網(wǎng)，使用隊(duì)列處理顯得明顯低效料祠，還可能導(dǎo)致數(shù)據(jù)大量積壓而無法處理骆捧。所以增加10倍，100倍髓绽，甚至1000倍機(jī)器來并行處理敛苇，變成了當(dāng)今唯一可解決的方法。

比如在交通燈處顺呕，增加傳感器枫攀，增加攝像頭括饶，使用 Spark, Storm, Flink, Apex Project 來實(shí)時(shí)傳導(dǎo)Iot數(shù)據(jù)，使得交管局可以實(shí)時(shí)監(jiān)控路面擁堵情況来涨，違規(guī)行為甚至犯罪行為等图焰。

項(xiàng)目六：流式ETL

這是一種特殊的數(shù)據(jù)整合方法，與傳統(tǒng)的批次處理不一樣的是蹦掐，在時(shí)間的時(shí)長維度上做了無限流的處理技羔。除了做數(shù)據(jù)的分包轉(zhuǎn)發(fā)之外，流式ETL還可以做專業(yè)分析卧抗，并將分析結(jié)果再分包轉(zhuǎn)發(fā)藤滥。

從宏觀來看，ETL既可以有跑批的步驟颗味，還能包含流式計(jì)算的步驟超陆。

上述的5種項(xiàng)目中牺弹，都可以涉及到這種項(xiàng)目的設(shè)計(jì)浦马。

（圖來自Confluent公司）

互聯(lián)網(wǎng)時(shí)代，慢张漂，正在成為用戶流失的重大因素晶默。在每個(gè)數(shù)據(jù)接口實(shí)現(xiàn)流式ETL變得非常有必要，實(shí)現(xiàn)數(shù)據(jù)流動(dòng)無斷點(diǎn)航攒，建立 Streaming Platform 變得越來越重要磺陡。

最適合用來搭建流式ETL的工具，Kafka.

一旦消息入庫（Kafka）,我們要做的事情就像是從水庫接水一樣漠畜，接入管道即可币他。

（圖來自Confluent公司）

NetFlix公司在Kafka實(shí)時(shí)流式處理方面有前衛(wèi)的探索，在這里一窺究竟：

項(xiàng)目七：可視化分析

市面上很多統(tǒng)計(jì)分析軟件都比較昂貴憔狞，他們獨(dú)有的算法搭配內(nèi)建的可視化展現(xiàn)組件蝴悉，經(jīng)過多年市場檢驗(yàn)，越磨越好用瘾敢。但成本上就是下不去拍冠，比如 SAS.

但如今大數(shù)據(jù)量的市場下，這些傳統(tǒng)供應(yīng)商顯得不夠友好簇抵，因此催生了iPython Notebook, Zeppelin 等一系列可直接用于大數(shù)據(jù)的可視化分析工具庆杜。尤其Python,Spark社群在機(jī)器學(xué)習(xí)，深度學(xué)習(xí)軟件庫上的開發(fā)碟摆，使得整個(gè)大數(shù)據(jù)統(tǒng)計(jì)分析生態(tài)日臻完美晃财，不僅對(duì)數(shù)據(jù)挖掘算法有友好的支持，對(duì)數(shù)據(jù)可視化組件也提供了開箱即用的軟件包典蜕。