快手大数据统一安全平台

Posted 2022-03-17 快手大数据

关注快手大数据 获取大数据资讯

导 读

本文主要介绍快手大数据统一安全平台。本文源自马玲玲老师在『快手大数据｜数据中台技术交流会』上的演讲，相关视频回放可用快手APP搜索“快手大数据”观看。

本文会分四个部分展开介绍。首先，对相关的背景进行介绍，包括快手大数据安全解决的问题、比较经典的数据安全理论和快手大数据安全遇到的挑战；其次，会重点介绍我们的解决方案，包括具体的落地路径、平台的发展历程和架构；再次，会重点介绍我们平台的一些核心技术；最后，会介绍我们当前取得的进展和未来的规划。

一、背景介绍

随着大数据时代的来临，数据是公司的核心竞争力，数据的泄露会给公司带来严重的损害。因此，大数据安全的建设尤为重要和关键。大数据安全其实就是保障大数据资产全生命周期处理的安全性和合规性。那什么是大数据资产呢？在大数据场景下，任何的数据实体都可以叫做大数据资产。比如，大家比较熟悉的HIVE表，以及应用系统的数据集、报表等。数据的生命周期包括从数据采集、数据传输、数据存储、数据处理、数据应用到数据销毁的全过程。大数据安全就是要保证全生命周期的各个过程数据处理的安全性。合规性是需要满足国家的法律法规的要求和公司法务的合规要求。

下面我来重点介绍下数据安全的两个经典理论。

第一个经典理论就是数据安全能力成熟度模型，简称DSMM。2019年8月30日，该模型正式成为国标对外发布，并于2020年3月起正式实施。该标准从三个维度全方位介绍了数据安全能力该如何进行建设，适用于作为组织数据安全能力的评估依据或者建设依据。

安全能力维度：通过对组织各数据安全过程应具备安全能力的量化，进而评估每项安全过程的实现能力。安全能力分为以下4个方面：

组织建设：数据安全组织的设立、职责分配和沟通协作;

制度流程：组织数据安全领域的制度和流程执行;

技术工具：通过技术手段和产品工具落实安全要求或自动化实现安全工作;

人员能力：执行数据安全工作的人员的安全意识及相关专业能力。

数据安全过程维度：包括通用安全和数据生存周期安全过程。

能力成熟度等级：数据安全能力成熟度等级分为五级：

非正式执行：随机、无序、被动的执行安全过程，依赖于个人经验，无法复制；

计划跟踪：在业务系统级别主动地实现了安全过程的计划与执行，但没有形成体系化；

充分定义：在组织级别实现了安全过程的规范执行；

量化控制：建立了量化目标，安全过程可度量；

持续优化：根据组织的整体目标，不断改进和优化安全过程。

第二个经典理论就是安全架构5A方法论。其中5A包括：

认证（Authentication）：判断访问主体是谁，解决身份问题；

授权（Authorization）：授予访问主体允许或者拒绝访问客体的权限；

访问控制（Access Control）：判断是否有权限的执行者；

资产保护（Asset Protection）：资产的保密性、完整性和可用性保障；

可审计（Auditable）：形成可供追溯的操作日志。

以上两个理论对快手大数据安全的体系化建设提供了很大的指导意义。下面我来介绍快手大数据安全建设遇到的挑战：

系统覆盖度广：快手大数据安全需要对底层的大数据引擎、数据中台工具和数据应用类平台等全链路系统进行安全管控。因此，我们需要提供一个通用的数据安全平台，满足通用的数据安全要求，保证系统的通用性。

数据精细化管控：我们需要支持报表、数据集、指标、维度等应用类资产和库、表、行、列、文件等底层引擎类资产的权限控制；同时还要对资产的读、写等操作进行细粒度的权限控制；还需要与快手特有的多租户体系相结合，实现数据的多级隔离。因此，就要求我们的权限模型足够灵活，满足数据精细化的管控需求。

业务灵活多变：我们需要满足多种业务线的权限管控需求，也需要满足数据应用类平台灵活多变的业务需求，这就要求我们平台需要具有良好的扩展性。

性能要求高：我们需要支撑千级的用户、百万资源的亿级规模的权限矩阵，同时还需要满足鉴权毫秒级的延时；还需要支持OLAP每天亿级的查询和HDFS百万级QPS等。因此，要求我们的平台具备高可用和高性能的保障机制。

二、解决方案

下面重点介绍快手大数据安全建设过程中的解决方案。我们通过参考数据安全能力成熟度模型，从组织保障、流程规范和平台工具三个方面进行体系化的建设。概括来说就是组织制定安全战略和方向，沉淀为统一的流程规范，然后由平台提供工具化支撑并落地。

快手大数据到目前为止经历了四个阶段：

初始阶段：在2018年，平台还处于原始阶段，权限粒度比较粗糙，平台能力方面只提供了简单的申请和授权的能力，而且功能比较难用，接入系统只覆盖了数据平台部门的部分应用类系统。因此，我们开始考虑衍化。

V1.0（一站式）：在2019年，我们迭代了V1.0版本，引入了全新的权限模型，提供了一站式权限管理的能力，包括申请、审批、授权、清查、回收，同时接入了第一个大数据引擎HIVE。在2019年下半年我们开始与公司安全组共建，成立数据安全工作小组，沉淀了数据权限申请规范、数据分类分级规范等。

V2.0（精细化）：在2020年，我们迭代了V2.0版本，提供精细化权限管控能力，包括行级权限、多租户数据隔离等，同时提供了认证和全链路审计的能力，也逐步接入了数据中台类的平台。

V3.0（数据合规）：在2021年，随着快手上市，公司对数据保护的能力要求越来越高，因此我们迭代了V3.0版本，以满足数据合规为目标，提供了字段加解密/脱敏等能力，同时全部覆盖底层的大数据存储引擎。

下面我来介绍下大数据统一安全平台的整体架构。

应用层：覆盖了数据应用、数据中台和大数据引擎全链路系统/组件；

接口层：提供了统一的REST和RPC API；

服务层：可以归纳为四个统一、一个Plugin和一个系统保障。四个统一分别为：统一服务层提供通用的认证、鉴权、查询、审计等服务；统一计算层提供模型和规则的计算；统一存储层提供缓存管理、缓存数据加载及版本管理等；统一接入层负责平台管控资源的接入、账号信息的同步等。一个Plugin是指每个大数据引擎都会引入大数据安全的plugin组件，满足各个引擎自身的特点，比如高QPS、低延时等；一个系统保障是指通过采用监控告警、降级容错、预案演练、限流等一系列措施保障系统的高可用，采用多级缓存等保障系统的高性能等。在服务层，我们还会依赖公司的外部系统，比如依赖流程中心提供审批的能力、与安全组共建审计、与生产管理和组织架构同步账号信息等。

存储引擎层：我们使用了三个存储引擎。我们的数据主要存储在mysql中，热点数据存储在REDIS中，MYSQL中的数据会定期同步至HIVE，以作冷备份和构建我们平台的离线数仓。

三、核心技术

下面对平台的核心技术做详细介绍，主要包括权限模型抽象、认证服务、鉴权服务、全链路审计和敏感数据保护。

首先，先介绍我们平台的基石权限模型。经典的权限模型包括ACL模型、RBAC模型、PBAC/ABAC模型。ACL模型是指用户和资源直接建立权限关系；RBAC模型是角色和资源直接建立权限关系，用户通过加入角色获得相应的权限；PBAC/ABAC模型是基于主体、环境或者客体的属性进行权限控制。ACL和RBAC在传统的功能权限场景使用的较多，但是对于数据权限场景，无法表达资源之间复杂的关系。而PBAC/ABAC模型虽然比较灵活，但只有在运行时才知道是否有权限，所以很难进行管理。

综上，我们通过参考已有的权限模型，并根据快手大数据的场景和需求，自研了一套组合RBAC和PBAC的PRBAC权限模型。该模型以策略为中心，整合了角色、资源、动作和条件四个核心要素。角色支持组合自定义两种类型。大数据场景的资源比较复杂，比如一个报表可以依赖多个数据集，数据集又依赖不同的指标维度，指标维度又可能来自于不同的库、表、行或列。因此大数据资源我们使用URN来进行表示，由公司域、资源域和唯一ID组成，而且资源之间支持继承和虚拟分组的关系。动作支持洞察、生产、读、写等类型。我们使用条件和规则语言来对大数据场景的行列权限进行抽象。

认证解决身份的问题，就是证明“我”就是“我”。我们的认证方案在选型的时候，遇到了一些挑战：

轻量级：快手当前大数据集群的规模比较大，而且已经比较成熟。我们的认证体系需要对当前系统/大数据组件入侵最小，对性能和稳定性影响比较小，原理简单且容易解释；

本地化：需要与快手大数据的生产组织管理体系相结合，相辅相成；

易衍化：能够较好的满足快手快速发展的需求，尤其是国际化、大集群等。

我们在探索快手大数据认证方案的时候，也对开源的框架做了调研。Kerberos是大数据经典的认证协议，内部实现比较复杂。当集群规模比较大时，Kerberos kdc会面临单点的风险，因此一些公司也逐步的走向了自研。综合来看，我们参考kerberos和业界的情况，自研了一套基于三方的无秘钥传输的统一大数据认证框架。

完成一次认证操作，需要进行三次网络通信。首先，客户端先与DSC KDC进行通信，完成客户端身份的认证；其次，客户端与DSC KDC进行第二次网络通信获取访问令牌；最后，客户端携带访问令牌访问大数据资源，hadoop server需要与DSC KDC进行通信完成令牌的验证，验证通过之后客户端才可以访问大数据的资源。

总结下来，我们的认证体系提供了2大能力。第一个能力是账号体系，我们支持三种账号类型，分别为个人、项目组和代理账号，统一使用principal进行表示，使用principal_name/type@realm格式。第二个能力是令牌种类，支持Access Token、Delegate Token和Degrade Token三种。

下面我们再来看看鉴权服务。左图是我们鉴权服务的全景图，可分为两大类：

应用类：每次鉴权会与远程DSC Server进行通信实时完成鉴权操作；

引擎类：我们会给每个引擎组件提供一个plugin，我们会根据引擎的特点在plugin内部选择不同的鉴权方式。比如对于低QPS的引擎，plugin会实时与远程DSC Server进行通信完成鉴权操作，若同时对延时要求比较高，plugin会对鉴权结果增加缓存以做加速。而对于QPS非常高的引擎，比如HDFS，会在plugin本地完成鉴权，而鉴权所需要的数据会定期从远端进行拉取。

概括下来的话，我们支持两种鉴权模式：本地模式，是指在plugin本地完成鉴权；远程模式，是指请求远端服务完成鉴权。

下图展示了鉴权服务的核心架构。一共分为两个核心模块：

DSC Auth Server/Plugin：鉴权服务或者鉴权plugin。该模块分为三个核心组件：

Auth Engine：鉴权引擎，负责模型和规则的计算；

Cache Manager：缓存管理器，负责本地缓存的管理，包括缓存的读写及定时持久化到本地磁盘等；

Policy Refresher：策略更新器，负责鉴权所需策略的增量和全量的更新。

DSC Admin Server：中央化的统一数据存储服务。里面有个核心组件是Data Loader，即数据加载器，负责策略数据的加载、版本的管理及数据库从库的路由。

下面介绍快手大数据全链路审计的建设思路和方案。

采集层：覆盖了数据应用类平台、数据工具类平台和大数据引擎全链路的系统和组件。

接入层：通过对全链路系统的操作进行梳理，需要上报的日志可以分为三类：基本元信息的数据上报给元数据服务；鉴权类日志上报给鉴权服务；其它操作类日志直接上报给日志标准化服务。日志标准化服务会对不同类型的操作日志进行统一计算和整合，以统一的标准发送到审计总线。

存储层：通过消费审计总线，把审计数据存储到ES和OLAP中。

服务层：提供了策略分析、特征支持和异常审计等能力。

应用层：给数据安全相关人员提供WEB管理入口。

敏感数据保护是全链路的能力，需要从数据的采集、加工到应用，全链路的系统进行联动，有些能力还需要嵌入到全链路的系统中。比如打标中台需要具备敏感数据识别能力；数据同步作为数仓的入口，需要具备敏感数据分类及定级的能力；执行引擎需要具备加解密、动态脱敏等；数据开发平台需要对ETL任务做敏感数据使用合规检测；元数据系统负责维护敏感数据的安全元信息等；安全中心提供严格的权限管控能力，并且联动全链路系统进行安全能力的落地。

概括来说，敏感数据保护支持四大能力：

数据识别：敏感数据标注、分类及定级；

数据保护：敏感数据严格且细粒度的权限控制；字段加解密/脱敏等；

数据检测：ETL任务上线前合规使用检测；下载及导出检测；

数据响应：异常使用行为监控；数据泄露预案响应等。

四、成果与规划

最后，介绍下快手统一安全平台目前取得的一些成果。平台当前接入30+系统，资源数在千万级，授权数在百万级，日均申请量在千级。

由于快手大部分的数据资产都是存储在HIVE中。所以，对于HIVE我们做了很多工作，整体可以分为四个关键里程碑：

关键里程碑1：在2019年12月，HIVE临时查询场景全部开启了权限控制，实现了HIVE权限控制从无到有的过渡；

关键里程碑2：在2020年7月，为了提升HIVE数据获取的效率，我们做了精简审批流、自动化审批等一系列措施；

关键里程碑3：在2020年12月，HIVE支持了认证能力，并推动使用方接入；

关键里程碑4：在2021年6月，我们开始推动HIVE生产场景开启权限控制。

HIVE支持的关键能力包括行/列/多租户等细粒度权限管控、统一认证、全链路审计、加解密/脱敏等敏感数据保护能力。

下面介绍快手大数据安全的未来规划。未来重点会从以下四个方面进行建设：

大数据引擎安全全覆盖：推动底层引擎的使用方100%接入认证鉴权等安全能力；提供细粒度管控能力；

增强安全态势感知能力：对数据资产的分布、敏感数据访问行为进行多维度全方位分析，对异常行为进行检测；

探索隐私增强技术：探索前沿的隐私保护技术，比如联邦学习、安全多方计算等，增强隐私数据保护，真正做到”数据的可用不可见“；

数据分类分级智能化：通过机器学习算法实现数据的智能化分类，持续提升数据分类分级的准确性。

作者简介：

马玲玲，快手大数据安全方向负责人，具有大数据应用平台建设和服务化平台建设经验，专注于大数据平台架构和大数据安全领域。

长按识别二维码关注『快手大数据』

查看交流会回放视频

分享、收藏、点赞，给个3连击吧！

技术干货：SQL on Hadoop在快手大数据平台的实践与优化

参考技术A 快手大数据架构工程师钟靓近日在 A2M 人工智能与机器学习创新峰会分享了题为《SQL on Hadoop 在快手大数据平台的实践与优化》的演讲，主要从 SQL on Hadoop 介绍、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用经验和改进分析、快手 SQL on Hadoop 的未来计划四方面介绍了 SQL on Hadoop 架构。

SQL on Hadoop，顾名思义它是基于 Hadoop 生态的一个 SQL 引擎架构，我们其实常常听到 Hive、SparkSQL、Presto、Impala 架构。接下来，我会简单的描述一下常用的架构情况。

HIVE，一个数据仓库系统。它将数据结构映射到存储的数据中，通过 SQL 对大规模的分布式存储数据进行读、写、管理。

根据定义的数据模式，以及输出 Storage，它会对输入的 SQL 经过编译、优化，生成对应引擎的任务，然后调度执行生成的任务。

HIVE 当前支持的引擎类型有：MR、SPARK、TEZ。

基于 HIVE 本身的架构，还有一些额外的服务提供方式，比如 HiveServer2 与 MetaStoreServer 都是 Thrift 架构。

此外，HiveServer2 提供远程客户端提交 SQL 任务的功能，MetaStoreServer 则提供远程客户端操作元数据的功能。

Spark，一个快速、易用，以 DAG 作为执行模式的大规模数据处理的统一分析引擎，主要模块分为 SQL 引擎、流式处理 、机器学习、图处理。

SPARKSQL 基于 SPARK 的计算引擎，做到了统一数据访问，集成 Hive，支持标准 JDBC 连接。SPARKSQL 常用于数据交互分析的场景。

SPARKSQL 的主要执行逻辑，首先是将 SQL 解析为语法树，然后语义分析生成逻辑执行计划，接着与元数据交互，进行逻辑执行计划的优化，最后，将逻辑执行翻译为物理执行计划，即 RDD lineage，并执行任务。

PRESTO，一个交互式分析查询的开源分布式 SQL 查询引擎。

因为基于内存计算，PRESTO 的计算性能大于有大量 IO 操作的 MR 和 SPARK 引擎。它有易于弹性扩展，支持可插拔连接的特点。

业内的使用案例很多，包括 FaceBook、AirBnb、美团等都有大规模的使用。

我们看到这么多的 SQL on Hadoop 架构，它侧面地说明了这种架构比较实用且成熟。利用 SQL on Hadoop 架构，我们可以实现支持海量数据处理的需求。

查询平台每日 SQL 总量在 70 万左右，DQL 的总量在 18 万左右。AdHoc 集群主要用于交互分析及机器查询，DQL 平均耗时为 300s；AdHoc 在内部有 Loacl 任务及加速引擎应用，所以查询要求耗时较低。

ETL 集群主要用于 ETL 处理以及报表的生成。DQL 平均耗时为 1000s，DQL P50 耗时为 100s，DQL P90 耗时为 4000s，除上述两大集群外，其它小的集群主要用于提供给单独的业务来使用。

服务层是对上层进行应用的。在上层有四个模块，这其中包括同步服务、ETL 平台、AdHoc 平台以及用户程序。在调度上层，同样也有四方面的数据，例如服务端日志，对它进行处理后，它会直接接入到 HDFS 里，我们后续会再对它进行清洗处理；服务打点的数据以及数据库信息，则会通过同步服务入到对应的数据源里，且我们会将元数据信息存在后端元数据系统中。

网页爬取的数据会存入 hbase，后续也会进行清洗与处理。

HUE、NoteBook 主要提供的是交互式查询的系统。报表系统、BI 系统主要是 ETL 处理以及常见的报表生成，额外的元数据系统是对外进行服务的。快手现在的引擎支持 MR、Presto 及 Spark。

管理系统主要用于管理我们当前的集群。HiveServer2 集群路由系统，主要用于引擎的选择。监控系统以及运维系统，主要是对于 HiveServer2 引擎进行运维。

我们在使用 HiveServer2 过程中，遇到过很多问题。接下来，我会详细的为大家阐述快手是如何进行优化及实践的。

当前有多个 HiveServer2 集群，分别是 AdHoc 与 ETL 两大集群，以及其他小集群。不同集群有对应的连接 ZK，客户端可通过 ZK 连接 HiveServer2 集群。

为了保证核心任务的稳定性，将 ETL 集群进行了分级，分为核心集群和一般集群。在客户端连接 HS2 的时候，我们会对任务优先级判定，高优先级的任务会被路由到核心集群，低优先级的任务会被路由到一般集群。

BeaconServer 服务为后端 Hook Server 服务，配合 HS2 中的 Hook，在 HS2 服务之外实现了所需的功能。当前支持的模块包括路由、审计、SQL 重写、任务控制、错误分析、优化建议等。

•无状态，BeaconServer 服务支持水平扩展。基于请求量的大小，可弹性调整服务的规模。

•配置动态加载，BeaconServer 服务支持动态配置加载。各个模块支持开关，服务可动态加载配置实现上下线。比如路由模块，可根据后端加速引擎集群资源情况，进行路由比率调整甚至熔断。

•无缝升级，BeaconServer 服务的后端模块可单独进行下线升级操作，不会影响 Hook 端 HS2 服务。

•Hive 支持 SPARK 与 TEZ 引擎，但不适用于生产环境。

•SQL on Hadoop 的 SQL 引擎各有优缺点，用户学习和使用的门槛较高。

•不同 SQL 引擎之间的语法和功能支持上存在差异，需要大量的测试和兼容工作，完全兼容的成本较高。

•不同 SQL 引擎各自提供服务会给数仓的血缘管理、权限控制、运维管理、资源利用都带来不便。

•在 Hive 中，自定义实现引擎。

•自动路由功能，不需要设置引擎，自动选择适合的加速引擎。

•根绝规则匹配 SQL，只将兼容的 SQL 推给加速引擎。

•复用 HiveServer2 集群架构。

基于 HiveServer2，有两种实现方式。JDBC 方式是通过 JDBC 接口，将 SQL 发送至后端加速引擎启动的集群上。PROXY 方式是将 SQL 下推给本地的加速引擎启动的 Client。

JDBC 方式启动的后端集群，均是基于 YARN，可以实现资源的分时复用。比如 AdHoc 集群的资源在夜间会自动回收，作为报表系统的资源进行复用。

路由方案基于 HS2 的 Hook 架构，在 HS2 端实现对应 Hook，用于引擎切换；后端 BeaconServer 服务中实现路由 服务，用于 SQL 的路由规则的匹配处理。不同集群可配置不同的路由规则。

为了保证后算路由服务的稳定性，团队还设计了 Rewrite Hook，用于重写 AdHoc 集群中的 SQL，自动添加 LIMIT 上限，防止大数据量的 SCAN。

•易于集成，当前主流的 SQL 引擎都可以方便的实现 JDBC 与 PROXY 方式。再通过配置，能简单的集成新的查询引擎，比如 impala、drill 等。

•自动选择引擎，减少了用户的引擎使用成本，同时也让迁移变得更简单。并且在加速引擎过载 的情况下，可以动态调整比例，防止因过载 对加速性能的影响。

•自动降级，保证了运行的可靠性。SQL 路由支持 failback 模块，可以根据配置选择是否再路由引擎执行失败后，回滚到 MR 运行。

•模块复用，对于新增的引擎，都可以复用 HiveServer2 定制的血缘采集、权限认证、并发锁控制等方案，大大降低了使用成本。

•资源复用，对于 adhoc 查询占用资源可以分时动态调整，有效保证集群资源的利用率。

当查询完成后，本地会轮询结果文件，一直获取到 LIMIT 大小，然后返回。这种情况下，当有大量的小文件存在，而大文件在后端的时候，会导致 Bad Case，不停与 HDFS 交互，获取文件信息以及文件数据，大大拉长运行时间。

在 Fetch 之前，对结果文件的大小进行预排序，可以有数百倍的性能提升。

示例：当前有 200 个文件。199 个小文件一条记录 a，1 个大文件混合记录 a 与 test 共 200 条，大文件名 index 在小文件之后。

Hive 中有一个 SimpleFetchOptimizer 优化器，会直接生成 FetchTask，减小资源申请时间与调度时间。但这个优化会出现瓶颈。如果数据量小，但是文件数多，需要返回的条数多，存在能大量筛掉结果数据的 Filter 条件。这时候串行读取输入文件，导致查询延迟大，反而没起到加速效果。

在 SimpleFetchOptimizer 优化器中，新增文件数的判断条件，最后将任务提交到集群环境，通过提高并发来实现加速。

示例：读取当前 500 个文件的分区。优化后的文件数阈值为 100。

一个表有大量的子分区，它的 DESC 过程会与元数据交互，获取所有的分区。但最后返回的结果，只有跟表相关的信息。

与元数据交互的时候，延迟了整个 DESC 的查询，当元数据压力大的时候甚至无法返回结果。

针对于 TABLE 的 DESC 过程，直接去掉了跟元数据交互获取分区的过程，加速时间跟子分区数量成正比。

示例：desc 十万分区的大表。

•复用 split 计算的数据，跳过 reduce 估算重复统计输入过程。输入数据量大的任务，调度速率提升 50%。

•parquetSerde init 加速，跳过同一表的重复列剪枝优化，防止 map task op init 时间超时。

•新增 LazyOutputFormat，有 record 输出再创建文件，避免空文件的产生，导致下游读取大量空文件消耗时间。

•statsTask 支持多线程聚合统计信息，防止中间文件过多导致聚合过慢，增大运行时间。

•AdHoc 需要打开并行编译，防止 SQL 串行编译导致整体延迟时间增大的问题。

HS2 启动时会对物化视图功能进行初始化，轮询整个元数据库，导致 HS2 的启动时间非常长，从下线状态到重新上线间隔过大，可用性很差。

将物化视图功能修改为延迟懒加载，单独线程加载，不影响 HS2 的服务启动。物化视图支持加载中获取已缓存信息，保证功能的可用性。

HS2 启动时间从 5min+提升至<5s。

HS2 本身上下线成本较高，需要保证服务上的任务全部执行完成才能进行操作。配置的修改可作为较高频率的操作，且需要做到热加载。

在 HS2 的 ThriftServer 层我们增加了接口，与运维系统打通后，配置下推更新的时候自动调用，可实现配置的热加载生效。

HiveServer2 的 scratchdir 主要用于运行过程中的临时文件存储。当 HS2 中的会话创建时，便会创建 scratchdir。在 HDFS 压力大的时候，大量的会话会阻塞在创建 scratchdir 过程，导致连接数堆积至上限，最终 HS2 服务无法再连入新连接，影响服务可用性。

对此，我们先分离了一般查询与 create temporay table 查询的 scratch 目录，并支持 create temporay table 查询的 scratch 的懒创建。当 create temporay table 大量创建临时文件，便会影响 HDFS NameNode 延迟时间的时候，一般查询的 scratchdir HDFS NameNode 可以正常响应。

此外，HS2 还支持配置多 scratch，不同的 scratch 能设置加载比率，从而实现 HDFS 的均衡负载。

Hive 调度其中存在两个问题。

一、子 Task 非执行状态为完成情况的时候，若有多轮父 Task 包含子 Task，导致子 Task 被重复加入调度队列。这种 Case，需要将非执行状态修改成初始化状态。

二、当判断子 Task 是否可执行的过程中，会因为状态检测异常，无法正常加入需要调度的子 Task，从而致使查询丢失 Stage。而这种 Case，我们的做法是在执行完成后，加入一轮 Stage 的执行结果状态检查，一旦发现有下游 Stage 没有完成，直接抛出错误，实现查询结果状态的完备性检查。

•HS2 实现了接口终止查询 SQL。利用这个功能，可以及时终止异常 SQL。

•metastore JDOQuery 查询优化，关键字异常跳过，防止元数据长时间卡顿或者部分异常查询影响元数据。

•增加开关控制，强制覆盖外表目录，解决 insert overwrite 外表，文件 rename 报错的问题。

•hive parquet 下推增加关闭配置，避免 parquet 异常地下推 OR 条件，导致结果不正确。

•executeForArray 函数 join 超大字符串导致 OOM，增加限制优化。

•增加根据 table 的 schema 读取分区数据的功能，避免未级联修改分区 schema 导致读取数据异常。

•部分用户并没有开发经验，无法处理处理引擎返回的报错。

•有些错误的报错信息不明确，用户无法正确了解错误原因。

•失败的任务排查成本高，需要对 Hadoop 整套系统非常熟悉。

•用户的错误 SQL、以及需要优化的 SQL，大量具有共通性。人力维护成本高，但系统分析成本低。

SQL 专家系统基于 HS2 的 Hook 架构，在 BeaconServer 后端实现了三个主要的模块，分别是 SQL 规则控制模块、SQL 错误分析模块，与 SQL 优化建议模块。SQL 专家系统的知识库，包含关键字、原因说明、处理方案等几项主要信息，存于后端数据库中，并一直积累。

通过 SQL 专家系统，后端可以进行查询 SQL 的异常控制，避免异常 SQL 的资源浪费或者影响集群稳定。用户在遇到问题时，能直接获取问题的处理方案，减少了使用成本。

示例：空分区查询控制。

SQL 专家系统能解决一部分 HS2 的任务执行的错误诊断需求，但是比如作业 健康 度、任务执行异常等问题原因的判断，需要专门的系统来解决，为此我们设计了作业诊断系统。

作业诊断系统在 YARN 的层面，针对不同的执行引擎，对搜集的 Counter 和配置进行分析。在执行层面，提出相关的优化建议。

作业诊断系统的数据也能通过 API 提供给 SQL 专家系统，补充用于分析的问题原因。

作业诊断系统提供了查询页面来查询运行的任务。以下是命中 map 输入过多规则的任务查询过程：