OPPO 實時數倉揭祕：從頂層設計實現離線與實時的平滑遷移

單日總數據處理量超 10 萬億，峯值大概超過每秒 3 億，OPPO 大數據平臺研發負責人張俊揭祕 OPPO 基於 Apache Flink 構建實時數倉的實踐，內容分爲如下四個方面：建設背景、頂層設計、落地實踐、將來展望。

1、建設背景

關於 OPPO 移動互聯網業務

你們都認爲 OPPO 是一家手機公司，但你們可能並不清楚，其實 OPPO 也會作與移動互聯網相關的業務。在 2019 年 12 月，OPPO 發佈了本身定製的手機操做系統 ColorOS 7.0 版本。目前包括海外市場在內，ColorOS 的日活已經超過了 3 億。ColorOS 內置了不少移動互聯網服務，包括應用商店、雲服務、遊戲中心等，而這些服務的日活也達到了幾千萬級別。

以數倉爲核心的數據架構

爲了支撐這些移動互聯網服務，OPPO 創建了以下圖以數倉爲核心的數據架構。圖中藍色的部分，相信你們應該都很熟悉，這部分基本上都是一些開源的組件，從數據接入，到基於數倉實現交互式查詢、數據處理，再到數據應用。其中的應用主要分爲三個方面：

• 第一是會將數據導入到 ES 裏面去作一些用戶的標籤以及人羣的定向投放等。
• 第二是將數據導入到 MySQL 或者 Kylin 裏面去作 BI 報表。
• 第三是將數據放到 Redis 或者 HBase 裏面去作服務接口。

在過去幾年的時間裏面，OPPO 內部的這套以數倉爲核心的數據架構已經逐漸開始成熟了。

以數倉爲核心的數據架構

可是隨着業務的發展以及數據規模的不斷膨脹，OPPO 對於數倉實時化的訴求愈來愈強烈。OPPO 對於數倉實時化的訴求能夠分爲兩個維度，即業務維度和平臺維度。

• 對於業務維度而言，愈來愈須要去作精細化的運營，也愈來愈須要去挖掘數據的價值，因此不管是實時報表、實時標籤仍是實時接口等都須要實時化能力。
• 對於平臺維度來說，也須要實時化。由於總體的數據規模愈來愈大，一般像傳統「T+1」的數據處理模式使得在凌晨的時候服務壓力很是大。若是可以將整個集羣的壓力均攤到全天的 24 小時裏面去，那麼整個集羣的使用效率就會更高一些。因此，即便從調度任務、用戶標籤的導入等來看，若是可以很是及時地發現數據的異常，對於平臺而言也是須要不少的實時化能力。

  

2、頂層設計

實時數倉的現狀

目前 OPPO 實時數倉的規模是 Flink 已經達到了 500 多個節點，Kafka 大概達到了 200 多個節點。在元數據維度，實時數據庫表達到了 500 多張，實時做業大概有 300 多個。在數據規模維度，天天總數據處理量超過了 10 萬億，峯值大概超過每秒 3 億。

實時數倉 VS 離線數倉

談到實時數倉的頂層設計，也不得不談到實時數倉的底層邏輯，由於底層邏輯決定頂層設計，而底層邏輯則來自於實時的觀察。

下圖中將實時數倉和離線數倉放在一塊兒進行了對比，發現二者的類似性不少，不管是數據來源、數據使用者、數據開發人員以及數據應用都很是類似，二者最大的差別點在於時效性，由於實時數倉中數據的時效性須要達到分鐘級或者秒級。

離線到實時數倉的平滑遷移

當有了對於底層邏輯的觀察以後，就可以推導出頂層設計狀況。OPPO 但願所設計出來的實時數倉可以實現從離線到實時的平滑遷移，以前你們如何使用和開發離線數倉，現在到了實時數倉也但願你們如何開發和使用。一般而言，當設計一款產品或者平臺的時候，能夠劃分爲兩層，即底層實現和上層抽象。對於底層實現而言，可能會有不一樣的技術，從 Hive 到 Flink，從 HDFS 到 Kafka。而在上層抽象而言，則但願對於用戶而言是透明的。

不管是離線仍是實時，最終都但願數倉的核心抽象就是一個 Table，圍繞着這個核心的抽象，上面還有三個維度的抽象。

• 第一個抽象就是數倉的結構，根據不一樣的結構可以劃分不一樣的主題域和層次。
• 第二個抽象就是數倉的開發模式，基本上都是 SQL+UDF 的開發模式。
• 第三個抽象就是管理，從管理上來看，數倉無非就是如何管理其權限以及數據的血緣和質量。

從以上三個抽象維度來看，咱們但願從離線到實時可以將抽象保持一致的，這樣對於用戶而言成本是最低的。接下來則會爲你們介紹如何將遷移的成本保持最低。

離線實時一體化接入鏈路

首先爲你們介紹離線實時一體化接入鏈路，OPPO 的數據從手機端到 OBus 內部數據收集服務，收集以後會統一落入到Kafka中去，再經過 Flink SQL 的任務能夠同時落入 HDFS 和 Kafka 中去。Flink 能夠實現數據通道的拆分，對於 OPPO 這樣一個手機公司而言，不少 APP 上報都是經過同一條通道，所以在將數據落入到數倉以前須要對於數據通道進行拆分，根據不一樣的業務和屬性作一些拆分，除此以外還會作一些格式的轉換。另一部分功能就是實現數據的監控，由於將數據落入到 HDFS 時須要有一個很重要的問題就是分區感知問題，好比離線 ETL 任務如何知道分區已經結束了。

OPPO 的作法是根據端到端不一樣數據的對帳實現的，所以須要在 Flink SQL 這一層完整地記錄收到多少條數據，寫入了多少條數據，而後和前面的 OBus 作一個數據對帳的對比，若是對比結果在必定範圍以內，就能夠寫一個成功文件，這樣就可讓後端的 ETL 任務開始運行。

使用 Flink SQL 所 帶來的好處在於：

• 第一，Flink SQL 能夠保證端到端的一致性，不管是從 Kafka 到 Kafka，仍是從 Kafka 到 HDFS，都可以保證端到端的數據一致性，這一點對於接入鏈路而言是很是重要的。
• 第二， Flink SQL 具備強大的數據預處理能力，OPPO 過去在數據接入通道里面使用過 Flume 等，可是這些組件的數據處理性能很難提高上去，所以須要追加不少機器來實現性能提高。而使用 Flink 以後，使得數據處理能力有了巨大提高。
• 第三，可以使用一套代碼來實現將數據落入到 HDFS 和 Kafka 裏面去，所以大大下降了維護成本。

離線實時一體化的管理流程

對於數倉的管理流程而言，無非就是元數據是如何管理的，表的字段是如何定義的，表的血緣如何追蹤以及表的權限如何管理，以及表的監控如何實現。現在在 OPPO 內部，離線和實時數倉的這些管理流程可以作到一致，首先二者使用的流程是一致的，其次表的 Schema 的定義以及表的血緣可以保證一致，而不須要用戶從新申請和定義。

離線實時一體化的開發環境

對於數倉的開發而言，抽象下來能夠分爲三個層面，即離線批處理的開發、流式開發以及交互式查詢。而對於用戶而言，但願可以保證用戶體驗的一致，而且但願實現開發流程的統一。

實時數倉的層級劃分

以下圖所示的是 OPPO 實時數倉的分層結構，從接入層過來以後，全部的數據都是會用 Kafka 來支撐的，數據接入進來放到 Kafka 裏面實現 ODS 層，而後使用 Flink SQL 實現數據的清洗，而後就變到了 DWD 層，中間使用 Flink SQL 實現一些聚合操做，就到了 ADS 層，最後根據不一樣的業務使用場景再導入到ES等系統中去。固然，其中的一些維度層位於 MySQL 或者 Hive 中。

SQL 一統天下的數據架構

對於數倉領域的近期發展而言，其中頗有意思的一點是：不管是離線仍是實時的數據架構，都慢慢演進成了 SQL 一統天下的架構。不管是離線仍是實時是數據倉庫，不管是接入，查詢、開發仍是業務系統都是在上面寫 SQL 的方式。

3、落地實踐

前面爲你們分享了 OPPO 實時數倉實踐的頂層設計，固然這部分並無所有實現，接下來爲你們分享 OPPO 已經有的落地實踐，

SQL 開發與元數據管理的實現

想要作實時數倉所須要的第一步就是支持 SQL 的開發與元數據管理的實現。OPPO 在這部分的設計大體以下圖所示。

這裏須要元數據系統和開發系統，須要可以在元數據系統中建立實時表並在開發系統裏面建立實時做業並寫 SQL，而不管是建立 Table 仍是 Job，都須要可以持久化到 MySQL 裏面去。

而後再去擴展 Flink 裏面的組件，並將其從 MySQL 裏面加載出來。

• 對於表而言，能夠擴展 Flink 的 Catalog，經過 Catalog 能夠從 MySQL 中加載出來，再轉化成 Flink 內部表達的數據表。
• 對於做業而言，OPPO 則使用了谷歌開源的框架，經過對於 Job Store 的實現能夠從數據源頭好比 MySQL 來加載這個做業，將這個做業提交給 Flink 的 Table 環境來作做業的編譯，最終定義成爲 Job Graph，而後提交給 YARN，這樣的流程就是支撐 OPPO 實時數倉的框架。

冗餘消費 Kafka Topic 問題的優化

在 OPPO 的場景下，咱們發現了本身所存在的一個很棘手的問題，那就是不少用戶在寫 SQL 的時候會出現同一個做業須要寫多個 SQL，好比剛纔提到的接入場景，若是想要作通道的拆分，一般而言須要來自同一個表格，通過不一樣的過濾，而後導入到不一樣的數據表裏面去，而 OPPO 但願在單個做業中就可以實現這樣的表達。

可是這樣作所帶來的問題就是將多個 SQL 放在一個做業裏面執行就會生成多個 Data Source，多個 Data Source 就會重複地消費 Kafka，這就使得 Kafka 集羣的壓力很是大，緣由是不少 Kafka 機器的寫入和讀取的操做比例差距很是大，一個 SQL 的做業可能會讀取不少次 Kafka 的 Topic。而這是沒有必要的，由於對於同一次做業而言，只須要消費一次 Kafka 便可，接下來數據能夠在 Flink 內部進行消化和傳播。

OPPO 針對於上述問題實現了一個很是巧妙的優化，由於 Flink 的 SQL 會生成一個 Job Graph，在這以前會生成一個 Stream Graph。而 OPPO 經過改寫 Stream Graph，使得不管用戶提交多少個 SQL，對應只有一個 Data Source，這樣就下降了對於 Kafka 的消費量，並且帶爲用戶來了很大的收益。

實時數據鏈路的自動化

線上 BI 的實時報表是很是通用的場景，對於實時報表而言，每每須要三個環節的配合：

• 第一個環節是數據分析師去寫 SQL 實現對數據的處理；
• 第二個環節是從一個數據表過來統計或者清洗，再寫入到 Kafka 裏面去，經過平臺的研發人員再將數據打入到 Druid 裏面去；
• 最終的一個環節就是用戶須要去 BI 系統中查看報表，所以就須要從 Druid 這張表導入到 BI 系統中去。

上述鏈路中的數據處理、數據導入和數據展示三個環節是比較割裂的，所以須要三種不一樣角色的人員來介入作這件事情，所以 OPPO 但願可以打通實時數據鏈路。OPPO 作了以下圖所示的實時數據鏈路的自動化，對於 Kafka 的表作了抽象，而對於用戶而言，其就是用於作 BI 展現的表，Kafka 的表須要定義哪些是維度、哪些是指標，這是作報表展現最基本的字段定義。

當完成了上述任務以後，就能夠將整個實時數據鏈路以自動化的方式串起來。當用戶將 SQL 寫完以後，能夠自動化地探測 Report Table 須要導入到 Druid 裏面去，以及哪些是指標，哪些是維度，而且能夠將數據從 Druid 自動地導入到 BI 系統。這樣一來，對於用戶而言只須要寫一個 SQL，以後就能夠在 BI 系統之上看到報表了。

實時數據鏈路的延遲監控

以前，OPPO 作數據鏈路的延遲監控時也屬於單個點進行監控的，能夠從下圖中看出至少有三級的 Kafka 的 Topic，對於每一個 Topic 都存在延遲的監控。而對於用戶而言，關注的並非點，而是面，也就是最終展示的數據報表中延遲狀況如何。

所以， OPPO 也實現了全鏈路的延遲監控，從接入的通道開始到每一層的 Kafka 消費，都將其 lag 狀況彙總起來，探索到每一級的 Flink SQL 表的血緣關係。有了這樣的血緣關係以後就能夠從 Druid 表推導到前面所接入的鏈路是哪個，而後將整體延遲加起來，這樣就能夠反映出總體鏈路的延遲狀況。

實時數據鏈路的多租戶管理

對於實時數據鏈路而言，多租戶管理一樣很是重要。OPPO 在這部分的實踐的核心是兩點：

• 其中一點 Kafka 裏面的認證和配額機制，當有了認證和配額機制以後能夠對於用戶作配額管理，好比對於 Kafka 的消費速度、生產速度等。
• 另一點就是用戶在向 YARN 上面提交的做業的時候也能夠指定隊列，這樣就能夠指定用戶消耗多少資源。

4、將來展望

更便捷的 SQL 開發

由於 OPPO 如今的實時數倉是基於 SQL 作的，因此在將來但願可以具備更好的、更便捷的 SQL 開發能力，總結來下就是如下四點：

• 表達能力：雖然 Flink SQL 正在朝着標準 SQL 不斷演進，可是目前一些場景仍舊沒法知足，好比在一個 SQL 裏面作多個窗口的統計等，所以須要加強Flink SQL 的表達能力。
• 鏈接類型：現在，實時數據倉庫的應用愈來愈多，所以也須要擴充更多的鏈接器，好比 Redis 等的 Sink。
• 開發模板：谷歌開源了 Dataflow Template，這是由於用戶在作統計、彙總等不少的狀況下，方法是通用的，所以對於用戶而言這些通用操做能夠作成模板，避免重複編寫 SQL。
• 開發規範：這也是 OPPO 在線上實踐中所觀察到的問題，不少數據分析師寫的 SQL 的性能不好，開發人員在定位問題時每每會發現 SQL 的編寫不規範，只須要進行一些小優化便可提高性能，所以將來須要將這些能力沉澱到系統裏面去。

更細力度的資源調度

目前，OPPO 是基於 YARN 作 Flink 的集羣調度，而 YARN 的調度是基於 VCore 以及內存維度實現的。在線上運行時就發現一些機器的 CPU 利用率很高，另一些卻很低，這是由於不一樣的 SQL 處理的複雜度以及計算密集度是不一樣的，若是仍是和之前同樣分配 VCore，那麼極可能致使對於資源的利用率不一樣，所以將來須要考慮將 SQL 對於資源的調度加入到考慮範圍內，儘可能避免資源的傾斜。

自動化的參數配置

對於數據分析師而言，你們都知道Flink裏面存在一些高級配置。除了寫 SQL 以外，還有不少其餘的知識，好比操做的併發度、狀態後臺以及水位間隔等，可是用戶每每會很難掌握如何配置這些複雜參數，所以 OPPO 但願將來可以將這些複雜的參數配置實現自動化。經過理解數據的分佈狀況和 SQL 的複雜狀況，自動地配置這些參數。

自動化的伸縮調優

更進一步，能夠從自動化實現自適應，變成智能化，也就是自動化的伸縮調優。之因此要作自動化的伸縮，主要是由於兩點，第一，數據分佈自己就是存在波動性的；第二，機器在不一樣的時間段也存在不一樣的狀態，所以須要及時探測和修復。所以，自動化的伸縮調優對於大規模集羣的成本節省是相當重要的。

做者介紹：

張俊，OPPO 大數據平臺研發負責人，主導了 OPPO 涵蓋「數據接入-數據治理-數據開發-數據應用」全鏈路的數據中臺建設。2011-碩士畢業於上海交通大學，曾前後工做於摩根士丹利、騰訊，具備豐富的數據系統研發經驗，目前重點關注數倉建設、實時計算、OLAP 引擎方向，同時也是Flink開源社區貢獻者。

更多案例：

小米 ｜小米流式平臺架構演進與實踐
bilibili ｜從 Spark Streaming 到 Apache Flink：bilibili 實時平臺的架構與實踐
網易 ｜ 覆蓋電商、推薦、ETL、風控等多場景，網易的實時計算平臺作了啥？
美團點評 ｜美團點評基於 Flink 的實時數倉平臺實踐
菜鳥物流 | 菜鳥供應鏈實時數倉的架構演進及應用場景
Lyft ｜Lyft 基於 Flink 的大規模準實時數據分析平臺（附FFA大會視頻）
奇安信 ｜基於 Flink 構建 CEP 引擎的挑戰和實踐
攜程 ｜監控指標10K+！攜程實時智能檢測平臺實踐
貝殼 ｜實時計算在貝殼的實踐