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

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

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

定義大數(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é)中，將看到怎樣的征兆意味著一個團(tuán)隊(duì)需要開始一個大數(shù)據(jù)項(xiàng)目了。

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

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

有其他的表征—例如數(shù)據(jù)的類型. 如何在傳統(tǒng)數(shù)據(jù)存儲中管理不斷增加的各種各樣的數(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ù)，圖片，視頻，語音等等。

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

當(dāng)下，如何充分利用增值數(shù)據(jù)以及如何能夠原生地搜索到它們呢?為了回答這一問題，再次考慮傳統(tǒng)存儲中為了加速查詢而創(chuàng)建的索引。如果為了復(fù)雜查詢而索引上百列而且包含了主鍵的不確定性，會是什么樣子?不希望在一個基礎(chǔ)SQL 數(shù)據(jù)庫中做這些;取而代之的是，需要考慮按照特殊需要而使用一個 NoSQL存儲. 所以，簡單回顧一下主要路徑：數(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)面對這些使用場景的時候，如果希望隨著商務(wù)的增長而彈性擴(kuò)展，就需要考慮一個分布式的大數(shù)據(jù)架構(gòu)。

客戶行為分析

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

情緒分析

公司關(guān)注的是其在社交網(wǎng)絡(luò)上所被感知的形象和聲譽(yù); 把可能使他們聲名狼藉的負(fù)面事件最小化并充分利用正面事件. 通過準(zhǔn)實(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)使市場活動的效益最大化。

預(yù)測

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

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

理解大數(shù)據(jù)技術(shù)生態(tài)系統(tǒng)

一旦確實(shí)要實(shí)施一個大數(shù)據(jù)項(xiàng)目, 最困難的事是架構(gòu)中的技術(shù)選型。這不僅是選擇最著名的Hadoop相關(guān)技術(shù)，而且需要理解如何給它們分類才能構(gòu)建一個一致性的分布式架構(gòu)。為了得到大數(shù)據(jù)星云中的項(xiàng)目數(shù)量，可以參見 https://github.com/zenkay/bigdata-ecosystem#projects-1 ，這里有100多個工程項(xiàng)目。這里，可以考慮選擇一個Hadoop的發(fā)布版,一個分布式文件系統(tǒng) ,一個類SQL處理語音, 一個機(jī)器學(xué)習(xí)語言, 調(diào)度器,面向消息的中間件, NoSQL數(shù)據(jù)存儲,數(shù)據(jù)可視化等等。

既然是描述構(gòu)建一個分布式架構(gòu)的可擴(kuò)展方法，所以不深入到所有的項(xiàng)目中;取而代之，重點(diǎn)在典型大數(shù)據(jù)工程中最可能使用的東西。顯然，架構(gòu)的選擇和項(xiàng)目的集成依賴于具體的需要，可以看到在特定的領(lǐng)域可以使用這些項(xiàng)目的具體實(shí)例。為了使Hadoop 技術(shù)表現(xiàn)的更有相關(guān)性，這一分布式架構(gòu)將適用于前面描述的典型場景，命名如下：

- 客戶行為分析

- 情緒分析

- CRM onboarding 和預(yù)測

Hadoop 發(fā)布版

在涵蓋了Hadoop 生態(tài)系統(tǒng)的大數(shù)據(jù)項(xiàng)目中，有兩個選擇：

• 在一個連貫，彈性和一致的架構(gòu)中分別下載相關(guān)項(xiàng)目，然后嘗試創(chuàng)建或組裝它們
• 使用一個廣泛流行的 Hadoop分發(fā)版, 已經(jīng)裝配或創(chuàng)建好了這些技術(shù).

盡管選項(xiàng)一完全可行，還是可能選擇方案二，因?yàn)橐粋€Hadoop 發(fā)型包保證了所有安裝組件的兼容性，安裝，配置部署，監(jiān)控和支持都非常簡單。

Hortonworks 和Cloudera 是這樣領(lǐng)域的主角。盡管它們之間有些區(qū)別，但是從大數(shù)據(jù)包的角度上看，它們是一樣的，不需要那些專屬的插件。我們的目標(biāo)不是描述每個發(fā)布版的所有組件，二是聚焦在每個提供者在標(biāo)準(zhǔn)生態(tài)系統(tǒng)中所增加的部分。同時，描述了在每種情況下，該架構(gòu)所依賴的其他組件。

Cloudera CDH

+ Cloudier在Hadoop基礎(chǔ)組件上增加了一個內(nèi)部機(jī)構(gòu)組件的集合; 這些組件被設(shè)計成更好的集群管理和搜索體驗(yàn)。部分組件列表如下：

Impala: 一個實(shí)時，并行化，基于SQL的引擎來搜索 HDFS

(Hadoop Distributed File System)和 HBase中的數(shù)據(jù). Impala被認(rèn)為是Hadoop 發(fā)布版提供商市場中最快的查詢引擎，是UC Bekeley Spark 的直接競爭者。

+ Cloudera Manager: 這是Cloudier的控制臺，用來管理和部署Hadoop集群內(nèi)的Hadoop組件.

+ Hue: 一個用于執(zhí)行用戶交互數(shù)據(jù)操作和執(zhí)行腳本的控制臺，可以操作集群內(nèi)不同的Hadoop組件.

Figure 1-1 解釋了Cloudera’s Hadoop分發(fā)包有如下組件分類:

+ 橙色部分是Hadoop核心棧.

+ 粉色部分是 Hadoop 生態(tài)系統(tǒng)項(xiàng)目

+ 藍(lán)色部分是 Cloudera的特使組件.

Figure 1-1. Cloudera Hadoop發(fā)布版

Hortonworks HDP

Hortonworks 是一個百分之百的開源而且使用了穩(wěn)定的組件包，而不是1Hadoop 項(xiàng)目中最新的分發(fā)版本。它增加了一個組件管理控制臺來與Cloudera Manager對比。Figure 1-2 展示了Hortonworks 發(fā)布版與Figure 1-1 相應(yīng)的分類：綠色部分是Hortonworks的特殊組件.

Figure 1-2. Hortonworks Hadoop 發(fā)布版

如前所述，當(dāng)我們構(gòu)建架構(gòu)的時候，這兩個發(fā)布版(Hortonworks 和Cloudera) 是一樣的。盡管如此, 如果考慮到每個發(fā)布版的成熟度，應(yīng)當(dāng)選擇; Cloudera Manager比Ambari更完整和穩(wěn)定 .進(jìn)一步，考慮實(shí)時與大數(shù)據(jù)集交互，更應(yīng)該因?yàn)樗男阅茏吭蕉褂肅loudera.

Hadoop Distributed File System (HDFS)

可能疑慮攝取到Hadoop集群中的數(shù)據(jù)存儲到哪里，一般都在一個專有的系統(tǒng)上，叫做HDFS。HDFS的核心特性:

• 分布式
• 高吞吐量訪問
• 高可用
• 容錯
• 參數(shù)調(diào)整
• 安全
• 負(fù)載均衡

HDFS 是Hadoop集群中數(shù)據(jù)存儲的頭等公民。數(shù)據(jù)在集群數(shù)據(jù)節(jié)點(diǎn)中自動復(fù)制。

Figure 1-3 展示了HDFS中的數(shù)據(jù)如何在 一個集群的五個節(jié)點(diǎn)中復(fù)制的。

Figure 1-3. HDFS 數(shù)據(jù)復(fù)制

可以從 hadoop.apache.org獲得更多的有關(guān)HDFS的信息。

Data Acquisition

數(shù)據(jù)的獲取或者攝取開始于不同的數(shù)據(jù)源，可能是大的日志文件，流數(shù)據(jù)， ETL處理過的輸出，在線的非結(jié)構(gòu)化數(shù)據(jù)，或者離線的結(jié)構(gòu)化數(shù)據(jù)。

Apache Flume

當(dāng)查看生成的攝取日志的時候，強(qiáng)烈推薦使用Apache Flume; 它是穩(wěn)定且高可用的，提供了一個簡單，靈活和基友流數(shù)據(jù)的可感知編程模型。基本上，僅通過配置管理不需要寫一行代碼就可以陪著一個數(shù)據(jù)流水線。

Flume 由sources, channels, 和sinks組成. Flume source 基本上從一個外部數(shù)據(jù)源來消費(fèi)一個事件如 Apache Avro source,然后存到channel. channel是一個像文件系統(tǒng)那樣的被動存儲系統(tǒng) ; 它在sink 消費(fèi)事件前一直持有它. sink 消費(fèi)事件，然后從channel中刪除該事件，并分發(fā)給一個外部的目標(biāo)。

Figure 1-4 描述了一個web server和HDFS間的日志流如 Apache,使用了Flume 流水線.

Figure 1-4. Flume 架構(gòu)

通過 Flume, 可以將web服務(wù)器產(chǎn)生的不同日志文件移動到HDFS. 牢記我們工作在一個分布式的架構(gòu)，可能包含有負(fù)載均衡器，HTTP servers,應(yīng)用服務(wù)器，訪問日志等等 . 我們是一不同的方式充分利用這些資源，使之能夠被Flume流水線處理 . 詳情參見 flume.apache.org.

Apache Sqoop

Swoop是一個從結(jié)構(gòu)化數(shù)據(jù)庫傳說大量數(shù)據(jù)到HDFS. 使用它，既可以從一個外部的關(guān)系型數(shù)據(jù)庫將數(shù)據(jù)導(dǎo)入到HDFS, Hive, 或者 HBase, 也可以Hadoop 集群導(dǎo)出到一個關(guān)系型數(shù)據(jù)庫或者數(shù)據(jù)倉庫.

Sqoop 支持主流的關(guān)系型數(shù)據(jù)庫例如Oracle, MySQL, 和Postgres. 這個項(xiàng)目把你從寫腳本傳輸數(shù)據(jù)中解脫出來;它提供了高性能數(shù)據(jù)傳輸?shù)奶匦?因?yàn)殛P(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)增長迅速, 最好從開始就定義那些快速增長的表，然后使用Sqoop將數(shù)據(jù)周期性地傳輸?shù)紿adoop，以便用于分析.

然后，結(jié)合Hadoop與其他數(shù)據(jù)，可以使用Sqoop 導(dǎo)出數(shù)據(jù)注入到BI 分析工具中. 詳情參見 sqoop.apache.org.

處理語言

一旦數(shù)據(jù)到了HDFS,可以使用不同的處理語言從原始數(shù)據(jù)得到最好的結(jié)果.

Yarn: NextGen MapReduce

MapReduce 是第一代Hadoop集群中的主要處理框架; 它基本上將滑動數(shù)據(jù)分組(Map) 在一起，然后依賴特殊的聚合操作(Reduce)來聚會數(shù)據(jù)。在Hadoop 1.0中, 用戶們可以使用不同的語言來寫 MapReduce jobs—Java, Python,

Pig, Hive等等. 無論用戶選擇了什么語言, 都依賴于相同的處理模型:MapReduce.

隨著Hadoop 2.0的發(fā)布, 有了HDFS之上新的數(shù)據(jù)處理架構(gòu). 現(xiàn)在已經(jīng)實(shí)現(xiàn)了YARN (Yet Another Resource Negotiator), MapReduce 已經(jīng)成為了眾多處理模型中的一個. 這意味著可以依賴特殊的使用場景來采用特殊的處理模型.

Figure 1-5 展示了HDFS, YARN, 和處理模型是如何組織的.

Figure 1-5. YARN 結(jié)構(gòu)

我們無法審視所有的語言和處理模型; 專注于 Hive 和Spark, 它們覆蓋了我們所用的用例，長時間數(shù)據(jù)處理和流處理。

使用Hive的批處理

當(dāng)決定寫第一個批處理job的時候, 使用所喜歡語言實(shí)現(xiàn)它，例如Java或 Python,但如果真的要做，最好舒服地使用mapping 和reducing 設(shè)計模式, 但這需要開發(fā)的時間和復(fù)雜的編碼，有時候很難去維護(hù)。

作為一個替代方式, 可以使用例如Hive這樣的高級語言, 以類SQL方式簡單而又強(qiáng)大地從HDFS中查詢數(shù)據(jù). 在用Java寫了10行代碼的MapReduce地方,在Hive中, 只需要一條 SQL 查詢語句.

當(dāng)使用其他語言而不是原生MapReduce, 其主要的缺陷是性能.在 Hive 和 MapReduce之間有著天然的時延; 另外, SQL查詢也與關(guān)系型數(shù)據(jù)庫中的查詢截然不同。詳情參見 hive.apache.org.

Hive 不是一個實(shí)時或準(zhǔn)實(shí)時的處理語言，被用作批處理，例如一個低優(yōu)先級的長時間處理任務(wù). 處理流式數(shù)據(jù)，需要使用Spark Streaming.

使用Spark Streaming的流處理

Spark Streaming 可以通過Java, Scale, 或者Python來寫批處理任務(wù), 但是可以處理流數(shù)據(jù). 這非常適合處理高吞吐量的數(shù)據(jù)源T例如社交網(wǎng)絡(luò)(Twitter), 點(diǎn)擊流日志, 或者 web 訪問日志.

Spark Streaming 是Spark的一個擴(kuò)展, 它充分利用了分布式數(shù)據(jù)處理架構(gòu)，把流式計算作為 一系列不確定的小時間間隔的微型批處理計算。詳情參見 spark.apache.org.

Spark Streaming 可以從各種源獲得數(shù)據(jù)，通過與如Apache Kafka這樣工具的結(jié)合, Spark Streaming 成為強(qiáng)容錯和高性能系統(tǒng)的基礎(chǔ)。

面向消息的中間件Apache Kafka

Apache Kafka 是一個由Linkedin開發(fā)的訂閱-發(fā)布消息的分布式應(yīng)用。Kafka經(jīng)常與 Apache ActiveMQ 或者RabbitMQ對比, 但根本不同是Kafka 沒有實(shí)現(xiàn)JMS (Java Message Service). 然而, Kafka是一個持久化消息的高吞吐量系統(tǒng) , 支持隊(duì)列和話題語意， 使用 ZooKeeper形成集群節(jié)點(diǎn)。

Kafka 實(shí)現(xiàn)了訂閱-發(fā)布的企業(yè)級集成，支持并行化，以及性能和容錯的企業(yè)級特性。

Figure 1-6 給出了訂閱-發(fā)布架構(gòu)的高層視角，消息在broker傳輸，服務(wù)于分區(qū)的話題。

Figure 1-6. Kafka 分區(qū)主題示例

使用 Kafka在我們架構(gòu)中的引導(dǎo)點(diǎn) ，主要用于接受數(shù)據(jù)并推送到Spark

Streaming. 詳情參見 kafka.apache.org.

機(jī)器學(xué)習(xí)

當(dāng)我們以無限收斂模型處理小數(shù)據(jù)采樣時，在架構(gòu)中討論機(jī)器學(xué)習(xí)還為時尚早。我們是充分利用現(xiàn)有的分層或特殊語言來使用機(jī)器學(xué)習(xí)，例如

Spark中的 Spark MLlib。

Spark MLlib

MLlib是Spark上的機(jī)器學(xué)習(xí)庫, 充分利用了 Spark Direct Acyclic Graph (DAG) 執(zhí)行引擎, 所提供的API 集合方便地集成到Spark中. 它由各種的算法組成 ：基本統(tǒng)計, 邏輯回歸， k-means 聚類, 從混合高斯到奇異值分解以及多維樸素貝葉斯。

通過 Spark MLlib 這些開箱即用算法，可以用幾行代碼就能過簡單地訓(xùn)練數(shù)據(jù)并構(gòu)建預(yù)測模型a 詳情參見 spark.apache.org/mllib.

NoSQL 存儲

NoSQL 存儲是數(shù)據(jù)架構(gòu)的基礎(chǔ)組件，因?yàn)樗鼈兛梢詳z取大量數(shù)據(jù)，提供彈性伸縮，高可用性以及開箱即用。Couchbase 和 ElasticSearch是兩種我們聚焦的技術(shù)，先做簡單討論，稍后使用它們。

Couchbase

Couchbase是一個面向文檔的NoSQL數(shù)據(jù)庫，提供了一個靈活的模型輕松縮放，以及一致性的高性能。使用 Couchbase作為文檔數(shù)據(jù)存儲，基本上重定向從前端來的所有查詢 到 Couchbase 防止了關(guān)系型數(shù)據(jù)庫的高吞吐量讀操作。詳情參見 couchbase.com.

ElasticSearch

ElasticSearch 是一種非常流行的 NoSQL 技術(shù)，擁有可伸縮分布式索引引擎和搜索特性，相當(dāng)于一般架構(gòu)中Apache Lucene 加上實(shí)時數(shù)據(jù)分析和全文搜索.

ElasticSearch是ELK平臺的一部分( ElasticSearch + Logstash + Kibana,)，是由Elastic公司發(fā)布的。三個產(chǎn)品結(jié)合在一起提供了數(shù)據(jù)采集，存儲和可視化最好的端到端平臺:

• Logstash 從各種數(shù)據(jù)源采集數(shù)據(jù)，例如社交數(shù)據(jù)，日志，消息隊(duì)列，或者傳感器，支持?jǐn)?shù)據(jù)的豐富性和轉(zhuǎn)換，然后傳輸?shù)揭粋€索引系統(tǒng)例如ElasticSearch.

• ElasticSearch 在一個彈性伸縮的分布式系統(tǒng)中索引數(shù)據(jù)，無縫提供了多語言庫，很容易在應(yīng)用中實(shí)現(xiàn)實(shí)時搜索和分析。

• Kibana 是一個定制化的用戶界面，可以構(gòu)建從簡單到復(fù)雜的儀表盤，來探索和可視化ElasticSearch 索引的數(shù)據(jù)。

Figure 1-7 展示了Elastic產(chǎn)品的結(jié)構(gòu).

Figure 1-7. ElasticSearch 開源產(chǎn)品

如前圖所示, Elastic 也提供了商用產(chǎn)品例如Marvel,基于Kibana的一個監(jiān)控控制臺; Shield, 一個安全框架, 例如提供授權(quán)和認(rèn)證; Watcher, 一個告警和通知系統(tǒng). 但不使用這些商用產(chǎn)品。我們主要使用ElasticSearch作為搜索引擎來持有Spark產(chǎn)生的產(chǎn)品。在處理和聚合之后，數(shù)據(jù)在ElasticSearch中被索引，使第三方系統(tǒng)通過ElasticSearch引擎查詢數(shù)據(jù)。另一方面，我們也使用 ELK來處理日志和虛擬化分析，而不只是平臺操作視角。詳情參見 elastic.co.

創(chuàng)建有長遠(yuǎn)規(guī)劃的大數(shù)據(jù)架構(gòu)

記住所有這些大數(shù)據(jù)技術(shù)，現(xiàn)在來構(gòu)建我們的架構(gòu)。

架構(gòu)概覽

從高層視角來看, 我們的架構(gòu)看起來象另一個電子商務(wù)應(yīng)用架構(gòu)，需要如下：

• 一個web應(yīng)用，訪客可以用它導(dǎo)航一個產(chǎn)品目錄
• 一個日志攝取應(yīng)用：拉取日志并處理它們
• 一個機(jī)器學(xué)習(xí)應(yīng)用：為訪客觸發(fā)推薦
• 一個處理引擎：作為該架構(gòu)的中央處理集群
• 一個搜索引擎：拉取處理數(shù)據(jù)的分析

Figure 1-8 展示了這些不同應(yīng)用如何在該架構(gòu)組織起來的。

Figure 1-8. 架構(gòu)概貌

日志攝取

日志攝取應(yīng)用被用作消費(fèi)應(yīng)用日志例如web 訪問日志. 為了簡化使用場景，提供一個web訪問日志，模擬訪客瀏覽產(chǎn)品目錄，這些日志代表了點(diǎn)擊流日志，既用作長時處理也用作實(shí)時推薦。架構(gòu)有兩個選項(xiàng)：第一個是以Flume來傳輸日志;第二個是以LEK 來創(chuàng)建訪問分析。

Figure 1-9 展示了ELK 和Flume是如何處理日志的.

Figure 1-9. 攝取數(shù)據(jù)

我們在架構(gòu)中使用ELK ，因?yàn)長EK的三個產(chǎn)品無縫集成，能夠比使用Flume給我們更多的價值 。

機(jī)器學(xué)習(xí)

機(jī)器學(xué)習(xí)應(yīng)用接收數(shù)據(jù)流，構(gòu)建推薦引擎。這一應(yīng)用使用一個基本的算法來基于Spark MLlib 介紹 機(jī)器學(xué)習(xí)的概念。

Figure 1-10 展示了該機(jī)器學(xué)習(xí)應(yīng)用如何使用Kafka 接收數(shù)據(jù)，然后發(fā)送給Spark 處理,最后在ElasticSearch 建立索引為將來使用做準(zhǔn)備。

Figure 1-10. 機(jī)器學(xué)習(xí)

處理引擎

處理引擎是該架構(gòu)的心臟; 它接收各種源的數(shù)據(jù)，代理合適模型的處理。

Figure 1-11 展示了由Hive組成的處理引擎如何接收數(shù)據(jù)，以及Spark的實(shí)時/準(zhǔn)實(shí)時處理。

Figure 1-11. Processing engine

這里使用Kafka 與 Logstash結(jié)合把數(shù)據(jù)分發(fā)給ElasticSearch. Spark位于 Hadoop 集群的頂端， 但不說必須的。為了簡化起見，不建立 Hadoop集群，而是以standalone模式運(yùn)行Spark。顯然，應(yīng)用同樣可以部署在所選擇的Hadoop 發(fā)布版上。

搜索引擎

搜索引擎充分利用處理引擎所處理的數(shù)據(jù)，同時暴露出專有的RESTful API以便于分析使用。

【本文來自51CTO專欄作者老曹的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】