Hive 常见面试问题

本文最后更新于 2024年1月9日 凌晨

Hive 常见面试问题

基础

Hive 介绍

Hive 是建立在 Hadoop 之上的开源数据仓库工具，其本质是将 Hive 查询语言（HiveQL）转化成 MapReduce 程序。以下是对 Hive 的主要特性和使用方面的详细解释：

  1. 面向分析： Hive专注于数据分析，能够高效执行复杂的查询和聚合操作，尤其适用于处理大量数据集和OLAP场景。
  2. SQL-like 查询语言： HiveQL类似于传统的SQL查询语言，使得用户能够通过直观和便捷的方式进行数据的查询、过滤、聚合和连接操作。这使得具备SQL知识的开发人员更容易上手。
  3. 大数据生态系统的整合： Hive完全集成了Hadoop生态系统，可以充分利用Hadoop的存储和计算能力，并与其他工具（如HBase、Spark）进行协同工作，实现整个数据处理和分析流程的协调一致。
  4. 扩展性和可扩展性： Hive可以扩展到处理PB级别的数据集规模，具备横向扩展的能力。它能够在成百上千个计算节点上进行并行处理，提供高效的数据处理和分析能力。
  • 优点：
    • 容易上手： Hive提供了类SQL查询语言，用户可以轻松进行数据查询和处理。
    • 大规模数据处理： Hive适用于处理PB级别的大规模数据集。
    • 高度可扩展： 具备横向扩展的能力，可以满足不断增长的数据处理需求。
    • 与Hadoop生态系统紧密集成： 作为Hadoop生态系统的一部分，Hive与其他工具紧密集成，方便协同工作。
  • 缺点：
    • 延迟较高： 由于采用基于批处理的模型和MapReduce作为执行引擎，Hive的实时性较差，不适合需要实时响应的应用场景。
    • 存储格式限制： Hive通常使用自有的列式存储格式（Parquet或ORC），不太适合需要频繁更新和修改的场景。

主要作用：

  • 数据存储和管理： Hive允许将结构化和半结构化数据存储在Hadoop的分布式文件系统中，并提供各种数据库操作，如创建表、加载数据、分区等。
  • 数据查询和分析： Hive提供类SQL查询语言（HiveQL），用户可以使用它进行复杂的查询、过滤、聚合和连接等操作，以满足分析需求。
  • ETL 处理： 通过Hive的数据转换能力，可以支持数据的提取、转换和加载等ETL操作，适应数据仓库和商业智能需求。

综上所述，Hive为大数据领域提供了一个建立在Hadoop生态系统之上的数据仓库方案，简化了存储和处理大数据的复杂性。它特别适用于需要在大规模数据集上进行查询和分析的场景，并具备与其他大数据工具密切集成的能力。

Hive 与 HBase 的对比

相同点：

  1. Hadoop 生态系统：Hive 和 HBase 都是建立在 Hadoop 生态系统之上的工具，可以与 Hadoop 的分布式文件系统（HDFS）和分布式计算框架（如 MapReduce）紧密集成。
  2. 大数据处理：Hive 和 HBase 都适用于大数据处理场景，能够处理 PB 级别的数据，并具备横向扩展的能力。

不同点：

  1. 数据模型和查询方式：Hive 是一个数据仓库工具，使用类似 SQL 的查询语言（HiveQL），采用类似于关系型数据库的表格型数据模型。HBase 是一个分布式的 NoSQL 数据库，基于列族和列的键值对数据模型，使用 API 和 shell 命令行进行数据访问。
  2. 存储方式：Hive 使用 HDFS 作为底层存储，适用于批量数据处理和离线分析。HBase 使用 HBase 作为底层存储，适用于实时数据访问和交互式查询。
  3. 数据一致性：Hive 通常是最终一致性的，即数据更新可能存在一定的延迟。HBase 保证强一致性，在单个数据单元（rowkey）上具有强一致性。

适用场景：

  • Hive 适合用于离线批处理、数据仓库和大规模数据分析场景。它适用于需要进行复杂查询、聚合和连接操作的场景，对实时性要求相对较低。
  • HBase 适合用于实时交互和低延迟数据访问场景。适合存储和处理结构灵活的非关系型数据，可以实现快速的实时读写和查询操作。

综上所述，Hive 适用于离线批处理和大规模数据分析，而 HBase 适用于实时交互和低延迟的数据访问。在实际应用中，选择使用 Hive 还是 HBase 应该基于具体的数据模型、查询需求和实时性要求来决策。

Hive 和 RDBMS 对比

Hive 的主要特点：

  1. 基于 Hadoop： Hive 是构建在 Hadoop 生态系统之上，用于处理和分析存储在 Hadoop 分布式存储（HDFS）中的大规模数据集的。
  2. SQL 接口： 提供了一个类似 SQL 的查询语言称为 HiveQL，这降低了学习成本，并允许用户轻松编写查询任务。
  3. 延迟高： 由于其查询结果需要通过 MapReduce 任务执行，因此响应时间较长，不适合实时查询和交互式分析。
  4. 扩展性和灵活性： Hive 擅长处理大规模数据集，并且能够扩展到多个节点上。
  5. 数据仓库功能： 支持创建数据库、表、视图等数据仓库的基本结构，并且可以对这些结构执行 DML 和 DDL 操作。
  6. 兼容 SQL 规范： 虽然 HiveQL 是基于 SQL，但还有自己的扩展，且并不完全遵守 SQL 标准。
  7. 优化机制： 可以通过索引、分区和桶等优化机制来提升查询效率。

Hive 和 RDBMS 的异同：

相同点：

  • 都提供了 SQL 接口，用户可以通过 SQL 语句进行数据操作。
  • 都支持基本的数据定义语言（DDL）操作，如创建表、视图等。
  • 都提供数据操纵语言（DML）功能，如 INSERT、UPDATE（Hive 中较为有限）、DELETE（同样限制较多）。
  • 都有优化查询性能的机制，如索引、分区等。

不同点：

  • 底层架构： Hive 基于 MapReduce 运行，适合批量处理；而 RDBMS 通常运行在单个或少量服务器上，适合在线交易处理。
  • 数据模型： Hive 支持非结构化或半结构化数据；RDBMS 仅支持结构化数据。
  • 实时查询： RDBMS 设计用于实时低延迟访问；Hive 的延迟较高，不支持实时查询。
  • 更新数据： RDBMS 支持对数据的即时更新和删除操作；Hive 的更新和删除是通过重写数据来实现，不适合频繁修改的场景。
  • 事务处理： RDBMS 提供了完整的事务支持；而 Hive 的事务能力较弱，虽然新版本中已经开始支持事务，但依然有诸多限制。
  • 查询优化： RDBMS 有复杂且成熟的查询优化器；Hive 的优化器相对简单，并依赖于底层的 MapReduce 或 Tez。

Impala 和 Hive 的对比

虽然 Impala 和 Hive 都是基于 Hadoop 数据仓库工具，并且都可以使用 SQL 类型的语言进行数据查询，它们在查询性能和架构方面存在明显的区别。以下为 Impala 与 Hive 在查询方面的主要区别：

  1. 架构和执行模型：
    • Impala 是一个 MPP（Massive Parallel Processing）架构的 SQL 查询引擎，它旨在提供低延迟和高并发的 SQL 查询性能。
    • Hive 最初是构建在 MapReduce 计算框架之上的，虽然现在可以通过 Tez 或 Spark 执行引擎来提高性能，但它的设计更适用于批量处理。
  2. 查询速度：
    • Impala 被设计为支持接近实时的、交互式数据查询，因此查询通常更快。
    • Hive 查询通常慢于 Impala，因为它们早期完全依赖于 MapReduce 作业，而每个作业都有启动延迟。
  3. 数据处理操作：
    • Impala 不需要将中间计算结果写回到磁盘，这减少了 I/O 开销，并且使用了更加高效的数据传输方法。
    • Hive 在执行查询时，可能需要将 MapReduce 阶段的输出写回到 HDFS 中，这会增加额外的磁盘 I/O 开销。
  4. 优化技术：
    • Impala 采用了许多尖端的优化技术，如直接操作内存中的数据、JIT（Just-In-Time）编译查询代码（LLVM）、优化的数据访问路径等。
    • Hive 通过经典的 MapReduce 或通过 Tez/Spark 进行查询，但，随着项目的演进，Hive 也不断集成新的技术改进查询性能。
  5. 数据存储格式：
    • Impala 支持多种存储格式，并且性能会受到存储格式的影响，针对不同格式可以优化查询性能。
    • Hive 也支持多种存储格式，但是对于某些格式可能需要额外的转换步骤来执行查询。
  6. 元数据共享：
    • Impala 能够直接利用 Hive 的元数据，因此可以轻松访问在 Hive 中定义的表。
    • Hive 自己管理元数据，并且由于与 Impala 的共享，Hive 表无需额外的步骤即可在 Impala 中被访问。

选择 Impala 还是 Hive 取决于具体的使用场景。如果需要快速的交互式查询和频繁的数据探索，Impala 可能更合适。而对于复杂的批量数据处理任务，尤其是那些不太关心延迟的场景，Hive 可能是更好的选择。随着两者的持续发展，Hive 和 Impala 的性能和功能差异在逐渐缩小，两者也经常在数据平台上共存，以便根据不同的查询需求选择最合适的工具。

内部表和外部表的区别

在 Hive 中，内部表和外部表的主要区别体现在数据的管理和生命周期上。以下是内部表和外部表的几个关键区别点：

  1. 定义方式：
    • 使用 CREATE TABLE 语句且未指定 EXTERNAL 关键字时，默认创建的是内部表。
    • 使用 CREATE EXTERNAL TABLE 语句时创建的是外部表。
  2. 数据的所有权和生命周期：
    • 内部表（Managed Table）：Hive 负责管理内部表的数据生命周期。当删除内部表时，Hive 会同时删除表的元数据和存储数据。
    • 外部表（External Table）：Hive 不管理外部表的数据生命周期。当删除外部表时，只有表的元数据信息被删除，而数据文件本身仍然保留在文件系统中。
  3. Location：
    • 对于内部表，可以在创建时指定数据文件的位置（LOCATION），如果不指定，默认会存放在 Hive 的仓库目录 /user/hive/warehouse 下。
    • 对于外部表，必须明确指定数据文件存放的位置（LOCATION），这些数据通常位于一个预先存在的路径下。
  4. 数据共享：
    • 外部表适合用于数据共享的情况，因为删除外部表不会影响原始数据，其他系统或者应用仍可以访问原始数据文件。
    • 内部表更适合于只有 Hive 需要访问的数据，因为数据与表的元数据绑定在一起。
  5. 使用场景：
    • 内部表通常用于数据的 ETL 过程中，数据仅在 Hive 中处理和分析，一旦表被删除，相关数据也将丢失。
    • 外部表通常用于多个应用或计算框架共享同一数据集的场景，表删除后不会影响数据，其他应用仍旧可以使用这些数据。

通常选择内部表还是外部表取决于数据的使用场景和生命周期要求。对于临时或中间的处理数据，内部表是一个好的选择。对于需要长期存储，可能被不同应用共享访问的稳定数据，外部表更为合适。

Metastore 配置模式

Hive Metastore 是 Hive 的核心组件之一，负责存储系统的元数据信息，例如：数据库、表、列以及分区的信息和所在的存储位置等。Hive 提供了三种 Metastore 配置模式，它们分别是：内嵌 Derby 方式、Local MySQL 方式和 Remote MySQL 方式。

  1. 内嵌 Derby 方式（Embedded Metastore）：
    • 内嵌模式通常是 Hive 的默认启动方式，Metastore 数据库直接运行在 Hive 进程中，使用的是 Derby 数据库。
    • Derby 模式适合于轻量级操作和单元测试，主要因为它易于设置且不需要独立的数据库服务器。
    • 缺点在于它不支持并发访问，也就是同一时间只能有一个客户端连接到 Metastore，因此它不适用于多用户环境和生产环境。
  2. Local MySQL 方式（Local Metastore）：
    • 在本地模式中，Metastore 服务运行在与 Hive 服务相同的 JVM（Java Virtual Machine）进程中，但是使用一个独立的、本地运行的关系型数据库（如 MySQL）来存储元数据。
    • 它比内嵌 Derby 方式更适合于多用户访问，但是与 Hive Server2 是否运行在相同服务器上仍然会影响性能和可用性。
  3. Remote MySQL 方式（Remote Metastore）：
    • 在远程模式下，Metastore 作为一个独立的服务运行，并且通常连接到一个远程的关系型数据库，如 MySQL 或 PostgreSQL。
    • 这种模式使得 Metastore 能够为多个 Hive 实例提供服务，并且极大地提高了并发访问和稳定性，是生产环境的推荐配置。

选择正确的 Metastore 配置模式取决于你的使用场景和需求。对于单用户的本地测试和开发，内嵌 Derby 模式可能足够好。然而，对于多用户环境，特别是生产环境，更健壮和可靠的 Remote MySQL 方式将是更好的选择。 Local 方式适合不想采用远程数据库但期望 Metastore 服务能够处理多用户并发的场合。

索引机制

Hive 支持索引（3.0版本之前），但是 Hive 的索引与关系型数据库中的索引并不相同，比如，Hive 不支持主键或者外键。并且 Hive 索引提供的功能很有限，效率也并不高，因此 Hive 索引很少使用。

  • 索引适用的场景：

适用于不更新的静态字段。以免总是重建索引数据。每次建立、更新数据后，都要重建索引以构建索引表。

  • Hive索引的机制如下：

hive在指定列上建立索引，会产生一张索引表（Hive的一张物理表），里面的字段包括：索引列的值、该值对应的HDFS文件路径、该值在文件中的偏移量。

Hive 0.8版本后引入bitmap索引处理器，这个处理器适用于去重后，值较少的列（例如，某字段的取值只可能是几个枚举值） 因为索引是用空间换时间，索引列的取值过多会导致建立bitmap索引表过大。

注意：Hive中每次有数据时需要及时更新索引，相当于重建一个新表，否则会影响数据查询的效率和准确性，Hive官方文档已经明确表示Hive的索引不推荐被使用，在新版本的Hive中已经被废弃了。

扩展：Hive是在0.7版本之后支持索引的，在0.8版本后引入bitmap索引处理器，在3.0版本开始移除索引的功能，取而代之的是2.3版本开始的物化视图，自动重写的物化视图替代了索引的功能。

调度方案

  1. 将 Hive 的 SQL 定义在脚本当中；
  2. 使用 azkaban 或者 oozie 进行任务的调度；
  3. 监控任务调度页面。

Hive 底层与数据库的交互原理

Hive 设计为用于在 Hadoop 生态系统中进行数据仓库任务。与传统的关系型数据库不同，Hive 直接在 Hadoop 上运行，使用 Hadoop 去执行读写操作、表扫描、数据汇总等，这些操作通常会转化为 MapReduce 或 Tez 任务。

元数据存储机制：

  • Hive 的元数据存储在一个称为“Metastore”的组件中。元数据主要包括表的定义、列和分区信息、存储的数据格式以及其他的数据属性。例如，Metastore 会记录表的 schema、数据存储路径、记录表和分区统计信息等。
  • Hive Metastore 通常使用传统的关系型数据库来存储元数据（例如 MySQL、PostgreSQL、Oracle 或 Derby 等），利用数据库管理系统（DBMS）的特性来处理频繁的读写和更新操作。

与数据库的交互原理：

  • Hive 组件与关系数据库交互来存取元数据。Hive Metastore 服务负责处理来自 Hive 的所有元数据读写请求。
  • 当 Hive 需要进行任何操作（如创建表、查询数据等）时，首先会从 Metastore 检索相应的元数据来执行逻辑判断和转换成具体的 Hadoop 作业。
  • 配置好 Hive 之后，它会通过 JDBC（Java Database Connectivity）连接器与配置的关系数据库交互，执行相关的 SQL 命令来对元数据进行操作。
  • Metastore 分为三种模式：
    1. **内嵌 Metastore (Embedded Metastore)**：默认模式，直接运行在 Hive 进程内部，通常使用 Apache Derby 数据库。
    2. **本地 Metastore (Local Metastore)**：在同一个 Java 虚拟机（JVM）内但作为独立的服务进程运行，可以让多个 Hive 实例共享同一个 Metastore。
    3. **远程 Metastore (Remote Metastore)**：Metastore 作为独立的服务运行在单独的 JVM 中，允许多个 Hive 实例和其他应用程序通过 Thrift 接口来进行连接。

在执行查询时，用户的 SQL 会被解析和编译，查询计划会生成与数据库交互的命令以收集必要的元数据，然后构建实际的 MapReduce 或 Tez 任务来执行查询，在这个过程中，Hive 会与元数据存储进行频繁的交互。

使用关系型数据库作为元数据存储提供了一种稳定、可伸缩且维护性好的方式来处理 Hive 元数据，它有效地支撑了 Hive 在大数据查询中的性能要求。

Pasted image 20230711101219

Tez 引擎

Tez 引擎优点：

  1. 作业优化： Tez 可以将多个有依赖的作业转换为一个作业，减少中间节点，提高计算性能。
  2. 性能提升： Tez 使用内存进行计算，相较于传统的 MapReduce 引擎，可以显著提高作业的计算性能。
  3. 资源利用： Tez 通过更有效的资源利用，提高了作业的执行效率，减少了资源浪费。
  4. 灵活性： Tez 提供了更灵活的作业控制，支持复杂的数据流和依赖关系，适用于各种不同的计算场景。

MapReduce vs. Tez vs. Spark 区别：

  • MapReduce 引擎：
    • 多个作业串联执行，基于磁盘，有较多的中间落盘操作。
    • 适用于处理周、月、年指标等一般处理场景。
  • Spark 引擎：
    • 在 Shuffle 过程中也有中间结果落盘，但不是所有算子都需要 Shuffle，尤其是多算子过程，中间过程不落盘。
    • 使用 DAG（有向无环图）优化计算流程，兼顾可靠性和效率。
    • 适用于处理天级别的指标等场景。
  • Tez 引擎：
    • 完全基于内存进行计算，快速出结果，但对于特别大的数据量需要慎重使用，容易导致内存溢出。
    • 适用于数据量较小、需要快速结果的场景。

综合来说，选择引擎需要根据具体场景和需求权衡性能、资源利用以及处理速度。

HQL

HQL 转 MR 的过程

Pasted image 20230711101052

以下是转换过程的六个主要阶段：

  1. 词法和语法解析：
    使用 Antlr (Another Tool for Language Recognition)，Hive 解析 SQL 查询，将其转换成**抽象语法树 (AST)**，AST 是 SQL 结构的一种内部表示。
  2. 生成基本查询单元：
    Hive 遍历 AST 生成查询块 (QueryBlock，QB) 作为一条 SQL 查询的基础组成单元，QB 包括三个主要部分：输入源、计算过程和输出目标。
  3. 生成操作树：
    根据 QB 生成一个OperatorTree。这是一个规范中间过程，将所有 SQL 操作映射到一系列 Operator，每一个 Operator 执行一个特定的数据处理操作，如过滤、聚集等。
  4. 逻辑优化：
    对生成的 OperatorTree 进行优化，包括简化操作、优化计算过程、合并操作节点等，来减少数据处理量和 MapReduce 任务的数量。
  5. 转换成 MapReduce 作业：
    把优化后的操作树翻译成 MapReduce 任务。此阶段涉及识别 Map 和 Reduce 阶段，并将适当的操作器映射到任务执行的不同阶段。
  6. 物理优化：
    在操作树转换成 MapReduce 任务之后，Hive 使用一系列物理优化策略进一步优化 MR 任务，这可以包括调整任务的并发性、调节资源占用和合并小文件等。

行列过滤和列过滤

在处理大量数据的查询时，有效的行过滤与列过滤对于优化性能至关重要。正确的应用行和列过滤可以减少不必要的数据读取和传输，进而降低查询所需的时间和资源。为了实现这一目标，可以遵循以下原则和实践：

  1. 列过滤：
    • 选择必要的列：在 SELECT 语句中，应该只选择需要的列来返回。这意味着避免使用 SELECT *，这种做法会检索表中的所有列，增加了 I/O 负载，尤其是当表中存在大量字段而只需少数几个字段时。
    • 使用分区过滤：如果表是按某些列分区的，应当在查询中使用 WHERE 子句来指定分区过滤器。这样可以利用分区的优势，只读取包含相关数据的分区，减少数据扫描量。
  2. 行过滤：
    • 使用 WHERE 子句：明确在 WHERE 子句中定义过滤条件，以便只查询满足特定条件的记录。
    • 优化外关联中的过滤条件：当使用 JOIN（尤其是外部 JOIN）时，需要注意 ON 和 WHERE 条件的使用。正确的方法是将与副表（外部 JOIN 的右侧表）相关的过滤条件放在 ON 子句中。如果将这些条件放在 WHERE 子句中，那么数据库会先执行全表 JOIN，然后再过滤结果，这样会导致更多的数据处理和内存使用。

分区与分桶

在 Hive 中，分区（Partitioning）和分桶（Bucketing）是两种不同的数据管理策略，各有其特点和适用场景：

1. 分区 (Partitioning)：

  • 分区是将数据根据某些特定列的值进行物理划分成不同的子目录，每个目录就是一个分区。
  • 当数据量大时，分区有助于改善性能，因为查询可以只扫描特定分区而非整个表。
  • 分区通常用于经常作为查询条件的列，如日期、地区等。
  • 分区的数据可以进一步被分桶。
    2. 分桶 (Bucketing)：
  • 分桶是将数据行按照某列（或某几列）的哈希值分散到预定义数量的桶（或文件）中。
  • 分桶能确保数据在桶中均匀分布，有助于有效进行抽样和更加高效的连接。
  • 分桶通常用于高频 join 列、需要进行抽样的数据，或者某些计算密集型查询。
    数据组织方式的差异：
  • 分区 数据是按目录划分，常见于 Hive 表的物理存储结构。
  • 分桶 数据则是在单个分区内进一步按文件排序，文件中的记录按照哈希表达式处理排序。
    数据查找的效率：
  • 通过分区字段筛选时，Hive 可以跳过不相关的分区，减少读取数据量。
  • 分桶则便于执行桶间 join 操作，只比较相同桶号的数据，减少计算。
    存储形式的不同：
  • 分区 是分散于不同目录的数据文件。
  • 分桶 数据则存储于一个或多个更细粒度的桶（文件）内。
    查询性能的影响：
  • 选择正确的分区策略可以在大数据量面前有效提升查询性能。
  • 分桶则对于数据抽样和等值连接操作特别有效，提高了性能。
    使用场景上的选择：
  • 分区适合处理大规模数据集的查询，特别是那些基于特定列筛选数据的查询。
  • 分桶适用于需要进行数据抽样或者提高特定类型 Join 操作性能的场景。

总体来说，分区主要通过将数据组织为独立的目录或文件夹，并根据分区列的值进行查找和过滤；而分桶则是通过哈希函数将数据分散存储在多个桶中，并根据桶的位置进行查找和处理。这两种数据组织方式可以根据实际需求来选择合适的方案，以提高查询效率和性能。

排序函数

在 Hive 中，根据数据的排序需求，提供了四种不同的排序方式，分别是 ORDER BY, SORT BY, DISTRIBUTE BY 和 CLUSTER BY。以下是这些排序方式的区别和特点：

  1. ORDER BY：
    • ORDER BY 用于全局排序，确保最终输出的结果是全局有序的。
    • 在执行时，它要求所有的数据都通过一个单一的 Reducer 进行处理，这意味着只有一个 Reducer 任务，这可能成为处理大数据集时的性能瓶颈。
    • 在严格模式（hive.mapred.mode=strict）下，为避免过多资源的消耗，ORDER BY 必须与 LIMIT 子句一起使用。
  2. SORT BY：
    • SORT BY 用于在每个 Reducer 上对数据进行局部排序。
    • 与 ORDER BY 不同，SORT BY 允许有多个 Reducers，每个 Reducer 输出的结果是有序的，但不保证全局有序。
    • 可以通过调整 mapred.reduce.tasks 参数来指定 Reducer 的数量。
    • 若与 LIMIT 子句一起使用，SORT BY 可以提高查询的性能。
  3. DISTRIBUTE BY：
    • DISTRIBUTE BY 主要用于控制数据的分布，即确定哪些数据被发送到哪个 Reducer。
    • 它按照指定的字段或表达式对数据进行分区。
    • 在结合使用 DISTRIBUTE BY 与 SORT BY 时，DISTRIBUTE BY 必须放在 SORT BY 之前。
  4. CLUSTER BY：
    • CLUSTER BY 是对 DISTRIBUTE BY 和 SORT BY 的简化写法，用于当 DISTRIBUTE BY 和 SORT BY 的字段相同时。
    • CLUSTER BY 同时定义了数据的分布和在 Reducer 层面的排序，即它可以确保数据在每个 Reducer 内部排序后被相应的 Reducer 处理。
    • 在 CLUSTER BY 中，排序是按照字段的默认排序规则进行的，但与原始描述的限制不同，CLUSTER BY 并不限制只能实现倒序排序，实际上，可以使用 ASC 或 DESC 来指定排序顺序。

为了决定使用哪种排序方式，需要考虑查询的具体需求。例如，如果需要对整个数据集做完全排序，那么 ORDER BY 是必须的。然而，如果只是要保证每个 Reducer 输出的分区按照特定的顺序排序，那么 SORT BY 就是合适的选择。对于数据划分与排序都有需求的情况，则可以使用 CLUSTER BY。

Join 函数

Hive 中除了支持和传统数据库中一样的内关联（JOIN）、左关联（LEFT JOIN）、右关联（RIGHT JOIN）、全关联（FULL JOIN），还支持左半关联（LEFT SEMI JOIN）

  • 内关联（JOIN）
    只返回能关联上的结果。
  • 左外关联（LEFT [OUTER] JOIN）
    以 LEFT [OUTER] JOIN 关键字前面的表作为主表，和其他表进行关联，返回记录和主表的记录数一致，关联不上的字段置为 NULL。
  • 右外关联（RIGHT [OUTER] JOIN）
    和左外关联相反，以 RIGTH [OUTER] JOIN 关键词后面的表作为主表，和前面的表做关联，返回记录数和主表一致，关联不上的字段为 NULL。
  • 全外关联（FULL [OUTER] JOIN）
    以两个表的记录为基准，返回两个表的记录去重之和，关联不上的字段为 NULL。
  • LEFT SEMI JOIN
    以 LEFT SEMI JOIN 关键字前面的表为主表，返回主表的 KEY 也在副表中的记录
  • 笛卡尔积关联（CROSS JOIN）
    返回两个表的笛卡尔积结果，不需要指定关联键。

Join 优化方案

Hive 能够处理大规模数据，但是不同的数据量和数据特征会影响其查询性能。对于大表 Join 小表和大表 Join 大表场景，可以使用以下优化技术来提高查询性能：

  1. 大表 Join 小表优化：
    • 小表缓存：早期 Hive 版本中，一般建议在 join 操作中把小表放在前面以利用 Hive 的小表缓存机制。现在很多 Hive 实现已经能够智能识别小表，自动优化 join 操作，所以小表的位置并不影响性能。
    • MapJoin：对于小表与大表的 join 操作，可以使用 MapJoin（在内存中执行的 join），使用 /*+ MAPJOIN(alias) */ 提示来指定小表做 MapJoin。
  2. 大表 Join 大表优化：
    • 空 KEY 过滤：对于潜在的导致数据倾斜的 key（如空值或者高频出现的值），在执行 join 之前过滤掉这些 key。这有助于减少单个 reducer 上的处理压力。
    • 空 key 转换：如果空 key 对应的数据是有效的且必需的，可以将这些字段赋予随机值，以便让数据在 reducers 之间均匀分布，避免数据倾斜。
  3. Group By 优化：
    • Map 端聚合：通过设置参数启用 Map 端先行聚合（hive. map. aggr=true），这样可以减少转移到 Reducer 端的数据量。
    • 检查间隔：可以调整 Map 端在每处理一定数目记录后进行一次聚合的频率，节省内存使用（hive. groupby. mapaggr. checkinterval）。
    • 数据倾斜处理：遇到倾斜数据时，通过设置 (hive. groupby. skewindata=true)，Hive 会增加一步 MR Job，首先在 Map 端分散并聚合数据，然后再通过另一个 MR Job 完成最终的聚合操作。

此外，针对大规模数据的优化还包括设计合适的表分区、索引使用、合理选择文件存储格式（如 Parquet、ORC），以及针对不同计算模式选用恰当的执行引擎（Tez、Spark）。

在设计查询时，应当关注数据的访问模式，了解 Hive 的内部工作机制，适配数据规模和查询类型，这样可以有效降低计算资源消耗与提高查询速度。这些优化措施需要对数据和业务场景有深入的理解，才能确保它们的效果。

笛卡尔积

在 Hive 中，避免笛卡尔积是非常重要的，特别是在进行 JOIN 操作时。笛卡尔积是指两个表的每一行都与另一个表的每一行进行组合，导致结果集的大小急剧增加。

原因：

  1. 性能影响： 笛卡尔积会导致庞大的中间数据集，需要更多的存储和计算资源，对性能产生负面影响。
  2. Reducer 数量受限： 当发生笛卡尔积时，Hive 只能使用一个 Reducer 来处理，这限制了并行处理的能力，降低了性能。

如何避免笛卡尔积：

  1. 明确指定关联条件（ON 条件）： 在进行 JOIN 操作时，始终确保提供有效的关联条件，明确指定 ON 条件，以避免无效的笛卡尔积。
  2. 检查 JOIN 条件的准确性： 确保 JOIN 条件的字段是相匹配且有意义的，以防止产生不必要的笛卡尔积。
  3. 使用合适的连接类型： 根据业务需求选择适当的连接类型，如 INNER JOIN、LEFT JOIN 等，以避免产生不必要的行组合。

Hive on MR 的 Join 原理

Hive 内部使用 MapReduce 来处理数据查询，包括表的关联（Join）。针对不同大小的表，Hive 采用不同的策略来实现表关联。

小表与大表的 Join（MapJoin）：

当一张表的数据量远小于另一张表时，可以在 Map 端进行 Join（称为 MapJoin），这样可以大大减少 MapReduce 中 Reduce 阶段的工作量。实现原理如下：

  1. Hive 会先将小表的数据加载到每个 Map 任务的内存中。
  2. 然后，每个 Mapper 读取大表的数据，并与内存中小表的数据匹配。
  3. 如果找到匹配的记录，就在 Map 任务内部执行 Join，并直接输出结果。

这种方法允许 Join 操作在 Map 阶段完成，不需要额外的 Reduce 阶段，大大提高了处理效率。

两个大表的 Join：

当需要联接的两张表都是大表时，就需要使用 Reduce 阶段来执行 Join。实现原理如下：

  1. 在 Mapper 阶段：
    • 读取两张表的数据。为了区别来自不同表的记录，可以为每个记录添加一个标记（flag），例如 0 代表表 A，1 代表表 B。
    • 选择一个 Join 的公共 key 作为 Mapper 的输出 key，把标记和原始数据作为输出 value。
  2. Shuffle 阶段（由 MapReduce 框架自动处理）：
    • 根据输出的 key（即 Join 的公共列）将来自不同 Mapper 的输出进行排序和分组。
  3. 在 Reducer 阶段：
    • 接收到具有相同 Join key 的来自两张表的记录集合。
    • 遍历记录集合，根据标记区分不同表的记录，然后对表 A 的记录和表 B 的记录进行配对和关联处理。

用户自定义函数 UDF

Hive 中的用户自定义函数（UDF） 是一种机制，允许用户编写自定义代码来执行那些 HiveQL 中未内置的操作。Hive 支持三种类型的自定义函数：

UDF (User-Defined Function)

  • 单行进入，单行输出： UDF 用于在单个数据行上执行操作，并返回一个结果。这类似 SQL 中的标准函数，如 LOWER() 或 UPPER()，它们对每个输入行的一个列或多个列进行操作。
  • 用途示例： 创建一个 UDF 来将温度从摄氏度转换为华氏度。每次调用函数只处理一行数据。

UDAF (User-Defined Aggregate Function)

  • 多行进入，单行输出： UDAF 用于执行聚合操作，如计算平均值、求和、最大值或最小值。这些函数作用于多行数据，并返回一个聚合后的单个结果。
  • 用途示例： 创建一个 UDAF 来计算整个数据集的中位数。函数需要处理多行数据，以生成最终结果。

UDTF (User-Defined Table-Generating Function)

  • 单行输入，多行输出： UDTF 是表生成函数，它允许处理单个数据行并产生任意多的行作为输出。这不同于标准的 Hive 函数，后者每次调用一般只生成一个输出行。
  • 用途示例： 创建一个 UDTF 来分解一个复杂数据对象（如 JSON 或数组）为多个行，其中每个行都包含对象中的若干部分。

创建一个自定义函数通常包含以下步骤：

  1. 选择编程语言：
    • UDF通常使用Java开发，因为Hive是用Java编写的，其UDF接口也是基于Java的。也可以使用Python等其他语言。
  2. 创建UDF类和方法：
    • 对于Java，创建一个类并继承Hive的org.apache.hadoop.hive.ql.exec.UDF类，实现evaluate()方法。
    • 对于Python等其他语言，使用特定的标记或框架提供Hive接入点。
  3. 编译和打包：
    • 对于Java，使用javac编译代码并使用jar命令打包。
    • 对于Python等，通常不需要编译，但可能需要打包或确保Hive能够访问到脚本。
  4. 在Hive上注册和使用UDF：
    • 将JAR文件或脚本传输到Hive服务器。
    • 使用Hive的ADD JAR命令将JAR文件添加到Hive classpath。
    • 使用CREATE FUNCTION为UDF创建别名，以便在HiveQL中使用。
    • 在Hive查询中调用该函数。

通过这些步骤，用户可以在 Hive 查询中使用自定义函数，极大地增加了 Hive 查询的灵活性和处理数据的能力。自定义函数使得 Hive 成为一个可以根据不同业务需求定制和扩展的平台。

常用函数

Hive 提供了大量的内置函数来帮助用户处理数据。这些函数可以分为几个类别：聚合函数、表生成函数（UDTF）、标量函数（UDF）和窗口函数。下面是一些常用的 Hive 函数介绍：

聚合函数（Aggregate Functions）

聚合函数用于对一组值执行计算，并返回单个值。

  • count(*)：计算指定列的行数。
  • sum(column)：计算指定列的数值总和。
  • avg(column)：计算指定列的平均值。
  • min(column)：返回指定列的最小值。
  • max(column)：返回指定列的最大值。

表生成函数 (UDTF)

表生成函数接受单个输入并产生多个输出行。

  • explode(array)：将一个数组类型的列转换成多行，表的其他列对于每个输出行都是重复的。
  • lateral view：与 UDTF 一起使用，用于将复杂数据类型如数组或结构拆分为单独的行。

标量函数（Scalar Functions）

标量函数逐行处理输入并返回单个值。

  • concat(string1, string2, ...)：连接两个或多个字符串。
  • substr(string, start, length)：返回从字符串起始位置开始的特定长度的子字符串。
  • length(string)：返回字符串的长度。
  • upper(string) / lower(string)：将字符串转换为大写或小写。
  • trim(string)：去除字符串首尾的空格。
  • replace(string old, string new)：替换字符串中的字符。
  • date_format(date/timestamp/string, format)：将日期/时间戳转换为特定格式的字符串。
  • current_date() / current_timestamp()：返回当前的日期或时间戳。

窗口函数（Window Functions）

窗口函数在通过相关的 SQL 查询定义的结果集的”窗口”上执行聚合运算。

  • row_number()：为每个分区中的每行返回一个唯一的行号。
  • rank()：在结果集分区内为每个唯一值返回一个唯一的排名。
  • dense_rank()：与 rank() 类似，但在给出排名时不会跳过任何排名（考虑重复排名）。
  • lead(column, offset, default)：返回当前行后 offset 行的值（向前看）。
  • lag(column, offset, default)：返回当前行前 offset 行的值（向后看）。
  • first_value(column)：在窗口分区中获取列的第一个值。
  • last_value(column)：在窗口分区中获取列的最后一个值。
  • sum(column) / avg(column)：计算窗口分区中指定列的总和或平均值。

条件函数

条件函数用于在查询中实现逻辑条件。

  • case when condition then value [when...] [else value] end：基于条件选择返回不同的值。
  • coalesce(value1, value2, ...)：返回参数列表中的第一个非空值。
  • if(boolean condition, value if true, value if false)：如果条件为真，则返回一个值，否则返回另一个值。
  • nvl(value,default)：如果值为 NULL，返回默认值。

这些仅是 Hive 支持的一部分函数，实际上 Hive 提供了更为丰富的函数库，并且还允许用户通过自定义函数（UDF、UDAF 和 UDTF）来扩展 Hive 的功能。在实际使用过程中，应根据业务需求和数据特点选择合适的函数，以提高查询效率和准确性。

Hive 压缩格式与技术

压缩格式：

TextFile 特点

  • 默认存储格式： Hive 最基本的存储格式，通常用来存储纯文本数据。
  • 兼容性： 具有良好的跨平台兼容性，易于查看和编辑。
  • 压缩与分片： 支持与 Gzip 或 Bzip 2 等压缩格式的结合，虽然可以节省存储，但这些格式通常不支持分片（split），从而影响并行处理能力。
  • 处理开销： 在进行数据处理时（如 MapReduce 作业），需要按字符解析，并检测分隔符，导致反序列化开销较大。

SequenceFile 特点

  • 二进制存储： 以键值对形式存储，通常用于 Hadoop 应用，支持二进制格式。
  • 分片支持： 自然支持数据分片，适配于 Hadoop 的 MapReduce 框架，加强了并行处理能力。
  • 压缩方式： 提供无压缩、记录压缩和块压缩选项，块压缩能在保证压缩比的同时获得较好的读取性能。
  • 适用场景： 特别适用于大型数据集的存储和处理。

RCFile 特点

  • 行列存储结合： 将数据分割成多个行组，并在每个行组内以列的形式存储和压缩数据。
  • 列压缩： 列级别压缩能够减少存储空间需求，并且当查询涉及部分列时可以节省 I/O 操作。
  • 数据读取： 支持高效的数据读取，尤其优化了列操作，但转换成 RCFile 格式可能有较大的开销。

ORCFile 特点

  • 高级列式存储： 提供更高级的列式存储机制和优化的压缩方式。
  • 列读取与索引： 能够在读取数据时快速跳过非目标数据列，同时支持索引，以降低读取成本。
  • 压缩比与性能： 相比于 RCFile，ORCFile 在压缩比和读取性能上都有所提升。
  • 数据仓库优选： 适用于需要频繁读取的数据仓库场景。

Parquet 特点：

  • 列式存储格式： Parquet 是一种二进制的列式存储格式，被广泛用在 Hadoop 生态系统中，包括 Hive、Impala 和 Spark 等。
  • 高效的压缩和编码方案： Parquet 通过使用高效的列存储和编码方案来优化存储空间和查询性能，对于不同的列采用不同的压缩技术。
  • 适用于复杂类型的存储： Parquet 支持复杂的嵌套数据结构，适合存储 Protobuf、Thrift 和 Avro 等序列化框架的数据。
  • 优化的读取性能： 当只需要查询表的一部分列时，Parquet 可以仅读取需要的列，降低 I/O。
  • 支持多种压缩算法： Parquet 可以与 Snappy、Gzip、LZO 等压缩算法配合使用，以提高压缩率。
  • 兼容性好： Parquet 具有很好的跨平台兼容性，可在多种计算框架间移植和访问。
  • 支持分片： 类似于 SequenceFile 和 ORCFile，支持分片操作，便于在 Hadoop 集群上的分布式处理。

Avro 特点：

  • 二进制存储格式： Avro 是一种轻量级的序列化框架，它采用 JSON 格式定义数据模式（schema），数据以二进制形式存储。
  • 模式演化： Avro 支持模式的演化，允许旧模式的数据在不丢失信息的情况下与新模式进行交互。
  • 自描述性： Avro 数据文件包含了模式，这样不需要外部的模式存储，使数据文件自描述。
  • 动态语言友好： Avro 主要用于动态语言（如 Python、Ruby），在数据序列化和反序列化方面表现良好。

Snappy、Gzip、LZO 等压缩技术的一些简要特点：

  • Snappy： 由 Google 开发的快速压缩和解压库，不像 Gzip 或 Bzip 2 那样关注最大可能的压缩率，而着重于高速度和合理的压缩率，适合对实时性要求比较高的场景。
  • Gzip： Gzip 提供了相对较好的压缩率，虽然压缩和解压速度慢于 Snappy，但由于其高压缩率，在带宽和存储有限的场景下更受欢迎。
  • LZO： LZO 是一种压缩技术，它以较快的压缩速度和更快的解压速度为特点，平衡了压缩率和性能，这使得它适用于需要经常读写的场景。

这些存储格式是 Hive 支持的常见选项，每种格式都有其独特的设计和适用场景。TextFile 适用于数据导入导出和跨平台兼容的简单场景，而 RCFile 和 ORCFile 更适合查询频繁的数据仓库环境，SequenceFile 则在 Hadoop 生态系统中的数据处理任务中更受青睐。当选择 Hive 用于数据分析时，考虑数据的使用模式和查询效率来选择最合适的存储格式是非常重要的。

Fetch Task 技术

在 Hive 的设计中，并非所有查询任务都必须启动 MapReduce 进程。 尤其是在 Hive 0.10.0 版本之后，引入了一项优化措施，对于一些简单的查询任务，即那些不包含聚合函数、仅涉及元数据检索或直接抽取数据的任务，Hive 可以通过 Fetch Task 直接从 HDFS 中读取数据，而无需启动任何 MapReduce 作业。

具体而言，以下类型的查询任务可以通过 Fetch Task 完成，而无需触发 MapReduce 作业：

  • 获取表的元数据信息（例如，使用 DESCRIBE 语句）。
  • 执行分区的数据抽样，尤其是在查询中使用了 LIMIT 子句的简单 SELECT 语句。

引入 Fetch Task 的目的在于提高查询效率。由于启动完整的 MapReduce 作业可能带来显著的开销，尤其是在查询相对简单的情况下，使用 Fetch Task 可以减少查询延迟，提供更迅速的反馈，特别适用于交互式查询场景。

因此，在使用 Hive 进行数据查询时，是否触发 MapReduce 任务取决于查询的复杂性、Hive 的配置以及优化策略。对于诸如 SELECT <col> FROM table LIMIT n 这样的简单查询语句，Hive 可以通过 Fetch Task 直接获取数据，而无需启动 MapReduce 作业。

加载 JSON 数据

在 Hive 中解析 JSON 字符串，通常有两种主要方法，选择哪种方式取决于数据的结构和解析需求：

  1. 使用 Hive 内置的函数

当 JSON 数据以字符串形式存储在 Hive 表的单个字段中，且结构相对简单时，可以使用 Hive 提供的内置函数。

使用 get_json_object 函数： 这个函数可以直接提取 JSON 字符串中的特定字段。

1
2
3
4
SELECT
  get_json_object(json_column, '$.field') AS extracted_field
FROM
  your_table;

使用 json_tuple 函数： 当需要同时从 JSON 中提取多个字段时，json_tuple 比较方便。

1
2
3
4
SELECT extracted_field1, extracted_field2, extracted_field3
FROM your_table
LATERAL VIEW json_tuple(json_column, 'field1', 'field2', 'field3') jt
  AS extracted_field1, extracted_field2, extracted_field3;

这些方法适合于轻量级的 JSON 解析工作，尤其是当 JSON 结构不是很复杂，需要提取的字段数目有限时。

  1. 使用 JSON SerDe

如果 JSON 数据以完整的 JSON 对象形式存储，并且其结构复杂或字段较多，可以使用 SerDe 来解析。SerDe 即 Serializer/Deserializer，它允许 Hive 在读取和写入数据时进行自定义的序列化和反序列化。

使用内置的 org.apache.hive.hcatalog.data.JsonSerDe：

在创建 Hive 表时，通过指定 SerDe 类来设定如何解析 JSON。

1
2
3
4
5
6
7
8
CREATE TABLE your_table (
  field1 STRING,
  field2 INT,
  field3 ARRAY<STRING>,
  ...
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS TEXTFILE;

这会要求你在加载数据时，每一行都是一个合法的 JSON 对象。Hive 表中的字段将自动匹配 JSON 对象中同名的键值对。

选择使用内置函数或者 SerDe 作为解析策略主要取决于你处理的 JSON 串的复杂程度。简单场景下，使用 get_json_object 和 json_tuple 函数就足够了。对于更加复杂的 JSON 结构，以及当你预计将持续处理大量结构化的 JSON 数据时，使用 SerDe 可能会更有优势。

注意： 在使用 SerDe 之前，确保已将 JSON SerDe 的 jar 文件添加到 Hive 的类路径中，如果它不是 Hive 发行版中的一部分。对于新版本的 Hive，内置的 org.apache.hive.hcatalog.data.JsonSerDe 可直接使用。对于旧版本，可能需要下载并添加相应的 jar。这可以通过 Hive 会话中的 ADD JAR 命令完成。

问题与优化方案

Hive 常见优化手段

综合整理了你提到的和我添加的一些 Hive 优化手段：

  1. 数据存储及压缩：
    • 选择合适的数据存储格式，常用的有 ORC 和 Parquet。
    • 使用压缩格式，如 Snappy，以减小存储空间和提高查询性能。
  2. 调参优化：
    • 设置合理的并行度，通过调节参数如 mapred.max.split.size、mapred.min.split.size.per.node 和 mapred.min.split.size.per.rack。
    • 调整 JVM 参数，重用 JVM。
    • 设置 Map 和 Reduce 的参数，开启/关闭推测执行。
  3. 表结构设计：
    • 使用合适的数据类型，避免不必要的大数据类型。
    • 使用分区表和桶表来减小数据集的大小。
  4. 合理使用分桶：
    • 对于大表，使用分桶可以提高特定列的聚合查询性能。
  5. 数据预处理和清洗：
    • 在导入 Hive 之前进行数据清洗和预处理，去除无效数据和冗余数据。
  6. 硬件和集群配置：
    • 选择适当的硬件规格和配置，包括磁盘、内存、CPU 等。
  7. 使用索引：
    • 使用 Hive 的索引功能，尤其对于小表的连接查询。
  8. 数据采样：
    • 在开发和调试阶段使用数据采样，加速查询的返回结果。
  9. 并行执行和动态分区：
    • 利用 Hive 的并行执行能力，通过设置适当的参数提高查询的并行度。
    • 使用动态分区避免频繁更新分区元数据。
  10. 缓存查询结果和避免不必要的计算：
    • 对于经常使用的查询，可以考虑将结果缓存起来，减少重复计算。
    • 在 SQL 中避免不必要的计算和操作，尽量精简查询。
  11. 数据倾斜处理：
    • 处理数据倾斜，采用一些手段如调整数据分布、使用随机数进行分桶等。
  12. 并行度调优：
    • 根据集群的规模和资源情况，调整并行度以最大化资源利用。

这些优化手段可以根据具体的业务场景和查询需求进行灵活调整，综合考虑以达到最佳的性能优化效果。

小文件问题

  1. 使用 Hive 自带的 concatenate 命令：

    • 使用 ALTER TABLE ... CONCATENATE; 命令可以自动合并小文件。
    • 注意，这个命令只支持 RCFILE 和 ORC 文件类型，且不能指定合并后的文件数量。

  2. 调整参数减少 Map 数量：

    • 设置与 Map 相关的参数，如 hive.input.format、mapred.max.split.size 等，以调整 Map 输入的合并小文件的相关参数。
    • 这样可以在 Map 阶段将多个小文件合并成一个 split 作为输入。

  3. 减少 Reduce 的数量：

    • Reduce 的数量决定了输出文件的个数，通过设置 mapreduce.job.reduces 或者 hive.exec.reducers.bytes.per.reducer 控制 Reduce 的数量。
    • 通过设置 distribute by rand() 等方式使数据均匀分布到各个 Reduce，防止出现文件过大或过小的情况。

  4. 使用 Hadoop 的 archive 将小文件归档：

    • 使用 Hadoop Archive（HAR）工具将多个小文件打包成一个 HAR 文件，减少 NameNode 的内存使用。
    • 通过设置相关参数和使用 ALTER TABLE ... ARCHIVE PARTITION 进行归档，可以有效管理小文件。

数据倾斜

数据倾斜问题是在处理大规模数据时常见的问题，特别是在使用 MapReduce 等分布式处理框架进行大批量数据处理时。数据倾斜会导致任务的负载不均匀，从而降低整体作业的效率。以下是一些常见的数据倾斜原因及其对应的解决方案：

数据倾斜的原因及对应解决方案：

  1. 空值引发的数据倾斜
    • 原因：当某个键值频繁出现，如空值时，可能会导致大量数据集中到同一个 reducer。
    • 解决方案：净化数据以减少空值，或在原有键值基础上加杂质（如添加随机数）以分散数据。
  2. 不同数据类型引发的数据倾斜
    • 原因：如果一个键值类型的数据量远超过其他类型，如一个常见词出现的频率远高于其他词。
    • 解决方案：对于频繁出现的键值类型，可以考虑单独处理。
  3. 不可拆分大文件引发的数据倾斜
    • 原因：单个文件过大且不能有效切分，导致处理该文件的任务成为瓶颈。
    • 解决方案：在数据读取阶段增加拆分逻辑，或事先手动对大文件进行预处理与拆分。
  4. 数据膨胀引发的数据倾斜
    • 原因：某些数据处理操作（如笛卡尔积）产生大量重复组合，引发数据量激增。
    • 解决方案：优化 SQL 查询逻辑，避免不必要的笛卡尔积，使用适当的 where 子句减少输出行。
  5. 表连接时引发的数据倾斜
    • 原因：两个表进行 Join 操作时，一侧的某个键值数据异常多。
    • 解决方案：使用 Hive 的’SKEWED BY’语句处理倾斜键值的数据，或采用 Map-side join 减少数据传输。
  6. 确实无法减少数据量引发的数据倾斜
    • 原因：某些计算确实需要对大量数据进行操作，无法通过简单的优化来减轻。
    • 解决方案：使用更多的 reduce 任务来分散负载，或在计算中引入更复杂的数据分布策略。

针对数据倾斜的通用处理策略：

  • Map 数的管理：对于小文件过多的问题，可以通过合并小文件减少 Map 任务的数量，使用 CombineFileInputFormat。对于大文件，调整 mapred.max.split.size 确保单个 Map 任务处理的数据块大小适中。
  • Reduce 数的配置：通过 hive.exec.reducers.bytes.per.reducer 参数调整每个 Reduce 任务处理的数据量，并根据实际情况设置 Reduce 任务的最大数量。
  • 并行执行：可以通过设置 hive.exec.parallel 为 true 来开启查询的并行执行，使得不同的 MapReduce 任务可以同时运行，加快整体处理速度。
  • 高级优化：使用 hive.optimize.skewjoin 开关开启倾斜连接优化，或者使用 salt 技术（给倾斜的键添加随机前缀）来重新分配倾斜的键。
  • 数据预处理：在执行查询之前预先对数据进行处理，例如通过 GROUP BY 和 DISTRIBUTE BY 重新分配数据，防止在执行 Query 时产生倾斜。

在解决数据倾斜问题时，通常需要深入了解数据本身的特征以及处理逻辑。在某些情况下，可能需要进行比较多的尝试或者多角度分析问题，以找到最合适的解决方案。

COUNT (DISTINCT) 问题及替代方案

COUNT(DISTINCT) 操作在大数据环境中性能低下的原因是该操作需要将所有唯一数据项聚集到单个 Reducer 上来确保准确性，这样做会创建一个性能瓶颈点，尤其是在高数据量情况下，这个单个 Reducer 负载过重，往往成为整个作业的性能瓶颈。

为了解决这个问题，并在大数据环境下提升去重统计的性能，可以考虑以下替代方案：

  1. **使用 GROUP BY 替代 COUNT (DISTINCT)**：

    • 在执行去重统计之前，先将数据使用 GROUP BY 子句聚合，此操作将分布在多个 Reducer 中进行，以避免对单个 Reducer 的压力。
    • 然后利用聚合后的结果执行 COUNT 操作，以计算去重后的总数。
      SQL 示例如下：
    1
    SELECT COUNT(1) FROM (SELECT column_name FROM table GROUP BY column_name) t;

  2. 使用近似算法：

    • 对于某些业务场合，接受一个可容忍的误差范围是可行的。这时可以使用近似算法（如 HyperLogLog）来估计唯一项的数量，这类算法通常更快，因为它们不需要移动所有数据到单个 Reducer。

  3. 覆盖 Hadoop/Hive 参数：

    • 尝试调整和优化 Hive 或 Hadoop 配置，比如增加 Reducer 的数量，优化内存配置，以便 MapReduce 或执行引擎更有效地处理大数据集。

  4. 使用 Hive 的 distinct rewrite 优化：

    • Hive 支持 distinct rewrite 特性，该特性可以自动将 count(distinct) 转换为两级聚合，以提升效率。

  5. 在 Hive on Tez 上执行：

    • 使用 Tez 执行引擎替代 MapReduce 可以获得更好的性能，特别是对于复杂的查询，因为 Tez 优化了作业的执行计划，并减少了数据移动。

通过这些策略，能显著提升处理大数据时去重统计的性能。然而，选择最佳方案还需要考虑数据的特征和查询需求，实际操作中可能需要做进一步的调整和试验。

参考

技术 > 大数据
#技术 #面试 #大数据 #Hive
Hive 常见面试问题
https://hexo.leelurker.com/posts/31903
作者
LeeLurker
发布于
2023年8月29日
许可协议