天天看點

企業級大資料技術架構

大資料嘗試從海量資料中,通過一定的分布式技術手段,挖掘出有價值的資訊,最終提供給使用者,進而産生實用價值和商業價值。

從資料在資訊系統中的生命周期看,大資料從資料源開始,經過分析、挖掘到最終獲得價值一般需要經過6個主要環節,包括資料收集、資料存儲、資源管理與服務協調、計算引擎、資料分析和資料可視化,每個環節都面臨不同程度的技術挑戰。

1、資料收集層

資料收集層由直接跟資料源對接的子產品構成,負責将資料源中的資料近實時或實時收集到一起。資料源具有分布式、異構性、多樣化及流式産生等特點:

  • 分布式:資料源通常分布在不同機器或裝置上,并通過網絡連接配接在一起。
  • 異構性:任何能夠産生資料的系統均可以稱為資料源,比如Web伺服器、資料庫、傳感器、手環、視訊攝像頭等。
  • 多樣化:資料的格式是多種多種多樣的,既有像使用者基本資訊這樣的關系型資料,也有如圖檔、音頻和視訊等非關系型資料。
  • 流式産生:資料源如同“水龍頭”一樣,會源源不斷地産生“流水”(資料),而資料收集系統應實時或近實時地将資料發送到後端,以便及時對資料進行分析。

由于資料源具有以上特點,将分散的資料源中的資料收集到一起通常是一件十分困難的事情。一個适用于大資料領域的收集系統,一般具備以下幾個特點:

  • 擴充性:能夠靈活适配不同的資料源,并能接入大量資料源而不會産生系統瓶頸;
  • 可靠性:資料在傳輸過程中不能夠丢失(有些應用可容忍少量資料丢失)。
  • 安全性:對于一些敏感資料,應有機制保證資料收集過程中不會産生安全隐患。
  • 低延遲:資料源産生的資料量往往非常龐大,收集系統應該能夠在較低延遲的前提下将資料傳輸到後端存儲系統中。

為了讓後端擷取全面的資料,以便進行關聯分析和挖掘,通常我們建議将資料收集到一個中央化的存儲系統中。

2、資料存儲層

資料存儲層主要負責海量結構化與非結構化資料的存儲。傳統的關系型資料庫(比如MySQL)和檔案系統(比如Linux檔案系統)因在存儲容量、擴充性及容錯性等方面的限制,很難适應大資料應用場景。

在大資料時代,由于資料收集系統會将各類資料源源不斷地發到中央化存儲系統中,這對資料存儲層的擴充性、容錯性及存儲模型等有較高要求,總結如下:

  • 擴充性:在實際應用中,資料量會不斷增加,現有叢集的存儲能力很快将達到上限,此時需要增加新的機器擴充存儲能力,這要求存儲系統本身具備非常好的線性擴充能力。
  • 容錯性:考慮到成本等因素,大資料系統從最初就假設建構在廉價機器上,這就要求系統本身就有良好的容錯機制確定在機器出現故障時不會導緻資料丢失。
  • 存儲模型:由于資料具有多樣性,資料存儲層應支援多種資料模型,確定結構化和非結構化的資料能夠很容易儲存下來。
3、資源管理與服務協調層

随着網際網路的高速發展,各類新型應用和服務不斷出現。在一個公司内部,既存在運作時間較短的批處理作業,也存在運作時間很長的服務,為了防止不同應用之間互相幹擾,傳統做法是将每類應用單獨部署到獨立的伺服器上。該方案簡單易操作,但存在資源使用率低、運維成本高和資料共享困難等問題。為了解決這些問題,開始嘗試将所有這些應用部署到一個公共的叢集中,讓它們共享叢集的資源,并對資源進行統一使用,同時采用輕量級隔離方案對各個應用進行隔離,是以便誕生了輕量級彈性資源管理平台,相比于“一種應用一個叢集”的模式,引入資源統一管理層可以帶來衆多好處:

  • 資源使用率高:如果每個應用一個叢集,則往往由于應用程式數量和資源需求的不均衡,使得在某段時間内有些應用的叢集資源緊張,而另外一些叢集資源空閑。共享叢集模式通過多種應用共享資源,使得叢集中的資源得到充分利用。
  • 運維成本低:如果采用“一個應用一個叢集”的模式,則可能需要多個管理者管理這些叢集,進而增加運維成本。而共享模式通常需要少數管理者即可完成多個架構的統一管理。
  • 資料共享:随着資料量的暴增,跨叢集間的資料移動不僅需花費更長的時間,且硬體成本也會大大增加,而共享叢集模式可讓多種應用共享資料和硬體資源,這将大大減小資料移動帶來的成本。

在建構分布式大資料系統時,會面臨很多共同的問題,包括leader選舉、服務命名、分布式隊列、分布式鎖、釋出訂閱功能等,為了避免重複開發這些功能,通常會建構一個統一的服務協調元件,包含了開發分布式系統過程中通用的功能。

4、計算引擎層

在實際生産環境中,針對不同的應用場景,我們對資料處理的要求是不同的,有些場景下,隻需離線處理資料,對實時性要求不高,但要求系統吞吐率高,典型的應用是搜尋引擎建構索引;有些場景下,需對資料進行實時分析,要求每條資料處理延遲盡可能低,典型的應用是廣告系統及信用卡欺詐檢測。為了解決不同場景下資料處理問題,起初有人嘗試建構一個大統一的系統解決所有類型的資料計算問題,但最終以失敗告終。究其原因,主要是因為不同類型的計算任務,其追求的目标是不同的,批處理計算追求的是高吞吐率,而實時計算追求的是低延遲。在現實系統中,系統吞吐率和處理延遲往往是沖突的兩個優化方向:系統吞吐率非常高時,資料處理延遲往往也非常高,基于此,用一個系統完美解決所有類型的計算任務是不現實的。

針對不同應用場景,單獨建構一個計算引擎,每種計算引擎隻專注于解決某一類問題,進而形成了多樣化的計算引擎。總體上講,可按照對時間性能的要求,将計算引擎分為三類:

  • 批處理:該類計算引擎對時間要求最低,一般處理時間為分鐘到小時級别,甚至天級别,它追求的是高吞吐率,即機關時間内處理的資料量盡可能大,典型的應用有搜尋引擎建構索引、批量資料分析等。
  • 互動式處理:該類計算引擎對時間要求比較高,一般要求處理時間為秒級别,這類系統需要跟人進行互動,是以會提供類SQL的語言便于使用者使用,典型的應用有資料查詢、參數化報表生成等。
  • 實時處理:該類計算引擎對時間要求最高,一般處理延遲在秒級以内,典型的應用有廣告系統、輿情監測等。
5、資料分析層

資料分析層直接跟使用者應用程式對接,為其提供易用的資料處理工具。為了讓使用者分析資料更加容易,計算引擎會提供多樣化的工具,包括應用程式API、類SQL查詢語言、資料挖掘SDK等。

6、資料可視化層