數(shù)據(jù)管理比以往更加復雜，到處都是大數(shù)據(jù)，包括每個人的想法以及不同的形式:廣告 , 社交圖譜,信息流 ,推薦 ,市場, 健康, 安全, 政府等等.過去的三年里，成千上萬的技術必須處理匯合在一起的大數(shù)據(jù)獲取，管理 和分析; 技術選型對IT部門來說是一件艱巨的任務，因為在大多數(shù)時間里沒有一個綜合的方法來用于選型.
當自己面臨選擇的時候，通常會問如下的問題: 什么時候需要考慮在IT系統(tǒng)中使用大數(shù)據(jù)? 準備好使用了么? 從哪里開始? 感覺大數(shù)據(jù)只是一種市場趨勢，我還是應該去做么？這些問題縈繞著CIO和CTO們，當決定部署一個全局化分布式大數(shù)據(jù)架構時，可能會把企業(yè)置于危險之中。
本章目的時定義大數(shù)據(jù)的表征—換句話說，就是什么時候需要考慮將大數(shù)據(jù)放入架構。 但是，也指出了各種大數(shù)據(jù)技術的區(qū)別，能夠理解在何種情況使用哪種技術。
最后, 基于真實世界的例子，構建了典型分布式大數(shù)據(jù)架構的基礎模型。
定義大數(shù)據(jù)表征
基于不同的需要，可能選擇開始大數(shù)據(jù)項目s: 因為所需處理的數(shù)據(jù)容量, 因為系統(tǒng)中數(shù)據(jù)結構的多樣性, 因為擴展性問題, 或者因為需要削減數(shù)據(jù)處理的成本。 本節(jié)中，將看到怎樣的征兆意味著一個團隊需要開始一個大數(shù)據(jù)項目了。
數(shù)據(jù)大小哪些事
使人們開始考慮大數(shù)據(jù)的兩個主要領域是何時出現(xiàn)了與數(shù)據(jù)大小和容量有關的問題。盡管大多數(shù)時間這些問題是考慮大數(shù)據(jù)的合情合理的原因，但今天而已，這并不是唯一的原因。
有其他的表征—例如數(shù)據(jù)的類型. 如何在傳統(tǒng)數(shù)據(jù)存儲中管理不斷增加的各種各樣的數(shù)據(jù)類型, 如SQL數(shù)據(jù)庫, 還期望象建表那樣的結構化么? 不增加靈活性是不可行的，當出現(xiàn)新的數(shù)據(jù)結構是需要技術層面的無縫處理。當討論數(shù)據(jù)類型是，需要想象非結構化數(shù)據(jù)，圖數(shù)據(jù)，圖片，視頻，語音等等。
不但要很好的存儲非結構化數(shù)據(jù)，而且最好是得到一些他們之外的東西。另一表征來自于這一承諾: 大數(shù)據(jù)也可以從大容量的各種數(shù)據(jù)中提取增值信息.若干年前，對于大量讀多于寫的操作，通用的緩存或數(shù)據(jù)庫隊友每周的ETL (extract, transform,load) 處理是足夠的。如今不再是這樣的趨勢。現(xiàn)在，需要一個架構具備長時間處理和準實時數(shù)據(jù)處理的能力。這一架構是分布式的，而不是依賴于高性能且價格高昂的商用機，取而代之的是，高可用，性能驅(qū)動和廉價技術所賦予的靈活性。
當下，如何充分利用增值數(shù)據(jù)以及如何能夠原生地搜索到它們呢？為了回答這一問題，再次考慮傳統(tǒng)存儲中為了加速查詢而創(chuàng)建的索引。如果為了復雜查詢而索引上百列而且包含了主鍵的不確定性，會是什么樣子？不希望在一個基礎SQL 數(shù)據(jù)庫中做這些;取而代之的是，需要考慮按照特殊需要而使用一個 NoSQL存儲. 所以，簡單回顧一下主要路徑：數(shù)據(jù)獲取，結構化，可視化這些真正數(shù)據(jù)管理的場景，顯而易見，數(shù)據(jù)大小不再是主要的考量因素。
典型的商務使用場景
除了技術和架構考慮，需要面對典型大數(shù)據(jù)用例的使用場景。它們部分和特殊的工業(yè)領域相關； 另外的部分可能適應于各種領域。這些考慮一般都是基于分析應用的日志，例如web訪問日志,應用服務器日志，和數(shù)據(jù)庫日志，但是也可以基于各種其他的數(shù)據(jù)源例如社交網(wǎng)絡數(shù)據(jù)。當面對這些使用場景的時候，如果希望隨著商務的增長而彈性擴展，就需要考慮一個分布式的大數(shù)據(jù)架構。
客戶行為分析
感知客戶, 或者叫做 “360-度客戶視角”可能是最流行的大數(shù)據(jù)使用場景?？蛻粢暯峭ǔＳ糜陔娮由虅站W(wǎng)站以及開始于一個非結構化的點擊流—換而言之, 由一個訪客執(zhí)行的主動點擊和被動的網(wǎng)站導航操作組成。通過計算和分析點擊量和面向產(chǎn)品或廣告的印象，可以依賴行為而適配訪客的用戶體驗， 目標是得到優(yōu)化漏斗轉(zhuǎn)換的見解。
情緒分析
公司關注的是其在社交網(wǎng)絡上所被感知的形象和聲譽; 把可能使他們聲名狼藉的負面事件最小化并充分利用正面事件. 通過準實時爬下大量的社交數(shù)據(jù)，可以提取出社交社區(qū)中關于品牌的感受和情緒，從而找到影響用戶并練習他們，改變并強化與這些用戶的交互。
CRM Onboarding
基于訪客的社交行為，可以將客戶的行為分析和數(shù)據(jù)的情感分析結合在一起。公司希望將這些在線數(shù)據(jù)源和已經(jīng)存在的離線數(shù)據(jù)結合在一起，這叫做 CRM (customer relationship management) onboarding, 以便于得到更好和更準確的客戶定位. 進而,公司能夠充分利用這一定位，從而建立更好的目標系統(tǒng)使市場活動的效益最大化。
預測
從數(shù)據(jù)中學習在過去幾年已經(jīng)成為主要的大數(shù)據(jù)趨勢?；诖髷?shù)據(jù)的預測在許多業(yè)界是非常有效的, 例如電信界, 這里可以預測大眾化的路由日志分析. 每一次在設備上發(fā)生了問題, 公司可以預測它并避免宕機時間或利潤丟失。
當結合以上的使用場景的時候，根據(jù)用戶的整體行為，可以使用一個預測型架構來誘惑產(chǎn)品目錄的選擇和價格。
理解大數(shù)據(jù)技術生態(tài)系統(tǒng)
一旦確實要實施一個大數(shù)據(jù)項目, 最困難的事是架構中的技術選型。這不僅是選擇最著名的Hadoop相關技術，而且需要理解如何給它們分類才能構建一個一致性的分布式架構。為了得到大數(shù)據(jù)星云中的項目數(shù)量，可以參見 https://github.com/zenkay/bigdata-ecosystem#projects-1 ，這里有100多個工程項目。這里，你可以考慮選擇一個Hadoop的發(fā)布版,一個分布式文件系統(tǒng) ,一個類SQL處理語音, 一個機器學習語言, 調(diào)度器,面向消息的中間件, NoSQL數(shù)據(jù)存儲,數(shù)據(jù)可視化等等。
既然本書的目的是描述構建一個分布式架構的可擴展方法，所以不深入到所有的項目中；取而代之，重點在典型大數(shù)據(jù)工程中最可能使用的東西。顯然，架構的選擇和項目的集成依賴于具體的需要，你可以看到在特定的領域可以使用這些項目的具體實例。為了使Hadoop 技術表現(xiàn)的更有相關性，這一分布式架構將適用于前面描述的典型場景，命名如下：
- 客戶行為分析
- 情緒分析
- CRM onboarding 和預測
Hadoop 發(fā)布版
在涵蓋了Hadoop 生態(tài)系統(tǒng)的大數(shù)據(jù)項目中，有兩個選擇：
- 在一個連貫，彈性和一致的架構中分別下載相關項目，然后嘗試創(chuàng)建或組裝它們
- 使用一個廣泛流行的 Hadoop分發(fā)版, 已經(jīng)裝配或創(chuàng)建好了這些技術.
盡管選項一完全可行，你還是可能選擇方案二，因為一個Hadoop 發(fā)型包保證了所有安裝組件的兼容性，安裝，配置部署，監(jiān)控和支持都非常簡單。
Hortonworks 和Cloudera 是這樣領域的主角。盡管它們之間有些區(qū)別，但是從大數(shù)據(jù)包的角度上看，它們是一樣的，你不需要那些專屬的插件。我們的目標不是描述每個發(fā)布版的所有組件，二是聚焦在每個提供者在標準生態(tài)系統(tǒng)中所增加的部分。同時，描述了在每種情況下，該架構所依賴的其他組件。
Cloudera CDH
Cloudier在Hadoop基礎組件上增加了一個內(nèi)部機構組件的集合; 這些組件被設計成給你更好的集群管理和搜素體驗。部分組件列表如下：
Impala: 一個實時，并行化，基于SQL的引擎來搜索 HDFS
(Hadoop Distributed File System)和 HBase中的數(shù)據(jù). Impala被認為是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)項目
藍色部分是 Cloudera的特使組件.
Figure 1-1. Cloudera Hadoop發(fā)布版
Hortonworks HDP
Hortonworks 是一個百分之百的開源而且使用了穩(wěn)定的組件包，而不是1Hadoop 項目中最新的分發(fā)版本。它增加了一個組件管理控制臺來與Cloudera Manager對比。Figure 1-2 展示了Hortonworks 發(fā)布版與Figure 1-1 相應的分類：綠色部分是Hortonworks的特殊組件.
Figure 1-2. Hortonworks Hadoop distribution
如前所述，當我們構建架構的時候，這兩個發(fā)布版(Hortonworks 和Cloudera) 是一樣的。盡管如此, 如果考慮到每個發(fā)布版的成熟度，應當選擇; Cloudera Manager比Ambari更完整和穩(wěn)定 .進一步，考慮實時與大數(shù)據(jù)集交互，更應該因為它的性能卓越而使用Cloudera.
Hadoop Distributed File System (HDFS)
你可能疑慮攝取到Hadoop集群中的數(shù)據(jù)存儲到哪里。一般都在一個專有的系統(tǒng)上，叫做HDFS。HDFS的核心特性:
- 分布式
- 高吞吐量訪問
- 高可用
- 容錯
- 參數(shù)調(diào)整
- 安全
- 負載均衡
HDFS 是Hadoop集群中數(shù)據(jù)存儲的頭等公民。數(shù)據(jù)在集群數(shù)據(jù)節(jié)點中自動復制。
Figure 1-3 展示了HDFS中的數(shù)據(jù)如何在 一個集群的五個節(jié)點中復制的。
Figure 1-3. HDFS data replication
可以從 hadoop.apache.org獲得更多的有關HDFS的信息。
Data Acquisition
數(shù)據(jù)的獲取或者攝取開始于不同的數(shù)據(jù)源，可能是大的日志文件，流數(shù)據(jù)， ETL處理過的輸出，在線的非結構化數(shù)據(jù)，或者離線的結構化數(shù)據(jù)。
Apache Flume
當查看生成的攝取日志的時候，強烈推薦使用Apache Flume; 它是穩(wěn)定且高可用的，提供了一個簡單，靈活和基友流數(shù)據(jù)的可感知編程模型。基本上，僅通過配置管理不需要寫一行代碼就可以陪著一個數(shù)據(jù)流水線。
Flume 由sources, channels, 和sinks組成. Flume source 基本上從一個外部數(shù)據(jù)源來消費一個事件如 Apache Avro source,然后存到channel. channel是一個像文件系統(tǒng)那樣的被動存儲系統(tǒng) ; 它在sink 消費事件前一直持有它. sink 消費事件，然后從channel中刪除該事件，并分發(fā)給一個外部的目標。
Figure 1-4 描述了一個web server和HDFS間的日志流如 Apache,使用了Flume 流水線.
Figure 1-4. Flume architecture
通過 Flume, 可以將web服務器產(chǎn)生的不同日志文件移動到HDFS. 牢記我們工作在一個分布式的架構，可能包含有負載均衡器，HTTP servers,應用服務器，訪問日志等等 . 我們是一不同的方式充分利用這些資源，使之能夠被Flume流水線處理 . 詳情參見 flume.apache.org.
Apache Sqoop
Swoop是一個從結構化數(shù)據(jù)庫傳說大量數(shù)據(jù)到HDFS. 使用它，既可以從一個外部的關系型數(shù)據(jù)庫將數(shù)據(jù)導入到HDFS, Hive, 或者 HBase, 也可以Hadoop 集群導出到一個關系型數(shù)據(jù)庫或者數(shù)據(jù)倉庫.
Sqoop 支持主流的關系型數(shù)據(jù)庫例如Oracle, MySQL, 和Postgres. 這個項目把你從寫腳本傳輸數(shù)據(jù)中解脫出來;它提供了高性能數(shù)據(jù)傳輸?shù)奶匦?因為關系型數(shù)據(jù)庫中的數(shù)據(jù)增長迅速, 最好從開始就定義那些快速增長的表，然后使用Sqoop將數(shù)據(jù)周期性地傳輸?shù)紿adoop，以便用于分析.
然后，結合Hadoop與其他數(shù)據(jù)，可以使用Sqoop 導出數(shù)據(jù)注入到BI 分析工具中. 詳情參見 sqoop.apache.org.
處理語言
一旦數(shù)據(jù)到了HDFS,可以使用不同的處理語言從原始數(shù)據(jù)得到最好的結果.
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ù)處理架構. 現(xiàn)在已經(jīng)實現(xiàn)了YARN (Yet Another Resource Negotiator), MapReduce 已經(jīng)成為了眾多處理模型中的一個. 這意味著可以依賴特殊的使用場景來采用特殊的處理模型.
Figure 1-5 展示了HDFS, YARN, 和處理模型是如何組織的.
Figure 1-5. YARN structure
我們無法審視所有的語言和處理模型; 專注于 Hive 和Spark, 它們覆蓋了我們所用的用例，長時間數(shù)據(jù)處理和流處理。
使用Hive的批處理
當決定寫第一個批處理job的時候, 使用所喜歡語言實現(xiàn)它，例如Java或 Python,但如果真的要做，最好舒服地使用mapping 和reducing 設計模式, 但這需要開發(fā)的時間和復雜的編碼，有時候很難去維護。
作為一個替代方式, 可以使用例如Hive這樣的高級語言, 以類SQL方式簡單而又強大地從HDFS中查詢數(shù)據(jù). 在用Java寫了10行代碼的MapReduce地方,在Hive中, 只需要一條 SQL 查詢語句.
當使用其他語言而不是原生MapReduce, 其主要的缺陷是性能.在 Hive 和 MapReduce之間有著天然的時延; 另外, SQL查詢也與關系型數(shù)據(jù)庫中的查詢截然不同。詳情參見 hive.apache.org.
Hive 不是一個實時或準實時的處理語言，被用作批處理，例如一個低優(yōu)先級的長時間處理任務. 處理流式數(shù)據(jù)，需要使用Spark Streaming.
使用Spark Streaming的流處理
Spark Streaming 可以通過Java, Scale, 或者Python來寫批處理任務, 但是可以處理流數(shù)據(jù). 這非常適合處理高吞吐量的數(shù)據(jù)源T例如社交網(wǎng)絡(Twitter), 點擊流日志, 或者 web 訪問日志.
Spark Streaming 是Spark的一個擴展, 它充分利用了分布式數(shù)據(jù)處理架構，把流式計算作為 一系列不確定的小時間間隔的微型批處理計算。詳情參見 spark.apache.org.
Spark Streaming 可以從各種源獲得數(shù)據(jù)，通過與如Apache Kafka這樣工具的結合, Spark Streaming 成為強容錯和高性能系統(tǒng)的基礎。
面向消息的中間件Apache Kafka
Apache Kafka 是一個由Linkedin開發(fā)的訂閱－發(fā)布消息的分布式應用。Kafka經(jīng)常與 Apache ActiveMQ 或者RabbitMQ對比, 但根本不同是Kafka 沒有實現(xiàn)JMS (Java Message Service). 然而, Kafka是一個持久化消息的高吞吐量系統(tǒng) , 支持隊列和話題語意， 使用 ZooKeeper形成集群節(jié)點。
Kafka 實現(xiàn)了訂閱－發(fā)布的企業(yè)級集成，支持并行化，以及性能和容錯的企業(yè)級特性。
Figure 1-6 給出了訂閱－發(fā)布架構的高層視角，消息在broker傳輸，服務于分區(qū)的話題。
Figure 1-6. Kafka partitioned topic example
使用 Kafka在我們架構中的引導點 ，主要用于接受數(shù)據(jù)并推送到Spark
Streaming. 詳情參見 kafka.apache.org.
機器學習
當我們以無限收斂模型處理小數(shù)據(jù)采樣時，在架構中討論機器學習還為時尚早。我們是充分利用現(xiàn)有的分層或特殊語言來使用機器學習，例如
Spark中的 Spark MLlib。
Spark MLlib
MLlib是Spark上的機器學習庫, 充分利用了 Spark Direct Acyclic Graph (DAG) 執(zhí)行引擎, 所提供的API 集合方便地集成到Spark中. 它由各種的算法組成 ：基本統(tǒng)計, 邏輯回歸， k-means 聚類, 從混合高斯到奇異值分解以及多維樸素貝葉斯。
通過 Spark MLlib 這些開箱即用算法，可以用幾行代碼就能過簡單地訓練數(shù)據(jù)并構建預測模型a 詳情參見 spark.apache.org/mllib.
NoSQL 存儲
NoSQL 存儲是數(shù)據(jù)架構的基礎組件，因為它們可以攝取大量數(shù)據(jù)，提供彈性伸縮，高可用性以及開箱即用。Couchbase 和 ElasticSearch是兩種我們聚焦的技術，先做簡單討論，稍后使用它們。
Couchbase
Couchbase是一個面向文檔的NoSQL數(shù)據(jù)庫，提供了一個靈活的模型輕松縮放，以及一致性的高性能。使用 Couchbase作為文檔數(shù)據(jù)存儲，基本上重定向從前端來的所有查詢 到 Couchbase 防止了關系型數(shù)據(jù)庫的高吞吐量讀操作。詳情參見 couchbase.com.
ElasticSearch
ElasticSearch 是一種非常流行的 NoSQL 技術，擁有可伸縮分布式索引引擎和搜索特性，相當于一般架構中Apache Lucene 加上實時數(shù)據(jù)分析和全文搜索.
ElasticSearch是ELK平臺的一部分（ ElasticSearch + Logstash + Kibana,），是由Elastic公司發(fā)布的。三個產(chǎn)品結合在一起提供了數(shù)據(jù)采集，存儲和可視化最好的端到端平臺:
Logstash 從各種數(shù)據(jù)源采集數(shù)據(jù)，例如社交數(shù)據(jù)，日志，消息隊列，或者傳感器，支持數(shù)據(jù)的豐富性和轉(zhuǎn)換，然后傳輸?shù)揭粋€索引系統(tǒng)例如ElasticSearch.
ElasticSearch 在一個彈性伸縮的分布式系統(tǒng)中索引數(shù)據(jù)，無縫提供了多語言庫，很容易在應用中實現(xiàn)實時搜索和分析。
Kibana 是一個定制化的用戶界面，可以構建從簡單到復雜的儀表盤，來探索和可視化ElasticSearch 索引的數(shù)據(jù)。
Figure 1-7 展示了Elastic產(chǎn)品的結構.
Figure 1-7. ElasticSearch products
如前圖所示, Elastic 也提供了商用產(chǎn)品例如Marvel,基于Kibana的一個監(jiān)控控制臺; Shield, 一個安全框架, 例如提供授權和認證; Watcher, 一個告警和通知系統(tǒng). 但本書中不使用這些商用產(chǎn)品。我們主要使用ElasticSearch作為搜索引擎來持有Spark產(chǎn)生的產(chǎn)品。在處理和聚合之后，數(shù)據(jù)在ElasticSearch中被索引，使第三方系統(tǒng)通過ElasticSearch引擎查詢數(shù)據(jù)。另一方面，我們也使用 ELK來處理日志和虛擬化分析，而不只是平臺操作視角。詳情參見 elastic.co.
創(chuàng)建有長遠規(guī)劃的大數(shù)據(jù)架構
記住所有這些大數(shù)據(jù)技術，現(xiàn)在來構建我們的架構。
架構概覽
從高層視角來看, 我們的架構看起來象另一個電子商務應用架構，需要如下：
- 一個web應用，訪客可以用它導航一個產(chǎn)品目錄
- 一個日志攝取應用：拉取日志并處理它們
- 一個機器學習應用：為訪客觸發(fā)推薦
- 一個處理引擎：作為該架構的中央處理集群
- 一個搜索引擎：拉取處理數(shù)據(jù)的分析
Figure 1-8 展示了這些不同應用如何在該架構組織起來的。
Figure 1-8. Architecture overview
日志攝取
日志攝取應用被用作消費應用日志例如web 訪問日志. 為了簡化使用場景，提供一個web訪問日志，模擬訪客瀏覽產(chǎn)品目錄，這些日志代表了點擊流日志，既用作長時處理也用作實時推薦。架構有兩個選項：第一個是以Flume來傳輸日志；第二個是以LEK 來創(chuàng)建訪問分析。
Figure 1-9 展示了ELK 和Flume是如何處理日志的.
Figure 1-9. Ingestion application
我們在架構中使用ELK ，因為LEK的三個產(chǎn)品無縫集成，能夠比使用Flume給我們更多的價值 。
機器學習
機器學習應用接收數(shù)據(jù)流，構建推薦引擎。這一應用使用一個基本的算法來基于Spark MLlib 介紹 機器學習的概念。
Figure 1-10 展示了該機器學習應用如何使用Kafka 接收數(shù)據(jù)，然后發(fā)送給Spark 處理,最后在ElasticSearch 建立索引為將來使用做準備。
Figure 1-10. Machine learning
處理引擎
處理引擎是該架構的心臟; 它接收各種源的數(shù)據(jù)，代理合適模型的處理。
Figure 1-11 展示了由Hive組成的處理引擎如何接收數(shù)據(jù)，以及Spark的實時/準實時處理。
Figure 1-11. Processing engine
這里使用Kafka 與 Logstash結合把數(shù)據(jù)分發(fā)給ElasticSearch. Spark位于 Hadoop 集群的頂端， 但不說必須的。為了簡化起見，本書不建立 Hadoop集群，而是以standalone模式運行Spark。顯然，應用同樣可以部署在所選擇的Hadoop 發(fā)布版上。
搜索引擎
搜索引擎充分利用處理引擎所處理的數(shù)據(jù)，同時暴露出專有的RESTful API以便于分析使用。
