架構(gòu)大數(shù)據(jù)分析應(yīng)用/典型分布式大數(shù)據(jù)架構(gòu)的基礎(chǔ)模型

這是《Scalable Big Data Architecture》一書的翻譯筆記和讀書札記，使用了原書中的大量圖片，融入了自己的部分觀點(diǎn) ….典型使用場景….大數(shù)據(jù)生態(tài)系統(tǒng)……..

數(shù)據(jù)管理比以往更加復(fù)雜，到處都是大數(shù)據(jù)，包括每個(gè)人的想法以及不同的形式:廣告 , 社交圖譜,信息流 ,推薦 ,市場, 健康, 安全, 政府等等.過去的三年里，成千上萬的技術(shù)必須處理匯合在一起的大數(shù)據(jù)獲取，管理 和分析; 技術(shù)選型對IT部門來說是一件艱巨的任務(wù)，因?yàn)樵诖蠖鄶?shù)時(shí)間里沒有一個(gè)綜合的方法來用于選型.

當(dāng)自己面臨選擇的時(shí)候，通常會(huì)問如下的問題: 什么時(shí)候需要考慮在IT系統(tǒng)中使用大數(shù)據(jù)? 準(zhǔn)備好使用了么? 從哪里開始? 感覺大數(shù)據(jù)只是一種市場趨勢，我還是應(yīng)該去做么？這些問題縈繞著CIO和CTO們，當(dāng)決定部署一個(gè)全局化分布式大數(shù)據(jù)架構(gòu)時(shí)，可能會(huì)把企業(yè)置于危險(xiǎn)之中。

本章目的時(shí)定義大數(shù)據(jù)的表征—換句話說，就是什么時(shí)候需要考慮將大數(shù)據(jù)放入架構(gòu)。 但是，也指出了各種大數(shù)據(jù)技術(shù)的區(qū)別，能夠理解在何種情況使用哪種技術(shù)。

最后, 基于真實(shí)世界的例子，構(gòu)建了典型分布式大數(shù)據(jù)架構(gòu)的基礎(chǔ)模型。

定義大數(shù)據(jù)表征

基于不同的需要，可能選擇開始大數(shù)據(jù)項(xiàng)目s: 因?yàn)樗杼幚淼臄?shù)據(jù)容量, 因?yàn)橄到y(tǒng)中數(shù)據(jù)結(jié)構(gòu)的多樣性, 因?yàn)閿U(kuò)展性問題, 或者因?yàn)樾枰鳒p數(shù)據(jù)處理的成本。 本節(jié)中，將看到怎樣的征兆意味著一個(gè)團(tuán)隊(duì)需要開始一個(gè)大數(shù)據(jù)項(xiàng)目了。

數(shù)據(jù)大小哪些事

使人們開始考慮大數(shù)據(jù)的兩個(gè)主要領(lǐng)域是何時(shí)出現(xiàn)了與數(shù)據(jù)大小和容量有關(guān)的問題。盡管大多數(shù)時(shí)間這些問題是考慮大數(shù)據(jù)的合情合理的原因，但今天而已，這并不是唯一的原因。

有其他的表征—例如數(shù)據(jù)的類型. 如何在傳統(tǒng)數(shù)據(jù)存儲(chǔ)中管理不斷增加的各種各樣的數(shù)據(jù)類型, 如SQL數(shù)據(jù)庫, 還期望象建表那樣的結(jié)構(gòu)化么? 不增加靈活性是不可行的，當(dāng)出現(xiàn)新的數(shù)據(jù)結(jié)構(gòu)是需要技術(shù)層面的無縫處理。當(dāng)討論數(shù)據(jù)類型是，需要想象非結(jié)構(gòu)化數(shù)據(jù)，圖數(shù)據(jù)，圖片，視頻，語音等等。

不但要很好的存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)，而且最好是得到一些他們之外的東西。另一表征來自于這一承諾: 大數(shù)據(jù)也可以從大容量的各種數(shù)據(jù)中提取增值信息.若干年前，對于大量讀多于寫的操作，通用的緩存或數(shù)據(jù)庫隊(duì)友每周的ETL (extract, transform,load) 處理是足夠的。如今不再是這樣的趨勢?，F(xiàn)在，需要一個(gè)架構(gòu)具備長時(shí)間處理和準(zhǔn)實(shí)時(shí)數(shù)據(jù)處理的能力。這一架構(gòu)是分布式的，而不是依賴于高性能且價(jià)格高昂的商用機(jī)，取而代之的是，高可用，性能驅(qū)動(dòng)和廉價(jià)技術(shù)所賦予的靈活性。

當(dāng)下，如何充分利用增值數(shù)據(jù)以及如何能夠原生地搜索到它們呢？為了回答這一問題，再次考慮傳統(tǒng)存儲(chǔ)中為了加速查詢而創(chuàng)建的索引。如果為了復(fù)雜查詢而索引上百列而且包含了主鍵的不確定性，會(huì)是什么樣子？不希望在一個(gè)基礎(chǔ)SQL 數(shù)據(jù)庫中做這些;取而代之的是，需要考慮按照特殊需要而使用一個(gè) NoSQL存儲(chǔ). 所以，簡單回顧一下主要路徑：數(shù)據(jù)獲取，結(jié)構(gòu)化，可視化這些真正數(shù)據(jù)管理的場景，顯而易見，數(shù)據(jù)大小不再是主要的考量因素。

典型的商務(wù)使用場景

除了技術(shù)和架構(gòu)考慮，需要面對典型大數(shù)據(jù)用例的使用場景。它們部分和特殊的工業(yè)領(lǐng)域相關(guān)； 另外的部分可能適應(yīng)于各種領(lǐng)域。這些考慮一般都是基于分析應(yīng)用的日志，例如web訪問日志,應(yīng)用服務(wù)器日志，和數(shù)據(jù)庫日志，但是也可以基于各種其他的數(shù)據(jù)源例如社交網(wǎng)絡(luò)數(shù)據(jù)。當(dāng)面對這些使用場景的時(shí)候，如果希望隨著商務(wù)的增長而彈性擴(kuò)展，就需要考慮一個(gè)分布式的大數(shù)據(jù)架構(gòu)。

客戶行為分析

感知客戶, 或者叫做 “360-度客戶視角”可能是最流行的大數(shù)據(jù)使用場景?？蛻粢暯峭ǔＳ糜陔娮由虅?wù)網(wǎng)站以及開始于一個(gè)非結(jié)構(gòu)化的點(diǎn)擊流—換而言之, 由一個(gè)訪客執(zhí)行的主動(dòng)點(diǎn)擊和被動(dòng)的網(wǎng)站導(dǎo)航操作組成。通過計(jì)算和分析點(diǎn)擊量和面向產(chǎn)品或廣告的印象，可以依賴行為而適配訪客的用戶體驗(yàn)， 目標(biāo)是得到優(yōu)化漏斗轉(zhuǎn)換的見解。

情緒分析

公司關(guān)注的是其在社交網(wǎng)絡(luò)上所被感知的形象和聲譽(yù); 把可能使他們聲名狼藉的負(fù)面事件最小化并充分利用正面事件. 通過準(zhǔn)實(shí)時(shí)爬下大量的社交數(shù)據(jù)，可以提取出社交社區(qū)中關(guān)于品牌的感受和情緒，從而找到影響用戶并練習(xí)他們，改變并強(qiáng)化與這些用戶的交互。

CRM Onboarding

基于訪客的社交行為，可以將客戶的行為分析和數(shù)據(jù)的情感分析結(jié)合在一起。公司希望將這些在線數(shù)據(jù)源和已經(jīng)存在的離線數(shù)據(jù)結(jié)合在一起，這叫做 CRM (customer relationship management) onboarding, 以便于得到更好和更準(zhǔn)確的客戶定位. 進(jìn)而,公司能夠充分利用這一定位，從而建立更好的目標(biāo)系統(tǒng)使市場活動(dòng)的效益最大化。

預(yù)測

從數(shù)據(jù)中學(xué)習(xí)在過去幾年已經(jīng)成為主要的大數(shù)據(jù)趨勢。基于大數(shù)據(jù)的預(yù)測在許多業(yè)界是非常有效的, 例如電信界, 這里可以預(yù)測大眾化的路由日志分析. 每一次在設(shè)備上發(fā)生了問題, 公司可以預(yù)測它并避免宕機(jī)時(shí)間或利潤丟失。

當(dāng)結(jié)合以上的使用場景的時(shí)候，根據(jù)用戶的整體行為，可以使用一個(gè)預(yù)測型架構(gòu)來誘惑產(chǎn)品目錄的選擇和價(jià)格。