知乎 Hive Metastore 实践：从 MySQL 到 TiDB

1. 数据的增长远比删除的要快，治标不治本；

2. 在删除超大分区表（分区数上百万）的分区时，会对 MySQL 造成一定的压力，只能单线程去做，否则会影响其他正常的 Hive 查询，效率极其低下；

3. 在知乎，元信息删除是伴随数据一起删除的（删除 HDFS 过期数据，节约成本），Hive 的用户可能存在建表不规范的情况，将分区路径挂错，导致误删数据。

其实问题主要在于，当数据量增加时，MySQL 受限于单机性能，很难有较好的表现，而将单台 MySQL 扩展为集群，复杂度将会呈几何倍上升。如果能够找到一款兼容 MySQL 协议的分布式数据库，就能完美解决这个问题。因此，我们选择了TiDB（https://github.com/pingcap/tidb）。

TiDB 是 PingCAP 开源的分布式 NewSQL 数据库，它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适 OLAP 场景的混合数据库。

选用 TiDB 的理由如下：

1. TiDB 完全兼容 MySQL 的协议，经过测试，TiDB 支持 Hive Metastore 对元数据库的所有增删改查操作， 使用起来不存在兼容性相关的问题。因此，除了将 MySQL 的数据原样 dump 到 TiDB，几乎没有其他工作需要做；

2. TiDB 由于其分布式的架构，在大数据集的表现远远优于 MySQL；

3. TiDB 的可扩展性十分优秀，支持水平弹性扩展，不管是选用分库分表还是 Federation，都可能会再次遇到瓶颈，届时需要二次切分和扩容，TiDB 从根本上解决了这个问题；

4. TiDB 在知乎已经得到了十分广泛的应用，相关技术相对来说比较成熟，因此迁移风险可控。

   ALTER TABLE '${table_name}' DROP IF EXISTS PARTITION(...);
   ALTER TABLE '${table_name}' ADD IF NOT EXISTS PARTITION(...);

SELECT `A0`.`PART_NAME`,`A0`.`PART_NAME` AS `NUCORDER0` FROM `PARTITIONS` `A0` LEFT OUTER JOIN `TBLS` `B0` ON `A0`.`TBL_ID` = `B0`.`TBL_ID` LEFT OUTER JOIN `DBS` `C0` ON `B0`.`DB_ID` = `C0`.`DB_ID` WHERE `C0`.`NAME` = '${database_name}' AND `B0`.`TBL_NAME` = '${table_name}' ORDER BY `NUCORDER0`

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/