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

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

一、大數據平臺

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

與業(yè)務相關，比如用戶畫像、風險控制等;

與決策相關，數據科學的領域，了解統(tǒng)計學、算法，這是數據科學家的范疇;

與工程相關，如何實施、如何實現(xiàn)、解決什么業(yè)務問題，這是數據工程師的工作。

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

如圖所示，大數據平臺第一個要素就是數據源，我們要處理的數據源往往是在業(yè)務系統(tǒng)上，數據分析的時候可能不會直接對業(yè)務的數據源進行處理，而是先經過數據采集、數據存儲，之后才是數據分析和數據處理。

從整個大的生態(tài)圈可以看出，要完成數據工程需要大量的資源;數據量很大需要集群;要控制和協(xié)調這些資源需要監(jiān)控和協(xié)調分派;面對大規(guī)模的數據怎樣部署更方便更容易;還牽扯到日志、安全、還可能要和云端結合起來，這些都是大數據圈的邊緣，同樣都很重要。

二、數據源的特點

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

第一類：從來源來看分為內部數據和外部數據;

第二類：從結構來看分為非結構化數據和結構化數據;

第三類：從可變性來看分為不可變可添加數據和可修改刪除數據;

第四類，從規(guī)模來看分為大量數據和小量數據。

內部數據

來自企業(yè)內部系統(tǒng)，可以采用主動寫入技術(push)，從而保證變更數據及時被采集。

外部數據

企業(yè)要做大數據的話肯定不會只局限于企業(yè)內部的數據，比如銀行做征信，就不能只看銀行系統(tǒng)里的交易數據和用戶信息，還要到互聯(lián)網上去拉取外部數據。

外部數據分為兩類：

一類是要獲取的外部數據本身提供API，可以調用API獲取，比如微信;

另一類是數據本身不提供API，需要通過爬蟲爬取過來。

這兩類數據都不是我們可控制的，需要我們去獲得，它的結構也可能跟我們企業(yè)內部數據的結構不一樣，還需要進行轉換，爬蟲爬取的數據結構更亂，因此大數據平臺里需要做ETL，由ETL進行數據提取、轉換、加載，清洗、去重、去噪，這個過程比較麻煩。爬蟲爬過來的數據往往是非結構性的、文檔型的數據，還有視頻、音頻，這就更麻煩了。

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

結構化和非結構化數據在存儲時的選型完全不同，非結構化數據偏向于文件，或者選擇NoSQL數據庫;考慮到事務的一致性，我們也可能選擇傳統(tǒng)的數據庫。

不變可添加數據

如果數據源的數據是不變的，或者只允許添加(通常，數據分析的事實表，例如銀行交易記錄等都不允許修改或刪除)，則采集會變得非常容易，同步時只需要考慮最簡單的增量同步策略，維持數據的一致性也相對變得容易。

對于大數據分析來說，我們每天在處理的數據大部分是不可變更的。正如Datomic數據庫的設計哲學就是數據為事實(fact)，它是不可變的，即數據是曾經發(fā)生的事實，事實是不可以被篡改的，哪怕改一個地址，從設計的角度來說也不是改動一個地址，而是新增了一個地址。交易也是如此。

可修改可刪除數據

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

大數據量

針對大數據量，如果屬于高延遲的業(yè)務，可以采用batch的處理方式，實時分析則需要使用流式處理，將兩者結合就是Lambda架構，即有實時處理、又能滿足一定的大數據量，這是現(xiàn)在比較流行的大數據處理方式。

三、數據存儲的技術選型

大數據平臺特征：相同的業(yè)務數據會以多種不同的表現(xiàn)形式，存儲在不同類型的數據庫中，形成一種poly-db的數據冗余生態(tài)。

先把數據源進行分類，然后根據其特點判斷用什么方式采集，采集之后要進行存儲。數據存儲的技術選型依據有三點：

第一點取決于數據源的類型和采集方式。比如非結構化的數據不可能拿一個關系數據庫去存儲。采集方式如果是流失處理，那么傳過來放到Kafka是最好的方式。

第二點取決于采集之后數據的格式和規(guī)模。比如數據格式是文檔型的，能選的存儲方式就是文檔型數據庫，例如MongoDB;采集后的數據是結構化的，則可以考慮關系型數據庫;如果數據量達到很大規(guī)模，首選放到HDFS里。

第三點是分析數據的應用場景。根據數據的應用場景來判定存儲技術選型。

場景一：輿情分析

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

我們后來選擇用ES，在單機上做了一個簡單的測試，大概三億多條數據，用最壞的查詢條件進行搜索，保證這個搜索是全表搜索(基于Lucence創(chuàng)建了索引，使得這種搜索更高效)，整個查詢時間能控制在幾秒以內。

如圖所示，爬蟲將數據爬到Kafka里，在里面做流處理，去重去噪做語音分析，寫到ElasticSearch里。我們做大數據的一個特點是多數據庫，會根據不同的場景選擇不同的數據庫，所以會產生大量的冗余。

場景二：商業(yè)智能產品

BI產品主要針對數據集進行的數據分析以聚合運算為主，比如求合、求平均數、求同比、求環(huán)比、求其他的平方差或之類的標準方差。我們既要滿足大數據量的水平可伸縮，又要滿足高性能的聚合運算。選擇Parquet列式存儲，可以同時滿足這兩個需求。

場景三：Airbnb的大數據平臺

Airbnb的大數據來自兩塊：一是本身的業(yè)務數據，二是大量的事件。數據源不同，采集方式也不一樣。日志數據通過發(fā)送Kafka事件，而線上數據則通過Sqoop同步。數據存儲選擇HDFS集群，然后通過Presto對Hive表執(zhí)行即席查詢。S3是一個獨立的存儲系統(tǒng)。

四、數據處理

數據處理分為三大類：

第一類是從業(yè)務的角度，細分為查詢檢索、數據挖掘、統(tǒng)計分析、深度分析，其中深度分析分為機器學習和神經網絡。

第二類是從技術的角度，細分為Batch、SQL、流式處理、machine learning、Deep learning。

第三類是編程模型，細分為離線編程模型、內存編程模型、實時編程模型。

結合前文講述的數據源特點、分類、采集方式、存儲選型、數據分析、數據處理，我在這里給出一個總體的大數據平臺的架構。值得注意的是，架構圖中去掉了監(jiān)控、資源協(xié)調、安全日志等。

左側是數據源，有實時流的數據(可能是結構化、非結構化，但其特點是實時的)，有離線數據，離線數據一般采用的多為ETL的工具，常見的做法是在大數據平臺里使用Sqoop或Flume去同步數據，或調一些NIO的框架去讀取加載，然后寫到HDFS里面，當然也有一些特別的技術存儲的類型，比如HAWQ就是一個支持分布式、支持事務一致性的開源數據庫。

從業(yè)務場景來看，如果我們做統(tǒng)計分析，就可以使用SQL或MapReduce或streaming或Spark。如果做查詢檢索，同步寫到HDFS的同時還要考慮寫到ES里。如果做數據分析，可以建一個Cube，然后再進入OLAP的場景。

這個圖基本上把所有的內容都涵蓋了，從場景的角度來分析倒推，用什么樣的數據源、采用什么樣的采集方式、存儲成什么樣子，能滿足離線、內存、實時、流的各種模型，都能從圖中得到解答。