為什么我們需要 Hive Metastore！
IT 中的每個人都與數(shù)據(jù)打交道，包括前端和后端開發(fā)人員、分析師、QA 工程師、產(chǎn)品經(jīng)理以及許多其他角色的人員。使用的數(shù)據(jù)和數(shù)據(jù)處理方法因角色而異，但數(shù)據(jù)本身往往不是關鍵。
——“這是一把非常特別的鑰匙，只適用于 The One”
重新加載的矩陣
——“它能解鎖什么？”
- “未來”
在數(shù)據(jù)工程領域，數(shù)據(jù)不僅僅是“數(shù)據(jù)”——它是我們工作的命脈。大多數(shù)時候，這就是我們的全部工作。我們的代碼以數(shù)據(jù)為中心，我們使用唯一真正的第五代語言——SQL。（第 5 代語言是那些讓您定義您想要實現(xiàn)的目標并且語言本身為您解決問題的語言。）
但是，有一個巨大的“但是”。數(shù)據(jù)很酷，使用它令人興奮，但訪問它通常很麻煩。數(shù)據(jù)以多種不同的格式、不同的位置和不同的訪問限制存儲，并且以非常不同的方式構建。我們必須全部了解它們，查詢它們，有時甚至將它們加入我們的查詢中。
因此，我們需要一個可以管理所有關于數(shù)據(jù)存儲的信息的地方。而這個地方就是 Hive Metastore。
Hive Metastore
根據(jù)亞馬遜網(wǎng)站的定義，Hive Metastore 是作為 Apache Hive 的一部分開發(fā)的，Apache Hive 是“一種分布式、容錯數(shù)據(jù)倉庫系統(tǒng)，可以進行大規(guī)模分析” 。這基本上意味著您可以從一個地方查詢所有內容。
Hive 通過成為有關數(shù)據(jù)存儲的所有元信息的存儲點來實現(xiàn)這一目標。憑借其 HQL 方言（與常規(guī) SQL 相比有一些限制，但也有一些優(yōu)勢），Hive 允許您將任何數(shù)據(jù)結構投影到適合使用 SQL 查詢的結構。
關于 Hive Metastore 的一個稍微令人困惑的事情是，盡管它的名稱中有“Hive”，但實際上它與 Hive 是分開的并且完全獨立于 Hive。
既然我們在談論組件，讓我們來探索 Hive Metastore 的架構。
架構
Hive Metastore 的實際架構非常簡單：
由于數(shù)據(jù)被投射到 SQL 中，因此有關它的信息很容易映射到簡單的關系結構，幾乎以實體-屬性-值的表示形式。例如，實體“表”-屬性“名稱”-值“點擊流”。
Hive Metastore 將類型從底層存儲投射到支持的 HSQL 類型，并存儲有關底層數(shù)據(jù)位置的信息。這些數(shù)據(jù)存儲在 Metastore 數(shù)據(jù)庫中，通常是 MySQL、Postgres 或 Derby。
但是數(shù)據(jù)庫本身只是一個實現(xiàn)細節(jié)。它的模式或多或少是流動的，它隨著時間的推移而變化，沒有任何事先通知。（好吧，如果您關注 hive-dev 郵件列表，您可以跟蹤更改，但很少有人這樣做。）該數(shù)據(jù)庫僅用于一個目的：為 Thrift 服務器提供數(shù)據(jù)。
Metastore Thrift 服務器是其 Metastore 客戶端的主要入口點。讓我們暫時關注 Thrift。Thrift是一個 RPC 協(xié)議，最初由 Facebook 創(chuàng)建，現(xiàn)在由 Apache 軟件基金會維護。任何一天我都會選擇 Thrift 而不是非常流行的 gRPC，原因如下：
它有類型的異常。因此，您不僅可以從 RPC 內部獲得隨機異常，還可以實際了解發(fā)生了什么問題。
它有一個豐富的標準庫（如果可以調用一組預定義的類型）。
與 gRPC 一樣，它支持多種語言，但在我看來，Thrift 的生成器比 gRPC 的生成器生成的代碼要好得多。
這個 Thrift 協(xié)議由 Facebook 開發(fā)，以滿足其大數(shù)據(jù)生態(tài)系統(tǒng)的需求，但這也使其非常適合 Hive，在我看來，也適合其他生態(tài)系統(tǒng)。
因此，回到 Thrift 服務器，它是一個相當簡單的應用程序，其 API 可讓您獲取有關 Hive Metastore 知道的數(shù)據(jù)源的必要信息。它是有類型的，但您仍然可以將它與 Python 等動態(tài)類型語言一起使用，Thrift 的代碼生成器也支持這些語言。
架構的下一部分是……沒有更多的部分了！包括 Hive 本身在內的所有客戶端僅與 Hive Metastore thrift 服務器通信。Thrift 服務器非常簡單，我們可以使用 Thrift 服務器的單個 docker 容器啟動它（假設我們將使用 Derby 作為 Metastore 數(shù)據(jù)庫）。當然，這對于生產(chǎn)環(huán)境來說是一種罕見的設置，但它對于實驗來說非常方便。
第三方系統(tǒng)的使用
最好的部分來了：許多新系統(tǒng)只需要了解 Thrift 服務器并與之通信。他們不需要 Hive 或任何其他查詢引擎來訪問數(shù)據(jù)。
這種系統(tǒng)的一個例子是Trino，它是 PrestoDB的衍生產(chǎn)品，由一家名為Starburst的獨立公司開發(fā)。使用 Trino 時，不需要安裝 Hive。只有 Hive Metastore 就足夠了。Trino 在 Docker 容器中啟動也非常簡單——只需一個命令即可。
LakeFS也是如此，該系統(tǒng)允許您使用類似 Git 的界面來處理數(shù)據(jù)湖。當您需要在不同的數(shù)據(jù)源之間快速切換時以及在許多其他情況下，這可能非常有用。在 Hive Metastore 的幫助下，集成非常簡單。
批評
像大多數(shù)事情一樣，Hive Metastore 并不完美。來自lakeFS 的Oz Katz 寫了一篇關于Metastore 局限性的精彩文章。他認為 Metastore 存在三個問題：
“節(jié)儉?！?nbsp;雖然 Thrift 不像 HTTP 那樣普及，但它是建立在 HTTP 之上的，所以我認為許多流行的工具都可以很好地使用它（例如 HAProxy）。但確實，您不能僅僅從 Thrift 流量中捕獲一條隨機消息并理解它在說什么。我同意這是一個小缺點。
“Metastore 只是 RDBMS 之上的一個薄層?！?nbsp;如果我正確理解這個論點，由于 Hive 的分區(qū)方案和關系數(shù)據(jù)庫的缺點，非常大的 Hive 表在使用 Metastore 時會讓人頭疼。同樣，這是一個有效的批評，但在這里我應該注意，我們實際上不必將 Metastore 與 Hive 一起使用。我們也可以將它與不同的工具一起使用，如果我們有其他滿足我們需求的解決方案，我們也不必使用分區(qū)。
“泄漏的抽象。” 這是一個非常有效的批評，很難反駁。不過，我不知道有任何抽象根本不會泄漏。是的，Metastore 可能比其他一些更容易泄漏，但有時您可以將這個問題轉化為在需要時進行微調的機會。當然，這只有在您確切知道自己在做什么時才有可能，但我想說這適用于那里的任何工具。
概括
今天我們討論了 Hive Metastore 是什么，它是如何工作的，以及它的用途。我們簡要概述了幾種使用 Hive Metastore 的產(chǎn)品，并討論了該技術的一些優(yōu)缺點。
那么，為什么我們最終需要 Hive Metastore 呢？因為它存儲了有關我們數(shù)據(jù)結構及其位置的所有信息。這就是為什么許多大公司都在使用它，效果很好的原因。
我們很清楚，我們的許多客戶都在使用 Hive Metastore 或其 Amazon 實施 Glue Data Catalog。它們都是很棒的工具，用戶應該擁有一個工具，它可以幫助他們以更有效的方式使用 Metastore，而不僅僅是使用 Hive 查詢事物。