導讀：本文將分上下篇講解宜人貸的PaaS數據服務平臺—Genie。在上篇中，我們首先簡單介紹一下數據平臺的發展歷程，然後介紹宜人貸數據平臺Genie的特點。在下篇中，我們重點講解實時數據倉庫發技術細節，並介紹數據平臺的功能。下面，讓我們先來了解數據平臺Genie的特點吧~
一、數據平臺的發展簡介
隨著數據時代的到來，數據量和數據複雜度的增加推動了數據工程領域的快速發展。為了滿足各類數據獲取/計算等需求，業內湧現出了諸多解決方案。但大部分方案都遵循以下原則：
- 降低數據處理成本
- 合理提高數據使用/計算效率
- 提供統一的編程範式
宜人貸的數據服務平臺也是遵循這三個原則。本人有幸親身經歷了宜人貸數據平臺Genie的整個發展過程，縱觀宜人貸和業內，可以說Genie的發展是工業界數據平臺發展的縮影。
Google 的三大論文和Apache Hadoop 開源生態圈的發佈應該是大數據處理技術走進“尋常百姓家”的起點。Hadoop 的組件均可在普通的廉價機器上運行，加上其代碼是開源的，因此得到了眾多公司的熱捧。那麼一開始這些公司都用它來做什麼呢？
答案是數據倉庫。
注：Google三大論文：
Bigtable: A Distributed Storage System for Structured Data
The Google File System
MapReduce: Simplefied Data Processing on Large Clusters
所以早期的數據平臺大概的架構都是由Sqoop+HDFS+Hive這三個組件組成，因為這個是搭建數據倉庫最廉價高效的方式。此時數據倉庫只能回答過去發生了什麼（離線階段），因為Sqoop離線抽取一般採用的t+1快照方案，也就是說只有昨天的數據。
緊接著由於對數據實時性的需求提高了，需要實時做增量數據的關聯聚合等複雜運算，這個時候數據平臺就會加入分佈式流計算的架構，如：Strom ，Flink， Spark Streaming 等。此時的數據倉庫可以回答的是正在發生什麼（實時階段）。
由於離線數據處理流程（如：Sqoop+HDFS+Hive）和實時數據處理流程（如：Binlog+Spark Steaming+Hbase）兩套流程計算邏輯耦合較大，並且通過組合才能支持實時全量的數據分析，所以就產生了很多架構，如早期的Lambda，Kappa等。此時歷史數據和實時數據結合數據倉庫可以回答什麼終將會發生（預測階段）。
數據平臺發展至此已經不再是一個數據倉庫就能解釋的了，它與各類業務部門緊密合作（如營銷、電銷、運營）打造出諸多數據產品。此時數據倉庫（數據平臺）已經進入了主
動決策階段。其實預測和實時的發展順序不同的公司有所不同，只用歷史數據就可以做出預測。
數據平臺應該屬於基礎架構的重要環節，曾經互聯網行業內有很多公司跟風搭建了大數據集群后發現很難發揮真正價值，其實最重要的原因應該是對數據使用的定位以及對數據平臺的定位問題。目前的數據平臺定位有以下幾點：
- 決策賦能
為決策層賦能，決策層通過使用BI報表快速瞭解公司運營情況，因為數據不會說假話。
- 業務數據分析/業務數據產品
平臺可以提供Adhoc即時分析，幫助分析師快速分析業務、快速定位問題、快速反饋。
- 計算存儲
業務數據產品也可以充分利用平臺的計算存儲資源打造數據產品，如推薦、智能營銷等等。
- 效率
提升數據處理效率，從而節約數據挖掘/處理的時間成本。
大部分公司早期人員架構如下圖：
運營、營銷以及決策層直接使用平臺，大部分就是直接查看BI報表。業務分析師梳理完業務需求會把需求提供給數據倉庫工程師，然後專業的數據倉庫工程師會把新的需求加入已存在的公司級別的數據倉庫之中。數據工程團隊主要負責運維集群。
初期為什麼是這樣的架構這裡就不做過多描述了，我們直接說一下它的缺點。
1. 當決策層使用報表時發現總是慢了一拍，總會有新的需求出來。原因很簡單：其實互聯網公司的業務並不像傳統行業（如銀行、保險等）的業務那麼穩定，因為互聯網公司的發展比較快，業務更新迭代的也很快。
2. 業務分析總有各種臨時的需求，原因和1類似。
3. 數據倉庫工程師累成狗。數據倉庫龐大笨重，很難靈活的運作，總是牽一髮而動全身。
4. 集群作業運維困難，作業間耦合性太大，例如：A業務的表a 沒跑出來直接影響了整個公司的所有作業。
相信這些頭疼的問題很多公司都遇到過，解決方式應該也是類似的。大體如下：
1. 搭建產品化的數據服務平臺。
2. 數據倉庫能量轉移到更加基礎更加底層的數據問題，如數據質量問題、數據使用規範、數據安全問題、模型架構設計等。
3. 業務分析師直接利用平臺搭建業務數據集市，提高敏捷性和專用性。
4. 數據工程主要職責不再是運維集群，而是搭建數據服務平臺和構建業務數據產品。
這樣做的好處是：
1. 解決了數據倉庫的瓶頸問題。
2. 讓最熟悉自己數據的人自己搭建數據集市，效率更高。
3. 業務數據產品可以直接使用數據服務平臺提高效率，縮減公司成本。
二、宜人貸數據平臺Genie特點介紹
宜人貸屬於互聯網金融公司，由於帶有金融屬性，所以對平臺的安全性、穩定性、數據質量等方面的要求要高於一般的互聯網公司。目前在宜人貸的數據結構中，數據總量為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和內存上做一些輕度隔離（hadoop3.0的 yarn 已經加入了磁盤和網絡io的隔離機制）。因為我們的工作基本上是“everything on yarn”，所以我們對yarn進行了修改。對yarn的修改和官方的解決方案類似利用cgroup來實現。對與服務進程間也要用cgroup做好隔離，如datanode nodemanager在一臺機器上的時候。
上圖很好的說明了數據平臺Genie的組成以及數據使用流程。先說數據使用流程，首先所有數據（包括結構化數據和非結構化數據）都會在數據倉庫中進行標準化，如：單位統一，字典統一，數據格式統一，數據命名統一等等。統一規範的數據會直接或者間接的被數據集市使用，作為數據集市的入口。數據集市之間業務耦合性很低，所以數據耦合性也就低，這樣可以很好的避免整體作業的耦合度。各個業務的數據應用也會直接使用自己的數據集市。
再說Genie的組成，Genie整體分七個子系統。
meta data: 元數據的管理是核心中的核心，元數據服務化是做數據平臺的基礎中的基礎，幾乎所有的需求功能都會依賴它來開展。
Authority: 統一權限切面，統一管理，靈活配置。此處權限包括數據的訪問權限配置。
Monitor: 監控，按照租戶維度統計集群使用情況等。
Triangle: 自研發調度系統，分佈式、服務化、高可用、使用友好。如上圖是Triangle調度系統的架構圖。整體是一個Master Slave的架構，Job Runtime Dir 概念是指當前Job的運行所需要的環境完整打包提供，如Python 環境。
Data Dev: 上圖是一個數據開發流程。數據開發平臺—開發測試上線的一站式平臺，安全、快捷、支持SQL, Python, Spark Shell。
Data Pipeline：數據管道，用於離線數據管道配置管理和實時數據管道配置管理。可以實現1分鐘完成離線入倉配置和實時入倉配置。
Data Knowledge：數據知識，用於血緣關係查詢、數據指標管理。
沒有最好的架構，只有更適合的架構 。每個公司的情況不一樣，業務模式不一樣，雖然都是ETL數據處理，都是數據倉庫，都是機器學習，但是有多少需求是數據倉庫？機器學習的應用場景是什麼？ETL實時性要求是怎麼樣的？這些細節都有很多複雜的客觀條件約束。
在技術架構的選型中有兩個至關重要的因素，即場景和成本。簡單來說，場景就是要做什麼，要低成本的方式實現，不要過度設計。如果場景複雜，那麼可以從多維度抽象細分，比如：時間維度（歷史待解決問題，目前的問題，未來可能面臨的問題）。同理，就成本而言，應該考慮的維度也很多，如：開發週期、運維複雜度、穩定性、現有人員的技術棧等等。
在下篇中，我們會從“實時數據倉庫技術細節”和“數據平臺功能簡介”兩方面繼續為大家解讀宜人貸的PaaS數據服務平臺Genie，敬請大家持續關注。
來源：敏捷大數據
