欧美中文字幕第一页-欧美中文字幕一区-欧美中文字幕一区二区三区-欧美中文字幕在线-欧美中文字幕在线播放-欧美中文字幕在线视频

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

我是創(chuàng)始人李巖:很抱歉!給自己產(chǎn)品做個(gè)廣告,點(diǎn)擊進(jìn)來(lái)看看。  

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

作者:Yanjun

基于PB級(jí)海量數(shù)據(jù)實(shí)現(xiàn)數(shù)據(jù)服務(wù)平臺(tái),需要從各個(gè)不同的角度去權(quán)衡,主要包括實(shí)踐背景、技術(shù)選型、架構(gòu)設(shè)計(jì),我們基于這三個(gè)方面進(jìn)行了架構(gòu)實(shí)踐,下面分別從這三個(gè)方面進(jìn)行詳細(xì)分析討論:

實(shí)踐背景

該數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)之初,實(shí)踐的背景可以從三個(gè)維度來(lái)進(jìn)行說(shuō)明:當(dāng)前現(xiàn)狀、業(yè)務(wù)需求、架構(gòu)需求,分別如下所示:

當(dāng)前現(xiàn)狀

收集了當(dāng)前已有數(shù)據(jù)、分工、團(tuán)隊(duì)的一些基本情況,如下所示:

  • 數(shù)據(jù)收集和基礎(chǔ)數(shù)據(jù)加工有專門的Team在做,我們是基于收集后并進(jìn)行過(guò)初步加工的基礎(chǔ)數(shù)據(jù),結(jié)合不同行業(yè)針對(duì)特定數(shù)據(jù)的需求進(jìn)行二次加工的。
  • 數(shù)據(jù)二次加工,會(huì)集成基礎(chǔ)數(shù)據(jù)之外的其它有業(yè)務(wù)屬性的數(shù)據(jù),比如引入第三方POI數(shù)據(jù)等。
  • 原始數(shù)據(jù)每天增量大約30~40TB左右。
  • 計(jì)算集群采用Spark on YARN部署模式,大約400個(gè)節(jié)點(diǎn)。
  • 所有數(shù)據(jù)各種屬性、行為信息,都是圍繞大約40億的移動(dòng)設(shè)備ID進(jìn)行很多倍膨脹,比如每天使用微信App的設(shè)備的行為信息。
  • 參與該平臺(tái)的研發(fā)人員,對(duì)實(shí)際數(shù)據(jù)業(yè)務(wù)需求了解不會(huì)非常深入,因?yàn)榭缍鄠€(gè)行業(yè)及其不同數(shù)據(jù)需求的變化較快。

業(yè)務(wù)需求

另外,實(shí)現(xiàn)的該數(shù)據(jù)服務(wù)平臺(tái),需要滿足當(dāng)前的基本數(shù)據(jù)業(yè)務(wù)需求,主要包括使用平臺(tái)的人員特點(diǎn),需要支撐的各種基本數(shù)據(jù)需求,經(jīng)過(guò)梳理,如下所示:

  • 平臺(tái)初期面向內(nèi)部業(yè)務(wù)人員使用,幾乎沒有技術(shù)背景。
  • 40億+的移動(dòng)設(shè)備大表,包含各類設(shè)備ID及其設(shè)備屬性,需要提供批量匹配功能:給定一類或多類設(shè)備ID的批量文件,從大表中獲取到匹配上的設(shè)備信息(ID及多個(gè)屬性信息)。
  • 對(duì)PB級(jí)數(shù)據(jù)進(jìn)行各種快速探索,輸入各種過(guò)濾條件,如地域(國(guó)家/省/市/區(qū))、地理圍欄(地圖圈選/上傳文件/直接輸入)、使用的App及分類(安裝/活躍)、時(shí)間范圍(日/周/月)、POI及分類等等,理論上不限制條件個(gè)數(shù),經(jīng)驗(yàn)值最多在5~6個(gè)左右。
  • 輸出主要包括明細(xì)信息、多維度統(tǒng)計(jì)(畫像)、圖表(熱力圖)等。
  • 平臺(tái)提供的數(shù)據(jù)服務(wù),都是批量模式的計(jì)算,所以需要為用戶提交的數(shù)據(jù)作業(yè),給予準(zhǔn)確的狀態(tài)變化反饋。
  • 有小部分面向開發(fā)人員的需求:將在數(shù)據(jù)平臺(tái)Web系統(tǒng)操作進(jìn)行的數(shù)據(jù)匹配、提取、探索等操作,進(jìn)行服務(wù)化以供其他系統(tǒng)中的服務(wù)調(diào)用。

架構(gòu)需求

在未來(lái)業(yè)務(wù)模式變化的情況下,能夠非常容易地?cái)U(kuò)展,并盡量復(fù)用大部分核心組件。同時(shí),還要面向開發(fā)人員復(fù)用數(shù)據(jù)平臺(tái)的數(shù)據(jù)業(yè)務(wù)服務(wù),以增加平臺(tái)利用率,間接產(chǎn)出數(shù)據(jù)價(jià)值。考慮如下一些當(dāng)前需要以及未來(lái)可能演變的架構(gòu)需求:

  • 定義作業(yè)和任務(wù)的概念:作業(yè)是用戶為滿足一次業(yè)務(wù)需要而提交的數(shù)據(jù)獲取請(qǐng)求,最終輸出想要的數(shù)據(jù)結(jié)果;任務(wù)是為滿足輸出一個(gè)作業(yè)結(jié)果,從邏輯上拆分成的基本計(jì)算單元。一個(gè)作業(yè)由多個(gè)任務(wù)的計(jì)算組合而完成。
  • 對(duì)于一個(gè)作業(yè)輸入的多個(gè)過(guò)濾條件,如果作為一個(gè)單獨(dú)的計(jì)算任務(wù),根本無(wú)法在PB量級(jí)的數(shù)據(jù)上輸出結(jié)果,所以需要將作業(yè)拆分成多個(gè)任務(wù)進(jìn)行分別計(jì)算,最后輸出結(jié)果。
  • 對(duì)用戶作業(yè)狀態(tài)的管理,具有一定的業(yè)務(wù)含義,基本不能在公司級(jí)別進(jìn)行復(fù)用,具體涉及內(nèi)容包括:排隊(duì)、組成作業(yè)的任務(wù)列表管理、作業(yè)優(yōu)先級(jí)管理。
  • 任務(wù)是最基本的計(jì)算單位,設(shè)計(jì)能夠協(xié)調(diào)整個(gè)任務(wù)計(jì)算的架構(gòu),可以分離出任何業(yè)務(wù)狀態(tài),實(shí)現(xiàn)為無(wú)狀態(tài)的任務(wù)計(jì)算架構(gòu),在公司級(jí)別可以復(fù)用,比如大量基于Spark的計(jì)算可以抽象為任務(wù)計(jì)算。
  • 由于時(shí)間范圍條件跨度需要支持幾年(如1~3年),計(jì)算依賴的數(shù)據(jù)量級(jí)在TB甚至PB級(jí)別,所以一定要通過(guò)預(yù)計(jì)算的方式壓縮數(shù)據(jù),并能提供支持快速計(jì)算的方式。
  • 預(yù)計(jì)算可以使用Spark計(jì)算集群,每天通過(guò)控制計(jì)算所需資源進(jìn)行大規(guī)模ETL處理。
  • ETL處理,迫切需要一個(gè)簡(jiǎn)單、輕量的ETL作業(yè)調(diào)度系統(tǒng),可以從開源產(chǎn)品中甄選。
  • 采用原生Spark計(jì)算基本無(wú)法為平臺(tái)上用戶提供快速計(jì)算的體驗(yàn),可能會(huì)考慮列式分布式數(shù)據(jù)庫(kù),或基于Bitmap結(jié)構(gòu)的分布式計(jì)算系統(tǒng)。
  • 面向開發(fā)人員,部分涉及業(yè)務(wù)相關(guān)內(nèi)容的模塊,第一階段可以通過(guò)硬編碼方式處理業(yè)務(wù)邏輯,后續(xù)第二階段可以基于對(duì)業(yè)務(wù)流程的熟悉來(lái)進(jìn)行改造,抽取通用業(yè)務(wù)邏輯規(guī)則,構(gòu)建能夠快速交付業(yè)務(wù)功能的模塊。
  • 對(duì)平臺(tái)架構(gòu)進(jìn)行分解,分離有狀態(tài)和無(wú)狀態(tài)模塊,分離帶業(yè)務(wù)屬性和不帶業(yè)務(wù)屬性的模塊,保持模塊輕量易于隨架構(gòu)演進(jìn)進(jìn)行改造、升級(jí)、維護(hù)。

技術(shù)選型

技術(shù)選型,主要從如下幾個(gè)方面進(jìn)行考慮:

數(shù)據(jù)存儲(chǔ)

  • 原始數(shù)據(jù)存儲(chǔ)

數(shù)據(jù)量級(jí)達(dá)到PB級(jí),所以,作為整個(gè)數(shù)據(jù)服務(wù)平臺(tái)的最初輸入數(shù)據(jù),我們稱為數(shù)據(jù)服務(wù)平臺(tái)的原始數(shù)據(jù),后續(xù)簡(jiǎn)稱原始數(shù)據(jù),這些原始數(shù)據(jù)是直接存儲(chǔ)在HDFS文件系統(tǒng)中,根據(jù)時(shí)間的維度,分為小時(shí)數(shù)據(jù)、日數(shù)據(jù)、月數(shù)據(jù)。這樣,可以根據(jù)數(shù)據(jù)計(jì)算需要,按照小時(shí)、日、月進(jìn)行加工處理,能夠在可允許的計(jì)算資源配額和計(jì)算時(shí)間范圍內(nèi)完成處理。
另外,根據(jù)每天大約30~40TB的增量數(shù)據(jù),原始數(shù)據(jù)采用parquet格式壓縮存儲(chǔ),我們進(jìn)行二次加工的輸出仍然是以parquet格式存儲(chǔ)。

  • 分布式關(guān)系數(shù)據(jù)存儲(chǔ)

對(duì)于PB級(jí)的數(shù)據(jù),想要在數(shù)據(jù)服務(wù)平臺(tái)中快速為用戶提供數(shù)據(jù)服務(wù),根據(jù)業(yè)務(wù)特點(diǎn),存儲(chǔ)在適合快速加載、快速計(jì)算的分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)中。
快速加載,必然要對(duì)數(shù)據(jù)進(jìn)行特殊格式處理,并在一定程度上壓縮數(shù)據(jù),這樣才能減少數(shù)據(jù)加載時(shí)間。可以很容易想到,使用支持列式存儲(chǔ)的分布式數(shù)據(jù)庫(kù)。比如Vertica分布式數(shù)據(jù)庫(kù)就是一款支持列式存儲(chǔ)的MPP數(shù)據(jù)庫(kù)。Vertica是HP開發(fā)的商用分布式數(shù)據(jù)庫(kù),同時(shí)也發(fā)布了開源的免費(fèi)社區(qū)版本,不過(guò)社版本有一定限制:只支持1TB原始數(shù)據(jù)、3節(jié)點(diǎn)集群規(guī)模。如果變通一些,可以通過(guò)Vertica社區(qū)版本進(jìn)行改造以支持解除3個(gè)節(jié)點(diǎn)集群規(guī)模和1TB存儲(chǔ)的限制,不過(guò)要在分片邏輯控制、分片數(shù)據(jù)一致性方面做更多工作,尤其是面向上層應(yīng)用提供單一的統(tǒng)一存取視圖是非常必要的。因?yàn)榱惺酱鎯?chǔ)支持計(jì)算時(shí)只加載用于計(jì)算的列,故而能夠達(dá)到快速加載的目的。
快速計(jì)算,首先要求計(jì)算能夠并行化,那么數(shù)據(jù)就應(yīng)該分片存儲(chǔ),使數(shù)據(jù)計(jì)算本地化。Vertica自然能夠?qū)崿F(xiàn)數(shù)據(jù)的并行計(jì)算,我們?cè)谇捌谑褂眠^(guò)程中驗(yàn)證了,對(duì)于從40億+的大表中批量匹配出任意信息(匹配ID,以及ID對(duì)應(yīng)的關(guān)聯(lián)表中的其它明細(xì)信息),效率非常好,基本分鐘級(jí)便可以輸出匹配結(jié)果。
我們也對(duì)開源不久的MPP數(shù)據(jù)庫(kù)Greenplum進(jìn)行了調(diào)研,它原生支持分布式架構(gòu),支持列式和行式兩種存儲(chǔ),自然具有Vertica對(duì)應(yīng)的列式存儲(chǔ)的優(yōu)勢(shì),又不需要手動(dòng)對(duì)分片進(jìn)行管理控制,但性能要比Vertica差一些。然而,Greenplum數(shù)據(jù)庫(kù)能夠支持?jǐn)?shù)組類型,支持多種編程語(yǔ)言的UDF,結(jié)合我們之前做過(guò)很多有關(guān)Bitmap的實(shí)踐,采用開源的RoaringBitmap,能夠很好的基于Greenplum實(shí)現(xiàn)快速的Bitmap計(jì)算。

  • 消息存儲(chǔ)

消息存儲(chǔ),主要是用來(lái)解耦后臺(tái)多個(gè)較重的系統(tǒng)之間的通信。因?yàn)楸旧磉@類系統(tǒng)比較重,如果采用RPC調(diào)用的方式進(jìn)行通信,某個(gè)系統(tǒng)進(jìn)行升級(jí),會(huì)導(dǎo)致依賴于該系統(tǒng)提供服務(wù)的其它系統(tǒng)管理更多的特殊情況處理。而采用消息機(jī)制,使得各個(gè)系統(tǒng)之間不需要關(guān)注交互系統(tǒng)處理狀態(tài),而對(duì)消息交換只需要關(guān)注消息的生成和消費(fèi)。
這樣,我們可以隨時(shí)對(duì)系統(tǒng)進(jìn)行改造、升級(jí)、Bug修復(fù)重啟等操作,而不會(huì)使整個(gè)平臺(tái)陷入不可控的狀態(tài)。消息中間件,我們選擇使用RabbitMQ。

數(shù)據(jù)處理

數(shù)據(jù)處理,主要包括原始數(shù)據(jù)ETL處理、應(yīng)用數(shù)據(jù)計(jì)算兩大類:

  • 原始數(shù)據(jù)ETL處理

基于HDFS存儲(chǔ)的數(shù)據(jù),最方便最高效的技術(shù)方案,自然是使用Spark計(jì)算集群來(lái)對(duì)數(shù)據(jù)進(jìn)行ETL處理。我們基于原生的Scala編程語(yǔ)言來(lái)開發(fā)各種ETL程序,實(shí)現(xiàn)數(shù)據(jù)清洗、抽取、轉(zhuǎn)換操作。

  • 應(yīng)用數(shù)據(jù)計(jì)算

數(shù)據(jù)服務(wù)平臺(tái)中,面向用戶的應(yīng)用數(shù)據(jù)計(jì)算,基于Greenplum數(shù)據(jù)庫(kù)支持的SQL語(yǔ)言來(lái)實(shí)現(xiàn)數(shù)據(jù)處理,并基于Java編程語(yǔ)言來(lái)實(shí)現(xiàn)整個(gè)應(yīng)用服務(wù)的開發(fā)。

ETL作業(yè)調(diào)度

數(shù)據(jù)處理需要進(jìn)行大量的ETL計(jì)算,管理各種計(jì)算任務(wù)之間的依賴關(guān)系及其調(diào)度,我們采用了非常輕量的Azkaban調(diào)度系統(tǒng)。

業(yè)務(wù)元數(shù)據(jù)管理

業(yè)務(wù)元數(shù)據(jù),主要用于支撐數(shù)據(jù)服務(wù)平臺(tái)Web UI上面的各種業(yè)務(wù)條件選項(xiàng),比如,常用的有如下一些:

  • 移動(dòng)設(shè)備機(jī)型、品牌、運(yùn)營(yíng)商、網(wǎng)絡(luò)、價(jià)格范圍、設(shè)備物理特性
  • 應(yīng)用名稱、包名、哈希值
  • 應(yīng)用分類
  • 地域信息,如國(guó)家、省份、城市、區(qū)縣
  • POI名稱、地址
  • POI分類,包括一級(jí)分類、二級(jí)分類

這些元數(shù)據(jù),有些來(lái)自于基礎(chǔ)數(shù)據(jù)部門提供的標(biāo)準(zhǔn)庫(kù),比如品牌、價(jià)格范圍等,可以從對(duì)應(yīng)的數(shù)據(jù)表中同步或直接讀取;而有些具有時(shí)間含義的元數(shù)據(jù),需要每天通過(guò)ETL處理生成,比如應(yīng)用信息;POI數(shù)據(jù)需要從外部抓取,并進(jìn)行處理,一般每個(gè)月更新一次。
這些元數(shù)據(jù),為支撐應(yīng)用計(jì)算使用,被存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中;而對(duì)于填充頁(yè)面上對(duì)應(yīng)的條件選擇的數(shù)據(jù),則使用Redis存儲(chǔ),每天/月會(huì)根據(jù)MySQL中的數(shù)據(jù)進(jìn)行加工處理,生成易于快速查詢的鍵值對(duì)類數(shù)據(jù),存儲(chǔ)到Redis中。

數(shù)據(jù)服務(wù)

數(shù)據(jù)服務(wù),主要支撐后臺(tái)的數(shù)據(jù)應(yīng)用,全平臺(tái)采用標(biāo)準(zhǔn)的REST接口風(fēng)格來(lái)定義,主要使用Spring Boot來(lái)快速開發(fā)對(duì)應(yīng)的接口。

  • 離線批量服務(wù)進(jìn)行REST接口封裝

還有一點(diǎn)我們需要遵循的是,任何具有復(fù)雜的數(shù)據(jù)處理邏輯的服務(wù),都通過(guò)一層REST接口進(jìn)行封裝,將全部的離線批量服務(wù)后置。這樣得到一個(gè)聚合服務(wù)的REST接口層,該層主要負(fù)責(zé)定義和管理接口的各個(gè)請(qǐng)求、響應(yīng)參數(shù),REST接口不變,而對(duì)應(yīng)的數(shù)據(jù)處理邏輯可以根據(jù)實(shí)際情況進(jìn)行調(diào)整,以后對(duì)存儲(chǔ)或計(jì)算方案進(jìn)行升級(jí)改動(dòng),都不影響使用上層REST接口調(diào)用方。

  • Greenplum服務(wù)網(wǎng)關(guān)

比如,我們采用Greenplum數(shù)據(jù)庫(kù),在Greenplum前面增加了一層Greenplum服務(wù)網(wǎng)關(guān),對(duì)于任何需要訪問(wèn)Greenplum數(shù)據(jù)庫(kù)的應(yīng)用,必須通過(guò)與Greenplum服務(wù)網(wǎng)關(guān)進(jìn)行交互,而不是直接去訪問(wèn)Greenplum數(shù)據(jù)庫(kù)。理想狀態(tài)下,Greenplum服務(wù)網(wǎng)關(guān)可以實(shí)現(xiàn)為無(wú)狀態(tài)的服務(wù)網(wǎng)關(guān),通過(guò)Nginx做反向代理實(shí)現(xiàn)HA,這樣后續(xù)因?yàn)闃I(yè)務(wù)變更,可以非常平滑地進(jìn)行變更和升級(jí),而不影響依賴于Greenplum服務(wù)網(wǎng)關(guān)的業(yè)務(wù)接口調(diào)用。

  • 微服務(wù)

除了數(shù)據(jù)服務(wù)平臺(tái)內(nèi)部進(jìn)行服務(wù)調(diào)用,最外層通過(guò)Web界面的風(fēng)格,只需要拖動(dòng)或選擇可視化組件,實(shí)現(xiàn)對(duì)非技術(shù)背景的業(yè)務(wù)用戶進(jìn)行數(shù)據(jù)提取和分析,未來(lái)我們還要將全部的服務(wù)暴露到外部(數(shù)據(jù)服務(wù)平臺(tái)所屬部門之外的其它部門,以及公司外部),最大化數(shù)據(jù)服務(wù)的價(jià)值。
微服務(wù)部分,我們選擇了Spring Cloud來(lái)快速構(gòu)建微服務(wù)。

UI展示

UI層主要根據(jù)我們開發(fā)人員的技術(shù)背景,使用Vue來(lái)構(gòu)建面向業(yè)務(wù)用戶的數(shù)據(jù)服務(wù)Web系統(tǒng)。

架構(gòu)設(shè)計(jì)

整個(gè)數(shù)據(jù)服務(wù)平臺(tái)的架構(gòu)設(shè)計(jì),如下圖所示:

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)
如上圖所示,對(duì)應(yīng)的各個(gè)核心子平臺(tái)及其服務(wù),下面將分別詳細(xì)說(shuō)明:

  • 數(shù)據(jù)服務(wù)Web系統(tǒng)

數(shù)據(jù)服務(wù)Web系統(tǒng)是面向用戶使用的,主要通過(guò)可視化業(yè)務(wù)組件的方式,將數(shù)據(jù)服務(wù)暴露出來(lái),方便業(yè)務(wù)用戶使用。同時(shí),該系統(tǒng)提供用戶權(quán)限管理的功能,可以設(shè)置用戶權(quán)限,主要包括業(yè)務(wù)用戶和管理用戶。
數(shù)據(jù)服務(wù)Web系統(tǒng)的設(shè)計(jì),如下圖所示:

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

該系統(tǒng)的設(shè)計(jì)比較容易,核心的思想就是前端和后端分離。前端定義的各種可視化組件,都是根據(jù)不同業(yè)務(wù)線的需求,經(jīng)過(guò)梳理分類,將需求頻度較高的抽象出來(lái),做成業(yè)務(wù)功能組件。后端服務(wù)包括兩類:一類是業(yè)務(wù)元數(shù)據(jù)服務(wù)接口,包括各種需要在頁(yè)面展示的數(shù)據(jù)項(xiàng),如設(shè)備機(jī)型、地域、應(yīng)用、POI等;另一類是作業(yè)管理服務(wù)接口,主要負(fù)責(zé)管理作業(yè)相關(guān)內(nèi)容,如作業(yè)查詢、保存等。

  • 業(yè)務(wù)作業(yè)調(diào)度平臺(tái)

業(yè)務(wù)作業(yè)調(diào)度平臺(tái)是整個(gè)數(shù)據(jù)服務(wù)平臺(tái)最核心的子平臺(tái)之一,設(shè)計(jì)該平臺(tái)主要考慮除了當(dāng)前支撐面向業(yè)務(wù)用戶需求之外,還要能夠很好的擴(kuò)展以支持其他業(yè)務(wù)部門開發(fā)人員對(duì)服務(wù)的使用。該平臺(tái)的架構(gòu),如下圖所示:

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

該平臺(tái)主要負(fù)責(zé)作業(yè)的解析編排、排隊(duì)、調(diào)度。
作業(yè)編排采用調(diào)用外部編排服務(wù)的方式,主要考慮的是編排需要根據(jù)業(yè)務(wù)的一些屬性進(jìn)行實(shí)現(xiàn),所以將易變的業(yè)務(wù)部分從作業(yè)調(diào)度平臺(tái)分離出去。如果后續(xù)有對(duì)編排邏輯進(jìn)行調(diào)整和修改,都無(wú)需操作業(yè)務(wù)作業(yè)度調(diào)度平臺(tái)。
排隊(duì),支持多隊(duì)列排隊(duì)配置,比如根據(jù)當(dāng)前及其未來(lái)的發(fā)展趨勢(shì),需要具有面向業(yè)務(wù)用戶的業(yè)務(wù)隊(duì)列、面向開發(fā)人員的服務(wù)隊(duì)列,而這兩種隊(duì)列所負(fù)責(zé)的作業(yè)調(diào)度的SLA是完全不同的,業(yè)務(wù)隊(duì)列中的作業(yè)每天可能成百上千個(gè),而服務(wù)隊(duì)列在初期對(duì)于每個(gè)業(yè)務(wù)線只需要每天調(diào)用一次或多次(正常會(huì)嚴(yán)格限制服務(wù)調(diào)用數(shù)量),初期從作業(yè)量上來(lái)看這兩個(gè)作業(yè)容量的比例大概是8:2,通過(guò)隊(duì)列來(lái)隔離調(diào)度,能夠更好地滿足具有不同需求的用戶。
調(diào)度,是對(duì)作業(yè)、以及屬于該作業(yè)的一組任務(wù)進(jìn)行調(diào)度,為了簡(jiǎn)單可控起見,每個(gè)作業(yè)經(jīng)過(guò)編排后會(huì)得到一組有序的任務(wù)列表,然后對(duì)每個(gè)任務(wù)進(jìn)行調(diào)度。這里面,稍有點(diǎn)復(fù)雜的是,作業(yè)是一級(jí)調(diào)度,任務(wù)是二級(jí)調(diào)度,但是要保證屬于同一個(gè)作業(yè)的任務(wù)能夠按照先后順序被調(diào)度運(yùn)行。所以,作業(yè)是排隊(duì)的基本單位,在每一個(gè)排隊(duì)單元中,要包含作業(yè)ID、任務(wù)個(gè)數(shù)、作業(yè)狀態(tài),同時(shí)為能夠控制任務(wù)正確調(diào)度,也需要包含當(dāng)前調(diào)度運(yùn)行中任務(wù)ID、運(yùn)行中任務(wù)狀態(tài),可見任務(wù)是調(diào)度運(yùn)行的基本單位。被調(diào)度運(yùn)行的任務(wù)會(huì)發(fā)送到RabbitMQ中,然后等待任務(wù)協(xié)調(diào)計(jì)算平臺(tái)消費(fèi)并運(yùn)行任務(wù),這時(shí)作業(yè)調(diào)度平臺(tái)只需要等待任務(wù)運(yùn)行完成的結(jié)果消息到達(dá),然后對(duì)作業(yè)和任務(wù)的狀態(tài)進(jìn)行更新,根據(jù)實(shí)際狀態(tài)確定下一次調(diào)度的任務(wù)。
另外,還有幾個(gè)點(diǎn)需要注意:第一,被調(diào)度運(yùn)行的任務(wù)需要進(jìn)行超時(shí)處理;第二,控制同時(shí)能夠被調(diào)度的作業(yè)(實(shí)際上運(yùn)行的是作業(yè)對(duì)應(yīng)的某個(gè)任務(wù))的數(shù)量;第三,作業(yè)優(yōu)先級(jí)控制。

  • 任務(wù)協(xié)調(diào)計(jì)算平臺(tái)

任務(wù)協(xié)調(diào)計(jì)算平臺(tái)也整個(gè)數(shù)據(jù)服務(wù)平臺(tái)最核心的子平臺(tái)之一,它是無(wú)狀態(tài)的,除了能夠支撐我們的數(shù)據(jù)服務(wù)平臺(tái),如果有其它想要接入的任務(wù),都可以通過(guò)該平臺(tái)協(xié)調(diào)來(lái)運(yùn)行。該平臺(tái)的架構(gòu),如下圖所示:

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

該平臺(tái)的設(shè)計(jì)是主從架構(gòu),Master和Slave之間通過(guò)RPC調(diào)用進(jìn)行通信,通信層使用了Netty網(wǎng)絡(luò)通信框架。Worker可以根據(jù)實(shí)際計(jì)算任務(wù)的壓力,進(jìn)行水平擴(kuò)展。
Master負(fù)責(zé)控制從RabbitMQ中拉取任務(wù)消息,然后根據(jù)Worker節(jié)點(diǎn)的資源狀況進(jìn)行任務(wù)的協(xié)調(diào)和調(diào)度,并將Worker上作業(yè)完成的信息發(fā)送到RabbitMQ,供上游業(yè)務(wù)作業(yè)調(diào)度平臺(tái)消費(fèi)從而控制更新作業(yè)的運(yùn)行狀態(tài)。同時(shí),Master管理注冊(cè)的Worker狀態(tài)、Worker資源狀態(tài)、Worker上運(yùn)行的任務(wù)的狀態(tài)。
Worker是實(shí)際運(yùn)行任務(wù)的工作節(jié)點(diǎn),它負(fù)責(zé)將任務(wù)調(diào)度到后端的計(jì)算集群,或者調(diào)用數(shù)據(jù)處理服務(wù)來(lái)實(shí)現(xiàn)任務(wù)的運(yùn)行。由于任務(wù)都是批量處理型計(jì)算任務(wù),所以Worker要管理任務(wù)的提交,以及對(duì)已提交任務(wù)運(yùn)行狀態(tài)的異步查詢(輪詢)。

  • Greenplum REST服務(wù)網(wǎng)關(guān)

Greenplum REST服務(wù)網(wǎng)關(guān),直接與Greenplum數(shù)據(jù)庫(kù)進(jìn)行交互,這樣起到保護(hù)Greenplum數(shù)據(jù)庫(kù)的作用。因?yàn)閷?shí)際Greenplum數(shù)據(jù)庫(kù)集群的計(jì)算容量有限,不能無(wú)限支持很高并發(fā),所以通過(guò)控制并發(fā)來(lái)加快每個(gè)計(jì)算任務(wù)。該REST服務(wù)網(wǎng)關(guān)的設(shè)計(jì),如下圖所示:

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

上圖中,通過(guò)排隊(duì)機(jī)制來(lái)保護(hù)Greenplum,并進(jìn)行任務(wù)的調(diào)度運(yùn)行,所以該服務(wù)是有狀態(tài)的。而且,該服務(wù)具有一定的業(yè)務(wù)特征,根據(jù)不同的數(shù)據(jù)需求,需要對(duì)接口以及SQL進(jìn)行調(diào)整,最好的方式是將業(yè)務(wù)接口與任務(wù)計(jì)算分離:業(yè)務(wù)接口層可以將調(diào)用任務(wù)保存到Redis隊(duì)列中,實(shí)現(xiàn)接口層的冗余部署和平滑升級(jí),然后作為消費(fèi)的任務(wù)處理服務(wù)直接消費(fèi)Redis隊(duì)列中的任務(wù),提交到Greenplum數(shù)據(jù)庫(kù)計(jì)算。

  • 數(shù)據(jù)微服務(wù)平臺(tái)

數(shù)據(jù)微服務(wù)平臺(tái),主要考慮復(fù)用已存在的數(shù)據(jù)服務(wù),以及支撐數(shù)據(jù)服務(wù)的核心組件,如業(yè)務(wù)作業(yè)調(diào)度平臺(tái)、任務(wù)協(xié)調(diào)計(jì)算平臺(tái)等,為面向開發(fā)人員使用的服務(wù)調(diào)用,通過(guò)服務(wù)接口的方式暴露出來(lái)。數(shù)據(jù)微服務(wù)平臺(tái)的架構(gòu),如下圖所示:

PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐-36大數(shù)據(jù)

該平臺(tái)主要基于Spring Cloud構(gòu)建,使用Eureka作為服務(wù)注冊(cè)中心。由于整個(gè)數(shù)據(jù)服務(wù)平臺(tái)是以離線計(jì)算為主,沒有高并發(fā)、服務(wù)降級(jí)的、調(diào)用鏈跟蹤等需求,所以并沒有完全使用Netflix OSS中大部分組件,如Zuul、Hystrix等。如果后續(xù)需要,可以非常容地集成進(jìn)來(lái)。
鑒權(quán)網(wǎng)關(guān),是所有調(diào)用微服務(wù)平臺(tái)的外部調(diào)用方的入口。為了保證整個(gè)微服務(wù)平臺(tái)的正常運(yùn)行,通過(guò)用戶、時(shí)間(調(diào)用期限)、調(diào)用頻率等限制調(diào)用方。比如某些業(yè)務(wù)線的應(yīng)用需要使用微服務(wù)平臺(tái)的服務(wù),由于對(duì)方業(yè)務(wù)可能下線,而服務(wù)程序沒有下線,仍然持續(xù)調(diào)用我們平臺(tái)服務(wù),這會(huì)對(duì)微服務(wù)平臺(tái)資源造成浪費(fèi)。另外,也避免了服務(wù)調(diào)用方測(cè)試、調(diào)試,對(duì)整個(gè)微服務(wù)平臺(tái)造成不可控的狀況。
上圖左面,服務(wù)注冊(cè)中心及其以上部分,是整個(gè)微服務(wù)平臺(tái)的核心部分,我們?cè)跇?gòu)建該平臺(tái)時(shí),也考慮了接入非微服務(wù)的組件。比如熱力圖服務(wù),數(shù)據(jù)是需要批量處理生成,而訪問(wèn)時(shí)是同步調(diào)用的,所以在數(shù)據(jù)服務(wù)平臺(tái)的Web部分提交的作業(yè),如果是熱力圖類型,會(huì)調(diào)用微服務(wù)平臺(tái)的熱力圖服務(wù)異步生成數(shù)據(jù),而用戶可以在Web系統(tǒng)中查看熱力圖(如果未生成則提示正在生成中);對(duì)其它上層數(shù)據(jù)應(yīng)用也可以直接調(diào)用微服務(wù)平臺(tái)的熱力圖服務(wù)生成數(shù)據(jù),并下載對(duì)應(yīng)數(shù)熱力圖據(jù)。

  • 其它服務(wù)/系統(tǒng)

其它服務(wù)/系統(tǒng)比較簡(jiǎn)單,所以這里只是簡(jiǎn)單說(shuō)明一下:
Java REST服務(wù)網(wǎng)關(guān):要對(duì)某些從Greenplum數(shù)據(jù)庫(kù)中計(jì)算得到的數(shù)據(jù),需要進(jìn)行再加工處理以滿足實(shí)際業(yè)務(wù),如熱力圖數(shù)據(jù)生成和壓縮等,將這些服務(wù)封裝成REST風(fēng)格接口調(diào)用。
Spark REST服務(wù)網(wǎng)關(guān):對(duì)于需要對(duì)HDFS上指定數(shù)據(jù)集處理,生成需要的結(jié)果數(shù)據(jù),使用Spark開發(fā)程序,同時(shí)將Spark計(jì)算作業(yè)封裝成REST風(fēng)格接口調(diào)用。
數(shù)據(jù)ETL調(diào)度系統(tǒng):使用開源的Azkaban調(diào)度系統(tǒng),實(shí)現(xiàn)所有ETL作業(yè)的統(tǒng)一調(diào)度。
數(shù)據(jù)采集服務(wù):根據(jù)數(shù)據(jù)業(yè)務(wù)需要,從網(wǎng)上或其它渠道采集數(shù)據(jù),比如通過(guò)高德API采集POI數(shù)據(jù)等。

架構(gòu)總結(jié)

通過(guò)上面的架構(gòu)設(shè)計(jì)實(shí)踐,我們總結(jié)一下實(shí)踐的經(jīng)驗(yàn),如下所示:

  • 底層數(shù)據(jù)處理引擎,可能會(huì)隨著業(yè)務(wù)的發(fā)展,以及新技術(shù)的更迭,我們會(huì)有更多選擇,所以在數(shù)據(jù)處理引擎之上,設(shè)計(jì)一層REST服務(wù),實(shí)現(xiàn)上層應(yīng)用與底層數(shù)據(jù)處理引擎解耦和。
  • 多個(gè)相對(duì)較重的服務(wù),如業(yè)務(wù)作業(yè)調(diào)度平臺(tái)、任務(wù)協(xié)調(diào)計(jì)算平臺(tái),它們之間通過(guò)消息解耦和,能更好的降低各個(gè)服務(wù)的復(fù)雜性,以及因?yàn)樽兏鼘?duì)雙方造成的影響。
  • 系統(tǒng)架構(gòu)分解,要考慮將有狀態(tài)和無(wú)狀態(tài)的部分分離,甚至在某個(gè)服務(wù)中,也有必要將有狀態(tài)和無(wú)狀態(tài)的部分進(jìn)行分離。
  • 業(yè)務(wù)部分和非業(yè)務(wù)部分的分離,這樣能夠適應(yīng)業(yè)務(wù)需求的變更,持續(xù)對(duì)業(yè)務(wù)部分進(jìn)行更新升級(jí),而非業(yè)務(wù)部分可能是相對(duì)穩(wěn)定的。

對(duì)于無(wú)狀態(tài)的服務(wù),我們可以通過(guò)冗余部署多個(gè)服務(wù)實(shí)例,再通過(guò)反向代理的方式實(shí)現(xiàn)服務(wù)的高可用,甚至在演進(jìn)為微服務(wù)架構(gòu)時(shí)也比較容易做到。對(duì)于有狀態(tài)的服務(wù),因?yàn)閱蝹€(gè)服務(wù)需要維護(hù)狀態(tài)新,所以實(shí)現(xiàn)高可用的思路是,啟動(dòng)多個(gè)實(shí)例,但是同一時(shí)刻只有一個(gè)是Active服務(wù)可以操作狀態(tài),而其它實(shí)例作為Standby服務(wù),需要通過(guò)一種機(jī)制來(lái)監(jiān)聽并發(fā)現(xiàn)Active服務(wù)的可用性,然后在其失敗時(shí)能切換到Standby服務(wù),比如常用的Zookeeper等。

End.

轉(zhuǎn)載請(qǐng)注明來(lái)自36大數(shù)據(jù)(36dsj.com): 36大數(shù)據(jù) ? PB級(jí)海量數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)設(shè)計(jì)實(shí)踐

隨意打賞

大數(shù)據(jù)平臺(tái)架構(gòu)大數(shù)據(jù)架構(gòu)設(shè)計(jì)app架構(gòu)設(shè)計(jì)海量大數(shù)據(jù)大平臺(tái)設(shè)計(jì)pb數(shù)據(jù)架構(gòu)設(shè)計(jì)
提交建議
微信掃一掃,分享給好友吧。
主站蜘蛛池模板: 二级毛片免费观看全程 | 日日操狠狠干 | 国产伦精品一区二区三区高清 | 亚洲韩国日本一级二级r级 亚洲韩精品欧美一区二区三区 | 九九久久国产精品 | 色淫综合| se94se亚洲欧美在线 | 日韩欧美中文 | 男人的网站在线观看 | 久久国产精品久久久久久 | 一区二区三区高清不卡 | 久久99免费 | 欧美一级特黄毛片免费 | 久草精品视频在线观看 | 欧美影院久久 | 国色天香成人网 | 91福利视频在线 | 日韩手机看片 | 骚视频在线观看 | 毛色毛片免费观看 | 亚洲精品高清视频 | 老黄网站 | 四虎精品影院 | 深夜福利视频在线一区 | 欧美日韩在线网站 | 青青青青久在线观看视频 | 全免费一级毛片在线播放 | 精品中文字幕在线 | 日韩国产成人精品视频 | 国产成人精品天堂 | 成人短视频在线观看视频 | 久草免费在线观看视频 | 久久国内精品自在自线观看 | 国产精品一国产精品 | 91精品久久一区二区三区 | 日韩欧美高清视频 | 日本在线不卡免 | 亚洲伊人tv综合网色 | 免费欧美日韩 | 天堂素人在线 | 久久精品国产99久久久 |