IT 中的每个人都与数据打交道，包括前端和后端开发人员、分析师、QA 工程师、产品经理以及许多其他角色的人员。使用的数据和数据处理方法因角色而异，但数据本身往往不是关键。
在数据工程领域，数据不仅仅是“数据”——它是我们工作的命脉。大多数时候，这就是我们的全部工作。我们的代码以数据为中心，我们使用唯一真正的第五代语言——SQL。（第 5 代语言是那些让您定义您想要实现的目标并且语言本身为您解决问题的语言。）
但是，有一个巨大的“但是”。数据很酷，使用它令人兴奋，但访问它通常很麻烦。数据以多种不同的格式、不同的位置和不同的访问限制存储，并且以非常不同的方式构建。我们必须全部了解它们，查询它们，有时甚至将它们加入我们的查询中。
因此，我们需要一个可以管理所有关于数据存储的信息的地方。而这个地方就是 Hive Metastore。
Hive Metastore
根据亚马逊网站的定义，Hive Metastore 是作为 Apache Hive 的一部分开发的，Apache Hive 是“一种分布式、容错数据仓库系统，可以进行大规模分析” 。这基本上意味着您可以从一个地方查询所有内容。
Hive 通过成为有关数据存储的所有元信息的存储点来实现这一目标。凭借其 HQL 方言（与常规 SQL 相比有一些限制，但也有一些优势），Hive 允许您将任何数据结构投影到适合使用 SQL 查询的结构。
关于 Hive Metastore 的一个稍微令人困惑的事情是，尽管它的名称中有“Hive”，但实际上它与 Hive 是分开的并且完全独立于 Hive。
既然我们在谈论组件，让我们来探索 Hive Metastore 的架构。
架构
Hive Metastore 的实际架构非常简单：
由于数据被投射到 SQL 中，因此有关它的信息很容易映射到简单的关系结构，几乎以实体-属性-值的表示形式。例如，实体“表”-属性“名称”-值“点击流”。
Hive Metastore 将类型从底层存储投射到支持的 HSQL 类型，并存储有关底层数据位置的信息。这些数据存储在 Metastore 数据库中，通常是 MySQL、Postgres 或 Derby。
但是数据库本身只是一个实现细节。它的模式或多或少是流动的，它随着时间的推移而变化，没有任何事先通知。（好吧，如果您关注 hive-dev 邮件列表，您可以跟踪更改，但很少有人这样做。）该数据库仅用于一个目的：为 Thrift 服务器提供数据。
Metastore Thrift 服务器是其 Metastore 客户端的主要入口点。让我们暂时关注 Thrift。Thrift是一个 RPC 协议，最初由 Facebook 创建，现在由 Apache 软件基金会维护。任何一天我都会选择 Thrift 而不是非常流行的 gRPC，原因如下：
- 它有类型的异常。因此，您不仅可以从 RPC 内部获得随机异常，还可以实际了解发生了什么问题。
- 它有一个丰富的标准库（如果可以调用一组预定义的类型）。
- 与 gRPC 一样，它支持多种语言，但在我看来，Thrift 的生成器比 gRPC 的生成器生成的代码要好得多。
这个 Thrift 协议由 Facebook 开发，以满足其大数据生态系统的需求，但这也使其非常适合 Hive，在我看来，也适合其他生态系统。
因此，回到 Thrift 服务器，它是一个相当简单的应用程序，其 API 可让您获取有关 Hive Metastore 知道的数据源的必要信息。它是有类型的，但您仍然可以将它与 Python 等动态类型语言一起使用，Thrift 的代码生成器也支持这些语言。
架构的下一部分是……没有更多的部分了！包括 Hive 本身在内的所有客户端仅与 Hive Metastore thrift 服务器通信。Thrift 服务器非常简单，我们可以使用 Thrift 服务器的单个 docker 容器启动它（假设我们将使用 Derby 作为 Metastore 数据库）。当然，这对于生产环境来说是一种罕见的设置，但它对于实验来说非常方便。
第三方系统的使用
最好的部分来了：许多新系统只需要了解 Thrift 服务器并与之通信。他们不需要 Hive 或任何其他查询引擎来访问数据。
这种系统的一个例子是Trino，它是 PrestoDB的衍生产品，由一家名为Starburst的独立公司开发。使用 Trino 时，不需要安装 Hive。只有 Hive Metastore 就足够了。Trino 在 Docker 容器中启动也非常简单——只需一个命令即可。
LakeFS也是如此，该系统允许您使用类似 Git 的界面来处理数据湖。当您需要在不同的数据源之间快速切换时以及在许多其他情况下，这可能非常有用。在 Hive Metastore 的帮助下，集成非常简单。
批评
像大多数事情一样，Hive Metastore 并不完美。来自lakeFS 的Oz Katz 写了一篇关于Metastore 局限性的精彩文章。他认为 Metastore 存在三个问题：
- “节俭。” 虽然 Thrift 不像 HTTP 那样普及，但它是建立在 HTTP 之上的，所以我认为许多流行的工具都可以很好地使用它（例如 HAProxy）。但确实，您不能仅仅从 Thrift 流量中捕获一条随机消息并理解它在说什么。我同意这是一个小缺点。
- “Metastore 只是 RDBMS 之上的一个薄层。” 如果我正确理解这个论点，由于 Hive 的分区方案和关系数据库的缺点，非常大的 Hive 表在使用 Metastore 时会让人头疼。同样，这是一个有效的批评，但在这里我应该注意，我们实际上不必将 Metastore 与 Hive 一起使用。我们也可以将它与不同的工具一起使用，如果我们有其他满足我们需求的解决方案，我们也不必使用分区。
- “泄漏的抽象。” 这是一个非常有效的批评，很难反驳。不过，我不知道有任何抽象根本不会泄漏。是的，Metastore 可能比其他一些更容易泄漏，但有时您可以将这个问题转化为在需要时进行微调的机会。当然，这只有在您确切知道自己在做什么时才有可能，但我想说这适用于那里的任何工具。
概括
今天我们讨论了 Hive Metastore 是什么，它是如何工作的，以及它的用途。我们简要概述了几种使用 Hive Metastore 的产品，并讨论了该技术的一些优缺点。
那么，为什么我们最终需要 Hive Metastore 呢？因为它存储了有关我们数据结构及其位置的所有信息。这就是为什么许多大公司都在使用它，效果很好的原因。
我们很清楚，我们的许多客户都在使用 Hive Metastore 或其 Amazon 实施 Glue Data Catalog。它们都是很棒的工具，用户应该拥有一个工具，它可以帮助他们以更有效的方式使用 Metastore，而不仅仅是使用 Hive 查询事物。
