作者：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ì)，如下圖所示：

如上圖所示，對(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ì)，如下圖所示：

該系統(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)，如下圖所示：

該平臺(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)，如下圖所示：

該平臺(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ì)，如下圖所示：

上圖中，通過(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)，如下圖所示：

該平臺(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í)踐