上篇：架構及元件

一、資料平臺的發展

1.1 背景介紹

隨著資料時代的到來，資料量和資料複雜度的增加推動了資料工程領域的快速發展。為了滿足各類資料獲取/計算等需求，業內湧現出了諸多解決方案。但大部分方案都遵循以下原則：

• 降低資料處理成本

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

• 提供統一的程式設計正規化

宜人貸的資料服務平臺也是遵循這三個原則。本人有幸親身經歷了宜人貸資料平臺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等。此時歷史資料和實時資料結合資料倉儲可以回答什麼終將會發生（預測階段）。

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

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

1.2 資料平臺定位

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

• 決策賦能

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

• 業務資料分析/業務資料產品

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

• 計算儲存

業務資料產品也可以充分利用平臺的計算儲存資源打造資料產品，如推薦、智慧營銷等等。

• 效率

提升資料處理效率，從而節約資料探勘/處理的時間成本。

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

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

1.3 初期架構的缺點

初期為什麼是這樣的架構這裡就不做過多描述了，我們直接說一下它的缺點。

• 當決策層使用報表時發現總是慢了一拍，總會有新的需求出來。原因很簡單：其實網際網路公司的業務並不像傳統行業（如銀行、保險等）的業務那麼穩定，因為網際網路公司的發展比較快，業務更新迭代的也很快。

• 業務分析總有各種臨時的需求，原因和1類似。

• 資料倉儲工程師累成狗。資料倉儲龐大笨重，很難靈活的運作，總是牽一髮而動全身。

• 叢集作業運維困難，作業間耦合性太大，例如：A業務的表a 沒跑出來直接影響了整個公司的所有作業。

1.4 常見解決方案

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

• 搭建產品化的資料服務平臺。

• 資料倉儲能量轉移到更加基礎更加底層的資料問題，如資料質量問題、資料使用規範、資料安全問題、模型架構設計等。

• 業務分析師直接利用平臺搭建業務資料集市，提高敏捷性和專用性。

• 資料工程主要職責不再是運維叢集，而是搭建資料服務平臺和構建業務資料產品。

這樣做的好處是：

• 解決了資料倉儲的瓶頸問題。

• 讓最熟悉自己資料的人自己搭建資料集市，效率更高。

• 業務資料產品可以直接使用資料服務平臺提高效率，縮減公司成本。

二、宜人貸資料平臺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：資料知識，用於血緣關係查詢、資料指標管理。

三、總結

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

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

在下篇中，我們會從“實時資料倉儲技術細節”和“資料平臺功能簡介”兩方面繼續為大家解讀宜人貸的PaaS資料服務平臺Genie，敬請大家持續關注。

下篇：技術細節及功能

導讀：在上篇中，我們已經簡單瞭解了宜人貸資料平臺Genie的特點，並且掌握了資料平臺發展歷程的一些資訊。本文作為下篇，首先我們會在其中重點講解實時資料倉儲的技術細節，之後介紹資料平臺的功能。下面我們一起來了解一下這些知識吧~  

四、實時資料倉儲技術細節

離線資料倉儲是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 做儲存索引的核心資料結構。

五、整體資料處理架構

綜上我大概的介紹了宜人貸的實時資料處理架構，下面我們看一下整體的資料處理架構。

整體Lambda架構speed層利用DBus和Wormhole組裝成了一套實時資料匯流排，speedlayer可以直接支撐實時資料產品。DataLake是一個抽象的概念實現方式，我們主要是利用Hdfs + Cassandra儲存資料，計算引擎主要以Hive 和Presto為主，再透過平臺統一的metadata對後設資料整合提供，這樣就實現了一個完整的DataLake。DataLake主要的應用場景是高階靈活的分析，查詢場景如 ml 。

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

六、資料平臺Genie的功能模組

整個Genie資料服務平臺由7個大的子平臺模組組成：

• 資料查詢

• 資料知識

• 實時報表

• 資料開發

• 作業排程

• 許可權管理

• 叢集監控管理

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

6.1 資料查詢模組

• 使用者可以查詢資料倉儲、資料集市、實時資料倉儲的資料

• 透過對SQL的解析來實現細粒度的許可權管理

• 提供多種查詢引擎

• 資料匯出

6.2 資料知識模組

• 後設資料監控管理

• 對全公司的後設資料提供管理查詢功能

• 可以監控後設資料變更並預警郵件

• 血緣分析查詢引擎

• SQL分析引擎

• 對倉庫所有的作業/表/欄位進行分析

• 提供血緣分析/影響分析

6.3 資料包表模組

• 實時資料倉儲

• Presto on Cassandra直連Presto

• 數百張表，實時同步（DBus+WHurl）

• 達芬奇報表平臺 （達芬奇url）

• 近千張報表全公司已使用

6.4 資料開發模組

• 資料程式設計 Genie-ide

• 提供Genie-ide進行資料程式的開發

• 提供網盤進行指令碼儲存管理

• 可以實時測試/上線

• 資料管道

  • 一鍵離線入倉

  • 一鍵實時入倉

6.5 作業排程Triangle模組

• 微服務架構設計每個模組均為一個服務

• 提供restful介面可以方便二次開發與其它平臺融合

• 提供健康監控作業管理後臺

• 提供公共作業和私有作業

• 作業流之間邏輯隔離

• 併發控制，失敗策略管理

七、資料平臺Genie的功能

以上是對資料平臺Genie模組功能的簡介，那Genie平臺具體可以做哪些事情呢？

首先，它可以實現離線入倉，實時入倉 1分鐘內配置完成（資料倉儲，資料集市）；

其次，實時入倉後可直接配置實時報表展示推送（BI分析）；

第三，實時資料支援多種含有許可權安全的同構對接方式：api ,kafka, jdbc（業務資料產品）；

第四，一站式資料開發支援hive，spark-sql，presto on cassandra，python（資料開發）；

第五，服務化的排程系統支援外部系統接入（基礎技術元件）。

參考文獻：

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

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

作者：孫立喆

來源：宜信技術學院