宜人貸PaaS數(shù)據(jù)服務(wù)平臺Genie:技術(shù)架構(gòu)及功能

      網(wǎng)友投稿 895 2025-04-04

      上篇:架構(gòu)及組件

      一、數(shù)據(jù)平臺的發(fā)展

      1.1 背景介紹

      隨著數(shù)據(jù)時代的到來,數(shù)據(jù)量和數(shù)據(jù)復(fù)雜度的增加推動了數(shù)據(jù)工程領(lǐng)域的快速發(fā)展。為了滿足各類數(shù)據(jù)獲取/計(jì)算等需求,業(yè)內(nèi)涌現(xiàn)出了諸多解決方案。但大部分方案都遵循以下原則:

      降低數(shù)據(jù)處理成本

      合理提高數(shù)據(jù)使用/計(jì)算效率

      提供統(tǒng)一的編程范式

      宜人貸的數(shù)據(jù)服務(wù)平臺也是遵循這三個原則。本人有幸親身經(jīng)歷了宜人貸數(shù)據(jù)平臺Genie的整個發(fā)展過程,縱觀宜人貸和業(yè)內(nèi),可以說Genie的發(fā)展是工業(yè)界數(shù)據(jù)平臺發(fā)展的縮影。

      Google 的三大論文和Apache Hadoop 開源生態(tài)圈的發(fā)布應(yīng)該是大數(shù)據(jù)處理技術(shù)走進(jìn)“尋常百姓家”的起點(diǎn)。Hadoop 的組件均可在普通的廉價機(jī)器上運(yùn)行,加上其代碼是開源的,因此得到了眾多公司的熱捧。那么一開始這些公司都用它來做什么呢?

      答案是數(shù)據(jù)倉庫

      注:Google三大論文:Bigtable: A Distributed Storage System for Structured Data;The Google File System;MapReduce: Simplefied Data Processing on Large Clusters

      所以早期的數(shù)據(jù)平臺大概的架構(gòu)都是由Sqoop+HDFS+Hive這三個組件組成,因?yàn)檫@個是搭建數(shù)據(jù)倉庫最廉價高效的方式。此時數(shù)據(jù)倉庫只能回答過去發(fā)生了什么(離線階段),因?yàn)镾qoop離線抽取一般采用的t+1快照方案,也就是說只有昨天的數(shù)據(jù)。

      緊接著由于對數(shù)據(jù)實(shí)時性的需求提高了,需要實(shí)時做增量數(shù)據(jù)的關(guān)聯(lián)聚合等復(fù)雜運(yùn)算,這個時候數(shù)據(jù)平臺就會加入分布式流計(jì)算的架構(gòu),如:Strom ,F(xiàn)link, Spark Streaming 等。此時的數(shù)據(jù)倉庫可以回答的是正在發(fā)生什么(實(shí)時階段)。

      由于離線數(shù)據(jù)處理流程(如:Sqoop+HDFS+Hive)和實(shí)時數(shù)據(jù)處理流程(如:Binlog+Spark Steaming+Hbase)兩套流程計(jì)算邏輯耦合較大,并且通過組合才能支持實(shí)時全量的數(shù)據(jù)分析,所以就產(chǎn)生了很多架構(gòu),如早期的Lambda,Kappa等。此時歷史數(shù)據(jù)和實(shí)時數(shù)據(jù)結(jié)合數(shù)據(jù)倉庫可以回答什么終將會發(fā)生(預(yù)測階段)。

      數(shù)據(jù)平臺發(fā)展至此已經(jīng)不再是一個數(shù)據(jù)倉庫就能解釋的了,它與各類業(yè)務(wù)部門緊密合作(如營銷、電銷、運(yùn)營)打造出諸多數(shù)據(jù)產(chǎn)品。此時數(shù)據(jù)倉庫(數(shù)據(jù)平臺)已經(jīng)進(jìn)入了主動決策階段。

      其實(shí)預(yù)測和實(shí)時的發(fā)展順序不同的公司有所不同,只用歷史數(shù)據(jù)就可以做出預(yù)測。

      1.2 數(shù)據(jù)平臺定位

      數(shù)據(jù)平臺應(yīng)該屬于基礎(chǔ)架構(gòu)的重要環(huán)節(jié),曾經(jīng)互聯(lián)網(wǎng)行業(yè)內(nèi)有很多公司跟風(fēng)搭建了大數(shù)據(jù)集群后發(fā)現(xiàn)很難發(fā)揮真正價值,其實(shí)最重要的原因應(yīng)該是對數(shù)據(jù)使用的定位以及對數(shù)據(jù)平臺的定位問題。目前的數(shù)據(jù)平臺定位有以下幾點(diǎn):

      決策賦能

      為決策層賦能,決策層通過使用BI報(bào)表快速了解公司運(yùn)營情況,因?yàn)閿?shù)據(jù)不會說假話。

      業(yè)務(wù)數(shù)據(jù)分析/業(yè)務(wù)數(shù)據(jù)產(chǎn)品

      平臺可以提供Adhoc即時分析,幫助分析師快速分析業(yè)務(wù)、快速定位問題、快速反饋。

      計(jì)算存儲

      業(yè)務(wù)數(shù)據(jù)產(chǎn)品也可以充分利用平臺的計(jì)算存儲資源打造數(shù)據(jù)產(chǎn)品,如推薦、智能營銷等等。

      效率

      提升數(shù)據(jù)處理效率,從而節(jié)約數(shù)據(jù)挖掘/處理的時間成本。

      大部分公司早期人員架構(gòu)如下圖:

      運(yùn)營、營銷以及決策層直接使用平臺,大部分就是直接查看BI報(bào)表。業(yè)務(wù)分析師梳理完業(yè)務(wù)需求會把需求提供給數(shù)據(jù)倉庫工程師,然后專業(yè)的數(shù)據(jù)倉庫工程師會把新的需求加入已存在的公司級別的數(shù)據(jù)倉庫之中。數(shù)據(jù)工程團(tuán)隊(duì)主要負(fù)責(zé)運(yùn)維集群。

      1.3 初期架構(gòu)的缺點(diǎn)

      初期為什么是這樣的架構(gòu)這里就不做過多描述了,我們直接說一下它的缺點(diǎn)。

      當(dāng)決策層使用報(bào)表時發(fā)現(xiàn)總是慢了一拍,總會有新的需求出來。原因很簡單:其實(shí)互聯(lián)網(wǎng)公司的業(yè)務(wù)并不像傳統(tǒng)行業(yè)(如銀行、保險等)的業(yè)務(wù)那么穩(wěn)定,因?yàn)榛ヂ?lián)網(wǎng)公司的發(fā)展比較快,業(yè)務(wù)更新迭代的也很快。

      業(yè)務(wù)分析總有各種臨時的需求,原因和1類似。

      數(shù)據(jù)倉庫工程師累成狗。數(shù)據(jù)倉庫龐大笨重,很難靈活的運(yùn)作,總是牽一發(fā)而動全身。

      集群作業(yè)運(yùn)維困難,作業(yè)間耦合性太大,例如:A業(yè)務(wù)的表a 沒跑出來直接影響了整個公司的所有作業(yè)。

      1.4 常見解決方案

      相信這些頭疼的問題很多公司都遇到過,解決方式應(yīng)該也是類似的。大體如下:

      搭建產(chǎn)品化的數(shù)據(jù)服務(wù)平臺。

      數(shù)據(jù)倉庫能量轉(zhuǎn)移到更加基礎(chǔ)更加底層的數(shù)據(jù)問題,如數(shù)據(jù)質(zhì)量問題、數(shù)據(jù)使用規(guī)范、數(shù)據(jù)安全問題、模型架構(gòu)設(shè)計(jì)等。

      業(yè)務(wù)分析師直接利用平臺搭建業(yè)務(wù)數(shù)據(jù)集市,提高敏捷性和專用性。

      數(shù)據(jù)工程主要職責(zé)不再是運(yùn)維集群,而是搭建數(shù)據(jù)服務(wù)平臺和構(gòu)建業(yè)務(wù)數(shù)據(jù)產(chǎn)品。

      這樣做的好處是:

      解決了數(shù)據(jù)倉庫的瓶頸問題。

      讓最熟悉自己數(shù)據(jù)的人自己搭建數(shù)據(jù)集市,效率更高。

      業(yè)務(wù)數(shù)據(jù)產(chǎn)品可以直接使用數(shù)據(jù)服務(wù)平臺提高效率,縮減公司成本。

      二、宜人貸數(shù)據(jù)平臺Genie架構(gòu)及特點(diǎn)

      2.1 Genie架構(gòu)

      宜人貸屬于互聯(lián)網(wǎng)金融公司,由于帶有金融屬性,所以對平臺的安全性、穩(wěn)定性、數(shù)據(jù)質(zhì)量等方面的要求要高于一般的互聯(lián)網(wǎng)公司。目前在宜人貸的數(shù)據(jù)結(jié)構(gòu)中,數(shù)據(jù)總量為PB級別,每天增量為TB級別。除了結(jié)構(gòu)化的數(shù)據(jù)之外,還有日志、語音等數(shù)據(jù)。數(shù)據(jù)應(yīng)用類型分為運(yùn)營和營銷兩大類,如智能電銷、智能營銷等。數(shù)據(jù)服務(wù)平臺需要保證每天幾千個批量作業(yè)按時運(yùn)行,并保證數(shù)據(jù)產(chǎn)品對數(shù)據(jù)實(shí)時計(jì)算的效率以及準(zhǔn)確性,與此同時,又要保證每天大量Adhoc查詢的實(shí)效性。

      以上是平臺底層技術(shù)架構(gòu)圖,整體是一個Lambda架構(gòu),Batch layer 負(fù)責(zé)計(jì)算t+1的數(shù)據(jù),大部分定時報(bào)表和數(shù)據(jù)倉庫/集市的主要任務(wù)在這一層處理。Speed layer 負(fù)責(zé)計(jì)算實(shí)時增量數(shù)據(jù),實(shí)時數(shù)倉,增量實(shí)時數(shù)據(jù)同步,數(shù)據(jù)產(chǎn)品等主要使用這一層的數(shù)據(jù)。Batch layer 采用sqoop定時同步到HDFS集群里,然后用Hive和Spark SQL 進(jìn)行計(jì)算。Batch layer的穩(wěn)定性要比運(yùn)算速度重要,所以我們主要針對穩(wěn)定性做了優(yōu)化。Batch layer的輸出就是Batch view。Speed layer 相對Batch layer 來說數(shù)據(jù)鏈路會長一些,架構(gòu)也相對復(fù)雜。

      DBus和Wormhole是宜信的開源項(xiàng)目,主要用來做數(shù)據(jù)管道。DBus的基本原理是通過讀取數(shù)據(jù)庫的binlog來進(jìn)行實(shí)時的增量數(shù)據(jù)同步,主要解決的問題是無侵入式的進(jìn)行增量數(shù)據(jù)同步。當(dāng)然也有其他方案,比如卡時間戳,增加trigger等,也能實(shí)現(xiàn)增量數(shù)據(jù)同步,但是對業(yè)務(wù)庫的壓力和侵入性太大。Wormhole的基本原理是消費(fèi)DBus同步過來的增量數(shù)據(jù)并把這些數(shù)據(jù)同步給不同的存儲,支持同構(gòu)和異構(gòu)的同步方式。

      總體來說Speed layer 會把數(shù)據(jù)同步到我們的各種分布式數(shù)據(jù)庫中,這些分布式數(shù)據(jù)庫統(tǒng)一稱為Speed view 。然后我們把Batch和Speed的元數(shù)據(jù)統(tǒng)一抽象出來一層叫Service layer。Service layer 通過NDB對外統(tǒng)一提供服務(wù)。因?yàn)閿?shù)據(jù)有兩個主要屬性,即data=when+what。在when這個時間維度上來說數(shù)據(jù)是不可變的,增刪改其實(shí)都是產(chǎn)生了新的數(shù)據(jù)。在平時的數(shù)據(jù)使用中我們常常只關(guān)注what的屬性,其實(shí)when+what才能確定data的唯一不可變特性。所以按照時間這個維度我們可以對數(shù)據(jù)進(jìn)行時間維度的抽象劃分,即t+1的數(shù)據(jù)在Batch view,t+0的數(shù)據(jù)在Speed view 。這是標(biāo)準(zhǔn)Lambda架構(gòu)的意圖:把離線和實(shí)時計(jì)算分開。但是我們的Lambda架構(gòu)有些許差異(此處不做過多表述)。

      要知道集群資源是有限的,把離線和實(shí)時等計(jì)算架構(gòu)放在一個集群內(nèi)必然會出現(xiàn)資源搶占的問題。因?yàn)槊總€公司的計(jì)算存儲方案可能不一樣,我在這里僅僅以我們的方案為例,希望能起到拋磚引玉的作用。

      要解決搶占問題,首先讓我們清晰的認(rèn)識一下?lián)屨肌挠脩羰褂镁S度上來說,如果平臺是多租戶的,那么租戶之間便存在搶占的可能性;從數(shù)據(jù)架構(gòu)上來說,如果離線計(jì)算和實(shí)時計(jì)算沒有分開部署,那么也存在搶占的可能性。需要強(qiáng)調(diào)的是搶占不僅僅是指cpu和內(nèi)存資源的搶占,網(wǎng)絡(luò)io 磁盤的io也是會搶占的。

      目前開源市場上的資源調(diào)度系統(tǒng),如yarn,mesos等資源隔離做的都不是很成熟,只能在cpu和內(nèi)存上做一些輕度隔離(hadoop3.0的 yarn 已經(jīng)加入了磁盤和網(wǎng)絡(luò)io的隔離機(jī)制)。因?yàn)槲覀兊墓ぷ骰旧鲜恰癳verything on yarn”,所以我們對yarn進(jìn)行了修改。對yarn的修改和官方的解決方案類似利用cgroup來實(shí)現(xiàn)。對與服務(wù)進(jìn)程間也要用cgroup做好隔離,如datanode nodemanager在一臺機(jī)器上的時候。

      上圖很好的說明了數(shù)據(jù)平臺Genie的組成以及數(shù)據(jù)使用流程。先說數(shù)據(jù)使用流程,首先所有數(shù)據(jù)(包括結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù))都會在數(shù)據(jù)倉庫中進(jìn)行標(biāo)準(zhǔn)化,如:單位統(tǒng)一,字典統(tǒng)一,數(shù)據(jù)格式統(tǒng)一,數(shù)據(jù)命名統(tǒng)一等等。統(tǒng)一規(guī)范的數(shù)據(jù)會直接或者間接的被數(shù)據(jù)集市使用,作為數(shù)據(jù)集市的入口。數(shù)據(jù)集市之間業(yè)務(wù)耦合性很低,所以數(shù)據(jù)耦合性也就低,這樣可以很好的避免整體作業(yè)的耦合度。各個業(yè)務(wù)的數(shù)據(jù)應(yīng)用也會直接使用自己的數(shù)據(jù)集市。

      2.2 Genie的功能模塊

      再說Genie的組成,Genie整體分七個子系統(tǒng)。

      meta data: 元數(shù)據(jù)的管理是核心中的核心,元數(shù)據(jù)服務(wù)化是做數(shù)據(jù)平臺的基礎(chǔ)中的基礎(chǔ),幾乎所有的需求功能都會依賴它來開展。

      Authority: 統(tǒng)一權(quán)限切面,統(tǒng)一管理,靈活配置。此處權(quán)限包括數(shù)據(jù)的訪問權(quán)限配置。

      Monitor: 監(jiān)控,按照租戶維度統(tǒng)計(jì)集群使用情況等。

      Triangle: 自研發(fā)調(diào)度系統(tǒng),分布式、服務(wù)化、高可用、使用友好。如上圖是Triangle調(diào)度系統(tǒng)的架構(gòu)圖。整體是一個Master Slave的架構(gòu),Job Runtime Dir 概念是指當(dāng)前Job的運(yùn)行所需要的環(huán)境完整打包提供,如Python 環(huán)境。

      Data Dev: 上圖是一個數(shù)據(jù)開發(fā)流程。數(shù)據(jù)開發(fā)平臺—開發(fā)測試上線的一站式平臺,安全、快捷、支持SQL, Python, Spark Shell。

      Data Pipeline:數(shù)據(jù)管道,用于離線數(shù)據(jù)管道配置管理和實(shí)時數(shù)據(jù)管道配置管理。可以實(shí)現(xiàn)1分鐘完成離線入倉配置和實(shí)時入倉配置。

      Data Knowledge:數(shù)據(jù)知識,用于血緣關(guān)系查詢、數(shù)據(jù)指標(biāo)管理。

      三、總結(jié)

      沒有最好的架構(gòu),只有更適合的架構(gòu) 。每個公司的情況不一樣,業(yè)務(wù)模式不一樣,雖然都是ETL數(shù)據(jù)處理,都是數(shù)據(jù)倉庫,都是機(jī)器學(xué)習(xí),但是有多少需求是數(shù)據(jù)倉庫?機(jī)器學(xué)習(xí)的應(yīng)用場景是什么?ETL實(shí)時性要求是怎么樣的?這些細(xì)節(jié)都有很多復(fù)雜的客觀條件約束。

      在技術(shù)架構(gòu)的選型中有兩個至關(guān)重要的因素,即場景和成本。簡單來說,場景就是要做什么,要低成本的方式實(shí)現(xiàn),不要過度設(shè)計(jì)。如果場景復(fù)雜,那么可以從多維度抽象細(xì)分,比如:時間維度(歷史待解決問題,目前的問題,未來可能面臨的問題)。同理,就成本而言,應(yīng)該考慮的維度也很多,如:開發(fā)周期、運(yùn)維復(fù)雜度、穩(wěn)定性、現(xiàn)有人員的技術(shù)棧等等。

      在下篇中,我們會從“實(shí)時數(shù)據(jù)倉庫技術(shù)細(xì)節(jié)”和“數(shù)據(jù)平臺功能簡介”兩方面繼續(xù)為大家解讀宜人貸的PaaS數(shù)據(jù)服務(wù)平臺Genie,敬請大家持續(xù)關(guān)注。

      下篇:技術(shù)細(xì)節(jié)及功能

      導(dǎo)讀:在上篇中,我們已經(jīng)簡單了解了宜人貸數(shù)據(jù)平臺Genie的特點(diǎn),并且掌握了數(shù)據(jù)平臺發(fā)展歷程的一些信息。本文作為下篇,首先我們會在其中重點(diǎn)講解實(shí)時數(shù)據(jù)倉庫的技術(shù)細(xì)節(jié),之后介紹數(shù)據(jù)平臺的功能。下面我們一起來了解一下這些知識吧~

      四、實(shí)時數(shù)據(jù)倉庫技術(shù)細(xì)節(jié)

      離線數(shù)據(jù)倉庫是t+1的數(shù)據(jù),也就是說數(shù)據(jù)時效性是處理前一天的數(shù)據(jù)。一般來說離線方案同步數(shù)據(jù)的策略是每天定時同步一次數(shù)據(jù),而且基本是同步一次全量數(shù)據(jù),也就是說每天一個全量數(shù)據(jù)(業(yè)務(wù)庫)的鏡像。

      除了時效性,還有一點(diǎn)就是鏡像的數(shù)據(jù)狀態(tài)只有一個,所以想知道某個值的歷史變化過程,就需要走拉鏈表(非常耗時耗資源)。實(shí)時數(shù)據(jù)倉庫的實(shí)現(xiàn)方式很多,但是大多都是殊途同歸。

      實(shí)時數(shù)倉有兩點(diǎn)特點(diǎn):第一訪問實(shí)時數(shù)據(jù);第二結(jié)果能近似實(shí)時的返回。當(dāng)然離線倉庫如果優(yōu)化的好,完成第二點(diǎn)也是可以實(shí)現(xiàn)的。思考兩個問題,為什么要用實(shí)時數(shù)據(jù)?為什么要有實(shí)時數(shù)據(jù)倉庫?

      近幾年數(shù)據(jù)工程師們在如何提高數(shù)據(jù)時效性上做了非常多的努力和嘗試。推動這些實(shí)時數(shù)據(jù)同步、處理技術(shù)發(fā)展的當(dāng)然還是場景與需求。中國的大互聯(lián)網(wǎng)環(huán)境競爭非常激烈,如何提高用戶轉(zhuǎn)化率變得尤為關(guān)鍵。

      用戶畫像、推薦系統(tǒng)、漏斗分析、智能營銷等等數(shù)據(jù)相關(guān)的產(chǎn)品都離不開實(shí)時數(shù)據(jù)的處理與計(jì)算。

      獲取實(shí)時數(shù)據(jù)最直接的方式是直連業(yè)務(wù)庫,優(yōu)勢明顯,缺點(diǎn)也很明顯,有些邏輯需要跨庫多源查詢關(guān)聯(lián)的時候直接連業(yè)務(wù)庫就行不通了。所以首先需要把多個源頭的數(shù)據(jù)集中同步起來,這個同步過程就是一個非常具有挑戰(zhàn)的地方,要考慮數(shù)據(jù)的時效性,對業(yè)務(wù)系統(tǒng)的侵入性,數(shù)據(jù)的安全性和數(shù)據(jù)的一致性等等諸多難題。

      所以我們需要一個同步數(shù)據(jù)的工具,它需要有以下幾個特點(diǎn):

      能夠近似實(shí)時的同步生產(chǎn)庫的數(shù)據(jù)和日志數(shù)據(jù)

      和生產(chǎn)庫還有應(yīng)用服務(wù)器完全解耦

      同步出來的數(shù)據(jù)可以分發(fā)到其他的存儲

      整個同步過程保證數(shù)據(jù)不丟失,或者說可以按照任意時間批量重新同步

      宜信敏捷大數(shù)據(jù)團(tuán)隊(duì)開發(fā)的DBus和Wormhole能很好的滿足以上4點(diǎn)。

      DBus利用數(shù)據(jù)庫的binlog進(jìn)行數(shù)據(jù)抽取,binlog一般延遲是比較低的,這樣既保證了實(shí)時的特性,也保證了對生產(chǎn)庫的零侵入。

      其實(shí)利用日志來構(gòu)建一個健壯的數(shù)據(jù)系統(tǒng)是一個很常見的方案。Hbase利用wal來保證可靠性,MySQL主備同步使用binlog,分布式一致性算法Raft利用日志保證一致性,還有Apache Kafka也是利用了日志來實(shí)現(xiàn)的。

      DBus很好的利用了數(shù)據(jù)庫的binlog日志并且進(jìn)行統(tǒng)一的schema轉(zhuǎn)化,形成了自己日志標(biāo)準(zhǔn),以便支持多種數(shù)據(jù)源。DBus的定義是一個商業(yè)級別的數(shù)據(jù)總線系統(tǒng)。它可以實(shí)時的將數(shù)據(jù)從數(shù)據(jù)源抽取發(fā)送給Kafka。

      Wormhole負(fù)責(zé)將數(shù)據(jù)同步寫入其他的存儲之中。Kafka就成了一個真正意義上的數(shù)據(jù)總線,Wormhole支持sink端按照任意時間開始消費(fèi)Kafka中的數(shù)據(jù),這樣也就能很好的進(jìn)行數(shù)據(jù)回溯。

      Genie的實(shí)時架構(gòu)如下:

      有了DBus和Wormhole我們可以很輕松的把數(shù)據(jù)從生產(chǎn)備庫實(shí)時的同步到我們的Cassandra集群,然后再同步Presto,為用戶提供SQL語言計(jì)算。

      通過這個簡單的架構(gòu)我們高效的完成了實(shí)時數(shù)據(jù)倉庫的搭建,并且實(shí)現(xiàn)了公司的實(shí)時報(bào)表平臺和一些實(shí)時營銷類的數(shù)據(jù)產(chǎn)品。

      對于為什么會使用Presto我可以給出以下的答案:

      Presto擁有交互級別的數(shù)據(jù)計(jì)算查詢體驗(yàn)

      Presto支持水平擴(kuò)展,presto on yarn (slider)

      宜人貸PaaS數(shù)據(jù)服務(wù)平臺Genie:技術(shù)架構(gòu)及功能

      支持標(biāo)準(zhǔn)SQL,并且方便擴(kuò)展

      facebook, uber, netflix生產(chǎn)使用

      開源語言java符合我們團(tuán)隊(duì)技術(shù)棧, 自定義函數(shù)

      支持多數(shù)據(jù)源關(guān)聯(lián)join 邏輯下推,Presto 可以接Cassandra, Hdfs等等

      pipelined executions - 減少了不必要的I/O開銷

      Presto 是m/s架構(gòu),整體細(xì)節(jié)不多說了。Presto有個數(shù)據(jù)存儲抽象層,可以支持不同的數(shù)據(jù)存儲上執(zhí)行SQL計(jì)算。Presto提供了meta data api,data location api, data stream api,支持自開發(fā)可插拔的connector。

      在我們的方案中是Presto on Cassandra的,因?yàn)镃assandra相對于Hbase來說可用性更好一些,比較適合adhoc查詢場景。Hbase CAP中偏向c,Cassandra CAP中偏向a。Cassandra是一個非常優(yōu)秀的數(shù)據(jù)庫,方便易用,底層使用Log-Structured Merge-Tree 做存儲索引的核心數(shù)據(jù)結(jié)構(gòu)。

      五、整體數(shù)據(jù)處理架構(gòu)

      綜上我大概的介紹了宜人貸的實(shí)時數(shù)據(jù)處理架構(gòu),下面我們看一下整體的數(shù)據(jù)處理架構(gòu)。

      整體Lambda架構(gòu)speed層利用DBus和Wormhole組裝成了一套實(shí)時數(shù)據(jù)總線,speedlayer可以直接支撐實(shí)時數(shù)據(jù)產(chǎn)品。DataLake是一個抽象的概念實(shí)現(xiàn)方式,我們主要是利用Hdfs + Cassandra存儲數(shù)據(jù),計(jì)算引擎主要以Hive 和Presto為主,再通過平臺統(tǒng)一的metadata對元數(shù)據(jù)整合提供,這樣就實(shí)現(xiàn)了一個完整的DataLake。DataLake主要的應(yīng)用場景是高級靈活的分析,查詢場景如 ml 。

      DataLake和數(shù)據(jù)倉庫的區(qū)別是,DataLake更加敏捷靈活,側(cè)重?cái)?shù)據(jù)的獲取,數(shù)據(jù)倉庫則側(cè)重于標(biāo)準(zhǔn)、管理、安全和快速索引。

      六、數(shù)據(jù)平臺Genie的功能模塊

      整個Genie數(shù)據(jù)服務(wù)平臺由7個大的子平臺模塊組成:

      數(shù)據(jù)查詢

      數(shù)據(jù)知識

      實(shí)時報(bào)表

      數(shù)據(jù)開發(fā)

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

      權(quán)限管理

      集群監(jiān)控管理

      下面我們來介紹一下其中的幾個模塊。

      6.1 數(shù)據(jù)查詢模塊

      用戶可以查詢數(shù)據(jù)倉庫、數(shù)據(jù)集市、實(shí)時數(shù)據(jù)倉庫的數(shù)據(jù)

      通過對SQL的解析來實(shí)現(xiàn)細(xì)粒度的權(quán)限管理

      提供多種查詢引擎

      數(shù)據(jù)導(dǎo)出

      6.2 數(shù)據(jù)知識模塊

      元數(shù)據(jù)監(jiān)控管理

      對全公司的元數(shù)據(jù)提供管理查詢功能

      可以監(jiān)控元數(shù)據(jù)變更并預(yù)警郵件

      血緣分析查詢引擎

      SQL分析引擎

      對倉庫所有的作業(yè)/表/字段進(jìn)行分析

      提供血緣分析/影響分析

      6.3 數(shù)據(jù)報(bào)表模塊

      實(shí)時數(shù)據(jù)倉庫

      Presto on Cassandra直連Presto

      數(shù)百張表,實(shí)時同步(DBus+WHurl)

      達(dá)芬奇報(bào)表平臺 (達(dá)芬奇url)

      近千張報(bào)表全公司已使用

      6.4 數(shù)據(jù)開發(fā)模塊

      數(shù)據(jù)程序設(shè)計(jì) Genie-ide

      提供Genie-ide進(jìn)行數(shù)據(jù)程序的開發(fā)

      提供網(wǎng)盤進(jìn)行腳本保存管理

      可以實(shí)時測試/上線

      數(shù)據(jù)管道

      一鍵離線入倉

      一鍵實(shí)時入倉

      6.5 作業(yè)調(diào)度Triangle模塊

      微服務(wù)架構(gòu)設(shè)計(jì)每個模塊均為一個服務(wù)

      提供restful接口可以方便二次開發(fā)與其它平臺融合

      提供健康監(jiān)控作業(yè)管理后臺

      提供公共作業(yè)和私有作業(yè)

      作業(yè)流之間邏輯隔離

      并發(fā)控制,失敗策略管理

      七、數(shù)據(jù)平臺Genie的功能

      以上是對數(shù)據(jù)平臺Genie模塊功能的簡介,那Genie平臺具體可以做哪些事情呢?

      首先,它可以實(shí)現(xiàn)離線入倉,實(shí)時入倉 1分鐘內(nèi)配置完成(數(shù)據(jù)倉庫,數(shù)據(jù)集市);

      其次,實(shí)時入倉后可直接配置實(shí)時報(bào)表展示推送(BI分析);

      第三,實(shí)時數(shù)據(jù)支持多種含有權(quán)限安全的同構(gòu)對接方式:api ,kafka, jdbc(業(yè)務(wù)數(shù)據(jù)產(chǎn)品);

      第四,一站式數(shù)據(jù)開發(fā)支持hive,spark-sql,presto on cassandra,python(數(shù)據(jù)開發(fā));

      第五,服務(wù)化的調(diào)度系統(tǒng)支持外部系統(tǒng)接入(基礎(chǔ)技術(shù)組件)。

      參考文獻(xiàn):

      https://www.confluent.io/blog/using-logs-to-build-a-solid-data-infrastructure-or-why-dual-writes-are-a-bad-idea/

      http://thesecretlivesofdata.com/raft/

      https://engineering.linkedin.com/data-replication/open-sourcing-databus-linkedins-low-latency-change-data-capture-system

      https://yq.aliyun.com/articles/195388

      https://www.cnblogs.com/tgzhu/p/6033373.html

      來源:宜信技術(shù)學(xué)院

      數(shù)據(jù)庫 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS)

      版權(quán)聲明:本文內(nèi)容由網(wǎng)絡(luò)用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

      版權(quán)聲明:本文內(nèi)容由網(wǎng)絡(luò)用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實(shí)后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

      上一篇:excel怎樣制作成虛線邊框
      下一篇:在線瑕疵檢測設(shè)備能夠及時準(zhǔn)確地檢測出產(chǎn)品的瑕疵
      相關(guān)文章
      亚洲国产精品久久久久久| 亚洲国产成人综合| 亚洲国产精品午夜电影| 中文字幕亚洲不卡在线亚瑟| 亚洲国产天堂久久综合| 国产精品亚洲综合一区在线观看| 亚洲免费网站观看视频| 亚洲精品无码久久久久APP| 亚洲乱码日产精品一二三| 亚洲高清一区二区三区电影| 亚洲精品9999久久久久无码| 亚洲AV无码专区在线观看成人| 亚洲欧美国产国产一区二区三区| 亚洲精品乱码久久久久蜜桃| 亚洲另类自拍丝袜第五页| 亚洲av中文无码乱人伦在线观看| 亚洲第一综合天堂另类专| www亚洲精品久久久乳| 亚洲av无码天堂一区二区三区 | tom影院亚洲国产一区二区| 亚洲Av高清一区二区三区| 亚洲丰满熟女一区二区v| 亚洲综合色区中文字幕| 亚洲一区二区三区成人网站 | 国产亚洲综合色就色| 亚洲av永久无码精品漫画| 无码乱人伦一区二区亚洲| 久久精品国产亚洲77777| 亚洲国产日韩女人aaaaaa毛片在线| 亚洲人成毛片线播放| 亚洲一本一道一区二区三区| 国产亚洲一卡2卡3卡4卡新区| 国产成人综合亚洲一区| 亚洲无码高清在线观看| 久久亚洲精品视频| 亚洲高清日韩精品第一区| 2017亚洲男人天堂一| 在线观看亚洲视频| 国产亚洲情侣一区二区无码AV| 国产V亚洲V天堂无码| 亚洲高清无在码在线电影不卡 |