而過去幾年，Netflix 已經為開源社群貢獻了很多非常成功的開源專案。Netflix 微服務技術棧的核心元件基本上都是開源的，現在大家耳熟能詳的 Zuul 閘道器、Eureka 服務發現註冊中心、Hystrix 熔斷限流、Archaius 配置等元件，Netflix 早在 2012 年左右就都開源出來了。今天，Netflix 又將其大資料發現服務框架 Metacat 開源了出來，旨在讓發現、處理和管理資料變得更為方便。Netflix 官網技術部落格對 Metacat 進行了詳細介紹，AI 前線將內容編譯如下。
更多優質內容請關注微信公眾號“AI 前線”，（ID：ai-front）
很多大公司都擁有大量的資料來源，它們的資料格式不盡相同，而且體量巨大。在 Netflix，我們的資料倉儲由很多大型的資料集組成，這些資料儲存在 Amazon S3、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 是一種聯合服務，提供統一的 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 上的資料。
由 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