宜人貸 PaaS 資料服務平台Genie 簡介（一）

目錄

1. 資料平台的發展簡介
2. 宜人貸資料平台特點介紹
3. 資料平台功能簡介

随着資料時代的到來，資料量和資料複雜度的增加推動了資料工程領域的快速發展。為了滿足各類資料擷取/計算等需求業内湧現出了諸多解決方案。

但大部分方案遵循以下原則：

1 降低資料處理成本

2 合理提高資料使用/計算效率

3 提供統一的程式設計範式

對于宜人貸的資料服務平台我們也是遵循的這3個原則。本人有幸親身經曆了宜人貸資料平台的整個發展過程，縱觀宜人貸和業内，可以說宜人貸資料平台的發展是工業界資料平台發展的縮影。

Google 的3篇論文和Apache Hadoop 開源生态圈的釋出應該是大資料處理技術走進’尋常百姓家’的起點。Hadoop 的元件均可運作在普通的廉價機器加上其代碼又是開源的，是以得到了衆多公司的熱捧。

那麼一開始這些公司都用它來做什麼呢？答案是資料倉庫。

是以早期的資料平台大概的架構都是由sqoop+hdfs+hive這三個元件組成，因為這個是搭建資料倉庫最廉價高效的方式。此時資料倉庫隻能回答過去發生了什麼（離線階段）因為sqoop離線抽取一般采用的t+1快照方案，也就是說隻有昨天的資料。

緊接着由于對資料實時性的需求提高了，需要實時做增量資料的關聯聚合等複雜運算，這個時候資料平台就會加入分布式流計算的架構如：Strom ，Flink， Spark Streaming 等。此時的資料倉庫可以回答的是什麼正在發生（實時階段）。

由于離線資料處理流程（如：sqoop+hdfs+hive）和實時資料處理流程（如：binlog+spark steaming+hbase）兩套流程計算邏輯耦合較大，并且通過組合才能支援實時全量的資料分析，是以就生出了很多架構 如早期的lambda，kappa等。此時曆史資料和實時資料結合資料倉庫可以回答什麼終将會發生（預測階段）。

資料平台發展至此已經不再是一個資料倉庫就能解釋的了，它與各類業務部門緊密合作（如營銷，電銷，營運）打造出諸多資料産品。此時資料倉庫（資料平台）已經進入了主動決策階段。

其實預測和實時的發展順序不同的公司有所不同，隻用曆史資料就可以做出預測。

資料平台應該屬于基礎架構的重要環節，曾經網際網路行業内有很多公司跟風搭建了大資料叢集後發現很難發揮真正價值，其實最重要的原因應該是對資料使用的定位以及對資料平台的定位問題。目前的資料平台的定位有以下幾點：

1: 決策賦能

為決策層賦能，決策層通過使用bi 報表 快速了解公司營運情況，因為資料不會說假話。

2: 業務資料分析/業務資料産品

平台可以提供adhoc即時分析幫助分析師快速分析業務快速定位問題快速回報。

3：計算存儲

業務資料産品也可以充分利用平台的計算存儲資源打造資料産品，如 推薦，智能營銷等等

4: 效率

提升資料處理效率，進而節約資料挖掘/處理的時間成本

人員架構方面早期大部分公司如下圖：

營運，營銷 以及決策層直接使用平台其實大部分就是直接檢視bi 報表。業務分析師梳理完業務需求會把需求提供給資料倉庫工程師，然後專業的資料倉工程師會把新的需求加入已存在的公司級别的資料倉庫之中。資料工程團隊主要負責運維叢集。初期為什麼是這樣的架構這裡就不做過多描述了，我直接說它的缺點。1，當決策層使用報表時發現總是慢了一拍，總會有新的需求出來，原因其實很簡單其實網際網路公司的業務并不像傳統行業（如銀行保險等）的業務那麼穩定。因為網際網路公司的發展比較快業務更新疊代的也很快。2，業務分析總有各種臨時的需求，原因和1類似。3，資料倉庫工程師累成狗。因為有一個龐大笨重的資料倉庫，很難靈活，牽一發動全身。4，叢集作業運維困難，作業間耦合性太大，例如：A業務的表a 沒跑出來直接影響了整個公司的所有的作業。

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

1: 搭建産品化的資料服務平台

2: 資料倉庫能量轉移到更加基礎更加底層的資料問題，如資料品質問題，資料使用規範，資料安全問題，模型架構設計

3: 業務分析師直接利用平台搭建業務資料集市，提高靈活性和專用性

4: 資料工程主要職責不再是運維叢集，而是搭建資料服務平台和建構業務資料産品

這樣做的好處是：

1: 解決了資料倉庫的瓶頸問題

2: 讓最熟悉自己資料的人自己搭建資料集市 效率更高

3: 業務資料産品可以直接使用資料服務平台提高效率，縮減公司成本。

宜人貸屬于網際網路金融公司，由于是有金融屬性所有對平台的安全性，穩定性，資料品質等方面要高于一般的網際網路公司。目前宜人貸的資料結構資料總量PB級别，每天增量TB級别。除了結構化的資料之外還有日志，語音等資料。資料應用類型分營運和營銷兩大類。如智能電銷，智能營銷等。資料服務平台需要保證每天幾千個批量作業按時運作和保證資料産品對資料實時計算的效率以及準确性，與此同時，又要保證每天大量的adhoc查詢的實效性。

以上是平台底層技術架構表示圖，整體是一個lambda架構，batch layer 負責計算t+1的資料，大部分定時報表和資料倉庫/集市的主要任務在這一層處理。speed layer 負責計算實時增量資料，實時數倉，增量實時資料同步，資料産品等主要使用這一層的資料。batch layer 采用sqoop定時同步到hdfs 叢集裡，然後用hive和spark sql 進行計算。batch layer的穩定性要比運算速度重要，是以我們主要針對穩定性做了優化。batch layer的輸出就是batch view。speed layer 相對batch layer 來說資料鍊路會長一些，架構也相對複雜。dbus和wormhole是宜信的開源項目，主要是用來做資料管道用的。dbus的基本原理是通過讀取資料庫的binlog來進行實時的增量資料同步。其實主要解決的問題是無侵入式的進行增量資料同步。當然也有其他的方案，比如 卡時間戳，增加trigger等 也能實作增量資料同步，但是對業務庫的壓力和侵入性太大。wormhole的基本原理是消費dbus同步過來的增量資料并把這些資料同步給不同的存儲，支援同構和異構的同步方式。總體來說speed layer 會把資料同步到我們的各種分布式資料庫中，這些分布式資料庫統一稱為 speed view 。然後我們把batch 和speed的中繼資料統一抽象出來一層叫service layer。service layer 通過ndb對外統一提供服務。因為資料有兩個主要屬性 data=when+what。 在when這個時間次元上來說資料是不可變的，增删改其實都是産生了新的資料。在平時的資料使用中我們常常隻關注what的屬性，其實when+what才能确定data的唯一不可變特性。是以按照時間這個次元我們可以對資料進行了時間的次元的抽象劃分，即 t+1的資料在batch view ，t+0的資料在speed view 。這是标準的lambda架構的意圖。把離線和實時計算分開。但是我們的lambda架構有些許差異（此處不做過多表述）。

要知道的是叢集資源是有限的，把離線和實時等計算架構放在一個叢集内必然會出現資源搶占的問題。因為每個公司的計算存儲方案可能不一樣，我在這裡僅僅以我們的方案為例 希望能夠做到抛磚引玉的作用。要解決搶占問題，首先讓我們清晰的認識一下搶占。從使用者使用次元上來說，如果平台是多租戶的也那麼租戶之間是存在搶占的可能性的；從資料架構上來說，如果離線計算和實時計算沒有分開部署那麼也是存在搶占的；需要強調的是搶占不僅僅是指cpu 和記憶體的資源，網絡io 磁盤io也是會搶占的。目前開源市場上的資源排程系統，如 yarn，mesos等 資源隔離做的都很不成熟，隻能在cpu和記憶體上做一些輕度隔離。（hadoop 3.0的 yarn 已經加入了磁盤和網絡io的隔離機制）。因我們主要做的事every thing on yarn 是以我們對yarn進行了修改。對yarn的修改和官方的解決方案類似利用cgroup來實作。對與服務程序間也要用cgroup做好隔離。如 datanode nodemanager在一台機器上的時候。

上圖很好的說明了宜人貸資料平台的組成以及資料使用過程。先說資料使用流程，首先所有資料包括結構化和非結構化的都會在資料倉庫中進行标準化 如：機關的統一，字典統一，資料格式統一，資料命名統一等等。統一規範的資料會直接或者間接的被資料集市使用，作為資料集市的入口。資料集市之間業務耦合性很低，是以資料耦合性也就低，這樣可以很好的避免整體作業的耦合度。各個業務的資料應用也會直接使用自己的資料集市。