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