> 本文首發於 **[Nebula Graph Community 公眾號](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/WeChatOffical.png)**

本文整理自 BIGO 在 nMeetp 上的主題分享，主要介紹 BIGO 過去一年在資料管理建設方面的理解和探索。而 BIGO 資料管理的核心重點在於後設資料平臺的建設，用以支撐上層資料管理和建設應用，包括資料地圖、資料建模、資料治理和許可權管理等等。本文主要圍繞以下五個方向展開：

1. OneMeta 基礎建設；
2. 圖引擎：Nebula 替換 JanusGraph
3. 資料資產平臺應用；
4. Adhoc 即席查詢；
5. 未來規劃

> BIGO 是歡聚時代（YY 直播母公司）原移動新產品部基礎上成立的獨立公司，致力於打造全球領先的社群化影片直播應用與品牌。旗下主打產品 BIGO LIVE，上線僅一個月就榮登泰國免費 APP 榜首。

## 資料管理平臺

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-01.jpeg)

上圖為 BIGO 資料資產管理平臺的抽象圖，如上圖所示，在後設資料平臺裡面儲存著技術後設資料、業務後設資料、資料血緣、資料計量、規範模型、許可權內容等資料，基於後設資料平臺上層對接應用層，包括：地圖、成本、取數、許可權、治理、模型。

## OneMeta 基礎建設

### 業務背景

目前 BIGO 資料管理面臨以下問題：

1. 後設資料雜亂無標準，沒有統一的搜尋和管理平臺；
2. 資料沒有血緣關係，各個開發平臺如同資料孤島；
3. 沒有業務類後設資料，業務方難以查詢及統一口徑；
4. 資料許可權管控粗放，許可權申請及審批流程原始化；

簡單來說：缺少標準、資料缺少聯絡、缺少業務後設資料、缺少細顆粒度的許可權管控，為此，BIGO 內部搭建了後設資料管理平臺 OneMeta 來解決上述問題。

而 OneMeta 的平臺能力如下：

1. 全域後設資料實時入庫及管理功能，統一構建公司個人及團隊資料資產目錄。
2. 資料地圖、取數查詢、資料治理、血緣姻聯、許可權管理、規範模型等應用儲存管理能力。
3. 支援 HIVE / HDFS / OOZIE / CLICKHOUSE / BAINA / SPARKSQL / KYUUBI / KAFKA 等後設資料及血緣關係的儲存。
4. 精準計量業務後設資料：各式各樣的後設資料的操作次數、冷熱程度、業務歸屬等資訊更新。

## 後設資料平臺架構

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-02.jpeg)

BIGO 後設資料平臺主要依賴 Apache Atlas、Vesoft Nebula、Yandex ClickHouse 和 BIGO 內部開發的 DataCollector 進行構建，整體上可以劃分為四層。

最上層（藍色部分）是資料採集的源頭和 DataCollector 服務，各個平臺的技術後設資料主要以 Hook 的形式實時收集，而業務後設資料則透過 DataCollector 服務以小時或天級定時排程、更新；第二層（橙色部分）是訊息佇列和 API 層，提供通道接入資料到 Atlas；第三層則是 Atlas（綠色部分），這是最核心的後設資料管理層，所有後設資料、屬性資訊和血緣關係等都在 Atlas 進行管理，此外 Atlas 層還提供了介面供應用呼叫；最底層（紫色部分）是儲存層，主要使用 Nebula Graph、Elasticsearch 和 ClickHouse，其中主要的後設資料都儲存在 Nebula 中，其中需要全文索引的資料透過 Nebula Graph 轉存到 ES，而需要查詢歷史趨勢或聚合的資料時，則去 CK（ClickHouse）中讀取資料。

### Apache Atlas 最佳化

這部分講解下 BIGO 基於開源的 Atlas 做了何種最佳化，主要有以下方面的最佳化：

1. 透過 SpringBoot 切面實現審計能力建設。
2. 引入 MicroMeter 和 Prometheus 實現監控告警能力建設。
3. 抽離圖引擎依賴，支援分散式 Nebula Graph 圖引擎的讀寫，新增 3w+ 行程式碼。
4. 新增訪問速度控制及黑白名單功能，控制突發流量和惡意訪問，保證系統穩定。
5. 定期任務，以便清理失效 Process 過程資料，避免資料膨脹。
6. 新增 Atlas 平滑退出機制，防止因重啟導致消費訊息丟失。
7. 重構血緣關係 DAG 圖展示，最佳化使用者視覺體驗同時避免大圖渲染過慢問題。
8. 支援血緣關係關聯排程引擎工作流，解決資料血緣中最重要的「查詢產出」一環。
9. Hook 擴充：全新支援 Oozie、Kyuubi、Baina、ClickHouse、Kafka 等後設資料採集。
10. 若干原生版本程式碼中的 BUG 修復。

### Data Collector 功能

在 BIGO 後設資料平臺中有個比較重要的功能——DataCollector，它是一個資料採集服務，主要功能用於定時收集並更新業務後設資料（服務於上層的資料計量等應用），比如 HIVE 表每天的訪問次數和訪問人員、HDFS 路徑的儲存量、後設資料的業務線歸屬、後設資料的冷熱判斷、後設資料的真實負責人等業務後設資料。同時，DataCollector 還具備資料清理（生命週期 TTL）和同步資料接入層（Baina）後設資料的功能。

## 圖引擎替代

Atlas 原生圖引擎是 JanusGraph，在使用過程中發現 Atlas Janus 有以下缺陷：第一，Atlas 依賴的內嵌 JanusGraph 圖引擎存在單點問題，併發量上來後存在計算瓶頸。第二，JanusGraph 依賴 Solr 構建索引，雖然 JanusGraph 聲稱可用 Elasticsearch 替換 Solr，但實際操作起來卻存在不少問題。此外，BIGO 內部對 Solr 不存在相關的技術累計，這需要投入一定的人力成本。第三，海量資料場景下 JanusGraph 搜尋效能差，並存在偶發搜尋不到資料的 BUG 難以解決。第四，JanusGraph 沒有開源社群與公司內部團隊支援，維護成本高。

再來說下 Nebula Graph 替換 JanusGraph 的幾大優勢。首先，**業務同學和運維同學多方測試證明 Nebula Graph 在圖探索效能上是 JanusGraph 的 N 倍以上**。再者，**Nebula Graph 是個分散式圖資料庫，支援分散式部署，計算和儲存均可橫向擴充套件，並且支援高併發**。此外，**Nebula Graph 開源社群活躍，產品不斷迭代最佳化，支援千億頂點和萬億邊的資料量**。最後，在 BIGO 內部有合作團隊支援與維護 Nebula Graph 平臺功能維護和開發。

### 圖引擎替換的挑戰&解決方案

雖然在選型上確定了用 Nebula Graph 來替換 JanusGraph，但是在實際的替換過程中還是存在一定的挑戰。

首先是在資料模型上，Nebula Graph 是個強 Schema 型別資料庫，如果要替換弱型別的 JanusGraph 的話，需要弱化 Tag 和 Edge 的概念。然後，在資料型別支援方面二者也有出入，原生 Nebula Graph 對 MAP、LIST 之類的複雜型別支援程度不高。再者是索引的設計問題，在 Nebula Graph 中索引功能並非起到加速作用，而是 `LOOKUP` 此類搜尋的必備條件。此外，Nebula Graph 本身是不支援事務的，這塊給我們增加了不少的工作量。最後一點，是使用習慣的轉變，在查詢方式上 Nebula Graph 自研查詢語言 nGQL，而 JanusGraph 支援透過 Java API 和 Gremlin 進行查詢。

問題出現瞭如何解決呢？在強弱型別轉換上，BIGO 內部修改了 Atlas 的核心程式碼，增加引數動態判斷 DDL 資料型別。簡單來說，在寫入資料或者執行查詢時，透過特定引數來判斷該條 nGQL 操作何種資料型別。在資料型別支援方面，Atlas 業務層自定義資料序列化方式來支援複雜型別。在原生索引搜尋上，在系統初始化時自動建立獨立索引和複合索引解決 Atlas 的搜尋問題。在事務方面，在 Atlas 業務層新增半事務介面，減少 Nebula Graph 儲存層資料出錯的機率。

### Atlas 和 Nebula Graph 的改造

這裡，集中講述在圖引擎替換過程中 BIGO 對 Atlas 和 Nebula Graph 的改造。

在 Atlas 改造過程中，BIOG 新增 3w+ 行程式碼解藕 Atlas 和原生圖引擎 JanusGraph 並支援分散式圖引擎 Nebula Graph 讀寫。透過改造全文索引實現在 Atlas 層以 `INTERSECT` 方式多條件併發過濾查詢，從而提升搜尋速度。還將 Atlas 的多屬性更新改造為併發更新，加速後設資料入庫的更新速度。對消費訊息丟失的預處理上，BIGO 在 Atlas 層新增平滑退出機制，防止因重啟導致消費訊息丟失。此外，Atlas 透過支援自定義多種（反）序列化方式實現對複雜型別資料的支援。剛有提到過事務支援，在 Atlas 層新增 `Vertex#openTranscation/Vertex#commit` 介面支援半事務，減少由於 Nebula Graph 無事務回滾出錯。最後，在 Atlas 層合併大量獨立索引為複合索引，透過建立預設索引和屬性最佳化系統初始化速度。

而 Nebula Graph 方面，BIGO 也對其進行了改造。首先是對 `LOOKUP` 子句的改造，讓其支援併發執行，經測試掃描 100 萬資料的 Latency 從 8s 降低到了 1s。此外，支援了 `LOOKUP` 從 Elasticsearch 查詢分頁功能。再者，其他部分改造工作集中在 Elasticsearch，BIGO 支援了後端 ElasticSearch 中的資料更新和刪除；對 Listener 也做了 Commitsnapshot 的支援，以及全量資料的更新。對全文索引支援了 `REBUILD` 功能，並將 `REBUILD INDEX` 許可權下發到 admin 使用者。BIGO 還增加了單獨建立和刪除全文索引功能，避免所有的列寫入 ElasticSearch 增加其儲存使用量。最後，對 Nebula Graph 的定期 Compaction 操作也進行了最佳化，減少上層效能波動。

### 替換之後搜尋效能

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-03.png)

上圖展示了 BIGO 用 Nebula Graph 替換 JanusGraph 之後的搜尋效能。上圖 P99 需要耗時 2s 多的原因是搜尋總存在大搜尋，會拖慢搜尋速度。替換之後，搜尋速度提升 5 倍以上，從原先的 5s 返回結果降低到了 1s 以內；而且再也不會出現偶爾搜尋不到資料的問題，系統維護也無需額外維護索引，還支援了高併發和超大資料量儲存。

## 資料資產平臺應用

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-04.jpeg)

之前有分享過下層的統一後設資料平臺架構，這裡再來詳細講解下。如上圖所示，下層主要為統一後設資料平臺，上層則為產品應用層。左下部分為實時後設資料入庫模組，包括 Hive、Kyuubi、Oozie、Baina、CK（ClickHouse）、HDFS 等等資料來源，經過 Hook 透過 Kafka 訊息佇列寫入到統一後設資料庫平臺。統一後設資料庫平臺核心元件是 Atlas，其依賴 ClickHouse 和 Nebula Graph。此外，統一後設資料平臺還依賴 BIGO 內部的 OneSQL 平臺，主要是統一 SQL 查詢引擎，以及 Ranger 主要負責許可權管控。

而資料資產平臺上層則對接了應用層，包括：REST 介面、資料地圖、實時血緣、即席查詢、數倉建模、視覺化建表、離職交接、許可權管理等應用。

下面著重來介紹下相關應用。

### 資料地圖

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-05.png)

上圖為資料地圖-搜尋（部分），支援全域後設資料（HIVE、HDFS、CK、BAINA）搜尋與發現（資料來源還在增加中）、結果排序和下載、支援篩選、支援高階搜尋等功能。在搜尋介面，左側為篩選條件，頂部為搜尋框入口，下方為搜尋結果展示資料。

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-06.png)

上圖為資料地圖-詳情（部分），透過搜尋找到特定的後設資料之後，可點選檢視技術明細、資料計量、業務歸屬、生命週期、歷史趨勢等後設資料基礎資訊。在詳情介面，以上圖 HIVE 後設資料的詳情為例，主要分為上方的基本資訊和下方的明細資訊、血緣關係、資料預覽展示。

基本資訊羅列了昨日查詢次數 107 次，資料大小 1.27 TiB，佔用空間為 3.8 TiB…此外，透過【編輯】操作可對資料生命週期、業務線進行管理。

明細資訊（下方左側）羅列欄位資訊：HIVE 表的欄位、欄位型別、欄位相關描述，供產品、運營使用。下方右側為分割槽欄位資訊，如果某個資料是分割槽表的話，該模組會展示分割槽欄位的資訊；如果是個全量表的話，則不會展示分割槽欄位資訊。此外，資料血緣關係、資料預覽功能這裡不作詳細介紹。

### 實時血緣

在實時血緣模組，BIGO 重構了有向無環圖 DAG 圖，新增資料表格展示，實現了資料懶載入、關聯和搜尋工作流，在業務層的血緣關係圖裡實時地展示工作流的執行狀態。

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-07.png)

血緣模組支援圖表和視覺化兩類檢視，上圖選擇了視覺化檢視模式。視覺化檢視部分可在上、下游節點中選擇對應節點，配有【顯示過程】按鈕用來顯示或者隱藏過程工作流。舉個例子，a 表和 b 表，b 表是由 a 表透過一個工作流生成，開啟【顯示過程】按鈕則會展示該生成過程，關閉【顯示過程】則會遮蔽這個過程資料。

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-08.png)

上圖為資料血緣核心模組，展示了某個後設資料的上下游。左側浮動深度和過濾選項，可選擇以某個後設資料為中心的上下游層數（深度），比如，上圖就選擇了 tiki_core_india... 資料的 2 層上游和下游節點。

### 資料治理

資料治理這塊，主要展示 TTL 管理，用於管理通用打點表各個事件的生命週期。

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-09.png)

上圖為資料治理 TTL 管理部分截圖，從上文提到的資料地圖詳情部分點選【編輯】按鈕即可對資料進行 TTL 生命週期管理。當然，BIGO 資料治理除了生命週期管理之外，還有別的功能這裡不做詳細介紹。

### 資料建模

在資料建模方面，後設資料統一平臺提供 SQL 指令碼方式用來建立表模型，供數倉開發者和資料分析師互動使用。

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-10.png)

圖注：一條 SQL 模型資料

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-11.png)

圖注：資料建模入口

### 監控大盤

BIGO 內部的監控大盤實時展示公司資料，包括資源總量、各業務線資源佔比、變化趨勢和熱門資源等，從而推動團隊、業務線進行成本最佳化。

![BIGO 的資料管理與應用實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/bigo-data-governance-practice-12.png)

圖注：脫敏的大盤截圖

除了上述的應用之外，資料資產管理平臺還有模板取數、許可權管理、離職交接、群組管理、資料預覽，以及收藏下載等應用。

## Adhoc 即席查詢

### 業務背景

BIGO 原來使用 Cloudera HUE 作為即席查詢平臺，但由於多種原因，HUE 早已無法適配內部查詢需求，經常被使用者投訴難用且不穩定。主要原因有：

1. 程式碼陳舊，基本處於被開源放棄狀態；
2. BIGO 歷史原因經歷至少六位員工接手 HUE，堆積大量內部程式碼；
3. HUE 運維非常繁瑣；
4. 編輯視窗不符合使用者實際需求；
5. BIGO 已內部建設統一 SQL 路由器，無需讓使用者選擇執行引擎。

基於上述原因，決定自研一套全新 SQL 查詢平臺，解決上述問題，統一後設資料管理和資料查詢到資產管理平臺，並加入以下特性：第一點，建設統一 SQL 路由器（onesql），根據語法規則自動路由 SQL 到後端 sparksql/hive/presto/flinksql 引擎執行；第二點，提供全新查詢入口給使用者執行 SQL，並規範化 DDL 語句，為資料治理、許可權管理及成本控制提供便利；第三點，根據產品調研設計全新多 TAG 互動操作的編輯視窗；第四點，提供透過 SQL 建表 / LOAD 資料或透過視覺化建表 / LOAD 資料的功能；第五點，自動相容 pad / phone 等移動裝置端查詢，方便國內外同事使用；第六點，增加日常使用者訪問審計 / 全面監控告警；最後一點，支援在統一入口查詢 ClickHouse 資料（規劃中）。

## 未來展望

資料平臺未來規劃的話，主要圍繞：後設資料建設、產品增加、業務賦能三方面。

在後設資料建設方面，將會覆蓋接入層、計算層、排程層、儲存層所有平臺的後設資料。此外，我們還在規劃計算資源治理以及一站式任務開發（Python / Jar / Shell / SQL）等。

在產品增強方面主要分為治理、成本、效率、應用四塊內容，在治理方面，加強資料治理能力，自動治理不健康的資料；在成本方面，幫助公司各團隊實現成本分析閉環，為成本最佳化提供工具；在效率方面，透過規範建表、精準計量、查詢最佳化、血緣建設等提升使用者工作效率；在應用方面，進一步完善整合即席查詢和分散式排程系統功能，增強使用者使用體驗。

在業務賦能方面，將會進行智慧歸因診斷，賦能業務團隊自動分析問題能力。此外，還會迭代最佳化模板取數，賦能業務團隊簡單挖掘更多資料價值。

以上，為本次 BIGO 資料平臺實踐分享。
---

---
[Nebula 社群首屆徵文活動進行中！](https://discuss.nebula-graph.com.cn/t/topic/8304)? 獎品豐厚，全場景覆蓋：擼碼機械鍵盤⌨️、手機無線充?、健康小助手智慧手環⌚️，更有資料庫設計、知識圖譜實踐書籍? 等你來領，還有 Nebula 精緻周邊送不停～?

歡迎對 Nebula 有興趣、喜鑽研的小夥伴來書寫自己和 Nebula 有趣的故事呀～
![](https://oscimg.oschina.net/oscnet/up-099c19fd9316db17d22fc566b23d9e42ca7.jpg)

交流圖資料庫技術？加入 Nebula 交流群請先[填寫下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手會拉你進群~~

[關注公眾號](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)

BIGO 的資料管理與應用實踐

相關文章