常用的幾種大資料架構剖析

2021-09-27 01:27:42 字數 3290 閱讀 6727

資料分析工作雖然隱藏在業務系統背後,但是具有非常重要的作用,資料分析的結果對決策、業務發展有著舉足輕重的作用。隨著大資料技術的發展,資料探勘、資料探索等專有名詞**度越來越高,但是在類似於hadoop系列的大資料分析系統大行其道之前,資料分析工作已經經歷了長足的發展,尤其是以bi系統為主的資料分析,已經有了非常成熟和穩定的技術方案和生態系統,對於bi系統來說,大概的架構圖如下: 

可以看到在bi系統裡面,核心的模組是cube,cube是乙個更高層的業務模型抽象,在cube之上可以進行多種操作,例如上鑽、下鑽、切片等操作。大部分bi系統都基於關係型資料庫,關係型資料庫使用sql語句進行操作,但是sql在多維操作和分析的表示能力上相對較弱,所以cube有自己獨有的查詢語言mdx,mdx表示式具有更強的多維表現能力,所以以cube為核心的分析系統基本佔據著資料統計分析的半壁江山,大多數的資料庫服務廠商直接提供了bi套裝軟體服務,輕易便可搭建出一套olap分析系統。不過bi的問題也隨著時間的推移逐漸顯露出來: 

由於資料倉儲為結構化儲存,在資料從其他系統進入資料倉儲這個東西,我們通常叫做etl過程,etl動作和業務進行了強繫結,通常需要乙個專門的etl團隊去和業務做銜接,決定如何進行資料的清洗和轉換。

當資料量過大的時候,效能會成為瓶頸,在tb/pb級別的資料量上表現出明顯的吃力。

資料庫的正規化等約束規則,著力於解決資料冗餘的問題,是為了保障資料的一致性,但是對於資料倉儲來說,我們並不需要對資料做修改和一致性的保障,原則上來說資料倉儲的原始資料都是唯讀的,所以這些約束反而會成為影響效能的因素。

etl動作對資料的預先假設和處理,導致機器學習部分獲取到的資料為假設後的資料,因此效果不理想。例如如果需要使用資料倉儲進行異常資料的挖掘,則在資料入庫經過etl的時候就需要明確定義需要提取的特徵資料,否則無法結構化入庫,然而大多數情況是需要基於異構資料才能提取出特徵。

在一系列的問題下,以hadoop體系為首的大資料分析平台逐漸表現出優異性,圍繞hadoop體系的生態圈也不斷的變大,對於hadoop系統來說,從根本上解決了傳統資料倉儲的瓶頸的問題,但是也帶來一系列的問題: 

基於大資料架構的資料分析平台側重於從以下幾個維度去解決傳統資料倉儲做資料分析面臨的瓶頸: 

總的來說,目前圍繞hadoop體系的大資料架構大概有以下幾種: 

傳統大資料架構

​之所以叫傳統大資料架構,是因為其定位是為了解決傳統bi的問題,簡單來說,資料分析的業務沒有發生任何變化,但是因為資料量、效能等問題導致系統無法正常使用,需要進行公升級改造,那麼此類架構便是為了解決這個問題。可以看到,其依然保留了etl的動作,將資料經過etl動作進入資料儲存。 

優點:簡單,易懂,對於bi系統來說,基本思想沒有發生變化,變化的僅僅是技術選型,用大資料架構替換掉bi的元件。 

缺點:對於大資料來說,沒有bi下如此完備的cube架構,雖然目前有kylin,但是kylin的侷限性非常明顯,遠遠沒有bi下的cube的靈活度和穩定度,因此對業務支撐的靈活度不夠,所以對於存在大量報表,或者複雜的鑽取的場景,需要太多的手工定製化,同時該架構依舊以批處理為主,缺乏實時的支撐。 

適用場景:資料分析需求依舊以bi場景為主,但是因為資料量、效能等問題無法滿足日常使用。 

流式架構

在傳統大資料架構的基礎上,流式架構非常激進,直接拔掉了批處理,資料全程以流的形式處理,所以在資料接入端沒有了etl,轉而替換為資料通道。經過流處理加工後的資料,以訊息的形式直接推送給了消費者。雖然有乙個儲存部分,但是該儲存更多的以視窗的形式進行儲存,所以該儲存並非發生在資料湖,而是在外圍系統。 

優點:沒有臃腫的etl過程,資料的實效性非常高。 

缺點:對於流式架構來說,不存在批處理,因此對於資料的重播和歷史統計無法很好的支撐。對於離線分析僅僅支撐視窗之內的分析。 

適用場景:預警,監控,對資料有有效期要求的情況。 

lambda架構

lambda架構算是大資料系統裡面舉足輕重的架構,大多數架構基本都是lambda架構或者基於其變種的架構。lambda的資料通道分為兩條分支:實時流和離線。實時流依照流式架構,保障了其實時性,而離線則以批處理方式為主,保障了最終一致性。什麼意思呢?流式通道處理為保障實效性更多的以增量計算為主輔助參考,而批處理層則對資料進行全量運算,保障其最終的一致性,因此lambda最外層有乙個實時層和離線層合併的動作,此動作是lambda裡非常重要的乙個動作,大概的合併思路如下: 

​以上的種種架構都圍繞海量資料處理為主,unifield架構則更激進,將機器學習和資料處理揉為一體,從核心上來說,unifield依舊以lambda為主,不過對其進行了改造,在流處理層新增了機器學習層。可以看到資料在經過資料通道進入資料湖後,新增了模型訓練部分,並且將其在流式層進行使用。同時流式層不單使用模型,也包含著對模型的持續訓練。 

優點:unifield架構提供了一套資料分析和機器學習結合的架構方案,非常好的解決了機器學習如何與資料平台進行結合的問題。 

缺點:unifield架構實施複雜度更高,對於機器學習架構來說,從軟體包到硬體部署都和資料分析平台有著非常大的差別,因此在實施過程中的難度係數更高。 

適用場景:有著大量資料需要分析,同時對機器學習方便又有著非常大的需求或者有規劃。 

總結

以上幾種架構為目前資料處理領域使用比較多的幾種架構,當然還有非常多其他架構,不過其思想都會或多或少的類似。資料領域和機器學習領域會持續發展,以上幾種思想或許終究也會變得過時。

常用的幾種大資料架構剖析

資料分析工作雖然隱藏在業務系統背後,但是具有非常重要的作用,資料分析的結果對決策 業務發展有著舉足輕重的作用。隨著大資料技術的發展,資料探勘 資料探索等專有名詞 度越來越高,但是在類似於hadoop系列的大資料分析系統大行其道之前,資料分析工作已經經歷了長足的發展,尤其是以bi系統為主的資料分析,已...

大資料之flume flume常用的幾種配置

配置一 主要是從目錄獲取資料並將資料寫入hdfs 定義agent名,source channel sink的名稱 a4.sources r1 a4.channels c1 a4.sinks k1 具體定義source a4.sources.r1.type spooldir a4.sources.r1...

剖析大資料平台的資料採集

我在一次社群活動中做過一次分享,演講題目為 大資料平台架構技術選型與場景運用 在演講中,我主要分析了大資料平台架構的生態環境,並主要以資料來源 資料採集 資料儲存與資料處理四個方面展開分析與講解,並結合具體的技術選型與需求場景,給出了我個人對大資料平台的理解。本文講解資料採集部分。資料採集的設計,幾...