關於大資料平臺，這有一套完整的方法論，你確定不收藏？

文|資料社

大資料時代這個詞被提出已有10年了吧，越來越多的企業已經完成了大資料平臺的搭建。隨著移動網際網路和物聯網的爆發，大資料價值在越來越多的場景中被挖掘，隨著大家都在使用歐冠大資料，大資料平臺的搭建門檻也越來越低。

藉助開源的力量，任何有基礎研發能力的組織完全可以搭建自己的大資料平臺。但是對於沒有了解過大資料平臺、資料倉庫、資料探勘概念的同學可能還是無法順利完成搭建，因為你會發現太多的東西，和架構，你不知道如何去選擇。

今天給大家分享下大資料平臺是怎麼玩的。

架構總覽

通常大資料平臺的架構如上，從外部採集資料到資料處理，資料顯現，應用等模組。

資料採集

使用者訪問我們的產品會產生大量的行為日誌，因此我們需要特定的日誌採集系統來採集並輸送這些日誌。Flume是目前常用的開源選擇，Flume是Cloudera提供的一個高可用的，高可靠的，分散式的海量日誌採集、聚合和傳輸的系統。

Flume支援在日誌系統中定製各類資料傳送方，用於收集資料；同時，Flume提供對資料進行簡單處理，並寫到各種資料接受方的能力。

對於非實時使用的資料，可以透過Flume直接落檔案到叢集的HDFS上。而對於要實時使用的資料來說，則可以採用Flume+Kafka，資料直接進入訊息佇列，經過Kafka將資料傳遞給實時計算引擎進行處理。

業務資料庫的資料量相比訪問日誌來說小很多。對於非實時的資料，一般定時匯入到HDFS/Hive中。一個常用的工具是Sqoop，Sqoop是一個用來將Hadoop和關係型資料庫中的資料相互轉移的工具，可以將一個關係型資料庫（例如 ：MySQL ，Oracle ，Postgres等）中的資料導進到Hadoop的HDFS中，也可以將HDFS的資料導進到關係型資料庫中。

而對於實時的資料庫同步，可以採用Canal作為中介軟體，處理資料庫日誌（如binlog），將其計算後實時同步到大資料平臺的資料儲存中。

資料儲存

無論上層採用何種的大規模資料計算引擎，底層的資料儲存系統基本還是以HDFS為主。HDFS（Hadoop Distributed File System）是Hadoop專案的核心子專案，是分散式計算中資料儲存管理的基礎。具備高容錯性、高可靠、高吞吐等特點。

HDFS儲存的是一個個的文字，而我們在做分析統計時，結構化會方便需要。因此，在HDFS的基礎上，會使用Hive來將資料檔案對映為結構化的表結構，以便後續對資料進行類SQL的查詢和管理。

資料處理

資料處理就是我們常說的ETL。在這部分，我們需要三樣東西：計算引擎、排程系統、元資料管理。

對於大規模的非實時資料計算來講，目前一樣採用Hive和spark引擎。Hive是基於MapReduce的架構，穩定可靠，但是計算速度較慢；Spark則是基於記憶體型的計算，一般認為比MapReduce的速度快很多，但是其對記憶體效能的要求較高，且存在記憶體溢位的風險。Spark同時相容hive資料來源。

從穩定的角度考慮，一般建議以Hive作為日常ETL的主要計算引擎，特別是對於一些實時要求不高的資料。Spark等其他引擎根據場景搭配使用。

實時計算引擎方面，目前大體經過了三代，依次是：storm、spark streaming、Flink。Flink已被阿里收購，大廠一直在推，社群活躍度很好，國內也有很多資源。

排程系統上，建議採用輕量級的Azkaban，Azkaban是由Linkedin開源的一個批次工作流任務排程器。

https：//

azkaban。github。io/

一般需要自己開發一套元資料管理系統，用來規劃資料倉庫和ETL流程中的元資料。元資料分為業務元資料和技術元資料。

業務元資料，主要用於支撐資料服務平臺Web UI上面的各種業務條件選項，比如，常用的有如下一些：移動裝置機型、品牌、運營商、網路、價格範圍、裝置物理特性、應用名稱等。

這些元資料，有些來自於基礎資料部門提供的標準庫，比如品牌、價格範圍等，可以從對應的資料表中同步或直接讀取；而有些具有時間含義的元資料，需要每天透過ETL處理生成，比如應用資訊。

為支撐應用計算使用，被儲存在MySQL資料庫中；而對於填充頁面上對應的條件選擇的資料，則使用Redis儲存，每天/月會根據MySQL中的資料進行加工處理，生成易於快速查詢的鍵值對類資料，儲存到Redis中。

技術元資料，主要包括資料倉庫中的

模型說明

、血緣關係、變更記錄、需求來源、模型欄位資訊等，詳細的可以檢視資料分析師應該瞭解的資料倉庫（3）

資料流轉

透過上面一張圖瞭解資料採集，資料處理，到資料展現的資料流轉。通常我們在實際工作中，從資料來源到分析報告或系統應用的過程中，主要包括資料採集同步、資料倉庫儲存、ETL、統計分析、寫入上層應用資料庫進行指標展示。

這是最基礎的一條線，現在還有基於資料倉庫進行的資料分析挖掘工作，會基於機器學習和深度學習對已有模型資料進一步挖掘分析，形成更深層的資料應用產品。

資料應用

俗話說的好，“酒香也怕巷子深”。資料應用前面我們做了那麼多工作為了什麼，對於企業來說，我們做的每一件事情都需要體現出價值，而此時的資料應用就是大資料的價值體現。資料應用包括輔助經營分析的一些報表指標，商城上基於使用者畫像的個性化推送，還有各種資料分析報告等等。

好的資料應用一定要藉助視覺化顯現，比如很多傳統企業買的帆軟，當然還有別的，不過就我經驗來說，帆軟是不錯的。

FineReport做的企業駕駛艙。