導讀：本文將大資料的工作角色分為三種類型，包括業務相關、資料科學相關和資料工程。大資料平臺偏向於工程方面，大資料平臺一般包括資料來源、資料採集、資料儲存、資料分析等方面。

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

一、大資料平臺

大資料在工作中的應用有三種：

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

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

如圖所示，大資料平臺第一個要素就是資料來源，我們要處理的資料來源往往是在業務系統上，資料分析的時候可能不會直接對業務的資料來源進行處理，而是先經過資料採集、資料儲存，之後才是資料分析和資料處理。

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

二、資料來源的特點

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

• 第一類：從來源來看分為內部資料和外部資料；
• 第二類：從結構來看分為非結構化資料和結構化資料；
• 第三類：從可變性來看分為不可變可新增資料和可修改刪除資料；
• 第四類，從規模來看分為大量資料和小量資料。

內部資料

來自企業內部系統，可以採用主動寫入技術(push)，從而保證變更資料及時被採集。

外部資料

企業要做大資料的話肯定不會只侷限於企業內部的資料，比如銀行做徵信，就不能只看銀行系統裡的交易資料和使用者資訊，還要到網際網路上去拉取外部資料。

外部資料分為兩類：

• 一類是要獲取的外部資料本身提供API，可以呼叫API獲取，比如微信；
• 另一類是資料本身不提供API，需要通過爬蟲爬取過來。

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

結構化資料 & 非結構化資料

結構化和非結構化資料在儲存時的選型完全不同，非結構化資料偏向於檔案，或者選擇NoSQL資料庫；考慮到事務的一致性，我們也可能選擇傳統的資料庫。

不變可新增資料

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

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

可修改可刪除資料

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

大資料量

針對大資料量，如果屬於高延遲的業務，可以採用batch的處理方式，實時分析則需要使用流式處理，將兩者結合就是Lambda架構，即有實時處理、又能滿足一定的大資料量，這是現在比較流行的大資料處理方式。

三、資料儲存的技術選型

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

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

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

場景一：輿情分析

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

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

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

場景二：商業智慧產品

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

場景三：Airbnb的大資料平臺

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

四、資料處理

資料處理分為三大類：

• 第一類是從業務的角度，細分為查詢檢索、資料探勘、統計分析、深度分析，其中深度分析分為機器學習和神經網路。
• 第二類是從技術的角度，細分為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.覺得這篇文章非常好，好大家一起分享。同時也為了以後的便於學習回顧。