大數據平臺架構技術選型與場景運用(轉)

導讀：本文將大數據的工做角色分爲三種類型，包括業務相關、數據科學相關和數據工程。大數據平臺偏向於工程方面，大數據平臺通常包括數據源、數據採集、數據存儲、數據分析等方面。

講師從數據來源、數據源結構、數據變化程度和數據規模等4個維度對數據源進行分類，數據源分類維度的不一樣決定最後的技術選型。講師還對數據源分類的定義及選型方式進行詳細講解，最終聯繫到大數據的應用場景，讓數據應用方式更加直觀。

1、大數據平臺

大數據在工做中的應用有三種：

• 與業務相關，好比用戶畫像、風險控制等；
• 與決策相關，數據科學的領域，瞭解統計學、算法，這是數據科學家的範疇；
• 與工程相關，如何實施、如何實現、解決什麼業務問題，這是數據工程師的工做。

數據工程師在業務和數據科學家之間搭建起實踐的橋樑。本文要分享的大數據平臺架構技術選型及場景運用偏向於工程方面。

如圖所示，大數據平臺第一個要素就是數據源，咱們要處理的數據源每每是在業務系統上，數據分析的時候可能不會直接對業務的數據源進行處理，而是先通過數據採集、數據存儲，以後纔是數據分析和數據處理。

從整個大的生態圈能夠看出，要完成數據工程須要大量的資源；數據量很大須要集羣；要控制和協調這些資源須要監控和協調分派；面對大規模的數據怎樣部署更方便更容易；還牽扯到日誌、安全、還可能要和雲端結合起來，這些都是大數據圈的邊緣，一樣都很重要。

2、數據源的特色

數據源的特色決定數據採集與數據存儲的技術選型，我根據數據源的特色將其分爲四大類：

• 第一類：歷來源來看分爲內部數據和外部數據；
• 第二類：從結構來看分爲非結構化數據和結構化數據；
• 第三類：從可變性來看分爲不可變可添加數據和可修改刪除數據；
• 第四類，從規模來看分爲大量數據和小量數據。

內部數據

來自企業內部系統，能夠採用主動寫入技術(push)，從而保證變動數據及時被採集。

外部數據

企業要作大數據的話確定不會只侷限於企業內部的數據，好比銀行作徵信，就不能只看銀行系統裏的交易數據和用戶信息，還要到互聯網上去拉取外部數據。

外部數據分爲兩類：

• 一類是要獲取的外部數據自己提供API，能夠調用API獲取，好比微信；
• 另外一類是數據自己不提供API，須要經過爬蟲爬取過來。

這兩類數據都不是咱們可控制的，須要咱們去得到，它的結構也可能跟咱們企業內部數據的結構不同，還須要進行轉換，爬蟲爬取的數據結構更亂，所以大數據平臺裏須要作ETL，由ETL進行數據提取、轉換、加載，清洗、去重、去噪，這個過程比較麻煩。爬蟲爬過來的數據每每是非結構性的、文檔型的數據，還有視頻、音頻，這就更麻煩了。

結構化數據 & 非結構化數據

結構化和非結構化數據在存儲時的選型徹底不一樣，非結構化數據偏向於文件，或者選擇NoSQL數據庫；考慮到事務的一致性，咱們也可能選擇傳統的數據庫。

不變可添加數據

若是數據源的數據是不變的，或者只容許添加（一般，數據分析的事實表，例如銀行交易記錄等都不容許修改或刪除），則採集會變得很是容易，同步時只須要考慮最簡單的增量同步策略，維持數據的一致性也相對變得容易。

對於大數據分析來講，咱們天天在處理的數據大部分是不可變動的。正如Datomic數據庫的設計哲學就是數據爲事實（fact），它是不可變的，即數據是曾經發生的事實，事實是不能夠被篡改的，哪怕改一個地址，從設計的角度來講也不是改動一個地址，而是新增了一個地址。交易也是如此。

可修改可刪除數據

銀行的交易記錄、保險單的交易記錄，互聯網的訪客訪問記錄、下單記錄等都是不可變的。可是數據源的數據有些可能會修改或刪除，尤爲是許多維表常常須要變更。要對這樣的數據進行分析處理，最簡單的辦法就是採用直連形式，但直連可能會影響數據分析的效率與性能，且多數數據模型與結構可能不符合業務人員進行數據分析的業務訴求。若是採用數據採集的方式，就要考慮同步問題。

大數據量

針對大數據量，若是屬於高延遲的業務，能夠採用batch的處理方式，實時分析則須要使用流式處理，將二者結合就是Lambda架構，即有實時處理、又能知足必定的大數據量，這是如今比較流行的大數據處理方式。

3、數據存儲的技術選型

大數據平臺特徵：相同的業務數據會以多種不一樣的表現形式，存儲在不一樣類型的數據庫中，造成一種poly-db的數據冗餘生態。

先把數據源進行分類，而後根據其特色判斷用什麼方式採集，採集以後要進行存儲。數據存儲的技術選型依據有三點：

• 第一點取決於數據源的類型和採集方式。好比非結構化的數據不可能拿一個關係數據庫去存儲。採集方式若是是流失處理，那麼傳過來放到Kafka是最好的方式。
• 第二點取決於採集以後數據的格式和規模。好比數據格式是文檔型的，能選的存儲方式就是文檔型數據庫，例如MongoDB；採集後的數據是結構化的，則能夠考慮關係型數據庫；若是數據量達到很大規模，首選放到HDFS裏。
• 第三點是分析數據的應用場景。根據數據的應用場景來斷定存儲技術選型。

場景一：輿情分析

作輿情分析的時候客戶要求全部數據存放兩年，一天600多萬，兩年就是700多天×600多萬，幾十億的數據。並且爬蟲爬過來的數據是輿情，作了分詞以後獲得的多是大段的網友評論，客戶要求對輿情進行查詢，作全文本搜索，並要求響應時間控制在10s之內。

咱們後來選擇用ES，在單機上作了一個簡單的測試，大概三億多條數據，用最壞的查詢條件進行搜索，保證這個搜索是全表搜索（基於Lucence建立了索引，使得這種搜索更高效），整個查詢時間能控制在幾秒之內。

如圖所示，爬蟲將數據爬到Kafka裏，在裏面作流處理，去重去噪作語音分析，寫到ElasticSearch裏。咱們作大數據的一個特色是多數據庫，會根據不一樣的場景選擇不一樣的數據庫，因此會產生大量的冗餘。

場景二：商業智能產品

BI產品主要針對數據集進行的數據分析以聚合運算爲主，好比求合、求平均數、求同比、求環比、求其餘的平方差或之類的標準方差。咱們既要知足大數據量的水平可伸縮，又要知足高性能的聚合運算。選擇Parquet列式存儲，能夠同時知足這兩個需求。

場景三：Airbnb的大數據平臺

Airbnb的大數據來自兩塊：一是自己的業務數據，二是大量的事件。數據源不一樣，採集方式也不同。日誌數據經過發送Kafka事件，而線上數據則經過Sqoop同步。數據存儲選擇HDFS集羣，而後經過Presto對Hive表執行即席查詢。S3是一個獨立的存儲系統。

4、數據處理

數據處理分爲三大類：

• 第一類是從業務的角度，細分爲查詢檢索、數據挖掘、統計分析、深度分析，其中深度分析分爲機器學習和神經網絡。
• 第二類是從技術的角度，細分爲Batch、SQL、流式處理、machine learning、Deep learning。
• 第三類是編程模型，細分爲離線編程模型、內存編程模型、實時編程模型。

結合前文講述的數據源特色、分類、採集方式、存儲選型、數據分析、數據處理，我在這裏給出一個整體的大數據平臺的架構。值得注意的是，架構圖中去掉了監控、資源協調、安全日誌等。

左側是數據源，有實時流的數據（多是結構化、非結構化，但其特色是實時的），有離線數據，離線數據通常採用的多爲ETL的工具，常見的作法是在大數據平臺裏使用Sqoop或Flume去同步數據，或調一些NIO的框架去讀取加載，而後寫到HDFS裏面，固然也有一些特別的技術存儲的類型，好比HAWQ就是一個支持分佈式、支持事務一致性的開源數據庫。

從業務場景來看，若是咱們作統計分析，就可使用SQL或MapReduce或streaming或Spark。若是作查詢檢索，同步寫到HDFS的同時還要考慮寫到ES裏。若是作數據分析，能夠建一個Cube，而後再進入OLAP的場景。

這個圖基本上把全部的內容都涵蓋了，從場景的角度來分析倒推，用什麼樣的數據源、採用什麼樣的採集方式、存儲成什麼樣子，能知足離線、內存、實時、流的各類模型，都能從圖中獲得解答.

文章轉載於:http://geek.csdn.net/news/detail/203332.以爲這篇文章很是好，好你們一塊兒分享。同時也爲了之後的便於學習回顧。