Hive MetaStore 的挑战及优化方案
Hive MetaStore 的挑战及优化方案
Apache Hive的元数据存储组件Hive MetaStore在大数据处理中扮演着关键角色。随着业务规模的不断扩大，Hive MetaStore面临着巨大的挑战。本文深入探讨了Hive MetaStore的架构、问题，并提供了多种优化方案，包括数据库层面的分库分表、读写分离、分布式数据库，以及Hive层面的API优化、WaggleDance和MetaStore Federation等。这些方案各有优劣，企业可以根据自身需求和资源选择最适合的优化策略。
Hive 简介
Apache Hive 是基于 Apache Hadoop 之上的数据仓库工具，提供 SQL 查询能力，用于大规模数据的提取、转换、加载、分析等。
Hive MetaStore（简称 HMS）是 Hive 架构中的关键组件，它是一个中心化的元数据存储库，用于存储Hive 表、分区以及数据库的元数据信息。这些元数据包括表的名称、列、数据类型、分区方案、存储位置等信息。其中，元数据信息一般存储在关系型数据库中，如 Derby、MySQL 等。
Hive 元数据库表结构
Hive 元数据中，对DB、Table、SDS（文件相关信息）等的管理比较细化，比如库相关的信息，存储在以 DBS 表、DATABASE_PARAMS 表、DB_PRIVS等表中，元数据信息储存采用三范式设计，表的外键很多。
以 DBS 表为中心的 ER 图：
以 TBLS 表为中心的 ER 图：
以 PARTITIONS 表为中心的 ER 图：
以 SDS 表为中心的 ER 图：
Hive MetaStore 的问题
在 Hive 中，元数据存储在元数据库（比如 MySQL 等），随着业务的不断发展，元数据也呈爆炸式增长。在很多知名互联网公司，Hive 表很多表分区数超百万乃至亿级规模，Hive 元数据中出现单表数据上亿规模，单日新增分区数几万乃至几十万的情况，对 MetaStore 乃至 MySQL 服务造成日益严重的挑战。
数据量大，再加上 Hive 元数据库表设计外键很多、关联很多，导致每次查询库表分区信息的查询时延会越来越大，并发请求多时，就会引起 MetaStore 查询元数据阻塞，最终导致整个大数据相关的查询任务延迟。
优化方案
数据库篇
1、分库分表
MetaStore 的压力，源自底层元数据库的数据量过大。解决 MySQL 数据量大的解决方案之一就是对 MySQL 进行分库分表。无论是垂直分表还是水平分表，通过 MetaStore 查询 MySQL 都需要修改大量的逻辑，对 Hive 调整巨大，如果使用这种方案改动较大，不仅风险及开发成本很高，而且后续运维及升级也会带来很多的工作量。
优点：分库分表技术成熟，理论上能够解决 MySQL 数据量及压力大的问题；
缺点：风险及开发成本高，后续运维及升级工作量很多；
实践：目前没有看到有哪家公司采用该方案；
2、读写分离
对 Hive 的元数据查询请求大的不止是计算引擎侧，还有来自数据地图、数据血缘等上层服务也高度依赖 MetaStore 及元数据。鉴于这些服务主要执行查询操作，如此，我们可以把 MetaStore 服务分为读写型和只读型两种模式，或者说，搭建只读 MetaStore 服务集群及读写 MetaStore 服务集群，同时读写 MetaStore 服务集群作为主集群，对应的 MySQL 库为主库，只读 MetaStore 服务集群单独一套 Mysql 数据库作为从库，开启 MySQL 主从数据库的数据同步功能即可。
在大数据查询场景中，既有读请求也有写请求，没有办法在服务层面进行区分开来。需要在查询层面实现 MetaStore API 粒度的读写分离，把对主库的读请求路由到从库，从而降低主库的压力。在这里需要注意的是，要保证主从数据的数据一致性，避免主从同步延迟带来读请求的漏读或者读取过期数据。
优点：开发成本相对较低，能很大程度上减少主库的压力。
缺点：并不能从根本解决主库数据量大的问题
实践：快手等公司都有进行此优化
3、分布式数据库
MySQL 受限于单机性能，在数据量过大时，超过了其本身处理能力，很难有较好的表现，而将单台 MySQL 扩展为集群，复杂度将会呈指数上升。而如果采用分布式数据库，并且能够完全兼容 MySQL 协议，把单机元数据库改为分布式数据库，就可以解决问题。所以，业界有公司采用 TiDB 数据库。
TiDB 是一个开源分布式 SQL 数据库，支持混合事务和分析处理 (HTAP) 工作负载。它与 MySQL 兼容，具有水平可扩展性、强一致性和高可用性。其为分布式架构，在处理海量数据集时比 MySQL 有更好的性能及表现。并且其优秀的可扩展性，能够在数据量逐步增多时，也能通过扩展集群容纳解决，而不需要对数据集进行切分或者进一步的架构设计。
但是，Hive 元数据设计比较复杂，主键、外键等较多，并且 MetaStore 查询 MySQL 存在各种关联查询，使用 TiDB 存在未知的风险。
优点：开发成本较低，可扩展；
缺点：需要做大量兼容及性能测试，并且存在未知的风险，需要相对强大的团队运维 TiDB；
实践：目前 VIVO 及知乎，都已经采用该方案，并且运行相对稳定；
Hive 篇
1、MetaStore API 优化
MetaStore 的 API 以及查询 MySQL 的接口，本身的一些问题，会随着数据量的增大而逐步显现。
大量的 API 调用，会造成 MySQL QPS 过高。比如 Hive 早期 1.2 版本中，初始化会先请求 get_database 获取所有的 Hive 库，然后对每个 Hive 库分别调用 get_functions 接口，接口调用次数和总的 Hive 库数量成正比，导致了大量冗余调用。Hive 2.3版本中已经针对这种情况进行了优化。
某些 API 调用所查询的数据量过大，导致 MySQL 压力过大。比如 DESC TABLE 请求中，会遍历目标表所有的分区信息，对于大分区的表而言，查询耗时会很高。
所以，对 MetaStore 进行 API 优化，会解决一些 Hive 固有的问题。
优点：一定程度上解决 MetaStore 的问题；
缺点：需要持续不断的发现 MetaStore 的问题，分析并解决；对 Hive 源码也有一定的侵入性；
实践：快手等公司都有进行此优化；
2、WaggleDance
WaggleDance 是一个开源项目（github.com/ExpediaGrou…），并在 Hive 官网推荐使用的一个组件。
该项目主要是做多个 MetaStore 的联邦查询服务，实现了一个跨多个 MetaStore 集群的代理网关。在 Hive DB 层面进行切割划分为不同的 MetaStore 集群，即多个不同的 MySQL 元数据库。WaggleDance 本身在 MetaStore 前方作为代理，向客户端隐藏了底层的多个 MetaStore 集群，并承接来自 HIveServer2 及其他地方的请求，按照指定的库与 MetaStore 集群的对应关系，进行路由转发。WaggleDance 实现了几乎全部的 MetaStore 的 Thrift API，客户端无需做任何改动。即，对使用方或调用方来说，WaggleDance 就是 MetaStore 服务本身。
官方架构图如下：
优点：对 MetaStore 本身不需要做任何修改，易于维护；
缺点：增加组件，MetaStore 配置容易不统一，需要迁移 Hive 元数据，需要对库与 MetaStore 集群映射关系精密设计，数据地图等元数据使用方需要变更；
实践：滴滴采用该方案，腾讯采用同样的思想自研组件；
3、MetaStore Federation
方案一：在 MetaStore 内部，RawStore 作为底层的物理存储操作接口，用于逻辑层和物理底层元数据库的交互。其中，ObjectStore 是 RawStore 的默认实现类。
在 MetaStore 加入一个基于 ObjectStore 的 FederationStore 的角色，该角色可以理解为一个路由器，MetaStore 在查询库表元数据信息时，通过 FederationStore 获取所要访问的元数据信息存放在哪个MySQL 库中，获取到具体的 MySQL 后，再构建相应的 ObjectStore 进行元数据查询。
方案二：在 MetaStore 中，HiveMetaStore.HMSHandler 继承自 IHMSHandler，而 IHMSHandler 又继承自 ThriftHiveMetastore.Iface，在 HMSHandler 中实现了所有操作的对外方法。路由的功能也可以放在 HMHandler 中实现。
优点：运维成本低，配置统一，可解决 MetaStore 的问题；
缺点：有相当的源码改造成本；
实践：B 站、快手采用此方案；
总结
以上方案中，读写分离、MetaStore API 优化，并不算是独立的解决方案，是优化方案。而分布式数据库、WaggleDance、MetaStore Federation 都是完整的解决方案，各有利弊。
除了以上的方案，我们也可以同时采用流量控制、流量降级等方案，来保证流量高峰时段高优先级任务的访问请求。
在选择具体的解决方案的时候，需要依据自身的需要和研发力量，大数据环境，以及对业务影响的可接受程度等因素综合考虑，最终确定。