建站
咨詢
售后
建站咨詢
新聞中心
大數(shù)據(jù)架構(gòu)是為處理超大數(shù)據(jù)量或復雜計算而設(shè)計的，流程上包括數(shù)據(jù)的獲取、處理和分析。
大數(shù)據(jù)，可以簡單理解為傳統(tǒng)數(shù)據(jù)庫無法處理的數(shù)據(jù)量，比如主從模式的MySQL在簡單場景下可以存儲和處理上億條數(shù)據(jù)，但涉及到分析場景，能處理的數(shù)據(jù)量可能遠遠小于1億。利用大數(shù)據(jù)架構(gòu)，可以輕松處理上億到千億數(shù)據(jù)的分析需求。
大數(shù)據(jù)架構(gòu)通常支持這些使用方式：
- 離線靜態(tài)數(shù)據(jù)的批處理
- 實時動態(tài)數(shù)據(jù)的流式處理
- 大數(shù)據(jù)的交互式查詢（ad hoc query）
- 機器學習訓練和推理
多數(shù)大數(shù)據(jù)架構(gòu)會包含下面這些組件：
數(shù)據(jù)源
所有大數(shù)據(jù)解決方案都必須從數(shù)據(jù)源開始，數(shù)據(jù)源有很多種，比如：
- 應(yīng)用的數(shù)據(jù)存儲，比如傳統(tǒng)關(guān)系型數(shù)據(jù)庫MySQL等
- 應(yīng)用產(chǎn)生的靜態(tài)文件，比如用戶行為日志
- 實時數(shù)據(jù)源，比如IoT設(shè)備
這些數(shù)據(jù)均來自于大數(shù)據(jù)系統(tǒng)外部，經(jīng)過數(shù)據(jù)清洗等流程存儲到大數(shù)據(jù)系統(tǒng)。
數(shù)據(jù)存儲
離線批處理的數(shù)據(jù)通常存儲在分布式文件系統(tǒng)里，這些文件系統(tǒng)可以以不同的格式存儲大量的大文件，比如塊存儲HDFS上單個block的大小可以是256MB，總體可存儲PB量級的數(shù)據(jù)。當然，存儲也分為對象存儲和塊存儲，比如AWS S3是Amazon閉源的對象存儲方案，在擴展性和小文件支持上有一些優(yōu)勢。
最近幾年，這類分布式塊存儲或文件存儲有一個更時髦的名字：數(shù)據(jù)湖。
批處理
由于數(shù)據(jù)量特別大，體現(xiàn)在數(shù)據(jù)條數(shù)多和占用磁盤空間大，大數(shù)據(jù)架構(gòu)在應(yīng)對分析場景時，通常采用耗時的批處理作業(yè)去處理數(shù)據(jù)，處理邏輯包括但不限于轉(zhuǎn)換、過濾、聚合等。這些批處理任務(wù)通常會 1）讀取源文件，2）處理數(shù)據(jù)，3）將結(jié)果寫入新文件。可選的技術(shù)有基于MapReduce/Spark的SQL，或使用Java/Scala/Python等編寫的MapReduce/Spark任務(wù)。
實時消息采集
如果數(shù)據(jù)源是實時的，那么架構(gòu)上必須支持捕獲并存儲實時消息，以方便后面進行流式處理。使用的存儲可以非常簡單，比如直接append到一個目錄下的文件里。但現(xiàn)實中并不會采用這個方案，而是使用一個消息存儲充當buffer。這樣就能支持多個下游子系統(tǒng)進行獨立處理、保障數(shù)據(jù)不丟失、并獲取消息排隊的能力。
可選的技術(shù)有：Kafka、RocketMQ、RabbitMQ 等。
流式處理
從Source采集到實時消息以后，還需要對消息進行過濾、聚合等操作，用于后續(xù)的分析場景。流式數(shù)據(jù)被處理以后寫入Sink。
在這個領(lǐng)域，F(xiàn)link是名副其實的第一，F(xiàn)link SQL也是阿里最近幾年推行的重點方向，除此之外還有 Spark Structured Streaming，Storm 等技術(shù)方案。對比而言，F(xiàn)link的生態(tài)更為完善，Streaming Warehouse也是基于Flink構(gòu)建的。
分析型數(shù)據(jù)庫
大數(shù)據(jù)系統(tǒng)的數(shù)據(jù)源通常是半結(jié)構(gòu)化的數(shù)據(jù)，分析場景下為了保證性能，通常查詢的是結(jié)構(gòu)化的數(shù)據(jù)表。在傳統(tǒng)商業(yè)BI系統(tǒng)中，數(shù)倉通常以Kimball維度數(shù)據(jù)倉庫理念進行建模，分析型數(shù)據(jù)庫支持在這種數(shù)據(jù)關(guān)系上的查詢。相對于Inmon理念，Kimball偏向于保持source不變，中間層做join，最終給業(yè)務(wù)提供一張大寬表，以滿足復雜多樣的分析需求。Kimball理念下的數(shù)據(jù)表關(guān)系呈現(xiàn)出典型的星型結(jié)構(gòu)：
除了存算一體的分析型數(shù)據(jù)庫，還有其他方式，比如：
- 通過一個低延遲的NoSQL數(shù)據(jù)庫去管理和展現(xiàn)數(shù)據(jù)，比如HBase
- 基于分布式存儲（HDFS、S3等）管理數(shù)據(jù)+ Hive metastore 管理結(jié)構(gòu)化信息，支持交互式的查詢
可選的技術(shù)有：交互式Hive、HBase、Spark SQL，目前流行的也有clickhouse、doris等能夠榨干機器性能的報表工具。
數(shù)據(jù)分析和報表
大數(shù)據(jù)方案的目標多數(shù)是通過分析和報表提供對數(shù)據(jù)的洞察能力。為了增強分析功能，我們通常在架構(gòu)中會包含一個數(shù)據(jù)建模層，比如一個多維OLAP cube表?；贑lickhouse 或 Excel，用戶自己通過簡單的拖拽或點點點，就能做報表。對于懂一些技術(shù)的數(shù)據(jù)科學家和分析師而言，Jupyter Notebook提供了更強大和彈性的交互式分析能力，使用Python或R 可以更自由地訪問更大的數(shù)據(jù)集，可以更好地支持JOIN操作，也能將結(jié)果非常輕松地喂tensorflow/pytorch實現(xiàn)更高級的建模分析。
任務(wù)調(diào)度與編排
多數(shù)大數(shù)據(jù)方案都包含大量的重復計算。一個經(jīng)典的工作流會包含：1）transform source 數(shù)據(jù)；2）在多個source和sink之間轉(zhuǎn)移數(shù)據(jù)；3）將處理過的數(shù)據(jù)寫入分析型數(shù)據(jù)庫；4）將結(jié)果寫入報表或儀表盤。為了把這些工作流自動化，我們可以使用一些編排工具，比如 Oozie、Sqoop 或大廠自研的那種。這些編排工具可以很好地處理任務(wù)的依賴關(guān)系，并嚴格按照依賴關(guān)系進行調(diào)度，通常也支持延遲報警、數(shù)據(jù)質(zhì)量報警等功能。
上面討論的這些功能組件，目前有很多開源的技術(shù)來支持，比如 Hadoop 系列中的 HDFS、HBase、Hive、Spark、Oozie、Sqoop、Kafka，向量分析數(shù)據(jù)庫Clickhouse、Doris等。目前主流的云平臺基本都支持這些開源組件，但也基本上都會自研一些，比如阿里的Max Compute等等。
應(yīng)用場景
- 存儲和處理的數(shù)據(jù)量遠遠超過了傳統(tǒng)數(shù)據(jù)庫的上限；
- 需要處理非結(jié)構(gòu)化的數(shù)據(jù)，用于分析和報表；
- 采集、處理、分析實時流數(shù)據(jù)，或要求低延遲的場景；
架構(gòu)優(yōu)勢
- 技術(shù)選型比較多：可以采用Apache開源技術(shù)，也可以使用云服務(wù)商的閉源技術(shù)，或者混用；
- 并行帶來的極致性能：大數(shù)據(jù)架構(gòu)充分利用了并行計算技術(shù)，能夠高性能地處理大批量數(shù)據(jù)；
- 彈性擴容：大數(shù)據(jù)的絕大多數(shù)組件都支持擴容，可以根據(jù)數(shù)據(jù)量和業(yè)務(wù)要求選擇物理資源，數(shù)據(jù)量增長時擴容的成本也不高；
- 與現(xiàn)存方案的兼容性：大數(shù)據(jù)組件既可以用于原始數(shù)據(jù)的采集，也可以用于頂層業(yè)務(wù)的數(shù)據(jù)分析，資源可以混合部署。
有哪些挑戰(zhàn)
- 架構(gòu)復雜度高：大數(shù)據(jù)架構(gòu)需要采集多個數(shù)據(jù)源的大量數(shù)據(jù)，包含了很多組件，非常復雜。一方面構(gòu)建、測試和調(diào)試大數(shù)據(jù)處理任務(wù)比較麻煩；另一方面，由于組件太多，多個組件的配置需要協(xié)同更改，才能達到優(yōu)化性能的目的；
- 技術(shù)棧多：很多大數(shù)據(jù)技術(shù)比較專，使用的框架和語言也多種多樣。好的一點是，大數(shù)據(jù)技術(shù)構(gòu)建新的API時，采用了業(yè)界廣泛推行的語言，比如SQL；
- 技術(shù)成熟度不夠高：大數(shù)據(jù)技術(shù)仍然在不斷演進。隨著Hadoop的核心技術(shù)逐漸穩(wěn)定下來，比如Hive、Pig、HDFS。新技術(shù)又不斷產(chǎn)生，比如Spark每次迭代都發(fā)布了大量的新特性。隨著Spark逐漸穩(wěn)定，F(xiàn)link、Clickhouse、Doris又崛起成為新的熱點；
- 安全性：大數(shù)據(jù)架構(gòu)中，數(shù)據(jù)通常被存儲在一個中心化的數(shù)據(jù)湖里。安全合規(guī)地訪問這些數(shù)據(jù)卻愈發(fā)重要，在多個應(yīng)用或平臺生產(chǎn)和消費數(shù)據(jù)的場景下尤其重要。
最佳實踐
- 充分利用并行計算。大數(shù)據(jù)架構(gòu)通常會充分利用多臺機器的多核特點，將計算任務(wù)并行化，以提升性能。并行計算對數(shù)據(jù)的存儲格式有一定的要求，比如數(shù)據(jù)必須以能夠分隔的格式存儲。分布式文件系統(tǒng)（比如HDFS）能夠優(yōu)化讀寫性能，在實際數(shù)據(jù)處理中由多個計算節(jié)點并行執(zhí)行，減少了作業(yè)的整體運行時長。
- 利用分區(qū)。離線數(shù)據(jù)處理通常按照固定的周期，比如天/周/月級定期執(zhí)行。把數(shù)據(jù)文件放到不同的日期分區(qū)里，用分區(qū)表把數(shù)據(jù)管理起來，分區(qū)的粒度可以與任務(wù)執(zhí)行的時間頻率保持一致。這種模式簡化了數(shù)據(jù)采集和作業(yè)調(diào)度，問題排查也會比較簡單。目前主流的框架都支持分區(qū)概念，比如Hive分區(qū)表，分區(qū)作為過濾條件也可以大大縮減計算時掃描的數(shù)據(jù)量?，F(xiàn)在流行的數(shù)據(jù)湖技術(shù)，在分區(qū)維度也做了很多優(yōu)化，比如隱藏分區(qū)、bloomfilter索引、hash索引等。另外，在分區(qū)的基礎(chǔ)上，Spark 3 通過 bucket 優(yōu)化shuffle數(shù)據(jù)量。
- 使用 schema-on-read 語義：數(shù)據(jù)湖概念出現(xiàn)以后，我們可以給文件定義不同的數(shù)據(jù)格式，數(shù)據(jù)格式是結(jié)構(gòu)化、半結(jié)構(gòu)化，或非結(jié)構(gòu)化的。通過 schema-on-read 語義，我們可以在處理數(shù)據(jù)時，動態(tài)地給數(shù)據(jù)賦予格式，而不是在存儲時使用定義好的格式。這給我們的架構(gòu)帶來了很多彈性，數(shù)據(jù)采集這一環(huán)，一定程度上避免了數(shù)據(jù)校驗或類型校驗帶來的問題。業(yè)界主流的方式仍然是在Hive提前創(chuàng)建好表結(jié)構(gòu)，數(shù)據(jù)寫入時必須滿足結(jié)構(gòu)限制，這樣下游的理解和接入成本比較低；另外，metadata使用中心化地存儲，還是去中心化，有很多考量因素，選擇schema-on-read模式前一定要慎重考慮。
- 就地處理數(shù)據(jù)。傳統(tǒng)的BI解決方案通常會通過extract-transform-load（ETL）任務(wù)將數(shù)據(jù)寫入數(shù)倉。對于數(shù)據(jù)量特別大、格式多種多樣的數(shù)據(jù)而言，通常會使用ETL的變種，比如 transform-extract-load （TEL）。使用這種方式，數(shù)據(jù)在分布式存儲內(nèi)部被轉(zhuǎn)換為目標格式，這個過程可以存在多個任務(wù)，產(chǎn)出多個中間表。我們一般用數(shù)倉分層理論來規(guī)范表的名字和屬性，比如ODS、DWS、DWD、APP等。APP層的數(shù)據(jù)表符合分析場景的格式要求，可以將其數(shù)據(jù)拷貝到分析型數(shù)據(jù)庫（Clickhouse、ElasticSearch等）。
- 資源使用率 vs 運行時間。在創(chuàng)建批處理任務(wù)時，通常要考慮兩個方面：1）計算節(jié)點上每個計算單元（CPU核）的價格，2）完成一個作業(yè)使用的計算節(jié)點一分鐘花多少錢。舉個例子，一個批處理任務(wù)，用4個計算節(jié)點需要執(zhí)行8小時。但仔細觀察發(fā)現(xiàn)，這4個節(jié)點在頭2個小時滿負荷運行，之后只有2個節(jié)點滿負荷運行。這種情況下，如果使用2個計算節(jié)點，作業(yè)總的執(zhí)行時間變成10個小時，并沒有加倍；但花的錢變少了。為了緩解這個問題，多個用戶/業(yè)務(wù)共用一個隊列是一個簡單但不完美的方案，但從更高的層面上，離線/在線資源混合調(diào)度才是更大的全局最優(yōu)解。
- 獨占資源。為了保障業(yè)務(wù)的正常運行，我們可以給不同類型的任務(wù)或業(yè)務(wù)分配獨占資源，包括計算和存儲。比如，對于離線處理，Spark/MapReduce 可以使用獨立的yarn隊列；對于Flink/Structured Streaming 任務(wù)，也使用獨立的yarn隊列；對于工作日上班時間的ad-hoc查詢，也可以分配獨立的隊列。當然，業(yè)務(wù)穩(wěn)定運行、開發(fā)/調(diào)試方便和省錢有天然的沖突，要解決這個問題，需要付諸很多努力。
- 對數(shù)據(jù)采集任務(wù)進行編排。在一些簡單場景中，業(yè)務(wù)應(yīng)用可以直接把文件寫入分布式存儲，然后供分析工具使用。但在大型互聯(lián)網(wǎng)公司中，通常不會這么干，而是把外部數(shù)據(jù)源的數(shù)據(jù)落到數(shù)據(jù)湖里，然后使用編排工具把作業(yè)統(tǒng)一管理起來，依賴關(guān)系同時被管理起來，以便穩(wěn)定產(chǎn)出、高效地復用在下游復雜的業(yè)務(wù)場景里。任務(wù)開發(fā)、定期調(diào)度、依賴管理、延遲報警、失敗debug，這一切通常被維護在一個有Web頁面的公司級平臺里。
- 及早清理敏感數(shù)據(jù)。數(shù)據(jù)采集過程中，我們可以及早清理掉敏感數(shù)據(jù)，避免落庫。
新聞名稱：服務(wù)架構(gòu)：大數(shù)據(jù)架構(gòu)
地址分享：http://m.5511xx.com/article/cdiiscj.html
