從最簡單的概念起始, 本系列文章會一步步講解推薦系統(tǒng)的發(fā)展進程以及最新實踐, 站在產(chǎn)品經(jīng)理的角度, 闡述與推薦系統(tǒng)相關的算法、技術和架構。本章作為第三章, 會對推薦系統(tǒng)的基石之一大數(shù)據(jù)進行系統(tǒng)性介紹。數(shù)據(jù)智能時代的“鐵公基”是大數(shù)據(jù), 其屬于一系列計算以及存儲的基礎設施, 推薦系統(tǒng)建構于大數(shù)據(jù)基礎之上, 大量的數(shù)據(jù)挖掘與模型訓練皆不能脫離大數(shù)據(jù)。大數(shù)據(jù)的這個叫法取得特別恰當, 要是面對的恰巧正好是非技術領域的人員, 那也絕對能夠從中領會到其中大的意思, 即是數(shù)據(jù)的數(shù)量特別龐大, 并且具備極為強大的計算能力?？墒? 這般強大無比的能力究竟是怎么產(chǎn)生的呢 , 針對此大數(shù)據(jù)生態(tài)體系在架構方面又是如何進行分工的呢?沒具體做過的同學并不知道今天就接著從產(chǎn)品經(jīng)理的角度, 深入且不失淺顯地來講這些問題, 實際上不一定非得是產(chǎn)品經(jīng)理, 對大數(shù)據(jù)感興趣的同學都能瞧瞧, 本文篇幅較長, 要是時間不夠, 建議先標記下。01 大數(shù)據(jù)的誕生與分布式大數(shù)技術誕生以前, 數(shù)據(jù)存儲與處理的大半部分是和MySql之類數(shù)據(jù)庫軟件相關的。這些傳統(tǒng)數(shù)據(jù)庫的文件系統(tǒng)是單機的, 這意味著, 數(shù)據(jù)僅能在一臺機器上運行 , 它們在處理達到TB級甚至上PB級的數(shù)據(jù)時會極其吃力。谷歌是第一個解決了該問題的公司, 其將分布式作為解決這個問題的思路, 在2003年至2004年間, 谷歌分別發(fā)表了三篇具有重量級的論文, 這些論文奠定了大數(shù)據(jù)的基礎。簡單的說谷歌通過論文公布了以下三個工具如何創(chuàng)造用于文件存儲的分布式系統(tǒng): File, 具備分布式并行計算能力的框架: 用于數(shù)據(jù)存儲的分布式系統(tǒng):這便是大數(shù)據(jù)技術初始的形態(tài)了。自谷歌的這一源頭起程邁出第一步, 歷經(jīng)較長時間的逐漸演變發(fā)展, 大數(shù)據(jù)最終造就而成當下這般完整的樣子所處的狀況了吶?？梢杂靡韵氯齻€分類來去解構整個大數(shù)據(jù)生態(tài)分布式存儲, 是將文件切割成多份, 而后分布著存儲到多臺機器之上。其常用的組件包含: HDFS、HBase等。分布式計算, 是把數(shù)據(jù)計算的任務切割成多個部分, 進而分配到多臺機器上去計算。其常用的組件有: Spark、Storm、Flink等。分布式工具, 涵蓋數(shù)據(jù)輔助類工具以及資源調(diào)度管理工具等。常見的組件有: YARN、Hive、Flume、Sqoop等。大數(shù)據(jù)的整個生態(tài)體系極為龐大, 與之相關的產(chǎn)品多得數(shù)不過來, 讓人看得眼睛都花了, 有種類似物種大爆發(fā)時的那種感覺。然而它也并非完全毫無頭緒可找。我們要去理解大數(shù)據(jù)生態(tài), 從這三個方面著手去理解便會輕松不少。本文也是依照這個方式嚴格地進行講述的。02 本文講述需要用的數(shù)據(jù)表因大數(shù)據(jù)生態(tài)極為龐大復雜, 為讓文章更淺顯易懂, 本文不對技術概念作過多闡述, 而是直接進入操作層面, 以圖示形式講解。因講述的是數(shù)據(jù)系統(tǒng), 我在此建一張數(shù)據(jù)表 USER, 通過用這張數(shù)據(jù)表在各個系統(tǒng)中的處理過程, 給大家講述大數(shù)據(jù)各個組件的工作原理及機制。03在整個互聯(lián)網(wǎng)技術生態(tài)圈里頭, 谷歌屬于超級績優(yōu)生。每當發(fā)表論文時, 都會致使諸多相關人員前來“抄作業(yè)”。Doug也就是其之父, 和他所帶領的團隊乃是眾多抄作業(yè)者當中的一個。他耗費業(yè)余中的兩年時間, 依據(jù)谷歌的論文去實現(xiàn)了一項針對分布情況進行數(shù)據(jù)處理的系統(tǒng), 進而用自己兒子的那個大象材質(zhì)毛絨制成的玩具體的名字, 把這個系統(tǒng)予以定名。而它的Logo也是呈現(xiàn)著大象的模樣。之后到了二零零六年, 被引入基金會, 變?yōu)橐粋€開源的頂級項目。伴隨它的持續(xù)發(fā)展, 在此項目里 , 出現(xiàn)了HBase, Hive, Pig等子項目, 并先后被基金會把它們獨立升級成了頂級項目。與此同時, 基金會持續(xù)不斷地兼收并攬著其他諸多大數(shù)據(jù)項目, 基本上將絕大部分在大數(shù)據(jù)范圍內(nèi)稱得上優(yōu)秀的項目都納入了自己的旗下, 給人一種仿佛天下所有的武功秘籍都出自少林那般的感覺。在大數(shù)據(jù)領域各種各樣的不同開源組件這個整體范疇之中, 它所旗下歸屬的那些才是如同少林正宗一般被視作正統(tǒng)的存在。閑話不多說我們來講?，F(xiàn)在的主要分三個部分高可靠HDFS( File ) 所充當?shù)姆植际酱鎯? 是一個能實現(xiàn)海量數(shù)據(jù)存儲的高吞吐量分布式文件系統(tǒng)?？蓪崿F(xiàn)海量計算的是一個分布式離線并行計算框架, 它屬于分布式計算范圍。作為一個實現(xiàn)硬件資源調(diào)配的框架, YARN是用以集群資源調(diào)度管理的分布式工具。04 以圖解形式呈現(xiàn)分布式。這里先具象的解釋下什么是大數(shù)據(jù)的分布式長什么樣當我們進行安裝一事的時候, 需要將同一個軟件安裝予以包, 安裝于三臺以上不同的機器之上。在安裝完成之后, 咱們便能夠獲取到一個分布式集群呢。像是下面所呈現(xiàn)的這樣, 把三個組件, 于集群的每一臺機器之上進行安裝, 這個集群存在七臺機器, 每一臺機器被稱作一個節(jié)點, 在這七個節(jié)點里, 要挑選出一個來充當老大, 我們?nèi)粲惺裁词虑? 會先去找這個老大, 這便是主節(jié)點, 由于主節(jié)點十分關鍵, 要是它出現(xiàn)故障, 整個集群都將無法正常運行, 故而通常會配置兩臺主節(jié)點, 其中一臺作為備份, 其余五個節(jié)點被叫做從節(jié)點, 在相關情境中, 主節(jié)點被命名為某特定名稱, 從節(jié)點則為Slave。05 分布式文件系統(tǒng)HDFS將下面所講到的首個組件, 也就是HDFS。HDFS身為分布式的一種文件系統(tǒng), 它是以文本這種方式去保存數(shù)據(jù)的, 換句話講, 數(shù)據(jù)通常會如同我們的TXT文件那般呈現(xiàn)。一個文件會依據(jù)設定, 被切割成不一樣的數(shù)據(jù)塊, 接著每個數(shù)據(jù)塊會被復制成多份, 隨后通過分布式的形式存儲到不同的節(jié)點當中。HDFS把集群節(jié)點劃分成兩種類型: 和。順著USER數(shù)據(jù)表來說, 舉個例子講講HDFS的運作過程。在實際的系統(tǒng)里面, 鑒于負荷偏重, 會安排一項起到協(xié)助作用而非備份作用的工作。上圖中HDFS先是將深藍色的文本數(shù)據(jù)進行切分, 切分成了三份, 每份數(shù)據(jù)依照系統(tǒng)設定, 像是64MB或是128MB作為一塊, 接著把三份數(shù)據(jù)塊復制成三份, 進而就有了九份數(shù)據(jù), 隨后把上一步所得到的九份數(shù)據(jù)劃分到不同之處, 并且建好目錄, 最后按照儲存分配, 將各個數(shù)據(jù)塊予以保存。具有數(shù)據(jù)容量大這一優(yōu)點的HDFS, 是大數(shù)據(jù)之中最為主要的數(shù)據(jù)存儲方式, 眾多其他組件皆建立于HDFS的基礎之上, 其應用極為廣泛。HDFS 存在缺點, 它屬于文件系統(tǒng), 并非數(shù)據(jù)庫系統(tǒng), 無法像關系數(shù)據(jù)庫系統(tǒng)那般借助建立索引之類的工具來提高處理速度以及定位到數(shù)據(jù)所在位置, 鑒于其數(shù)據(jù)記錄以一行一行的字符串形式呈現(xiàn), 所以無法定位, 并且不支持對數(shù)據(jù)進行直接修改。06 分布式離線計算引擎它是專門負責分布式計算的, 它呢, 是一個組合詞, 這個組合詞可以進行劃分, 能分成兩個部分, 一部分是Map, 另一部分是。簡而言之, Map所做的便是將需計算的數(shù)據(jù)拆分為多個計算任務, 然而是對Map過程斬獲的結果予以匯總處理。假定當下我們計劃計算在USER表當中, 男性與女性各自的人數(shù)分別是多少。計算詳細過程如下上圖中階段, 會去劃分數(shù)據(jù)成三塊, 通常是基于在HDFS存儲時切分的基礎之上再進行切分, 接著為每一個切分出來的數(shù)據(jù)塊創(chuàng)建一個任務, 逐一條一條地去計算每條數(shù)據(jù)對應的結果, 之后把結果存儲在磁盤里, 也就是要對階段產(chǎn)生的結果做分揀, 任務必須等全部完成之后才能夠開展, 就是把分揀好的數(shù)據(jù), 實施匯總。通過這種方式獲得了強大的運算能力。優(yōu)點在于, 其具備強大的計算能力, 運算所耗費的成本較為低廉, 并且在運算能力處于一般水平的機器之上它也能夠運行。缺點是, 它誕生的那個年代, 內(nèi)存那時還很貴, 在進行計算的進程中, 那些中間結果得持續(xù)存入磁盤里, 目的是減輕內(nèi)存的壓力, 然而如此一來就致使運算速度相對較慢。另外還有, 代碼并非簡潔, 學習曲線比較陡峭, 后續(xù)在HIVE部分將要講述。07 資源管理調(diào)度系統(tǒng)YARNYARN的全稱是Yet直譯就是另一種資源協(xié)調(diào)者。看名字便曉得, 他屬于其中一種資源調(diào)度器 , 其最為關鍵的組件是 , 借由該組件 , YARN能夠為我們的任務開展資源分配 , 所分配的資源是一個個計算容器 , 每個計算任務于這個容器里運行 , 因出色 , 后來YARN進一步得以廣泛發(fā)揚 , 成為了諸多大數(shù)據(jù)組件之外的資源調(diào)度框架。08 數(shù)據(jù)分析和數(shù)據(jù)倉庫工具HIVE有著的當中, 加以處理數(shù)據(jù)作業(yè)的程序是得經(jīng)由JAVA去達成的, 然而JAVA在進行書寫程序進程之際并不簡單明快, 比如說我們先前談到過在統(tǒng)計某張數(shù)據(jù)表里面男丁與女人人數(shù)該項特別普通操作的時候是必不可少嚴格遵循諸如, 自Input開啟以至此這樣步驟嚴格遵循且要達到五步來促成的一項操作, 編寫代碼通常狀況下長度達到上百行之譜。然而, 去統(tǒng)計這般數(shù)據(jù)的結果, 針對于SQL來講, 那可是僅僅一句話就能搞定的事兒啦: 以sex作為分組依據(jù), 從USER表當中來統(tǒng)計COUNT(1) , 就是這樣的。這般來言, 為了達成不再撰寫長度冗長亦頗繁瑣的 JAVA 之目標后, Hive 便順勢而誕生了。而 Hive 這個組件主要所負責去做的之事就在于, 把 SQL 相關代碼進行轉譯成為另外一種形式, 之后再放置到由 YARN 構建而成的容器當中, 進而運行產(chǎn)生出相應的結果來。如此一來, 當我們需要去進行對USER表之中的男性以及女性人數(shù)予以統(tǒng)計之際, 便無需通過編寫JAVA來達成實現(xiàn), 進而能夠實現(xiàn)調(diào)動了, 在此之處, 我們借助畫圖的方式來對此予以說明:除此以外, Hive除了具備轉譯SQL這個功能之外, 它還能夠被用于構建數(shù)據(jù)庫以及數(shù)據(jù)表。它所擁有的能力是與數(shù)據(jù)庫具備的能力一樣的, 并且還能夠對大量的數(shù)據(jù)予以處理, 因而通常人們還會把Hive運用構建數(shù)據(jù)倉庫。對于數(shù)據(jù)倉庫而言, 其主要的功能是把歷史數(shù)據(jù)全部存入其中, 能夠反復地進行統(tǒng)計計算以供使用。數(shù)據(jù)倉庫最為主要的特征則是其數(shù)據(jù)數(shù)量極其龐大。由于它構建于一定基礎之上, Hive具備可計算的容量龐大的特點, 其運算能力較為強大, 然而速度并不快, Hive也無法直接對數(shù)據(jù)進行修改, 針對Hive開展數(shù)據(jù)的修改操作會耗費相當長的時間。最后介紹一下Hive和MySql的區(qū)別09 離線計算和流式計算DAG計算引擎SPARKSpark屬于分布式計算引擎, 是大數(shù)據(jù)生態(tài)體系里速度快且功能強大的組件, Spark整個框架極為龐大, 具備極為豐富的離線計算以及流式計算能力。本小節(jié)先介紹Spark的離線計算功能。因摩爾定律作用下硬件基礎設施得以升級, 內(nèi)存愈發(fā)便宜, 不同于主要將中間結果持續(xù)寫入磁盤, Spark主要把數(shù)據(jù)置于內(nèi)存中進行計算, 如此Spark在速度方面便得了上千倍數(shù)目的提升。內(nèi)存不足之際, Spark會需要把中間結果存儲至磁盤。然而在此情形下, Spark在速度方面相較于也有著上百倍的提高。源于Spark給出了 RDD以及這樣的數(shù)據(jù)表工具, 還為這些數(shù)據(jù)表籌備了一系列效率高計算的算子, 切實提升了速度。多個算子疊加便成了一個DAG(Graph), 故而Spark也被稱作DAG計算引擎。下面介紹Spark的計算流程。鑒于RDD皆是類乎關系數(shù)據(jù)庫的數(shù)據(jù)表, 其流程機制大體無異, 于此選用作解釋。當Spark針對USER表的數(shù)據(jù)予以處理之際, 會經(jīng)歷如下過程:上圖中數(shù)據(jù)取讀, 得從文本、HDFS、HIVE、JSON等好些格式里取讀。將取讀的數(shù)據(jù)表轉變?yōu)镾park的內(nèi)置格式, 且在上圖里被命名為。有了它便能直接對其開展算子操作。上圖里所用到的和count都是算子。算子的功用就是施行某類核算的操作。算子運算, 是分組的算子。它達成了依照男女把數(shù)據(jù)予以分組, 獲得一個分組后的新的, 在上圖里命名為。每回算子運算過后, 都會得到一個新的。對于count算子的運算, 是要在上一步所得到的結果里面, 再度去開展個數(shù)方面的計算, 進而獲取到最后的結果。多個算子相互混合起來了之后, 便形成了一個DAG, 在這個DAG上面所進行的操作, 會造就以下的DAG。Spark先是通過構建DAG, 而后再下發(fā)給從節(jié)點來進行計算呢。與此同時, 這個計算進程亦是如此這般, 把計算任務劃分成 Map 以及別外兩個階段模樣, 在多臺機器當中以分布式的形式來進行計算此處便不再予以詳述了。10 離線計算和流式計算Spark是離線計算的代表之一, 離線計算意味著在計算之前就已具備所有需計算的數(shù)據(jù), 而且每次計算都是所有數(shù)據(jù)都參與其中的運算, 由于每次都是整批數(shù)據(jù)進行計算, 故而離線計算通常又被稱作批量計算, 然而在日常事務里, 存在諸多場景是需要持續(xù)實時更新數(shù)據(jù)的。倘若我們的USER表, 當下鑒于有一名新用戶注冊進來了, 從而多增加了一條與之對應的關于用戶的具體數(shù)據(jù)“蔡九, 女, 27”。離線計算的行為就要將這新增從而出現(xiàn)的新數(shù)據(jù)加以匯總, 之后再開展針對諸多既有數(shù)據(jù)的計算操作:增加一條用戶日志, 就得對全部的予以計算, 在數(shù)據(jù)量極為龐大之際, 這壓根就是不可能做到的事。所以我們還需另外的一種計算方式, 也就是流式計算。流式計算鑒于其實時性, 又常常被稱作在線計算以及實時計算。這里是流式計算的進程, 相同的新添數(shù)據(jù), 流失計算之時只需針對新添數(shù)據(jù)加以計算, 其后匯總予以更新。有流式計算引擎, 分別是SPARK , Storm以及Flink , 它們都能夠提供流式計算的服務, 然而存在著些不同之處。11 分布式結構化存儲系統(tǒng)HBASE往前提及了谷歌所發(fā)表的、以大數(shù)據(jù)作為主題的三篇論文, 于這里額外補充一下, 它們在后續(xù), 發(fā)展變化而產(chǎn)生的最終成果:File相關演變成的分布式文件系統(tǒng)是HDFS, , 演變成什么的分布式并行計算框架, , 存在演變成另外一個大名鼎鼎就是HBase的分布式數(shù)據(jù)庫。這就是HBase的誕生。一個名為HBase的存在, 屬于NoSql數(shù)據(jù)庫范疇。其于整個大數(shù)據(jù)生態(tài)里的定位, 乃是針對數(shù)據(jù)開展實時的操作行為, 涵蓋查詢、更新、刪除以及插入等各項操作。先前提及的HIVE, 具備處理大量數(shù)據(jù)的能力, 然而速度較為緩慢, 并且無法對數(shù)據(jù)實施修改操作。而諸如MySql這類傳統(tǒng)數(shù)據(jù)庫, 響應速度快, 可運算能力卻有所欠缺。HBase的問世, 目的便在于解決這些方面所存在的問題。并不支持SQL語句的數(shù)據(jù)庫, 這便是NoSql數(shù)據(jù)庫的意思, HBase具備下面這些特征:通過一種便捷的方式來促使理解, 我們采取直接繪圖去查看HBase的工作情形, 當我們讓那屬于我們的USER數(shù)據(jù)表放置到HBase里之后, 它呈現(xiàn)出這樣的形態(tài), 是如此這般模樣的:其中在MySql里頭, 要是有修改數(shù)據(jù)的情況發(fā)生, 那舊數(shù)據(jù)就會被覆蓋掉。然而于HBase當中, 同一個鍵值對是能夠留存多個數(shù)據(jù)版本的。這個版本會是以時間戳的樣式去進行標記。就好比張三這個人, 有一天他改名為張三豐了, 這種狀況下, 它可不是把原有的張三給覆蓋了事, 而是會把這兩個版本都保存下來。如下如所示HBase具備強大的讀取能力, HBase具備強大的增刪改查能力, HBase能夠保存不同時間的數(shù)據(jù)版本, 在推薦系統(tǒng)里, 用戶畫像的結果數(shù)據(jù)是保存在HBase中的, 離線召回的數(shù)據(jù)是保存在HBase中的, 近線召回等數(shù)據(jù)是保存在HBase中的。此外, HBase能夠做到快速響應, 推薦系統(tǒng)中需要快速讀取的數(shù)據(jù)都能夠存在HBase中。12 數(shù)據(jù)采集大數(shù)據(jù)得以誕生, 并非是要將傳統(tǒng)的關系型數(shù)據(jù)庫給取代掉, 而是會轉變成一種補充, 傳統(tǒng)數(shù)據(jù)庫存不了的數(shù)據(jù), 由大數(shù)據(jù)來進行存儲, 傳統(tǒng)數(shù)據(jù)庫算不了的數(shù)據(jù), 由大數(shù)據(jù)來進行計算, 大數(shù)據(jù)系統(tǒng)僅僅是把現(xiàn)有系統(tǒng)的數(shù)據(jù)采集到大數(shù)據(jù)里, 去做存儲以及計算, 對于已有的業(yè)務流程和系統(tǒng)架構并不會產(chǎn)生什么影響。要把數(shù)據(jù)收集到大數(shù)據(jù)里, 通常會運用到兩個工具, 哎, 這倆工具分別是Sqoop工具以及Flume工具。實際上, 不同的公司在使用數(shù)據(jù)采集工具這件事兒上不盡相同, 這塊兒僅僅是做個簡單的講述罷了。有一種我們極其常見的數(shù)據(jù), 叫做關系型數(shù)據(jù), Sqoop是一座架設在關系型數(shù)據(jù)庫與大數(shù)據(jù)之間, 用于數(shù)據(jù)流動的橋梁它能夠被用以把MySql的數(shù)據(jù)導入至HDFS與HBASE之中, 或者將大數(shù)據(jù)里的數(shù)據(jù)導入到MySql。還有一種平常會出現(xiàn)的數(shù)據(jù), 是源自日志系統(tǒng)的數(shù)據(jù), 于生產(chǎn)環(huán)境里, 我們的搜索服務, 推薦服務, 廣告服務始終無時無刻不在生出許許多多的流式日志, 這些日志數(shù)據(jù)樣式不同, 形態(tài)紛雜, 它們俱是非結構數(shù)據(jù)。這些數(shù)據(jù)大體是以文本這一方式存于各個業(yè)務系統(tǒng)里, 對于推薦系統(tǒng)來說。最重要的用戶埋點行為數(shù)據(jù)是存在日志當中的。而針對這些非關系型數(shù)據(jù), 當我們要采集到大數(shù)據(jù)階段時。就需要用到Flume了。Flume能夠采集批量數(shù)據(jù), 也能夠采集流數(shù)據(jù)。這兩個工具知道作用即可不用深究太多。13 分布式消息隊列KAFKA使用Sqoop或者Flume進行數(shù)據(jù)采集之際, 存在著這么一種情況, 那便是一對一的直采專線服務模式。我們將生產(chǎn)數(shù)據(jù)的系統(tǒng)稱作生產(chǎn)者, 把消費數(shù)據(jù)的系統(tǒng)稱為消費者。伴隨系統(tǒng)的持續(xù)發(fā)展, 通常生產(chǎn)者與消費者的數(shù)量都會不斷增多, 一旦全部采用一對一直采方式, 連接數(shù)便會呈指數(shù)形式上升, 并且維護起來頗具難度。一旦生產(chǎn)者的數(shù)據(jù)未能及時被消費者接收, 或者出現(xiàn)丟包現(xiàn)象, 數(shù)據(jù)便會遺失。為了解決這些問題Kafka被創(chuàng)造了出來。經(jīng)過Kafka, 生產(chǎn)者僅需將數(shù)據(jù)進行打包, 對Topic做好標記, 而后扔至Kafka的消息隊列之上便可。至于消費者呢, 所要做的事兒就是去訂閱該生產(chǎn)者的Topic。一旦有新的數(shù)據(jù)抵達時, Kafka便會通知消費者去取了。數(shù)據(jù)會被暫且留存在Kafka的硬盤里一陣子通常是7天, 消費者能隨時前來拿取。被保存下的那一系列數(shù)據(jù)塊, 是一個個依據(jù)時間排列的消息隊列。同樣地, Kafka是分布式的, 它會被安設在多個節(jié)點內(nèi), 數(shù)據(jù)也會被存于多個節(jié)點中。14 架構可以看到這里, 已然是極為不容易的了, 先前業(yè)已把本文所要介紹的大數(shù)據(jù)組件講授完畢了。大數(shù)據(jù)規(guī)模極其龐大, 并且各自履行職責, 分工細致入微。數(shù)目眾多的大數(shù)據(jù)框架存在, 如離線計算、流式計算, 還有各異的分布式存儲、不同的分布式工具, 那么, 這般眾多框架如何構建成為一個涵蓋全方位大數(shù)據(jù)的、綜合性且復雜的系統(tǒng)呢?這就要介紹大數(shù)據(jù)的架構。架構是大數(shù)據(jù)系統(tǒng)里極為關鍵、有著重大影響力的架構, 數(shù)據(jù)通道被劃分成兩條不同的分支, 一條是實時流, 另一條是離線。按照流式架構的實時流保障了它的實時性, 而主要以批處理方式的離線, 保障了最終一致性, 適用于存在實時需求同時又存在離線需求的情況。抽象掉所有的框架可以把架構簡化成如下方式推薦系統(tǒng)可是個在存儲以及算力消耗方面堪稱大戶的存在, 它有著這樣的需求, 其一, 要進行離線計算, 針對那些對時間不敏感的數(shù)據(jù)展開大批量的計算, 其二, 還得進行實時流式計算, 為的是對用戶畫像, 還有物品畫像數(shù)據(jù)予以實時更新。把本章之中所提及的大數(shù)據(jù)的各種框架組件, 依照架構的形式進行組建之后, 我們能夠獲得下圖。就實際情形而言, 比起上圖來講還要更加復雜一部分 , 然而針對本文來說呢 , 借助機器學習的術語來講 , 要是再復雜下去那就會出現(xiàn)“過擬合 ”了 , 適量的這種情況能夠預防過擬合。舍棄掉一些 , 或許會是更佳的?？偨Y由分布式存儲、分布式計算以及輔助性組件構成的一個龐大的數(shù)據(jù)技術生態(tài)體系, 被匯總成一句話: 大數(shù)據(jù)。它存在幾個關鍵知識點:得去明白, 關于分布式存儲的那種機制, 鑒于數(shù)據(jù)量龐大, 數(shù)據(jù)存儲的最終承載者是最為簡單的文本數(shù)據(jù), 不存在諸多繁雜花哨的事物, 這些文本數(shù)據(jù)被劃分成多個數(shù)據(jù)塊, 呈分布式地存于不同的數(shù)據(jù)節(jié)點里頭, 得去理解分布式計算當中的機制, 要領會HIVE的工作機制, 要弄清楚啥是離線計算, 啥是流式計算, 最終要是可以的話, 記住架構。寫在最后的話太多了大數(shù)據(jù)的知識點, 因篇幅受到限制, 這次只是有選擇性地去介紹, 推薦系統(tǒng)所需要用到的, 大數(shù)據(jù)開源類裝置。這個生態(tài)體系仍在持續(xù)地發(fā)展著, 我同樣也還處于行進途中。存在不足之處, 還需乞請各路高手, 不吝給出教導。