数据仓库、数据湖与湖仓一体技术详解
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接口 |