簡介

本文介紹完善的大數據中臺架構了解這些架構里每個部分的位置，功能和含義及背后原理及應用場景。

幫助技術與產品經理對大數據技術體系有個全面的了解。

數據中臺定義：集成離線數倉與實時數倉，并以多數據源統一整合采集到kafka,再通過kafka進行離線數據倉庫及實時數據倉庫，并集用戶標簽，統一數據資產管理(對數據資產目錄、元數據、數據質量、數據血緣、數據生命周期等進行管理和展示，以一種更直觀的方式展現企業的數據資產，提升企業的數據意識)提供給客戶以及上層領導進行數據分析、數據運營等功能。

直觀框架圖如下：

整個數據流程分為五個環節

從數據采集-->數據傳輸-->數據存儲-->數據計算及查詢-->數據可視化及分析。

1、數據采集

根據平臺產生的日志，將數據采集后寫入到HDFS，HBase，Hive ，提供后續計算流程進行消費使用。

數據來源有網絡的Python爬蟲數據、java后臺日志數據、還有各種 API 接口及數據文件等等，匯聚到服務器本地磁盤。針對不同的數據來源有各自的采集方式，其中因為日志數據有數據量多，數據結構多樣，產生環境復雜等特點，屬于主要采集的對象。日志采集框架挑應用較廣泛的有 Flume，Logstash進行數據采集。

Flume

Flume是Cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸的系統。Flume基于流式架構，靈活簡單。

主要特點：

• 可靠性當節點出現故障時，日志能夠被傳送到其他節點上而不會丟失。
• 可擴展性Flume采用了三層架構，分別為agent，collector和storage，每一層均可以水平擴展。其中，所有agent和collector由master統一管理，這使得系統容易監控和維護，且master允許有多個(使用ZooKeeper進行管理和負載均衡)，這就避免了單點故障問題。
• 可管理性

(1)所有agent和colletor由master統一管理，這使得系統便于維護。
　　(2)多master情況，Flume利用ZooKeeper和gossip，保證動態配置數據的一致性。
　　(3)用戶可以在master上查看各個數據源或者數據流執行情況，且可以對各個數據源配置和動態加載。
　　(4)Flume提供了web 和shell script command兩種形式對數據流進行管理。

• 功能可擴展性用戶可以根據需要添加自己的agent，collector或者storage。此外，Flume自帶了很多組件，包括各種agent(file， syslog等)，collector和storage(file，HDFS等)。
• 文檔豐富，社區活躍Flume 已經成為 Hadoop 生態系統的標配，它的文檔比較豐富，社區比較活躍，方便我們學習。

Flume組成架構

Logstash

Logstash是一個開源數據收集引擎，具有實時管道功能。Logstash可以動態地將來自不同數據源的數據統一起來，并將數據標準化到你所選擇的目的地。

Logstash最常用于ELK(elasticsearch + logstash + kibane)logstash(收集)、elasticsearch(存儲+搜索)、kibana(展示)作為日志收集器使用。

主要特點：

• 集中、轉換和存儲你的數據Logstash是一個開源的服務器端數據處理管道，可以同時從多個數據源獲取數據，并對其進行轉換，然后將其發送到你最喜歡的“存儲” 。首選Elasticsearch 是我們的輸出方向，能夠為我們的搜索和分析帶來無限可能，但它并非唯一選擇。
• 支持訪問任何類型數據如：file,redis,kafka,mq
• 支持各種自定義插件可擴展插件生態系統，提供超過200個插件，以及創建和貢獻自己的靈活性。
• Logstash耗資源較大，運行占用CPU和內存高。另外沒有消息隊列緩存，存在數據丟失隱患。

從兩者的設計思想來看，Flume本身最初設計的目的是為了把數據傳入HDFS中(并不是為了采集日志而設計，這和Logstash有根本的區別)，所以理所應當側重于數據的傳輸，程序員要非常清楚整個數據的路由，并且比Logstash還多了一個可靠性策略，其中channel就是用于持久化目的，數據除非確認傳輸到下一位置了，否則不會刪除，這一步是通過事物來控制的，這樣的設計使得可靠性非常好。相反，Logstash則明顯側重對數據的預處理，因為日志的字段需要大量的預處理，為解析做鋪墊。

2、數據傳輸

應用較廣泛的有Kafka，Kafka是一個分布式的基于發布/訂閱模式的消息隊列，主要應用于大數據實時處理領域。

應用場景如：

數據的傳遞,使用Flume消費Kafka數據存儲到HDFS/Hbase

業務日志數據實時存儲到Kafka集群，然后通過Flume Source組件實時去消費Kafka業務Topic采集數據，將消費后的數據通過Flume Sink組件發送到HDFS/Hbase進行存儲。

3、數據存儲

數據庫存儲方面,可分不同類別的數據存儲組件,各類數據存儲組件的設計是為滿足不同場景下數據存儲的需求，提供不同的數據模型抽象，以及面向在線和離線的不同的優化偏向。

比較常見的數據存儲組件如下表：

存儲組件的選型

做架構設計時，最大的挑戰是如何對計算組件和存儲組件進行選型和組合。存儲組件包含數據庫(又分為SQL和NoSQL兩類，NoSQL下又根據各類數據模型細分為多類)、對象存儲、文件存儲和高速緩存等不同類別。

存儲組件選型需要綜合考慮數據分層、成本優化以及面向在線和離線的查詢優化偏向等各種因素。平臺根據不同的場景使用不同的存儲組件進行數據寫入、存儲、查詢和分析等需求。

大數據領域常用的存儲組件有：

HDFS

Hadoop Distributed File System (HDFS) — Apache Hadoop 項目的一個子項目， 是一個高度容錯的分布式文件系統，可以理解成HDFS一個以集群方式實現的一個文件系統，HDFS設計用于在低成本硬件上運行。HDFS 提供高吞吐量應用程序數據訪問功能，適合帶有大型數據集的應用程序。

使用場景如下：

• HDFS不適合大量小文件的存儲。

• HDFS適用于高吞吐量，而不適合低時間延遲的訪問。

• 流式讀取的方式，不適合多用戶寫入一個文件(一個文件同時只能被一個客戶端寫)，以及任意位置寫入(不支持隨機寫)，支持文件尾部apend操作，或者文件的覆蓋操作。

• HDFS更加適合寫入一次，讀取多次的應用場景，通過線上HDFS集群的監控，hadoop目前業務的讀寫比為10:1，在設計上也是考慮了這一點，讀速度比較快。

• HDFS 適合用來做大數據分析的底層存儲服務。

HBase

HBase是一個分布式存儲、數據庫引擎，可以支持千萬的QPS、PB級別的存儲，這些都已經在生產環境驗證，并且在廣大的公司已經驗證。

使用場景如下圖：

對象存儲：我們知道不少的頭條類、新聞類的的新聞、網頁、圖片存儲在HBase之中，一些病毒公司的病毒庫也是存儲在HBase之中。時序數據：HBase之上有OpenTSDB模塊，可以滿足時序類場景的需求。推薦畫像：特別是用戶的畫像，是一個比較大的稀疏矩陣，螞蟻的風控就是構建在HBase之上。時空數據：主要是軌跡、氣象網格之類，滴滴打車的軌跡數據主要存在HBase之中，另外該技術所有大一點的數據量的車聯網企業，數據都是存在HBase之中。CubeDB OLAP：Kylin一個cube分析工具，底層的數據就是存儲在HBase之中，不少客戶自己基于離線計算構建cube存儲在hbase之中，滿足在線報表查詢的需求。消息/訂單：在電信領域、銀行領域，不少的訂單查詢底層的存儲，另外不少通信、消息同步的應用構建在HBase之上。Feeds流：典型的應用就是xx朋友圈類似的應用。NewSQL：之上有Phoenix的插件，可以滿足二級索引、SQL的需求，對接傳統數據需要SQL非事務的需求。

Hive

Hive最初是Facebook為了滿足對海量社交網絡數據的管理和機器學習的需求而產生和發展的。Hive是一種建立在Hadoop文件系統上的數據倉庫架構，并對存儲在HDFS中的數據進行分析和管理。

使用場景如下：

• 日志分析：大部分互聯網公司使用hive進行日志分析。如： 統計網站一個時間段內的pv、uv及多維度數據分析等。
• 海量結構化數據離線分析。

ElasticSearch簡稱ES

ElasticSearch天然支持分布式，具備存儲海量數據的能力，其搜索和數據分析的功能都建立在ElasticSearch存儲的海量的數據之上。

使用場景如下：

• 全文檢索，高亮，搜索推薦。
• 用戶行為日志(點擊，瀏覽，收藏，評論)+社交網絡數據，數據分析。
• 站內搜索(電商，招聘，門戶，等等)具體如：電商網站檢索商品。
• 日志數據分析，logstash采集日志，ES進行復雜的數據分析(ELK技術，elasticsearch+logstash+kibana)。
• 商品價格監控網站。

Elasticsearch作為傳統數據庫的一個補充，提供了數據庫所不能提供的很多功能。如：比如全文檢索，同義詞處理，相關度排名，復雜數據分析，海量數據的近實時處理。

4、數據計算及查詢

數據計算

大數據計算場景可分為批處理和流處理分別對應離線分析和實時分析。

常用框架分類有：

流處理框架(實時分析)：Storm，Samza。

批處理框架(離線分析)：Hadoop MapReduce 簡稱：MR。

混合框架：Spark、Flink。

Spark

Apache Spark是一個圍繞速度、易用性和復雜分析構建的大數據處理框架，最初在2009年由加州大學伯克利分校的AMPLab開發，并于2010年成為Apache的開源項目之一，與Hadoop和Storm等其他大數據和MapReduce技術相比，Spark有如下優勢：

• Spark提供了一個全面、統一的框架用于管理各種有著不同性質(文本數據、圖表數據等)的數據集和數據源(批量數據或實時的流數據)的大數據處理的需求。
• Spark可以將Hadoop集群中的應用在內存中的運行速度提升100倍，甚至能夠將應用在磁盤上的運行速度提升10倍。

Spark與hadoop

Hadoop有兩個核心模塊，分布式存儲模塊HDFS和分布式計算模塊Mapreduce。spark本身并沒有提供分布式文件系統，因此spark的分析大多依賴于Hadoop的分布式文件系統HDFS。Hadoop的Mapreduce與spark都可以進行數據計算，而相比于Mapreduce，spark的速度更快并且提供的功能更加豐富。

Flink

Flink 作為更新一代的處理框架，擁有更快的計算能力，更低的延遲。

Fink與Spark Streaming 對應 流(Stream)與微批(Micro-batch)

如下圖：

數據模型

spark采用RDD模型，spark streaming的DStream實際上也就是一組組小批數據RDD的集合。

fink基礎數據模型是數據流，以及事件(Event)序列。

運行時架構

spark是批計算，將DAG劃分為不同的stage,一個完成后才可以計算下一個。

fink是標準的流執行模式，一個事件在一個節點處理完后可以直接發往下一個節點進行處理。

flink內部支持多種函數，其中包括窗口函數和各種算子和spark很像，但是flink在性能和實時上比 spark高。

Storm

storm流式處理，低延遲(ms級延遲)，高吞吐，且每條數據都會觸發計算。

Spark與storm對比， spark屬于批處理轉化為流處理即將流式數據根據時間切分成小批次進行計算，對比與storm而言延遲會高于0.5s(秒級延遲)，但是性能上的消耗低于storm。流式計算是批次計算的特例(流式計算是拆分計算的結果)。

fink與storm對比 ，flink為流式計算而生屬于每一條數據觸發計算，在性能的消耗低于storm，吞吐量高于storm，延時低于storm，但比storm更加易于編寫。因為storm如果要實現窗口需要自己編寫邏輯，但是flink中有窗口方法。

綜合對比spark、storm和flink的功能、容錯和性能

相比于storm ，spark和flink兩個都支持窗口和算子，減少了不少的編程時間。flink相比于storm和spark，flink支持亂序和延遲時間(在實際場景中，這個功能很牛逼)，這個功能就可以勝spark。對于spark而言他的優勢就是機器學習，如果我們的場景中對實時要求不高可以考慮spark，但是如果是要求很高就考慮使用flink，比如對用戶異常消費進行監控，如果這個場景使用spark的話那么等到系統發現開始預警的時候(0.5s)，已經完成了交易，可想而知在某些場景下flink的實時有多重要。

數據查詢

數據計算結果后，還需要面向用戶接觸和使用的高效查詢引擎。

術語

ETL：也即是數據抽取、清理、裝載，是數據倉庫建設的核心一環。

ODS：操作數據存儲 ODS(Operational Data Store)是數據倉庫體系結構中的一個重要部

分，ODS 具備數據倉庫的部分特征和 OLTP 系統的部分特征，主要存儲原始庫表同步過來的

數據以及接口上報采集過來的數據。

DW：數據倉庫(Data Warehouse), 面向主題的、集成的、相對穩定的、隨時間不斷變

(不同時間)的數據集合。

OLAP：OLAP是英文是On-Line Analytical Processing的縮寫，意為聯機分析處理。OLAP允許以一種稱為多維數據集的結構，訪問業務數據源經過聚合和組織整理后的數據。

統一數倉分層規范

ODS(貼源數據層)：

對各業務系統數據進行采集、匯聚，盡可能保留原始業務流程數據，與業務系統基本保持一致，僅做簡單整合、非結構化數據結構化處理或者增加標識數據日期描述信息，不做深度清洗加工。

統一拉通層：

把DW層的數據做統一的清洗處理。去重、去噪、字典翻譯、空值轉化，日期格式化等操作。

DWD(明細層)：

和ODS粒度一致的明細數據，對數據進行去重，臟數據過濾和砍字段處理，空處理，保證

數據質量，簡單邏輯通過視圖實現，并解決數據的完整度問題。

DWS(服務層)：

輕度匯總數據及集市大寬表(按主題)存放數據。

DIM:(維表層)：

通過ods層獲取得到。

應用數據ADS層(kylin/impala)

應用數據層ADS(Application Data Store)：按照業務的需要從統一數倉層、標簽層抽取數據，并且面向業務的特殊需要加工業務特定數據，以滿足業務以及性能需求，向特定應用組裝應用數據。

目前 OLAP 的查詢分析框架有：

• 基于 HBase 做預聚合：如Kylin 等，均需指定預聚合的指標，在數據接入的時候進行聚合運算，適合相對固定，維度較多的業務報表類需求。

• 基于 Parquet 做列式存儲：如impala 等，基本是完全基于內存的并行計算，Parquet 系能降低存儲空間，提高IO效率，以離線處理為主，很難提高數據寫的實時性，超大表的 Join 支持可能不夠好。

標簽數據層TDM

標簽數據層TDM(Tag Data Model)：面向對象建模，把跨業務板塊、跨數據域的特定對象數據進行整合，通過ID-Mapping把各個業務板塊各個業務過程同一對象的數據打通，形成對象的全域標簽體系，方便深度的分析、挖掘、應用。

5、大數據應用

數據運營方面：用戶畫像、精準推薦、智能檢索。

數據分析方面：olap報表、決策支持、可視化大屏。

大數據可視化

總結

以上是生活随笔為你收集整理的大数据实验报告总结体会_建设大数据中台架构思考与总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。