网易杭研大数据实践：网易杭研大数据实践：Apache Hive稳定性测试稳定性测试
编辑推荐编辑推荐:
本文主要介绍了Apache Hive稳定性测试的背景、稳定性测试分析、稳定性测试实
践与总结及展望，希望对你有帮助。
本文来自知乎，由火龙果软件Linda编辑、推荐。
1. 背景
Hive是Apache开源的数据仓库工具，主要是将基于Hadoop的结构化数据文件映射为数据库表，并提供类SQL查询功能。Hive
最初的目标是为了降低大数据开发的门槛，它屏蔽了底层计算模型的复杂开发逻辑，类SQL的查询功能也便于数据应用的开
发，但Hive并不适合哪些低延迟的查询服务，如联机事务处理（OLTP）类查询，主要用于离线数据分析，数据量一般都巨
大，一般会有分钟级的查询延迟。
随着大数据的发展，Hive衍生出了基于Thrift的RPC服务Hiveserver2、Metastore，便于进行规模化的运维及扩展。网易杭研
研发的大数据平台网易猛犸的数仓建设及离线分析均是基于Hive，权限、血缘及其他基于Hadoop的类SQL计算引擎也与Hive
密不可分。面对业务数据分析需求的不断增加，数仓及数据开发任务的规模也在不断扩大，给Hive带来的挑战也越来越大，一
旦服务的稳定性出现问题，用户侧所有的数据应用也都可能陷入瘫痪。
从线上Hive的历史运维及发展来看，主要存在以下几个痛点：
社区版本遗留的问题：线上故障频繁出现，大压力场景下服务FullGC、异常退出等情况；
依赖组件带来的风风险：服务链路较长，依赖服务的异常往往会导致Hive服务出现不可恢复的异常；
变更带来的风险：随着业务的发展，血缘、权限、UDF的扩展越来越多，往往会对服务带来不可预知的影响。
痛定思痛之下，我们将Hive的稳定性保障作为工作的重点，目标是提升Hive服务的可用率，一方面保证版本迭代更新后线上服
务稳定可用，另一方面当故障出现时有对应的预案，能够快速的恢复，减少故障的定位及恢复时间。
2 Hive稳定性测试分析
2.1 线上问题分析
在进行Hive的稳定性测试之前，首先需要对线上当前的稳定性问题进行分析，综合历史所有的线上故障，主要原因在以下几个
方面：
大并发大压力场景下，服务偶现异常；
大数据场景下的特定SQL导致服务内存溢出。
扩展JAR可能会导致服务进程异常退出；
依赖组件的异常导致服务不可用且无法恢复。
基于上述的问题，主要从压力测试、故障注入两个方面来进行保障。在压力测试方面，除了需要流量模型的构造外，还需要重
点关注请求SQL、数据场景，这就需要对线上场景充分分析后进行模拟，在故障注入方面，需要首先对架构及链路进行分析。
2.2 压测方案
2.2.1 测试环境
Hiveserver2/Metastore 线上部署均采用Zookeeper来做高可用及随机的负载均衡，且均为混部的方式（即Hiveserver2、
Metastore 部署于同一节点），以线上某集群为例，存在2节点的Hiveserver2及Metastore。
稳定性测试环境的部署拓扑需要与线上保持一致，且服务的核心配置需要与线上保持一致或者按照服务器规格进行一定比例的
缩小。这里需要重点关注的是，线上线下最大的差异在于底层的存储及计算资源，线上Hadoop集群规模往往在数百个节点甚
至上千个节点，线下测试环境受限于成本，一定与生产环境存在较大差异，这就需要在铺地数据、流量构造方面针对测试环境
资源进行针对性的构造。
2.2.2 SQL场景构建
综合对于HQL的分析，可以将SQL大致分为三类，DDL、DML及DQL
DDL主要是Hive库、表、列、分区进行创建、修改、删除相关的操作，此类操作一般SQL相对简单执行耗时较短，主要的压力
在于对于Metastore元数据的增删改查。这里需要重点注意partition的数据铺地，在Hive元数据中通常来说只有partitions数据
可以达到百万级别（库表数据的量级往往较小）。
评论0