单元1 数据仓库基础与Hive入门
先想清楚“为什么要数据仓库”，再认识 Hive 这位“把 SQL 翻译成 MapReduce 的翻译官”
本单元学习目标 摘自课件“学习目标/Target”页
- 了解数据仓库，能够说出数据仓库的显著特点。
- 了解数据仓库的意义，能够说出构建数据仓库的目的。
- 熟悉数据仓库分层架构，能够描述三层架构中ODS、DW和DA的概念。
- 了解数据仓库的数据模型结构，能够说出星形模型和雪花模型的区别。
- 了解Hive的基本概念，能够说出Hive的主要作用及其在大数据分析中的应用场景 。
- 了解Hive架构，能够说出Hive基础架构中各组件的作用。
- 掌握Hive的数据模型，能够描述数据库、表、分区和分桶的概念和作用。
- 熟悉Hive的数据类型，能够描述原生数据类型和复杂数据类型的概念。
单元概述
在信息时代，数据已成为企业发展的关键资产，但如何有效处理并从中提取决策价值，已成为亟待解决的难题。面对企业内部大量分散且异构的数据，数据仓库应运而生。它像一座精心设计的“桥”，整合并重组数据以支持高效的分析决策。在众多数据仓库工具中，Hive以其接近SQL的语法和面向海量数据的处理能力脱颖而出，成为企业构建数据仓库的常见选择。
知识地图
本单元知识地图
学完本单元，你应该能回答
- 数据仓库与 OLTP 数据库的本质区别是什么？
- ODS / DW / DA 三层架构各自解决什么问题？
- Hive 把 HQL 变成 MapReduce 作业，中间要经过哪几步？
- Hive 的数据模型（库、表、分区、分桶）如何在 HDFS 上落地？
知识链位置
核心知识 点击标题右侧勾选框可标记“已掌握”，进度会保存在本机浏览器
1.1 认识数据仓库
数据仓库简介
了解数据仓库，能够说出数据仓库的显著特点。
数据仓库（Data Warehouse）是用于数据存储、分析和报表生成的集成化管理系统，旨在构建面向分析的统一数据环境，为企业决策提供支持。数据仓库技术的发展不仅推动了企业的数字化转型，也体现了科技工作者在推动社会经济高质量发展中的责任担当。
数据仓库具有四个显著特点，分别是面向主题（Subject-Oriented）、集成性（Integrated）、非易失性（Non-Volatile）和时变性（Time-Variant）。
面向主题是指将分析对象抽象为主题，以便集中分析和综合归类。
面向主题
集成性要求将来自不同系统的数据进行集中处理，解决字段定义不统一、计量单位不一致、缺失值等问题。
集成性
非易失性是指数据仓库主要用于分析而非频繁修改。
非易失性
时变性强调随着时间推移，数据仓库会持续引入新的数据批次，支持对不同时间段的数据进行分析。
时变性
数据仓库的特点
ETL的定义
ETL是Extract-Transform-Load的缩写，其中Extract（抽取）指从一个或多个数据源抽取数据；Transform（转换）指对抽取的数据进行清洗与转换；Load（加载）指将转换后的数据加载到目标系统。
📄 展开课件原文（第 7–10 页，共 4 页）
数据仓库的意义
了解数据仓库的意义，能够说出构建数据仓库的目的。
明确数据仓库的基本概念后，我们通过实际场景说明企业搭建数据仓库的意义。以大型保险集团为例，企业往往覆盖寿险、财险、车险、养老险等多条业务线，各线独立运作，分别记录和维护保单、客户、理赔等信息。这些信息一般由OLTP系统管理，该类系统常基于MySQL、Oracle、SQL Server等关系型数据库构建，核心目标是高并发、低延迟地支持日常事务的快速读写。
随着业务规模扩大，管理层会提出需要通过数据分析回答的经营问题，例如：险种是否适配市场、续保政策是否合理、理赔流程是否存在欺诈等。这类问题不能仅凭经验解决，必须依托数据分析实现数据驱动决策。
性能影响：
数据范围受限：
复杂分析查询会占用大量计算与I/O资源，拖慢事务处理，甚至引发超时。
OLTP系统通常仅保留近期数据，历史数据多被归档到系统外，难以支撑长周期趋势分析。
数据异构分散：
大型企业常存在多个业务系统，字段、单位、格式不统一，跨系统联查困难。
理论上，企业可直接在OLTP系统上开展数据分析，但在实践中既不适用也效率低，主要原因如下。
数据仓库通过ETL定期从各业务系统抽取数据，支持多维分析、趋势挖掘、可视化报表等需求，同时与日常业务系统解耦。下图展示了典型的数据仓库架构。
OLTP和OLAP
理解OLTP和OLAP（Online Analytical Processing，联机分析处理）概念有助于区分数据库和数据仓库的本质差别，具体介绍如下。
OLAP
OLTP
OLTP是一种操作型处理模式，核心目标是支持日常数据处理，针对具体业务场景在数据库中执行联机事务操作，通过对数据的增、删、改、查完成业务交互。
1. OLTP
2. OLAP
OLAP是一种分析型处理模式，核心目标是支持数据分析，针对特定业务主题的历史数据执行复杂的多维分析，为管理决策提供依据。
接下来，通过一张表来比较OLTP和OLAP，具体如表。
| 对比维度 | OLTP | OLAP |
|---|---|---|
| 核心目标 | 面向应用、支撑事务 | 面向主题、支撑决策 |
| 数据规模 | MB/GB级 | TB/PB级 |
| 数据模型 | 第三范式，行存为主，避免冗余 | 星形/雪花模型，列存为主，可通过冗余换取分析性能 |
| 响应时间 | 毫秒级 | 秒/分钟/小时/天（取决于数据量和查询复杂度） |
| 并发量 | 高并发 | 中等并发 |
| 操作类型 | 以增、删、改、查为主，针对少量数据的高频简单操作 | 以查询为主，针对全量历史数据的低频复杂操作 |
📄 展开课件原文（第 11–18 页，共 8 页）
数据仓库分层架构
熟悉数据仓库分层架构，能够描述三层架构中ODS、DW和DA的概念。
数据仓库的一个核心特性是自身不产生数据，而是从各类数据源收集数据。同时，它不直接消费分析结果，而是将结果提供给业务场景使用。这一特性形成了“数据流入→数据分析→数据流出”的过程。基于这一过程形成分层设计的理念。
数据仓库分层是通过将数据按处理阶段和用途划分为不同层级，且每个层级中的数据均以表的形式进行组织存储，以实现数据管理的规范化和灵活性。关于分层数量，行业并无硬性标准，企业可根据自身业务需求灵活设定层次。不过，最基础且经典的划分思路是三层架构，包括ODS层、DW层和DA层，如图。
ODS层从各业务系统抽取原始数据，通常不对数据进行改动，其作用类似一个缓冲区，先将分散的原始数据集中存储，为后续的数据加工处理奠定基础。通过ODS层，可避免直接连接业务系统带来的耦合性及潜在风险。各业务系统的数据源类型多样，包括数据库、系统日志、网络爬虫等。
1. ODS层
DW层是整个数据仓库分层架构的核心部分，其数据由ODS层的原始数据经清洗、转换加工而成，将零散的原始数据处理为可分析、可复用的主题化数据。在DW层内部，企业会根据业务复杂度和分析需求进一步细分层次，常见的细分层次包括DWD层、DWB层、DWS层和DIM层。
2. DW层
DWD层主要存储ODS层的原始数据转化为结构规范、质量可靠的明细数据，这些明细数据存储于明细事实表（或明细表）中，完整保留业务的原始细节，既可以直接用于特定场景的明细查询，也可以为上层的汇总计算提供准确、一致的数据源。
(1) DWD层
DWB层主要存储对DWD层的明细数据按业务主题进行整合和关联后的数据，这些数据存储于中间事实表（或业务表）中。DWB层的核心作用是聚焦特定业务场景，将分散的明细数据通过关联字段串联起来，形成面向完整业务过程的数据视图。
(2) DWB层
DWS层主要存储对DWD层的明细数据进行聚合计算后得到的汇总数据，这些数据存储于汇总事实表（或宽表）中。DWS层的核心作用是根据分析需求，将分散的明细数据按不同维度（如地区、月份、用户群体等）汇总到对应粒度，形成标准的指标化的数据
通过预先聚合计算，上层应用可直接获取汇总后的指标数据，无需每次从DWD层的明细数据中重复计算，从而减少大量资源消耗提升分析效率和响应速度。
(3) DWS层
DIM层主要存储描述业务实体的维度数据。维度数据是指用来描述和刻画业务事实的属性信息，为分析业务问题提供多样化的观察角度，在数据仓库中通常存储于维度表中。例如在电商场景中，用户、商品、地区、时间等都属于维度。
DIM层的核心作用是支撑多维度查询与分析，通过提供标准化的维度定义，为各类事实表提供统一的维度关联基础，确保不同事实表在按维度统计时口径统一，避免分析结果因维度定义差异产生歧义。
(4) DIM层
DA层是整个数据仓库分层架构中最接近上层应用的部分，其存储的数据源于DW层加工后的标准化数据，通过结合具体业务场景的分析需求，进行针对性的计算、建模或可视化处理，最终形成可直接被业务人员调用的结果数据。
DA层覆盖的业务场景广泛，包括但不限于固定报表输出、可视化展示、BI设计等，直接支撑业务决策的落地与执行。
3. DA层
通过上述内容的学习可以看出，数据仓库的分层设计会带来一定程度的数据冗余，那么为什么企业在实际应用中，仍然需要对数据仓库进行分层呢？
原因主要有以下几点。
结构清晰：
支持数据血缘追踪：
每层数据都有清晰的作用域，使用者可根据需求快速定位所需数据，同时通过层级定位能更直观地理解数据的来源、加工程度和适用场景，减少数据理解成本。
当用户在上层应用中使用某个表时，能够通过分层架构追溯到该表的数据来源于哪些底层数据源，以及在各层级间经过了哪些转换处理。
避免重复开发：
数据仓库通过分层设计对外提供统一的查询接口，各业务部门均可使用同一套标准化的数据源，无须各自重复开发ETL过程，从而减少了大量的冗余工作和计算消耗。
把复杂问题简单化：
屏蔽原始数据的变化：
数据处理的全流程被拆解为多个独立的环节，每一层仅处理特定的任务。若某一层出现问题，只需对该层进行局部维护，无须重构整个数据链路。这种解耦合的设计大大降低了开发和维护的复杂度，提高了工作效率。
当业务系统发生变更时，可在ODS层或ETL过程中进行适配处理，确保上层的DW层、DA层数据不受影响。这种隔离机制使上层系统与下游业务解耦，减少了上层应用的改动成本，保障了业务分析工作的连续性。
📄 展开课件原文（第 19–31 页，共 13 页）
数据仓库的数据模型结构
了解数据仓库的数据模型结构，能够说出星形模型和雪花模型的区别。
数据仓库中的数据模型结构是数据组织的骨架，它通过明确事实与维度之间的关联逻辑，将业务场景转化为可计算的表关系，直接影响查询效率和业务适配性。常见的数据模型结构包括星形模型和雪花模型，具体介绍如下。
雪花
模型
星形
1. 星形模型
星形模型是一种结构简单的多维数据模型，因整体形态类似星星而得名。它以一个事实表为核心，周围连接多个维度表，其中事实表主要存储业务事件中可量化的度量数据，以及与各维度表关联的外键，是记录业务行为结果的核心载体；而维度表则用于描述这些业务事件的相关属性，为度量数据提供丰富多样的观察视角。
在星形模型中，事实表通过外键与所有维度表直接关联，而维度表之间无任何关联关系，保持相互独立。这种设计使星形模型结构简洁、直观易懂，查询时仅需通过事实表与维度表的直接连接即可获取完整分析数据，无须复杂的多表嵌套关联，因此查询效率较高，成为数据仓库中支撑高频业务分析的主流建模方法。
关于星形模型的示意图如图。
2. 雪花模型
雪花模型是在星型模型基础上的扩展形式，因维度表细分后结构形似雪花而得名。其核心特征是将星型模型中的部分维度表进一步细分为多个关联的子维度表，形成层级关系。雪花模型通过维度细分实现了更细致的业务描述，但由于维度表存在多层级关联，查询时需要更多的表连接操作，因此查询效率通常低于星形模型。
关于雪花模型的示意图如图。
任务：认识Hive
1.2
📄 展开课件原文（第 32–39 页，共 8 页）
1.2 认识Hive
Hive概述
了解Hive的基本概念，能够说出Hive的主要作用及其在大数据分析中的应用场景。
随着大数据时代的到来，企业与组织面临的数据量呈爆炸式增长，传统关系型数据库在处理PB级甚至EB级数据时，逐渐显现出存储容量有限、计算效率低下等问题。Hadoop生态系统的出现，为海量数据的存储和分布式计算提供了基础，但MapReduce编程模型复杂，要求开发者具备扎实的分布式计算理论和Java编程能力，这使得大量熟悉SQL的数据分析人员难以直接参与大数据处理工作。
在这样的背景下，Hive应运而生。Hive最初的设计目标是解决企业内部海量日志数据的分析需求，随后被捐献给Apache软件基金会。经过持续迭代，Hive逐渐成为大数据领域主流的数据仓库工具。使用Hive的版本为4.1.0。
Hive是一个基于Hadoop的数据仓库工具，它提供了类似SQL的查询语言——HiveQL（Hive Query Language，简称HQL），使用户可以通过编写HiveQL语句，对存储在HDFS（Hadoop Distributed File System，Hadoop分布式文件系统）中的大规模数据进行查询、分析和管理，而无须编写复杂的分布式计算程序。
Hive的核心思想是将HDFS上的半结构化数据或结构化数据文件映射为具有明确表结构的表，从而支持类似关系型数据库的表级操作。对于大规模数据的复杂分析任务，Hive会将HiveQL语句自动转换为分布式计算任务，Hive 4.1.0默认执行引擎为Tez，也可以配置为MapReduce（不推荐），从而利用分布式计算能力处理海量数据。这种设计显著降低了大数据分析的门槛，使熟悉 SQL 的用户能够快速上手并处理大规模数据，因此成为企业构建数据仓库时的常用工具。
📄 展开课件原文（第 40–44 页，共 5 页）
Hive架构
了解Hive架构，能够说出Hive基础架构中各组件的作用。
Hive作为构建在Hadoop之上的数据仓库工具，采用模块化、分层式架构设计，旨在支持大规模数据的分析与查询。Hive的典型执行路径涵盖了从用户提交HiveQL语句到最终在YARN上调度并执行任务的完整过程，各核心组件在其中分工明确、协作紧密。
关于Hive的基础架构如图。
下面将对Hive基础架构中的各个组件进行详细介绍。
Hive客户端是用户与Hive交互的入口，常见的客户端包括Beeline、JDBC/ODBC驱动程序、BI工具等。Hive客户端主要负责接收用户提交的HiveQL语句，并通过Thrift协议与HiveServer2建立连接。Hive客户端本身并不承担HiveQL语句的解析或执行计划生成等复杂逻辑，而是作为交互入口存在。需要说明的是，在Hive 4.1.0中，原有的命令行工具Hive CLI已被替换为Beeline。
Hive 客户端HiveServer2是一种基于Thrift协议的服务，主要用于代理Hive客户端的访问请求，负责会话管理、连接池、身份验证等功能。HiveServer2接收来自Hive客户端提交的HiveQL语句，并将其转交给Driver进行解析、优化和执行计划生成等后续处理。
HiveServer2
Metastore是一种基于Thrift协议的元数据管理服务，负责存储和管理表结构、分区信息、存储位置等元数据。Metastore可以将元数据保存在外部关系型数据库（如MySQL、PostgreSQL等），或内嵌的Derby数据库中。
Metastore
Driver是处理HiveQL语句的核心组件，内部包含 Parser（解析器）、SemanticAnalyzer（语义分析器）、Optimizer（优化器）和Compiler（编译器）四个组件，各组件协同完成HiveQL语句从输入到执行计划生成的完整处理流程，具体职责如下。
Driver
Parser负责接收用户输入的HiveQL语句，并将其转换为抽象语法树（AST，Abstract Syntax Tree）。
SemanticAnalyzer负责对抽象语法树进行语义校验，包括元数据验证、函数是否存在且参数是否合法、数据类型是否匹配等。
Optimizer负责对逻辑执行计划进行优化，转换为更高效的物理执行计划，并根据内置规则生成最优执行策略。
Compiler负责将物理执行计划编译为可运行的任务列表，并将这些任务构建为Task DAGTask 。DAG是一种用于描述任务之间依赖关系的图模型。
ExecutionEngine负责根据指定的执行引擎，在YARN上提交并执行任务，并通过HDFS读取所需的数据。不过，Hive并不会在执行所有HiveQL语句时都调用执行引擎。当用户执行的查询语句较为简单，不涉及分组、排序、连接等复杂操作，且底层存储格式支持直接读取时，Compiler会将物理执行计划编译为一个FetchTask，直接从数据源读取结果，无须执行引擎参与。此外，当HiveQL语句仅涉及元数据操作时，同样不会触发执行引擎的调用，因为此类操作仅依赖于Metastore的元数据服务。
ExecutionEngine（执行引擎）
ResourceManager和NodeManager是YARN的核心组件，其中ResourceManager负责接收客户端提交的任务，并根据集群资源状况进行资源分配，将任务分发到合适的NodeManager；NodeManager负责接收并执行ResourceManager分配的任务。
ResourceManager和NodeManager
NameNode和DataNode是HDFS的核心组件，其中NameNode负责管理文件系统的元数据；DataNode负责实际存储数据块。当执行建表、添加分区等操作时，Hive先通过Driver 向NameNode发起创建目录请求，目录创建成功后，Metastore会更新元数据。
NameNode和DataNode
任务：认识Hive的数据组织方式
1.3
📄 展开课件原文（第 45–57 页，共 13 页）
1.3 认识Hive的数据组织方式
Hive的数据模型
掌握Hive的数据模型，能够描述数据库、表、分区和分桶的概念和作用。
数据模型用于描述、组织和操作数据，是对现实世界数据特征的抽象表达。Hive的数据模型设计借鉴了传统关系型数据库的表结构与模式管理理念，同时针对大规模分布式存储和计算环境进行了专门优化，使其能够高效管理和查询存储在HDFS中的海量半结构化和结构化数据。
关于Hive的数据模型示意图如图。
在Hive中，数据库是逻辑上的命名空间，用于组织和隔离表。每个数据库可以包含多张表。数据库的引入不仅有助于分类管理，还便于在多用户环境下实现资源隔离。
在物理存储层，Hive会在HDFS上为每个数据库（除默认数据库default）创建一个独立的目录，用于存放该数据库下所有表的数据文件。目录的命名格式为databasename.db，其中databasename为数据库名称。
数据库
在Hive中，表是最基本的数据组织单位，定义了数据的结构和存储位置，类似于传统关系型数据库中的表。Hive中的表主要分为内部表和外部表两种类型。内部表的生命周期由Hive全权管理，当用户删除内部表时，Hive会同时删除该表的元数据和对应的数据文件。相对而言，外部表仅由Hive管理其元数据，底层数据文件则由用户或外部系统负责维护。删除外部表时，Hive只会移除其元数据，不会删除实际数据文件，这使得外部表更适合用于与其他系统共享数据的场景。
表
在物理存储层，Hive会在HDFS上为每个表创建一个独立的目录。当表所属的数据库不是default数据库时，其在HDFS上的默认存储路径如下。
{hive.metastore.warehouse.dir}/databasename.db/tablename表示实际的表名
分区是Hive提供的一种逻辑划分机制，用于在物理存储层（如HDFS）按照一个或多个维度，将同一张表的数据分布到不同的目录中。这种机制特别适用于按时间、地域等维度对大规模数据进行切分的应用场景。
在查询时，Hive会利用分区裁剪技术，仅读取目标分区的数据，从而避免全表扫描，大幅减少不必要的数据读取，并显著提升查询效率。
分区
在物理存储层，Hive会在HDFS上为每个分区创建一个独立的目录，目录名以“分区字段=分区值”的形式命名，其中分区字段用于划分表数据，不属于表实际存储数据的字段；分区值是分区字段的具体取值。当表所属的数据库不是default数据库时，其包含的分区在HDFS上的默认存储路径如下。
{hive.metastore.warehouse.dir}/databasename.db/tablename/column=valuecolumn和value分别表示分区字段和分区值
在Hive中，分桶是将表或分区中的数据进一步划分为多个数据文件的划分机制。分桶有助于均衡数据分布，提升连接查询、抽样查询等特定类型查询的执行效率。
分桶拆分数据的规则是，根据指定的分桶数量，对表中分桶字段的值进行哈希计算，取哈希值的绝对值再与分桶数量取模，余数相同的记录会被分配到同一个数据文件中。分桶数量决定了拆分后生成的数据文件数量，通常每个桶对应一个数据文件，但在事务表、多次写入或文件合并等场景下，一个桶可能对应多个数据文件。
在物理层面，表或分区的数据会在对应的存储目录下划分为多个文件。
分桶
📄 展开课件原文（第 58–66 页，共 9 页）
Hive的数据类型
熟悉Hive的数据类型，能够描述原生数据类型和复杂数据类型的概念。
数据类型决定了表中字段的数据格式。Hive的数据类型体系围绕SQL兼容性与分布式数据处理需求设计，涵盖原生数据类型（Primitive Data Types）和复杂数据类型（Complex Data Types）两大类，具体介绍如下。
复杂数据类型
原生数据类型
1. 原始数据类型
原生数据类型用于存储简单且单一的数据，主要包括数值类型（Numeric Types）、字符串类型（String Types）、日期/时间类型（Date/Time Types）和其他类型（Misc Types），具体介绍如下。
数值类型用于表示整数、浮点数和精确十进制数字，关于数值类型支持数据类型的介绍如表。
（1）数据类型
| 数据类型 | 描述 |
|---|---|
| TINYINT | 1字节有符号整数，[-128,127] |
| SMALLINT | 2字节有符号整数，[-32768,32767] |
| INT/INTEGER | 4字节有符号整数，[-231,231-1] |
| BIGINT | 8字节有符号整数，[-263,263-1] |
| 数据类型 | 描述 |
|---|---|
| FLOAT | 4字节单精度浮点数 |
| DOUBLE | 8字节双精度浮点数 |
| DECIMAL | 精确十进制数字，语法格式为DECIMAL(p[,s])，其中p表示数字的总有效位数，包括整数位和小数位，最大取值为38；s用于指定小数位的位数，要求s必须小于p的取值。例如，DECIMAL(7,2)的最大值为99999.99，若尝试写入100000会导致溢出错误 |
| NUMERIC | 自Hive 3.0开始NUMERIC只是DECIMAL的别名 |
字符串类型用于表示文本信息，关于字符串类型支持数据类型的介绍如表。
（2）字符串类型
| 数据类型 | 描述 |
|---|---|
| STRING | 可变长字符串，长度无上限 |
| VARCHAR | 可变长字符串，必须声明允许的最大字符数。若实际输入值超过该限制，会截取超出部分的字符。语法格式为VARCHAR(n)，n的取值范围是[1,65535] |
| CHAR | 定长字符串。语法格式为CHAR(n)，n的取值范围是[1,255] |
日期/时间类型用于表示日期和时间信息，关于日期/时间类型支持数据类型的介绍如表。
（3）日期/时间类型
| 数据类型 | 描述 |
|---|---|
| TIMESTAMP | 支持具有纳秒级精度的时间戳，格式为“YYYY-MM-DD HH:MM:SS.fffffffff”。例如，2024-01-01 12:34:56.789表示具有毫秒级精度的时间戳 |
| DATE | 格式为“YYYY-MM-DD”的日期。例如，2024-01-01 |
| INTERVAL | 表示时间长度，而非具体日期或时间。主要分为两类定义方式，分别为INTERVAL YEAR TO MONTH和INTERVAL DAY TO SECOND，前者用于表示跨年的时间跨度，精确到月，例如，INTERVAL '2-3' YEAR TO MONTH表示2年3个月；后者用于表示不足一个月的时间跨度，支持微秒级精度，例如，INTERVAL '2 03:04:05.678' DAY TO SECOND表示2天3小时4分5.678秒 |
Hive中的其他类型主要包括布尔类型和二进制类型，具体介绍如表。
（4）其他类型
| 数据类型 | 描述 |
|---|---|
| BOOLEAN | 逻辑值。仅允许TRUE、FALSE和NULL三种取值，大小写均可 |
| BINARY | 二进制数据。可用于存储加密后的数据、序列化对象、图片、音频等非文本信息 |
2. 原始数据类型
复杂数据类型是Hive为适应半结构化和嵌套数据存储而引入的重要扩展，主要包括ARRAY、MAP、STRUCT和UNIONTYPE四种数据类型，其中UNIONTYPE类型的支持尚不完善，目前仅具备基本的存储和传输能力，无法在复杂查询中充分发挥作用，使用场景非常有限，因此本教材不做重点介绍。关于其他三种复杂数据类型的介绍如表。
| 数据类型 | 语法格式 | 描述 |
|---|---|---|
| ARRAY | ARRAY<element_type> | 表示由同类型元素构成的有序集合。element_type用于定义元素的数据类型，可以是Hive支持的任意数据类型。可以通过下标访问集合中的元素，下标从0开始。 |
| 数据类型 | 语法格式 | 描述 |
|---|---|---|
| MAP | MAP<key_type,value_type> | 表示由键值对构成的无序集合，键必须唯一。key_type用于定义键的数据类型，必须是Hive支持的任意原生数据类型。value_type用于定义值的数据类型，可以是Hive支持的任意数据类型。可以通过键访问对应的值。 |
| STRUCT | STRUCT<field:type,field:type,…> | 表示具有固定字段的集合，每个字段具有独立的数据类型。field用于定义字段名称。type用于定义相应字段的数据类型，可以是Hive支持的任意数据类型。可以通过字段访问对应的值。 |
构建复杂的数据结构，具体示例代码如下。
CREATE TABLE orders (order_id INT,
customer STRUCT<
id: INT,
name: STRING,
address: STRUCT<city: STRING, zip: STRING>
>,
items ARRAY<STRUCT<product_id: INT, name: STRING, price: DOUBLE>>,
metadata MAP<STRING, STRING>
);基本格式
数据类型为INT
数据类型为STRUCT
数据类型为ARRAY
数据类型为MAP
数据类型转换
Hive支持隐式类型转换和显式类型转换两种方式对数据的类型进行转换，其中隐式类型转换是指在没有显式指定转换的情况下，不同数据类型的数据协同工作时自动发生转换，例如在对不同类型的数据进行计算时。显式类型转换是指通过Hive提供的CAST函数明确指定目标数据类型来进行转换。如果转换成功，数据将以新类型的格式进行显示；否则，转换失败的数据将显示为NULL。
需要注意的是，Hive在进行隐式类型转换时，只有符合转换规则的数据类型才能成功转换为目标类型。关于隐式类型转换支持的数据类型转换规则如图。
AI助学
学完本单元后，读者已经初步了解数据仓库的基本思想，认识Hive在数据仓库建设中的作用及其数据组织方式。然而，在面对真实业务需求时，仍可能难以准确判断数据仓库层级的划分方式，难以将业务过程抽象为事实表和维度表，也难以进一步确定Hive中数据库、表、分区、分桶以及字段数据类型的设计方案。此时，可借助AI对业务需求进行初步拆解，将较为复杂的业务描述转化为清晰的数据仓库设计思路和Hive数据组织方案。
AI
助
学
单元总结
本单元主要讲解了数据仓库和Hive相关的基础知识。首先，介绍了数据仓库的基本概念，包括其特点、意义、分层架构和数据模型结构。然后，详细讲解了Hive的基本概念和架构。最后，重点介绍了Hive的数据模型和数据类型。通过本单元的学习，读者能够对数据仓库和Hive有一个初步的认识，为后续深入掌握Hive的应用奠定坚实的基础。
单
元
总
结
📄 展开课件原文（第 67–81 页，共 15 页）
🧪 动手做一遍 10 分钟跑通你的第一条 HiveQL
预计用时约 10 分钟 · 每一步都给出可执行语句与预期结果，建议边看边在 Beeline / DataGrip 里敲一遍
本实例步骤
- 01 连上 Hive 客户端
- 02 看看有哪些库，然后建一个自己的库
- 03 建表并塞两条数据
- 04 查一下
- 05 看一眼执行计划
- 06 退出
01连上 Hive 客户端
用 Beeline 通过 JDBC 连接 HiveServer2（远程模式），这是生产环境最常用的方式。
beeline -u "jdbc:hive2://hadoop1:10000" -n hadoop| 提示 |
|---|
| Connected to: Apache Hive (version 4.1.0) |
| Beeline version 4.1.0 by Apache Hive |
| 0: jdbc:hive2://hadoop1:10000> ← 出现这个提示符就表示连上了 |
hive 回车即可；本地模式常用 beeline -u jdbc:hive2://。02看看有哪些库，然后建一个自己的库
数据库是 Hive 最外层的数据组织单位，先把“仓库”建出来。
SHOW DATABASES; -- 默认只有 default
CREATE DATABASE IF NOT EXISTS demo
COMMENT '第一次动手演示库'
LOCATION '/user/hive/warehouse/demo.db'; -- 不写 LOCATION 时使用默认仓库目录
USE demo; -- 切换进去| database_name |
|---|
| default |
| demo ← 新建的库 |
💡 库在 HDFS 上就是一个目录：/user/hive/warehouse/demo.db。
03建表并塞两条数据
体验 DDL + DML 的最短闭环：建表 → INSERT VALUES。
CREATE TABLE IF NOT EXISTS demo.t_stu(
name STRING COMMENT '姓名',
age INT COMMENT '年龄'
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
STORED AS TEXTFILE;
INSERT INTO demo.t_stu VALUES ('张三', 20), ('李四', 21);LOAD DATA。04查一下
验证数据确实进来了。
SELECT * FROM demo.t_stu;
SELECT name FROM demo.t_stu WHERE age > 20;| name | age |
|---|---|
| 张三 | 20 |
| 李四 | 21 |
💡 第二条只返回“李四”。WHERE 在 Map/Reduce 阶段前就会做过滤，扫描的数据量更小。
05看一眼执行计划
理解“HQL 会被翻译成分布式作业”这件事。
EXPLAIN SELECT name FROM demo.t_stu WHERE age > 20;TableScan、Filter、Map Operator Tree 等，说明这条 SQL 被转成了分布式任务；把执行引擎换成 Tez 后再看，计划结构会不一样。06退出
收工。
!quit