数据仓库、数据湖与湖仓一体技术笔记
数据仓库、数据湖与湖仓一体技术详解
1. 数据仓库 (Data Warehouse)
1.1 核心概念
- 定义：面向主题、集成、相对稳定、反映历史变化的数据集合，用于支持管理决策。
- 四大特征：
- 面向主题：围绕决策重点（如客户、产品）组织数据，区别于操作型数据库的事务处理导向。
- 集成：抽取分散的操作型数据，经加工/集成/统一后加载。
- 相对稳定：侧重查询分析，数据不可频繁更新。
- 反映历史变化：周期性（时/日/周）从数据源抽取数据，记录历史轨迹。
1.2 系统结构
| 组件 | 功能描述 |
|---|---|
| 数据源 | 提供原始数据的数据库或业务系统 |
| 数据存储与管理 | 存储集成后的数据，支持高效访问 |
| OLAP服务器 | 提供多维分析能力，支持复杂查询 |
| 前端工具 | 报表/可视化/数据挖掘等应用接口 |
1.3 数据仓库 vs 数据库
| 特性 | 数据库 | 数据仓库 |
|---|---|---|
| 核心功能 | 事务处理 | 分析、报告、大数据处理 |
| 数据源 | 单一来源捕获 | 多来源抽取与标准化 |
| Schema | 高度标准化静态结构 | 非标准化灵活结构 |
| 写入优化 | 连续写入 | 批量计划写入 |
| 存储优化 | 行式存储（高吞吐写） | 列式存储（高速查询） |
| 读取优化 | 大量小型读取 | 最小化I/O，最大化吞吐 |
2. 数据湖 (Data Lake)
2.1 核心概念
- 定义：存储原始格式（对象块/文件）的全量企业数据仓库，包含原始数据及转换数据。
- 本质：由 存储架构 + 处理工具 构成的解决方案。
- 工具分类：
- 数据入湖工具：定义数据源、数据迁移、目录编制、质量管理（如 AWS Lake Formation + Glue）。
- 数据分析工具：支持机器学习、实时分析、交互式分析（如 Spark、Presto）。
2.2 数据湖 vs 数据仓库
| 特性 | 数据仓库 | 数据湖 |
|---|---|---|
| 数据类型 | 结构化数据 | 结构化/半结构化/非结构化 |
| Schema | 事前设计 | 按需分析时定义 |
| 成本 | 起步成本高（本地存储） | 起步成本低（存算分离） |
| 数据质量 | 高（可信事实依据） | 原始数据为主 |
| 主要用户 | 业务分析师 | 数据科学家/开发人员 |
| 典型应用 | BI报表、可视化分析 | 机器学习、数据探索、流处理 |
2.3 解决的企业痛点
- 打破数据孤岛：统一存储分散数据，实现跨源联合分析。
- 降低存储成本：原生格式存储 + 低成本对象存储（如 S3）。
- 超越SQL分析：支持非结构化数据挖掘（文本/图像）。
- 弹性扩展：存算分离架构应对海量数据增长。
- 灵活建模：无需预先定义业务模型，适应快速变化。
3. 湖仓一体 (Lakehouse)
核心架构与特性
- 定位：融合数据仓库性能与数据湖灵活性，支持多数据类型共享。
- 数据流动：湖中“新鲜”数据可流入仓实时分析，仓中“陈旧”数据可归档至湖长期保存。
| 特性 | 描述 |
|---|---|
| 事务支持 | 提供ACID保证，确保并发读写一致性（SQL模式） |
| 数据治理 | 支持星型/雪花模型，具备完整治理与审计机制 |
| BI直连 | BI工具可直接查询源数据，降低延迟与冗余存储 |
| 存算分离 | 独立扩展存储与计算资源，支撑大规模并发 |
| 开放格式 | 使用Parquet等开放存储格式，兼容多引擎（Python/R/ML） |
4. Hive 概述
4.1 传统数仓的挑战
- 海量存储瓶颈：关系数据库横向扩展性差，难应对TB级数据增长。
- 多类型数据支持不足：仅能处理结构化数据，无法兼容半/非结构化数据。
- 计算能力有限：TB级数据处理时性能急剧下降。
4.2 Hive 简介
- 定位：基于Hadoop的数据仓库工具，提供类SQL接口（HiveQL）。
- 底层依赖：
- 存储：HDFS
- 计算：MapReduce/Tez/Spark
- 核心特点：
- 批处理导向：适合静态数据分析，非实时场景。
- ETL工具链：内置数据提取、转换、加载能力。
4.3 Hive 生态定位
| 组件 | 与Hive的关系 |
|---|---|
| HDFS | 底层存储依赖，提供高可靠性 |
| MapReduce | 默认计算引擎，执行HiveQL转换的任务 |
| Pig | 替代工具，侧重数据流处理与ETL |
| HBase | 互补系统，提供实时数据访问能力 |
4.4 Hive vs 传统数据库
| 对比项 | Hive | 传统数据库 |
|---|---|---|
| 数据插入 | 批量导入 | 支持单条+批量 |
| 数据更新 | 不支持 | 支持 |
| 索引 | 支持 | 支持 |
| 分区 | 支持 | 支持 |
| 执行延迟 | 高（分钟级） | 低（毫秒级） |
| 扩展性 | 高（分布式） | 有限 |
5. Hive 系统架构
| 模块 | 组成与功能 |
|---|---|
| 用户接口 | CLI（Hive 3.0+由Beeline替代）、HWI、JDBC/ODBC、Thrift Server |
| 驱动模块 | 编译器 + 优化器 + 执行器（MapReduce/Tez/Spark） |
| 元存储 | 独立关系数据库（如MySQL），管理表结构/分区/位置等元数据 |
6. Hive 工作原理
6.1 SQL 转 MapReduce 逻辑
连接操作实现（示例：SELECT name, orderid FROM user JOIN order ON user.uid=order.uid）
| 阶段 | 操作 |
|---|---|
| Map | 标记数据来源： - user 表 → (uid, <1, name>)- order 表 → (uid, <2, orderid>) |
| Shuffle/Sort | 按 uid 哈希分组，同组数据排序（标记位1在前） |
| Reduce | 同组数据做笛卡尔积：<1, name> + <2, orderid> → 输出 (name, orderid) |
分组操作实现（示例：SELECT rank, level, COUNT(*) FROM score GROUP BY rank, level）
| 阶段 | 操作 |
|---|---|
| Map | 输出键值对：(<rank, level>, 1) |
| Shuffle/Sort | 按 <rank, level> 分组排序 |
| Reduce | 累加同键计数值：<A,1> 的 [1,1,1] → 输出 (A,1,3) |
6.2 查询执行流程
- 驱动模块接收HiveQL查询。
- 编译器解析语法→生成逻辑计划→优化执行路径。
- 执行器将计划转为MapReduce任务提交至Hadoop。
- 结果通过用户接口返回（*简单查询可能跳过MapReduce）。
7. Hive HA 高可用
- 架构核心：多Hive实例池 + HAProxy统一接口。
- 工作流程：
- 客户端请求发送至HAProxy。
- HAProxy轮询检测可用Hive实例。
- 通过健康检查的实例处理查询。
- 结果经HAProxy返回客户端。
8. Impala 实时查询系统
8.1 核心定位
- 目标：提供低延迟SQL查询，补充Hive批处理场景。
- 兼容性：与Hive共享元数据、ODBC接口及SQL语法。
- 执行引擎：MPP架构（非MapReduce），避免作业启动开销。
8.2 系统架构
| 组件 | 功能 |
|---|---|
| Impalad | 进程实例，含三大模块： - Query Planner（解析SQL） - Query Coordinator（任务分发） - Query Exec Engine（本地执行） |
| State Store | 跟踪Impalad状态与资源，通过statestored进程维护心跳 |
| CLI | 提供命令行及Hue/JDBC/ODBC接口 |
8.3 查询流程
- 注册：Impalad向State Store注册并订阅状态。
- 解析：Query Planner将SQL转为执行计划树（PlanFragment）。
- 元数据获取：从MySQL元数据库和HDFS NN获取数据位置。
- 任务分发：Query Coordinator将任务分配至数据所在节点。
- 结果汇聚：各节点流式返回结果，由Coordinator汇总。
- 输出：最终结果返回至CLI客户端。
8.4 Impala vs Hive
| 维度 | Hive | Impala |
|---|---|---|
| 查询延迟 | 高（批处理分钟级） | 低（实时秒级） |
| 执行引擎 | MapReduce（管道型任务） | MPP（完整计划树分发） |
| 内存依赖 | 允许溢出到磁盘 | 纯内存计算，拒绝对外存 |
| 适用场景 | 大数据量ETL/批处理 | 交互式查询/小结果集分析 |
| 共享能力 | 同数据源（HDFS/HBase）、同元数据、同SQL接口 |