重磅！Netflix開源大數據發現服務框架Metacat

策劃編輯 | Natalie

做者 | Ajoy Majumdar，Zhen Li

編譯 | 無明

編輯 | Natalie

AI 前線導讀： 喜聞樂見！Netflix 又貢獻了一個全新的開源項目！對於 Netflix 來講，開放開源是身爲技術公司的競爭戰略。既可以將本身的解決方案創建爲行業標準和最佳實踐，又能創建 Netflix 的技術品牌，還能從共享生態中得到反饋輸入並受益。

而過去幾年，Netflix 已經爲開源社區貢獻了不少很是成功的開源項目。Netflix 微服務技術棧的核心組件基本上都是開源的，如今你們耳熟能詳的 Zuul 網關、Eureka 服務發現註冊中心、Hystrix 熔斷限流、Archaius 配置等組件，Netflix 早在 2012 年左右就都開源出來了。今天，Netflix 又將其大數據發現服務框架 Metacat 開源了出來，旨在讓發現、處理和管理數據變得更爲方便。Netflix 官網技術博客對 Metacat 進行了詳細介紹，AI 前線將內容編譯以下。

更多優質內容請關注微信公衆號「AI 前線」，（ID：ai-front）

不少大公司都擁有大量的數據源，它們的數據格式不盡相同，並且體量巨大。在 Netflix，咱們的數據倉庫由不少大型的數據集組成，這些數據存儲在 Amazon S三、Druid、Elasticsearch、Redshift、Snowflake 和 MySql 中。咱們的平臺支持 Spark、Presto、Pig 和 Hive，咱們用它們來消費、處理和生成數據集。由於數據源的多樣性，爲了確保咱們的數據平臺可以橫跨這些數據集成爲一個「單一」的數據倉庫，咱們開發了 Metacat。Metacat 是一種元數據服務，方便咱們發現、處理和管理數據。

目 標

Netflix 大數據平臺的核心架構涉及三項關鍵服務：執行服務（Genie）、元數據服務和事件服務。這些想法並不是 Netflix 所獨有，在構建一個可以知足如今及將來規模的數據基礎設施時，就須要這樣的架構。

多年前，當咱們開始構建這個平臺時，咱們使用 Pig 做爲 ETL 語言，Hive 做爲專用查詢語言。因爲 Pig 自己並不具有元數據系統，所以對於咱們來講，構建一個能夠在二者之間進行互操做的方案彷佛是理想之選。

所以 Metacat 誕生了，這個系統充當了全部數據存儲的元數據訪問層，也是各類計算引擎能夠用來訪問不一樣數據集的集中式服務。Metacat 的三個主要目標是：

• 元數據系統的聯合視圖

• 用於數據集元數據的統一 API

• 數據集的任意業務和用戶元數據存儲

其餘擁有大量分佈式數據集的公司也面臨着相似挑戰。Apache Atlas、Twitter 的數據抽象層和 Linkedin 的 WhereHows（Linkedin 的數據發現服務）等等，都是爲了解決相似問題而構建的，只是他們都有各自的架構選擇。

Metacat

Metacat 是一種聯合服務，提供統一的 REST/Thrift 接口來訪問各類數據存儲的元數據。元數據存儲仍然是模式元數據的事實來源，因此 Metacat 沒有保存這部分元數據。Metacat 只保存業務相關和用戶定義的元數據。它還將全部關於數據集的信息發佈到 Elasticsearch，以便進行全文搜索和發現。

Metacat 的功能能夠分爲如下幾類：

• 數據抽象和互操做性

• 業務和用戶定義的元數據存儲

• 數據發現

• 數據變動審計和通知

• Hive Metastore 優化

數據抽象和互操做性

Netflix 使用多種查詢引擎（如 Pig、Spark、Presto 和 Hive）來處理和使用數據。經過引入通用的抽象層，不一樣的引擎能夠交互訪問這些數據集。 例如：從 Hive 讀取數據的 Pig 腳本可以從 Hive 列類型的表中讀取數據，並轉成 Pig 類型。在將數據從一個數據存儲移動到另外一個數據存儲時，Metacat 經過在目標數據存儲中建立具備目標類型的表來簡化這一過程。Metacat 提供了一組預約義的數據類型，可將這些類型映射到各個數據存儲中的數據類型。例如，咱們的數據移動工具使用上述功能將數據從 Hive 移動到 Redshift 或 Snowflake。

Metacat 的 Thrift 服務支持 Hive 的 Thrift 接口，便於與 Spark 和 Presto 集成。咱們所以可以經過一個系統聚集全部的元數據變動，併發布有關這些變動的通知，實現基於數據驅動的 ETL。當新數據到達時，Metacat 能夠通知相關做業開始工做。

業務和用戶定義的元數據

Metacat 也會保存數據集的業務和用戶定義元數據。咱們目前使用業務元數據來存儲鏈接信息（例如 RDS 數據源）、配置信息、度量指標（Hive/S3 分區和表）以及數據表的 TTL（生存時間）等。顧名思義，用戶定義的元數據是一種自由格式的元數據，可由用戶根據本身的用途進行定義。

業務元數據也能夠大體分爲邏輯元數據和物理元數據。有關邏輯結構（如表）的業務元數據被視爲邏輯元數據。咱們使用元數據進行數據分類和標準化咱們的 ETL 處理流程。數據表的全部者可在業務元數據中提供數據表的審計信息。他們還能夠爲列提供默認值和驗證規則，在寫入數據時會用到這些。

存儲在表中或分區中的實際數據的元數據被視爲物理元數據。咱們的 ETL 處理在完成做業時會保存數據的度量標準，在稍後用於驗證。相同的度量可用來分析數據的成本和空間。由於兩個表能夠指向相同的位置（如 Hive），因此要可以區分邏輯元數據與物理元數據。兩個表能夠具備相同的物理元數據，但應該具備不一樣的邏輯元數據。

數據發現

做爲數據的消費者，咱們應該可以輕鬆發現和瀏覽各類數據集。Metacat 將模式元數據和業務及用戶定義的元數據發佈到 Elasticsearch，以便進行全文搜索。咱們的 Big Data Portal SQL 編輯器所以可以實現 SQL 語句的自動建議和自動完成功能。將數據集組織爲目錄有助於消費者瀏覽信息，根據不一樣的主題使用標籤對數據進行分類。咱們還使用標籤來識別表格，進行數據生命週期管理。

數據變動通知和審計

做爲數據存儲的中央網關，Metacat 將捕獲全部元數據變動和數據更新。咱們還圍繞數據表和分區變動開發了通知推送系統。目前，咱們正在使用此機制將事件發佈到咱們本身的數據管道（Keystone），以更好地瞭解數據的使用狀況和趨勢。咱們也將事件發佈到 Amazon SNS。咱們正在將咱們的數據平臺架構發展爲基於事件驅動的架構。將事件發佈到 SNS 可讓咱們數據平臺中的其餘系統對這些元數據或數據變動作出「反應」。例如，在刪除數據表時，咱們的 S3 數據倉庫管理員服務能夠訂閱這些事件，並適當地清理 S3 上的數據。

Hive Metastore 優化

由 RDS 支持的 Hive Metastore 在高負載下表現不佳。咱們已經注意到，在使用元數據存儲 API 寫入和讀取分區方面存在不少問題。爲此，咱們再也不使用這些 API。咱們對 Hive 鏈接器（在讀寫分區時，該鏈接器直接與 RDS 通訊）進行了改進。以前，添加數千個分區的 Hive Metastore 調用一般會超時，在從新實現後，這再也不是個問題。

下一步

咱們在構建 Metacat 方面已經走了很長的一段路，但尚未完成咱們的使命。如下是咱們仍須要努力加強的一些特性。

• 模式和元數據的版本控制，用於提供數據錶的歷史記錄。例如，跟蹤特定列的元數據變動，或查看錶的大小隨時間變化的趨勢。可以查看過去某個時刻元數據的信息對於審計、調試以及從新處理和回滾來講都很是有用。

• 爲數據 lineage 服務提供數據表的上下文信息。例如，在 Metacat 中彙總數據表訪問頻率等元數據，併發布到數據 lineage 服務中，用於對數據表的關鍵性程度進行排序。

• 增長對 Elasticsearch 和 Kafka 等數據存儲的支持。

• 可插拔的元數據驗證。因爲業務和用戶定義的元數據是自由形式的，爲了保持元數據的完整性，咱們須要對其進行驗證。Metacat 應該有一個可插拔的架構，可在存儲元數據以前執行驗證策略。

相關連接

Metacat GitHub 地址：

https://github.com/Netflix/metacat

原文連接：

https://medium.com/netflix-techblog/metacat-making-big-data-discoverable-and-meaningful-at-netflix-56fb36a53520