本篇內(nèi)容主要講解“Genie的特點是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“Genie的特點是什么”吧!

為開平等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及開平網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、開平網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

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

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

• 合理提高數(shù)據(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ù)走進“尋常百姓家”的起點。Hadoop 的組件均可在普通的廉價機器上運行，加上其代碼是開源的，因此得到了眾多公司的熱捧。那么一開始這些公司都用它來做什么呢？

        答案是數(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這三個組件組成，因為這個是搭建數(shù)據(jù)倉庫最廉價高效的方式。此時數(shù)據(jù)倉庫只能回答過去發(fā)生了什么（離線階段），因為Sqoop離線抽取一般采用的t+1快照方案，也就是說只有昨天的數(shù)據(jù)。

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

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

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

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

        數(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ā)揮真正價值，其實最重要的原因應(yīng)該是對數(shù)據(jù)使用的定位以及對數(shù)據(jù)平臺的定位問題。目前的數(shù)據(jù)平臺定位有以下幾點：

• 決策賦能

為決策層賦能，決策層通過使用BI報表快速了解公司運營情況，因為數(shù)據(jù)不會說假話。

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

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

• 計算存儲

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

• 效率

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣做的好處是：

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

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

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

        宜人貸屬于互聯(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)用類型分為運營和營銷兩大類，如智能電銷、智能營銷等。數(shù)據(jù)服務(wù)平臺需要保證每天幾千個批量作業(yè)按時運行，并保證數(shù)據(jù)產(chǎn)品對數(shù)據(jù)實時計算的效率以及準確性，與此同時，又要保證每天大量Adhoc查詢的實效性。

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

        DBus和Wormhole是宜信的開源項目，主要用來做數(shù)據(jù)管道。DBus的基本原理是通過讀取數(shù)據(jù)庫的binlog來進行實時的增量數(shù)據(jù)同步，主要解決的問題是無侵入式的進行增量數(shù)據(jù)同步。當(dāng)然也有其他方案，比如卡時間戳，增加trigger等，也能實現(xiàn)增量數(shù)據(jù)同步，但是對業(yè)務(wù)庫的壓力和侵入性太大。Wormhole的基本原理是消費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ù)。因為數(shù)據(jù)有兩個主要屬性，即data=when+what。在when這個時間維度上來說數(shù)據(jù)是不可變的，增刪改其實都是產(chǎn)生了新的數(shù)據(jù)。在平時的數(shù)據(jù)使用中我們常常只關(guān)注what的屬性，其實when+what才能確定data的唯一不可變特性。所以按照時間這個維度我們可以對數(shù)據(jù)進行時間維度的抽象劃分，即t+1的數(shù)據(jù)在Batch view，t+0的數(shù)據(jù)在Speed view 。這是標(biāo)準Lambda架構(gòu)的意圖：把離線和實時計算分開。但是我們的Lambda架構(gòu)有些許差異（此處不做過多表述）。

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

        要解決搶占問題，首先讓我們清晰的認識一下?lián)屨肌挠脩羰褂镁S度上來說，如果平臺是多租戶的，那么租戶之間便存在搶占的可能性；從數(shù)據(jù)架構(gòu)上來說，如果離線計算和實時計算沒有分開部署，那么也存在搶占的可能性。需要強調(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的隔離機制）。因為我們的工作基本上是“everything on yarn”，所以我們對yarn進行了修改。對yarn的修改和官方的解決方案類似利用cgroup來實現(xiàn)。對與服務(wù)進程間也要用cgroup做好隔離，如datanode nodemanager在一臺機器上的時候。

        上圖很好的說明了數(shù)據(jù)平臺Genie的組成以及數(shù)據(jù)使用流程。先說數(shù)據(jù)使用流程，首先所有數(shù)據(jù)（包括結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)）都會在數(shù)據(jù)倉庫中進行標(biāo)準化，如：單位統(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ù)集市。

        再說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)計集群使用情況等。

• Triangle: 自研發(fā)調(diào)度系統(tǒng)，分布式、服務(wù)化、高可用、使用友好。如上圖是Triangle調(diào)度系統(tǒng)的架構(gòu)圖。整體是一個Master Slave的架構(gòu)，Job Runtime Dir 概念是指當(dāng)前Job的運行所需要的環(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ù)據(jù)管道配置管理?？梢詫崿F(xiàn)1分鐘完成離線入倉配置和實時入倉配置。

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

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

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

到此，相信大家對“Genie的特點是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！