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

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

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

定義大數據表征

基于不同的需要，可能選擇開始大數據項目s: 因為所需處理的數據容量, 因為系統(tǒng)中數據結構的多樣性, 因為擴展性問題, 或者因為需要削減數據處理的成本。 本節(jié)中，將看到怎樣的征兆意味著一個團隊需要開始一個大數據項目了。

數據大小哪些事

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

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

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

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

典型的商務使用場景

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

客戶行為分析

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

情緒分析

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

CRM Onboarding

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

預測

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

當結合以上的使用場景的時候，根據用戶的整體行為，可以使用一個預測型架構來誘惑產品目錄的選擇和價格。

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

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

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

- 客戶行為分析

- 情緒分析

- CRM onboarding 和預測

Hadoop 發(fā)布版

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

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

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

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

Cloudera CDH

+ Cloudier在Hadoop基礎組件上增加了一個內部機構組件的集合; 這些組件被設計成更好的集群管理和搜索體驗。部分組件列表如下：

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

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

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

+ Hue: 一個用于執(zhí)行用戶交互數據操作和執(zhí)行腳本的控制臺，可以操作集群內不同的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 發(fā)布版

如前所述，當我們構建架構的時候，這兩個發(fā)布版(Hortonworks 和Cloudera) 是一樣的。盡管如此, 如果考慮到每個發(fā)布版的成熟度，應當選擇; Cloudera Manager比Ambari更完整和穩(wěn)定 .進一步，考慮實時與大數據集交互，更應該因為它的性能卓越而使用Cloudera.

Hadoop Distributed File System (HDFS)

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

• 分布式
• 高吞吐量訪問
• 高可用
• 容錯
• 參數調整
• 安全
• 負載均衡

HDFS 是Hadoop集群中數據存儲的頭等公民。數據在集群數據節(jié)點中自動復制。

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

Figure 1-3. HDFS 數據復制

可以從 hadoop.apache.org獲得更多的有關HDFS的信息。

Data Acquisition

數據的獲取或者攝取開始于不同的數據源，可能是大的日志文件，流數據， ETL處理過的輸出，在線的非結構化數據，或者離線的結構化數據。

Apache Flume

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

Flume 由sources, channels, 和sinks組成. Flume source 基本上從一個外部數據源來消費一個事件如 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 架構

通過 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的發(fā)布, 有了HDFS之上新的數據處理架構. 現在已經實現了YARN (Yet Another Resource Negotiator), MapReduce 已經成為了眾多處理模型中的一個. 這意味著可以依賴特殊的使用場景來采用特殊的處理模型.

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

Figure 1-5. YARN 結構

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

使用Hive的批處理

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

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

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

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

使用Spark Streaming的流處理

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

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

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

面向消息的中間件Apache Kafka

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

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

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

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

使用 Kafka在我們架構中的引導點 ，主要用于接受數據并推送到Spark

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

機器學習

當我們以無限收斂模型處理小數據采樣時，在架構中討論機器學習還為時尚早。我們是充分利用現有的分層或特殊語言來使用機器學習，例如

Spark中的 Spark MLlib。

Spark MLlib

MLlib是Spark上的機器學習庫, 充分利用了 Spark Direct Acyclic Graph (DAG) 執(zhí)行引擎, 所提供的API 集合方便地集成到Spark中. 它由各種的算法組成 ：基本統(tǒng)計, 邏輯回歸， 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公司發(fā)布的。三個產品結合在一起提供了數據采集，存儲和可視化最好的端到端平臺:

• Logstash 從各種數據源采集數據，例如社交數據，日志，消息隊列，或者傳感器，支持數據的豐富性和轉換，然后傳輸到一個索引系統(tǒng)例如ElasticSearch.

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

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

Figure 1-7 展示了Elastic產品的結構.

Figure 1-7. ElasticSearch 開源產品

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

創(chuàng)建有長遠規(guī)劃的大數據架構

記住所有這些大數據技術，現在來構建我們的架構。

架構概覽

從高層視角來看, 我們的架構看起來象另一個電子商務應用架構，需要如下：

• 一個web應用，訪客可以用它導航一個產品目錄
• 一個日志攝取應用：拉取日志并處理它們
• 一個機器學習應用：為訪客觸發(fā)推薦
• 一個處理引擎：作為該架構的中央處理集群
• 一個搜索引擎：拉取處理數據的分析

Figure 1-8 展示了這些不同應用如何在該架構組織起來的。

Figure 1-8. 架構概貌

日志攝取

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

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

Figure 1-9. 攝取數據

我們在架構中使用ELK ，因為LEK的三個產品無縫集成，能夠比使用Flume給我們更多的價值 。

機器學習

機器學習應用接收數據流，構建推薦引擎。這一應用使用一個基本的算法來基于Spark MLlib 介紹 機器學習的概念。

Figure 1-10 展示了該機器學習應用如何使用Kafka 接收數據，然后發(fā)送給Spark 處理,最后在ElasticSearch 建立索引為將來使用做準備。

Figure 1-10. 機器學習

處理引擎

處理引擎是該架構的心臟; 它接收各種源的數據，代理合適模型的處理。

Figure 1-11 展示了由Hive組成的處理引擎如何接收數據，以及Spark的實時/準實時處理。

Figure 1-11. Processing engine

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

搜索引擎

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

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