宜人貸PaaS數據服務平臺Genie：技術架構及功能

時間 2019-11-15

標籤宜人 paas 數據服務平臺 genie 技術架構功能欄目雲服務简体版

原文原文鏈接

上篇：架構及組件

1、數據平臺的發展

1.1 背景介紹

隨着數據時代的到來，數據量和數據複雜度的增長推進了數據工程領域的快速發展。爲了知足各種數據獲取/計算等需求，業內涌現出了諸多解決方案。但大部分方案都遵循如下原則：html

下降數據處理成本java
合理提升數據使用/計算效率node
提供統一的編程範式python

宜人貸的數據服務平臺也是遵循這三個原則。本人有幸親身經歷了宜人貸數據平臺Genie的整個發展過程，縱觀宜人貸和業內，能夠說Genie的發展是工業界數據平臺發展的縮影。算法

Google 的三大論文和Apache Hadoop 開源生態圈的發佈應該是大數據處理技術走進「尋常百姓家」的起點。Hadoop 的組件都可在普通的廉價機器上運行，加上其代碼是開源的，所以獲得了衆多公司的熱捧。那麼一開始這些公司都用它來作什麼呢？sql

答案是數據倉庫。數據庫

注：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快照方案，也就是說只有昨天的數據。api

緊接着因爲對數據實時性的需求提升了，須要實時作增量數據的關聯聚合等複雜運算，這個時候數據平臺就會加入分佈式流計算的架構，如：Strom ，Flink， Spark Streaming 等。此時的數據倉庫能夠回答的是正在發生什麼（實時階段）。安全

因爲離線數據處理流程（如：Sqoop+HDFS+Hive）和實時數據處理流程（如：Binlog+Spark Steaming+Hbase）兩套流程計算邏輯耦合較大，而且經過組合才能支持實時全量的數據分析，因此就產生了不少架構，如早期的Lambda，Kappa等。此時歷史數據和實時數據結合數據倉庫能夠回答什麼終將會發生（預測階段）。

數據平臺發展至此已經再也不是一個數據倉庫就能解釋的了，它與各種業務部門緊密合做（如營銷、電銷、運營）打造出諸多數據產品。此時數據倉庫（數據平臺）已經進入了主動決策階段。

其實預測和實時的發展順序不一樣的公司有所不一樣，只用歷史數據就能夠作出預測。

1.2 數據平臺定位

數據平臺應該屬於基礎架構的重要環節，曾經互聯網行業內有不少公司跟風搭建了大數據集羣后發現很難發揮真正價值，其實最重要的緣由應該是對數據使用的定位以及對數據平臺的定位問題。目前的數據平臺定位有如下幾點：

決策賦能

爲決策層賦能，決策層經過使用BI報表快速瞭解公司運營狀況，由於數據不會說假話。

業務數據分析/業務數據產品

平臺能夠提供Adhoc即時分析，幫助分析師快速分析業務、快速定位問題、快速反饋。

計算存儲

業務數據產品也能夠充分利用平臺的計算存儲資源打造數據產品，如推薦、智能營銷等等。

效率

提高數據處理效率，從而節約數據挖掘/處理的時間成本。

大部分公司早期人員架構以下圖：

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

1.3 初期架構的缺點

初期爲何是這樣的架構這裏就不作過多描述了，咱們直接說一下它的缺點。

當決策層使用報表時發現老是慢了一拍，總會有新的需求出來。緣由很簡單：其實互聯網公司的業務並不像傳統行業（如銀行、保險等）的業務那麼穩定，由於互聯網公司的發展比較快，業務更新迭代的也很快。
業務分析總有各類臨時的需求，緣由和1相似。
數據倉庫工程師累成狗。數據倉庫龐大笨重，很難靈活的運做，老是牽一髮而動全身。
集羣做業運維困難，做業間耦合性太大，例如：A業務的表a 沒跑出來直接影響了整個公司的全部做業。

1.4 常看法決方案

相信這些頭疼的問題不少公司都遇到過，解決方式應該也是相似的。大致以下：

搭建產品化的數據服務平臺。
數據倉庫能量轉移到更加基礎更加底層的數據問題，如數據質量問題、數據使用規範、數據安全問題、模型架構設計等。
業務分析師直接利用平臺搭建業務數據集市，提升敏捷性和專用性。
數據工程主要職責再也不是運維集羣，而是搭建數據服務平臺和構建業務數據產品。

這樣作的好處是：

解決了數據倉庫的瓶頸問題。
讓最熟悉本身數據的人本身搭建數據集市，效率更高。
業務數據產品能夠直接使用數據服務平臺提升效率，縮減公司成本。

2、宜人貸數據平臺Genie架構及特色

2.1 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的組成以及數據使用流程。先說數據使用流程，首先全部數據（包括結構化數據和非結構化數據）都會在數據倉庫中進行標準化，如：單位統一，字典統一，數據格式統一，數據命名統一等等。統一規範的數據會直接或者間接的被數據集市使用，做爲數據集市的入口。數據集市之間業務耦合性很低，因此數據耦合性也就低，這樣能夠很好的避免總體做業的耦合度。各個業務的數據應用也會直接使用本身的數據集市。

2.2 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：數據知識，用於血緣關係查詢、數據指標管理。

3、總結

沒有最好的架構，只有更適合的架構。每一個公司的狀況不同，業務模式不同，雖然都是ETL數據處理，都是數據倉庫，都是機器學習，可是有多少需求是數據倉庫？機器學習的應用場景是什麼？ETL實時性要求是怎麼樣的？這些細節都有不少複雜的客觀條件約束。

在技術架構的選型中有兩個相當重要的因素，即場景和成本。簡單來講，場景就是要作什麼，要低成本的方式實現，不要過分設計。若是場景複雜，那麼能夠從多維度抽象細分，好比：時間維度（歷史待解決問題，目前的問題，將來可能面臨的問題）。同理，就成本而言，應該考慮的維度也不少，如：開發週期、運維複雜度、穩定性、現有人員的技術棧等等。

在下篇中，咱們會從「實時數據倉庫技術細節」和「數據平臺功能簡介」兩方面繼續爲你們解讀宜人貸的PaaS數據服務平臺Genie，敬請你們持續關注。

下篇：技術細節及功能

導讀：在上篇中，咱們已經簡單瞭解了宜人貸數據平臺Genie的特色，而且掌握了數據平臺發展歷程的一些信息。本文做爲下篇，首先咱們會在其中重點講解實時數據倉庫的技術細節，以後介紹數據平臺的功能。下面咱們一塊兒來了解一下這些知識吧~

4、實時數據倉庫技術細節

離線數據倉庫是t+1的數據，也就是說數據時效性是處理前一天的數據。通常來講離線方案同步數據的策略是天天定時同步一次數據，並且基本是同步一次全量數據，也就是說天天一個全量數據（業務庫）的鏡像。

除了時效性，還有一點就是鏡像的數據狀態只有一個，因此想知道某個值的歷史變化過程，就須要走拉鍊表（很是耗時耗資源）。實時數據倉庫的實現方式不少，可是大多都是異曲同工。

實時數倉有兩點特色：第一訪問實時數據；第二結果能近似實時的返回。固然離線倉庫若是優化的好，完成第二點也是能夠實現的。思考兩個問題，爲何要用實時數據？爲何要有實時數據倉庫？

近幾年數據工程師們在如何提升數據時效性上作了很是多的努力和嘗試。推進這些實時數據同步、處理技術發展的固然仍是場景與需求。中國的大互聯網環境競爭很是激烈，如何提升用戶轉化率變得尤其關鍵。

用戶畫像、推薦系統、漏斗分析、智能營銷等等數據相關的產品都離不開實時數據的處理與計算。

獲取實時數據最直接的方式是直連業務庫，優點明顯，缺點也很明顯,有些邏輯須要跨庫多源查詢關聯的時候直接連業務庫就行不通了。因此首先須要把多個源頭的數據集中同步起來，這個同步過程就是一個很是具備挑戰的地方，要考慮數據的時效性，對業務系統的侵入性，數據的安全性和數據的一致性等等諸多難題。

因此咱們須要一個同步數據的工具，它須要有如下幾個特色：

可以近似實時的同步生產庫的數據和日誌數據
和生產庫還有應用服務器徹底解耦
同步出來的數據能夠分發到其餘的存儲
整個同步過程保證數據不丟失，或者說能夠按照任意時間批量從新同步

宜信敏捷大數據團隊開發的DBus和Wormhole能很好的知足以上4點。

DBus利用數據庫的binlog進行數據抽取，binlog通常延遲是比較低的，這樣既保證了實時的特性，也保證了對生產庫的零侵入。

其實利用日誌來構建一個健壯的數據系統是一個很常見的方案。Hbase利用wal來保證可靠性，MySQL主備同步使用binlog，分佈式一致性算法Raft利用日誌保證一致性，還有Apache Kafka也是利用了日誌來實現的。

DBus很好的利用了數據庫的binlog日誌而且進行統一的schema轉化，造成了本身日誌標準，以便支持多種數據源。DBus的定義是一個商業級別的數據總線系統。它能夠實時的將數據從數據源抽取發送給Kafka。

Wormhole負責將數據同步寫入其餘的存儲之中。Kafka就成了一個真正意義上的數據總線，Wormhole支持sink端按照任意時間開始消費Kafka中的數據，這樣也就能很好的進行數據回溯。

Genie的實時架構以下：

有了DBus和Wormhole咱們能夠很輕鬆的把數據從生產備庫實時的同步到咱們的Cassandra集羣，而後再同步Presto，爲用戶提供SQL語言計算。

經過這個簡單的架構咱們高效的完成了實時數據倉庫的搭建，而且實現了公司的實時報表平臺和一些實時營銷類的數據產品。

對於爲何會使用Presto我能夠給出如下的答案：

Presto擁有交互級別的數據計算查詢體驗
Presto支持水平擴展，presto on yarn （slider）
支持標準SQL，而且方便擴展
facebook, uber, netflix生產使用
開源語言java符合咱們團隊技術棧, 自定義函數
支持多數據源關聯join 邏輯下推，Presto 能夠接Cassandra, Hdfs等等
pipelined executions - 減小了沒必要要的I/O開銷

Presto 是m/s架構，總體細節很少說了。Presto有個數據存儲抽象層，能夠支持不一樣的數據存儲上執行SQL計算。Presto提供了meta data api，data location api， data stream api，支持自開發可插拔的connector。

在咱們的方案中是Presto on Cassandra的，由於Cassandra相對於Hbase來講可用性更好一些，比較適合adhoc查詢場景。Hbase CAP中偏向c，Cassandra CAP中偏向a。Cassandra是一個很是優秀的數據庫，方便易用，底層使用Log-Structured Merge-Tree 作存儲索引的核心數據結構。

5、總體數據處理架構

綜上我大概的介紹了宜人貸的實時數據處理架構，下面咱們看一下總體的數據處理架構。

總體Lambda架構speed層利用DBus和Wormhole組裝成了一套實時數據總線，speedlayer能夠直接支撐實時數據產品。DataLake是一個抽象的概念實現方式，咱們主要是利用Hdfs + Cassandra存儲數據，計算引擎主要以Hive 和Presto爲主，再經過平臺統一的metadata對元數據整合提供，這樣就實現了一個完整的DataLake。DataLake主要的應用場景是高級靈活的分析，查詢場景如 ml 。

DataLake和數據倉庫的區別是，DataLake更加敏捷靈活，側重數據的獲取，數據倉庫則側重於標準、管理、安全和快速索引。