标准的 JDBC 接口、标准的 SQL 做事器、分布式任务实行以及元数据中央，这一系列组合让 Hive 完全地具备了构建一个企业级数据仓库的所有特性，并且 Hive 的 SQL 做事器是目前利用最广泛的标准做事器。
虽然 Hive 有非常明显的优点，可以找出完备替代 Hive 的组件寥寥无几，但是并不即是 Hive 在目前阶段是一个完备知足企业业务哀求的组件，很多时候选择 Hive 出发点并不是由于 Hive 很好地支持了企业需求，单单是由于暂时找不到一个能支撑企业诉求的替代做事。
数仓架构常日是一个企业数据剖析的出发点，在数仓之下会再有一层数据湖，用来做异构数据的存储以及数据的冷备份。但是也有很多企业，特殊是险些完备以构造化数据为主的企业在履行上会把数据湖和企业数仓库合并，基于某个数仓平台合二为一。
企业在考虑构建自身数仓体系的时候，虽然须要参考现有的行业技能体系，以及可以选择的组件做事，但是不能太过于局限于组件本身，探求 100%开箱即用的产品。太过局限于探求完备契合的组件做事一定受限于做事本身的实现，给未来扩展留下巨大的约束。企业数据仓库架构一定不即是一个组件，大部分企业在数仓架构履行的都是基于现有的部分方案，进行基于自己业务得当的方向进行部分开拓与定制，从而达到一个半自研的稳态，既能跟上业务变革的速率，又不过于依赖和受限于组件自身的发展。
一样平常来说企业级数仓架构设计与选型的时候须要从以下几个维度思考：
开拓的便利性：所选择的数仓架构是否具有很好的开拓生态，可以供应不同类型的开拓态接口，不限于 SQL 编辑器，代码提交，以及第三方工具整合。生态：所选择实现引擎自身是否有很好的生态功能，或者是否可以很好的与其他做事集成，例如数据湖引擎 delta lake，icebeg，hudi 等精良组件涌现，但是 Hive 集成的节奏却非常慢。解耦程度：分布式任务一定须要多个组件的折衷，例如分布式存储，资源管理，调度等，像 Hive 就重度依赖于 YARN 体系，打算引擎也与 MR 强绑定，在解耦方面较弱，如果企业考虑在 K8S 上构建自己的打算引擎，Hive 面临的局限会更加明显。性能：整体架构是否拥有更好的性能。安全：是否支持不同级别，不同力度的用户访问和数据安全鉴权体系。对付企业数仓架构来说，最主要的是如何基于企业业务流程来设计架构，而不是基于某个组件来扩展架构。
一个企业数仓的整体逻辑如上图所示，数仓在构建的时候常日须要 ETL 处理和分层设计，基于业务系统采集的构造化和非构造化数据进行各种 ETL 处理成为 DWD 层，再基于 DWD 层设计上层的数据模型层，形成 DM，中间会有 DWB/DWS 作为部分中间过程数据。
从技能选型来说，从数据源的 ETL 到数据模型的构建常日须要永劫任务，也便是全体任务的运行韶光常日是小时及以上级别。而 DM 层紧张是支持业务的需求，对时效性哀求比较高，常日运行在 DM 层上的任务韶光以分钟作为单位。
基于如上的分层设计的架构图可以创造，虽然目前有非常多的组件，像 Presto、Doris、ClickHouse、Hive 等等，但是这些组件各自事情在不同的场景下，像数仓构建和交互式剖析便是两个范例的场景。
交互式剖析强调的是时效性，一个查询可以快速出结果，像 Presto、Doris、ClickHouse 虽然也可以处理海量数据，乃至达到 PB 及以上，但紧张还是用在交互式剖析上，也便是基于数据仓库的 DM 层，给用户供应基于业务的交互式剖析查询，方便用户快速进行探索。由于这类引擎更聚焦在交互式剖析上，因此对付永劫任务的支持度并不友好，为了达到快速获取打算结果，这类引擎重度依赖内存资源，须要给这类做事配置很高的硬件资源，这类组件常日有着如下约束：
没有任务级的重试，失落败了只能重跑 Query，代价较高。一样平常全内存打算，无 shuffle 或 shuffle 不落盘，无法实行海量数据。架构为了查询速率快，实行前已经调度好了 task 实行的节点，节点故障无法重新调度。一旦发生任务非常，例如网络抖动引起的任务失落败、机器宕机引起的节点丢失，再次重试所花费的韶光险些即是重新提交一个任务。在分布式任务的背景下，任务运行的韶光越长，涌现缺点的概率越高。对付此类组件的利用，业界最佳实践的建议也是不超过 30 分钟旁边查询利用这类引擎是比较得当的。
而在离线数仓场景下，险些所有任务都是永劫任务，也便是任务运行时长在小时级以上，这时就哀求实行 ETL 和构建数仓模型的组件做事须要具有较高的容错性和稳定性，当任务发生缺点时可以以低本钱的办法快速规复，尽可能避免由于部分节点状态非常导致全体任务完备失落败。
可以创造在这样的诉求下类似于 Presto、Doris、ClickHouse 就很难知足这样的哀求，而像 Hive、Spark 这类打算引擎依托于 Yarn 做资源管理，对付分布式任务的重试、调度、切换有着非常可靠的担保。Hive、Spark 等组件自身基于可重算的数据落盘机制，确保某个节点涌现故障或者部分任务失落败后可以快速进行规复。数据保存于 HDFS 等分布式存储系统上，自身不管理数据，具有极高的稳定性和容错处理机制。
反过来，由于 Hive、Spark 更长于处理这类批处理的永劫任务，因此这类组件不善于与上层的交互式剖析，对付这种对时效性哀求更高的场景，都不能很好地知足。以是在考虑构建数仓的时候，常日会选择 Hive、Spark 等组件来卖力，而在上层供应交互式剖析查询的时候，常日会利用 Presto、Doris、ClickHouse 等组件。
归纳如下：
Presto、Doris、ClickHouse：更看重交互式剖析，对单机资源配置哀求很高，重度依赖内存，缺少容错规复，任务重试等机制，适宜于 30 分钟以内的任务，常日事情在企业的 DM 层直接面向业务，处理业务需求。Hive、Spark：更看重任务的稳定性，对网络，IO 哀求比较高，有着完善的中间临时文件落盘，节点任务失落败的重试规复，更加得当小时级以上的永劫任务运行，事情在企业的的 ETL 和数据模型构建层，卖力洗濯和加工上层业务所须要的数据，用来支撑全体企业的数仓构建。一个企业在履行数据平台的时候，由多个不同组件各自事情在不同的架构层中，无法相互取代，相互协作合营，承载全体企业的数据平台业务。
企业级数仓技能选择Google 揭橥的三篇论文从存储、打算、检索三个方向阐述了海量数据下一种新的分布式数据加工处理技能，这三个方向被雅虎 Nutch 团队实现落后献给 Apache，也便是目前大家看到的 HDFS、MapReduce 和 HBase，形成了早期 Hadoop 的三大利器。
然而这三大利器更聚焦在异构数据的信息提取处理上，没有供应对构造化数据很友好的类似 SQL 语法的剖析入口，同时在编程态的支撑也不足友好，只有 Map 和 Reduce 两阶段，严重限定了业务处理的实现，雅虎团队也是爬虫干系业务孵化而出，可以看出 Hadoop 早期的三大套件有着如下特点：
门槛高，须要编程实现，并且编程态受限于 MapReduce 的两阶段约束。以离散数据处理为主，对剖析能力、查询等常用数据剖析功能支持不敷。没有交互式客户端，无法实现交互式探索。Hive 便是出身在这样的较大的行业背景下，Hive 的涌现刚好填补了 Hadoop 只能用来做离线数据处理这个毛病，供应了一种常用的剖析接口，并且供应了非常好的用户交互办法。
Hive 整体架构如上图所示，Hive 供应 JDBC 接口实现支持以编程形式进行交互，同时业内险些所有 SQL Client、开源或商业 BI 工具都支持通过标准 JDBC 的办法连接 Hive，可以支持数据探索的动作，极大地丰富了大数据生态圈下的组件多样性，同时也降落了利用门槛，可以让熟习 SQL 的职员低本钱迁移。
基于这些设计非常好的殊效，加上 Hive 经由多年的逐步完善，发展到本日已经是一个非常稳定成熟的生产环境可用的数据仓库组件，乃至替代品都很难找到，因此利用 Hive 作为数据仓库的构建根本是一个非常好的选择。
如上图所示，个中有很多优点：
稳定：稳定性是 Hive 一个非常让人称道的特性，很多时候虽然 Hive 的性能，打算速率不及其他引擎，但是 Hive 的稳定性却一贯是非常好的。低门槛：只须要节制基本的 SQL 技能，便可利用 Hive 进行开拓，比较其他分布式打算引擎引擎本钱更低。生态丰富：Hive 和 Hadoop 生态圈紧密结合，而 Hive 自身的 Metastore 也成了大数据生态圈内的标准元数据做事，大部分引擎都支持直接适配 MetaStore。扩展方便：Hive 自身的 UDF 机制可以快速基于业务须要扩展功能。安全：Hive 支持 Kerberos/LDAP 多种认证办法，并且和 Ranger 结合可以做到更细粒度的行列权限级别，拥有较好的数据安全。集成本钱低：MapReduce 只支持编程态的接口，并且不支持迭代打算，Hive 封装了 MapReduce 供应 SQL 的接口，可以很低本钱的和上层数据挖掘，数据剖析工具进行集成。以是，虽然 Hive 涌现已经有很永劫光了，但依旧是数仓构建的首选，在全体数仓构建中随处可见 Hive 的身影。只管 Hive 有各类优点，让人难以割舍，但是并不即是能很好地支撑企业业务需求。很多时候选择 Hive 仅仅是由于暂时没有其他可选的组件，如果自己从头开拓一个，或者基于某个组件改造，本钱又会远超企业预期，因此不得不连续选择利用 Hive。
基于实践来看，Hive 在构建企业数仓过程中存在的紧张局限环绕在以下几个方面：
性能：Hive 基于 MapReduce 虽然带来了非常好的稳定性，同时也降落了它的性能，虽然有 TEZ 做一定的优化，但是与同类的打算引擎 Spark 比较依旧有非常大的差距。资源配置：由于 Hive 底层利用 MapReduce 作为打算引擎，而 MapReduce 对 SQL 不友好，因此 Hive 在 HiveServer2 层面实现了 SQL 的转换处理，再天生基于 MapReduce 的物理操持，从而导致 HiveServer2 须要非常高的配置，才能坚持足够好的稳定性。并发：Hive 的并发受限于 HiveServer2，企业须要掩护多个高配的 HiveServer2 实例才能支持更好的并非，常日 Hive 的瓶颈都在 HiveServer2 而不是更底层的分布式打算。容错本钱：Hive 基于 HiveServer2 进行 SQL 的剖析处理，多个 HiveServer2 之间相互独立不共享信息，因此当 HiveServer2 挂掉后，全体 HiveServer2 的任务都会结束，须要客户端自行重试，为全体作业级别的容错重启。事务支持：Hive 的事务设置在 HiveServer2 上，一旦 HiveServer2 实例开缘由务后，全体通过该 HiveServer2 的要求都会开缘由务，全体事务本钱过高。支配：如果企业的打算引擎支配是基于 K8S 等容器架构，Hive on K8S 将会带来非常大的支配本钱。虽然 Hive 在以上局限层面也做了很多考试测验（Hive On Spark），但是受限于 Hive 的架构，HiveServer2 自身有自己的 SQL 解析引擎，为了兼容架构将解析后的结果直接翻译成 Spark 最底层的接口，整体性能反而提升不大。
除了 Hive 之外，还有非常多其他的精良组件。然而，从企业数仓技能选型的视角来看，适宜用来构建数据仓库的，目前只有 Hive 和 Spark SQL 相对更加得当，在这两个组件中，Spark SQL 相对 Hive 的上风又更加明显。
SparkSQL 如何支撑企业级数仓Spark 引擎由于自身强大的生态和方便的编程接口被广泛运用在数据处理场景下，Spark 供应的 Spark SQL 模块更是为利用 Spark 支撑企业数据仓库供应了一个良好的根本举动步伐。
如上图所示，一个范例的数据仓库架构须要包含不同层次的模型构建。由于数据量大、数据构造异构等多种缘故原由，大数据架构下的企业数仓构建抛弃了基于关系型数据库下的 Cube 设计，直接采取基于分布式任务进行处理来构建多层数据模型。因此对付构建企业数仓的做事来说，有着如下哀求：
支持永劫任务，常日是小时以上，天级别居多。支持多任务，也便是高并发。稳定性必须被保障。速率快。支持 SQL 的交互式接口。易于集成。支持任务的重跑和容错以及快速任务失落败规复。基于以上特性可以创造，在目前可选择的组件范围内，Spark SQL 比较其他组件（乃至 Hive）更加适宜承担这类任务。但是很多企业在进行架构设计的时候割舍不掉 Spark SQL 带来的丰富特性，又愁于 Spark SQL 缺少类似 Hive 这样的 SQL 做事器，于是退而求其次变成 Hive 与 Spark SQL 两个组件共存的形态，Hive 退化为仅仅供应 MetaStore 做事，因此从很多实践的征象来看，Hive 构建企业数仓已是过去式，采取 Spark SQL 进行数据仓库的构建是浩瀚的选择。
如上图所示，企业在构建数仓的时候，通过一个 Spark SQL Server 供应基于 SQL 接口的常驻做事，同时也可以采取 Spark Submit 的办法直接提交 Jar 任务去运行，既能达到供应标准 SQL 交互式接口，又能供应更灵巧的编程态接口。
从不同的企业级数仓构建视角来看，Hive 带来的约束都越来越大，而 Spark SQL 的成熟度和发展趋势已经完备具备取代 Hive 来构建全体数仓，Spark SQL 的上风集中表示在如下方面：
丰富的生态：Spark 不仅可以和很多组件集成，其自身拥有生态已经涵盖各个方面，从数据剖析到机器学习和图打算。开放：Spark 架构设计上非常开放，可以快速整合其他产品，例如比较 Hive，在集成 Iceberg，Hudi 等特性方面就会开放很多。支配：Spark 既可以支配在 ECS 虚拟机上，也可支配在 K8S 架构上，多种支配形态非常灵巧。性能：Spark 的机制的流批处理性能非常得当用来构建企业数仓。易于开拓：Spark SQL 既有 SQL 接口，也支持灵巧的可迭代编程接口，非常方便不同场景下的数据开拓。安全：Spark SQL 可和不同的安全做事集成，实现细粒度的鉴权。因此，完备基于利用 Spark SQL 来支撑企业级的数仓是完备可行的，并且在目前也被浩瀚企业实践验证。
如上图所示，一个基于 Spark SQL 构建的企业数仓架构逻辑架构设计上包含以上几个部分，每一个 Spark SQL 引擎都是一个做事器，Spark SQL 引擎将自己的信息注册到 Zookeeper 中，SQL 做事器基于 Zookeeper 中的 Spark SQL 引擎来实行客户端过来的要求，SQL 做事器是一个兼容 Hive JDBC 接口的做事器，在利用 Spark SQL 来支撑数仓构建的时须要重点考虑的履行点是：
如何供应一个交互做事用来支撑不同的客户端来连接，包括交互式的 beeline，以及编程态的 JDBC 和工具接口。如何打通权限对接，如果是 Ranger 的话须要的是 Spark SQL Ranger Plugin。如何支持跨多个行列步队的任务提交。利用 Spark SQL 支撑企业级数仓的核心之处还是在于如何供应一个好用的任务做事器，用来支撑任务的管理。任务管理做事器在逻辑上与 HiveServer2 相似，但是更加的轻量，没有 HiveServe2 中繁芜而繁重的 SQL 解析，同时又没有 Spark Thrift Server 这种自身便是一个 YARN 作业的约束。企业可以基于自身的业务流程，开拓一个轻量的做事器，在这方面字节有非常深的实践履历，同时也有自己的 Spark SQL 引擎做事器，可关注后续的动态。同时业界也有其他企业做了类似的事情，例如网易开源的 Kyuubi。
Kyuubi 全体架构图如上所示，Kyuubi 基于 Spark SQL 之上，较好地填补了 Spark Thrift Server 在多租户、资源隔离和高可用等方面的不敷，是一个真正可以知足大多数生产环境场景的开源项目。但是 Kyuubi 在设计时考虑的是如何填补 Spark Thrift Server 的不敷，目的在于增强 Spark SQL 的能力，而不是对等设计一个可以更换 Hive 组件的做事。因此对付遗留项目来说迁移本钱较高，Spark SQL 与 Hive 有着两套不兼容的 SQL，在利用 Kyuubi 的时候如何降落遗留系统的迁移本钱将是一个非常大的事情量。
而行业也有开源的 Spark Thrift Server，该思路是非常精良的，但是由于开拓过程中有点太过于局限，导致依旧存在很多问题，紧张表示在：
Driver 单点：全体 Spark thrift server 以一个 Spark 任务的形式运行在 YARN 上，所有的要求都运行在一个 Driver 中，一旦 Driver 挂掉后，所有任务都会同时失落败。资源隔离：由于 Spark thrift server 因此 Spark 任务的形式运行在 YARN 上，因此提交的任务如果有跨行列步队提交需求的时候，Spark thrift server 很难支撑，其次多个任务运行在同一个 Driver 之中，资源利用会相互影响，很难更风雅化的进行资源的管理。多租户：Spark thrift server 从要求层面是可以支持多用户的，但是从架构层面来看 Spark thrift server 是一个运行在 Yarn 上的任务，它也有自己的 Application Id 有自己的任务提交者，因此它实际上因此一个超级管理员的身份运行，再做二次租户隔离，一定存在一定的资源安全问题。高可用：Spark thrift server 本身是没有高可用涉及的，因此它的高可用须要自行单独设计，且还得考虑客户真个兼容，例如 Hive JDBC 将 HA 信息存储在 ZK 中，而 Spark thrift server 没有这样的机制，因此高可用的履行本钱较高。因此虽然 Spark 供应了 Spark thrift server 做事用来供应类似 JDBC 这样的接口交互办法，但是目前依旧缺少很多生成功能，导致在生产环境利用的情形非常少，Spark thrift server 更像是一个小众的半成品，小修小补地考试测验着办理部分问题，但是没有给予一个彻底的方案，导致现在有点缺少实际的生产运用。
字节跳动 EMR 产品在 Spark SQL 的优化实践数据湖引擎集成Hudi、Iceberg 等数据湖引擎目前利用的越来越广泛，很多 B 端客户在利用 Spark SQL 的时候也存在须要利用数据湖引擎的需求，因此字节 EMR 产品须要将数据湖引擎集成到 Spark SQL 中，在这个过程中碰着了非常多的问题。
首先在与 Iceberg 集成的时候，对体验和易用的问题进行了优化，用户在利用 Spark SQL 过程中，须要手动输入很多指令，并且须要找到对应的 spark-iceberg 依赖包，这个也是目前集成 Iceberg 最常用的方案。我们的办理办法是在预先安装的过程中，提前把 iceberg 的干系 jar 包放到 spark jars 目录下，这样用户只须要指定 catalog 即可，无需再手动输出很多指令。
其次在 Spark 与 Hive 跨引擎剖析场景下利用 Iceberg，Spark 正常创建表，Presto/Trono 可以正常读写，但 Hive 无法正常读写，这个问题官方的文档也没有清晰的描述，办理方案是须要修正 Spark 的配置文件或者修正 Hive 的 hive-site-spark override 配置，确保初始化出来的 Spark Session 中的配置项 iceberg.engine.hive.enable 的值为 true，Hive 才能正常地读取 Spark 创建的表。
问题实质上是由于 Iceberg 为了支持 Hive 引擎，在整体的设计上做了一些妥协，利用了 Storage Handler 的办法去实现 Hive 对 Iceberg 格式的表的读写，须要显式的指定 Hive 的 Input/Output Format 实现，而 Presto/Trono 则可以基于 Hive 的 format_type 自动识别表的格式进行识别。
在兼容性上，由于 Iceberg 0.12 版本不支持 Spark 3.2，由于升级 Spark 的影响范围非常大，于是更新了 Iceberg，利用了社区的一个 master 的 snapshot 版本进行编译，与 Spark 3.2 进行集成。
Spark SQL 做事器虽然行业针对 Spark SQL 供应一个 SQL 做事器已经有 Spark Thrift Server 或者 Kyuubi 这样的工具，但是在某些 B 端客户的业务背景下，这些工具并不能完备知足哀求，因此字节跳动 EMR 团队自己设计实现了 Spark SQL Server，紧张聚焦办理的是如了局景：
兼容 Hive 语义：由于大部分 B 端客户早期是基于 Hive 构建的数据仓库，后续逐步全部更换为 Spark SQL，中间一定面临大量的系统迁移，而由于 Hive 与 Spark SQL 语义不尽相同，重写 SQL 实现的事情量非常大，因此在字节 EMR 产品中的 Spark SQL Server 中实现 Hive 语义和 Spark SQL 语义的兼容，在实现方案上采取的时候讲 Hive SQL 解析注入到 Spark 引擎中，形成一个 SQL Parser Chain，终极会匹配到某一个解析器，实现对 SQL 的解析，从而达到对全体 SQL 语义的兼容。提前初始化 Spark SQL 引擎：在业务要求到达条件前在 YARN 上提交 Spark 任务，初始化资源信息，让全体引擎处于等待的状态，可以减少任务提交花费的韶光，在用户较多的情形下可以提示整体的任务实行韶光。跨 Yarn 行列步队的任务提交：用户可以指定 Yarn 行列步队实行任务。如上图所示，SQL 做事器是一个实现了 Thrift 接口的做事器，供应标准的 JDBC 访问接口，Spark SQL 引擎同样实现了 Thrift 接口，Spark SQL 引擎在做事启动的时候便已经被提交至 Yarn，处于等待状态。当业务任务到达的时候，由 SQL 做事器实现引擎的筛选，匹配一个已经存在的引擎，或者重新提交一个全新的引擎用来实行任务。
SQL 做事器支持 OpenLDAP、Kerberos 等常用的权限认证，同时支持多种不同的隔离级别，例如 Session 级别则每一个业务 SQL 都会初始化一个 Spark SQL 引擎用来吸收任务，任务实行结束后，引擎从 Yarn 中销毁。而 User 级别则针对用户会初始性 0-N 个引擎，常驻于 Yarn 中，处于交替实行任务。
这样的做事器设计冲破了 Spark Thrift Server 的单 Driver 所带来的局限，解耦了 SQL 做事和任务实行。也就支持更细粒度的资源管理和跨行列步队的任务提交。
同时也兼容了 Hive 的接口，用户可以通过如下办法访问做事器：
HA 访问链接： ./bin/beeline -u "jdbc:hive2://emr-5fqkwudj144d2gc1k8hi-master-1/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=midas/ha;auth=LDAP" -n emr_dev -pEMR123456emr非 HA 访问链接：
./bin/beeline -u "jdbc:hive2://emr-master-2:10005/default;auth=LDAP” -n test_sub -pEMR123456emr
HA 模式下的信息被记录在 Zookeeper 中，保存的内容格式与 HiveServer2 的内容同等，能确保利用 Hive 的客户端可以直接访问 HA 模式下的做事器。
Spark SQL 多租户在 Hive 任务实行过程中，HiveServer2 做事承担了供应 SQL 做事器进行用户身份认证、权限判断，以及解析 SQL 天生终极的实行操持，再由 MR 引擎实行详细的分布式任务。
在这个过程中 HiveServer2 承担了非常重的职责，因此须要花费非常大的资源，因此会很大程度的影响用户的并发。对付分布式任务运行来说，它的资源约束来自于 Yarn 作为资源管理器所分配的资源，但是在 Hive 架构下却受限于 HiveServer2 的影响，导致用户并发的数量无法随着 Yarn 资源的提升而提升。
而在 Spark SQL 引擎中，SQL 解析是下推到引擎内部，与详细的分布式任务实行合为一体，不须要单独的做事器去做 SQL 解析。也正由于 Spark SQL 与 Hive 在解析模块的架构存在差异，Hive On Spark 的模式会变得非常难。
针对如上的场景，字节跳动 EMR 团队重新设计的 SQL 做事器只负任务务的吸收，进行用户资源、权限和身份的判断，然后将任务发送给运行在 Yarn 中的 Spark SQL 做事器。冲破了 Hive 这种并发受制于 HiveServer2 和 Yarn 两层约束的局势，只由 Yarn 的资源决定用户的并发程度，从而极大的降落了 Spark SQL 做事器的资源需求，增强了其稳定性，在用户并发上有了非常大的提升。
其次通过引擎预热的功能减少任务实行的韶光，提升整体速率，引擎预热指的是在做事启动的时候便向 Yarn 提交 Spark SQL 引擎，处于等待的状态，当业务要求到达的时候，基于业务类型从已经处于就绪的引擎中选择一个引擎来实行任务。
并不是每一个预热提交的引擎都会当选择实行，在 SQL 做事器中存在如下三种引擎隔离级别：
Session：基于每一个 connection 都会全新提交 Spark SQL 引擎，在链接断开后，引擎从 Yarn 上销毁。User：同一个用户可以共享多个 Spark SQL 引擎，详细的 Spark SQL 引擎个数由该用户提交的任务资源需求决定，引擎在连接断开后不会销毁，直到引擎空闲时长到达上限。Open：所有用户都可共享的 Spark SQL 引擎，常日是用来应对大账号，或者集群不须要做权限管理的场景。由此可见只有在 User、Open 的级别下引擎预热才会产生代价，预热省去了 Spark Submit 的韶光，当用户数量足够多，群体为统计单位所节省的韶光越多。
Spark SQL 事务支持Hive 的事务力度是基于 HiveServer2 实现的，例如通过如下语法：
CREATE TABLE tm (a int, b int) stored as orc TBLPROPERTIES('transactional'='true', 'transactional_properties'='insert_only')
可开缘由务，但是由于对事务的管理是在做事器上，因此须要开启 ACID 的时候受影响的是全体 HiveServer2 的所有要求，而 Spark SQL 很好地集成和支持了 Hudi，Iceberg 等数据湖格式，因此在 Spark SQL 做事器中不须要实现类似 HiveServer2 的事务机制，只须要在终极读取处理数据的时候，采取 Hudi、Iceberg 等特性便可达到支持事务的效果。
例如对付 Icdberg 数据格式的表已支持 update、delete 操作：
MERGE INTO prod.nyc.taxis ptUSING (SELECT FROM staging.nyc.taxis) stON pt.id = st.idWHEN NOT MATCHED THEN INSERT ;
因此当 Spark SQL 集成了 Iceberg 后，便具有了事务能力，再合营 SQL 做事器，便可在很低的本钱上具有和 Hive 事务能力同等的效益，同时也没有 Hive 下的一些约束，从这样的架构设计上来看，能够完全地更换 Hive。其余一个方面当用户数量变多，同时数据会发生修正、更新等操作，很随意马虎造大量的小广播传输，从而引起 Driver 的 OOM。虽然大广播也会存在 OOM 的问题，但是大广播可以通过阈值掌握，而小广播阈值对其不生效，一旦说数量变多，很随意马虎引起 Driver 的 OOM。字节 EMR 团队通过对小广播进行合并广播，办理大量小广播进行传播，导致打爆 Driver 的情形涌现。
尾声随着企业的业务发展越来越繁芜，须要更加灵巧、更加高效的数仓架构，在这样的业务驱动背景下，Hive 的局限变得越来越明显，而基于 Spark SQL 灵巧构建数仓的方案将会变得越来越主流。以是企业在考虑数据仓库构建体系的时候，可以考虑如何基于 Spark SQL 构建自身数据体系，Spark 完善和开放的生态在未来一定会有更多精良的做事环绕 Spark 形成强大的上风。
