網易雲音樂基於Flink實時數倉實踐

本次ITPUB技術棧線上沙龍2020上，網易雲音樂Flink & Calcite contributor李涵淼分享了關於網易雲音樂基於Flink實時數倉實踐，內容包括實時數倉版本的演進過程，具體實現和最佳實踐。

▲網易雲音樂Flink & Calcite contributor李涵淼

嘉賓簡介：Flink & Calcite contributor。擁有多年的流計算研發經驗，熟悉流計算生態圈，參與和設計了網易雲音樂實時計算平臺、實時數倉、Notebook、批流一體等專案。目前專注於Flink SQL的研究，致力於打造方便、易用、穩定的大資料SQL生態系統。

一、背景介紹

截止到今天為止，網易雲音樂實時計算平臺的機器數量有150多個，執行任務有700個，資料峰值的QPS有400萬。李涵淼透露道，“大概有180多個開發者在用這個實時計算平臺。”

在業務覆蓋層面，跟實時有關的基本是全覆蓋，包括實時報表、實時特徵、實時索引，以及實時業務等。實時計算平臺是從2018年上半年開始做的，期間經歷了兩個版本的迭代，直到2020上半年，任務增長了將近200%。

網易雲是基於1.7的版本，做的實時計算平臺version-1設計。大家都知道，Flink已經更新到1.11版本了，它整合了很多Blink的優秀特性。在被阿里收購以後，Flink從1.9版本開始，每一個版本迭代，程式碼的改動都是非常多的。

因為社群版本的Flink 1.7不支援SQL DDL，所以為了方便使用者的使用，我們基於Antlr的自定義SQL語法，包含DDL和維表JOIN。此外，實時平臺的第一版本沒有資料血緣追蹤功能，問題定位的時候比較困難。

實時平臺的第一版本沒有後設資料管控，Jar任務的遊離。它的任務監控是不健全的。當問題出現的時候，我們收集的指標不足以定位問題。現在來看，實時平臺第一版本的問題是非常多的。

二、實時數倉建設

實時數倉版本是基於Flink 1.9版本做的，它主要的特性包括：與後設資料中心的整合，使得使用者不用過多地定義資料的格式;提供SQL和SDK給使用者使用;端到端血緣收集;資料來源和任務監控完善。

▲實時數倉的架構圖

從最源頭開始看實時數倉的架構圖，SQL和SDK作為輸入，直接去走Planner。Planner和SQL打通，可以解析整體的SQL語句。接下來，會有一個Catalog的注入，它接的是MetaHub(雲資料中心)。

所有的後設資料都被管控起來，就形成了一個系統，也就是後設資料中心。它可以管理所有存在後設資料系統的儲存，並具備獨立模組管理MQ後設資料、插拔式後設資料管理、統一資料型別、後設資料檢索等功能。

數倉建設分為三個部分：統一表表示格式 (catalog.db.table) 、數倉分層，以及表許可權管理。在做實時數倉時，我們完全以現有離線的數倉模式，複製出來一個實時數倉的表。

SDK提供封裝內部SQL執行邏輯，簡易的API，以及資料血緣收集。上圖是用SDK做的一個DEMO，這是真實的一個業務程式碼。之前是用了將近190多行程式碼去實現的，在封裝之後總體不過十幾行程式碼，方便使用者使用。

從資料、資料來源、資料寫出，我們均提供細粒度任務級別指標監控和MQ資料量監控。李涵淼認為，“當平臺做到一定程度的時候，這種叢集級別的監控是必不可少的。監控做的完善，對平臺是一個很好的補充。”

三、實時數倉實踐

實時數倉第一個很典型的實踐就是ABTest，把原始資料存到HIVE裡面去，再用Spark做清洗和聚合，然後再輸到上層的表裡。值得注意的是，實時數倉和離線數倉的分層，其實是一致的。

實時數倉版ABTest擺脫了之前HIVE+Spark的處理模式，應用效果非常好。

實時數倉第二個典型的實踐是實時報表，如上圖所示，網易雲音樂直播播放量的統計表格。實時報表建立任務更容易，資料問題定位更清晰。

第三個典型的實踐是實時特徵，具備特徵複用和特徵血緣展示。我們做過一個統計，各個演算法團隊做出來的任務，輸出的特徵很多都是重複的，這無形中就造成了資源的浪費，增加了團隊開發的成本。

實時數倉對特徵做了分層，所有的表根據業務做了隔離，並全部統一起來。演算法團隊如果想用一些特徵的話，他可以直接在平臺上搜尋相關特徵，然後根據其中包含的資訊，做進一步的操作。