数据入湖入仓问题分析笔记

一、现有技术栈核心问题分析

1.1 架构现状

• 核心技术栈：Hive传统数仓为主体，无原生数据湖能力
• 数据量级：PB级海量数据，存储成本高度敏感
• 数据类型：结构化、半结构化、非结构化数据并存
• 同步方式：全量同步为主，存在新增、日常更新、大批量变更场景
• 业务场景：离线分析为主、部分实时统计、AI建模实验
• 核心诉求：支持任意时间点数据快照回溯、统一查询引擎

1.2 现存技术痛点

• Hive无ACID事务，不支持UPDATE/DELETE，数据更新仅能全量重刷，资源损耗极大
• 无原生快照回溯能力，无法支撑对账、故障恢复、业务审计溯源
• 强写死Schema，不兼容日志、JSON、附件等非结构化数据，AI建模存在中转冗余
• 无冷热分层机制，PB级数据长期高价存储，成本居高不下
• 流批架构割裂，离线、实时两套存储，无统一查询与存储底座

二、数据入湖入仓核心概念

2.1 数据入仓（Hive数仓）

• 架构模式：ETL模式（先清洗、后入库）
• 核心特征：写时Schema校验、结构固定、约束严格、口径统一
• 适配数据：纯结构化标准化业务数据
• 核心短板：无增量更新、无版本快照、多类型数据兼容差、存储成本高

2.2 数据入湖（Hudi/Iceberg）

• 架构模式：ELT模式（先落盘、后清洗）
• 核心特征：读时Schema解析、支持Schema演进、ACID事务、Upsert更新、TimeTravel回溯、冷热分层
• 适配数据：结构化、半结构化、非结构化全类型数据
• 核心优势：适配PB级数据、CDC增量、大批量更新、AI样本存储、低成本归档

三、入湖入仓适用场景及业务案例

3.1 数据入湖适用场景

• 多源原始数据归档：业务全量、CDC增量、埋点日志、系统日志、图片附件原始落湖
• 高频大批量更新：订单状态、库存、余额等频繁变更、批量更新业务表
• 数据回溯审计：财务月末对账、数据故障恢复、业务操作溯源
• AI建模场景：算法特征工程、模型训练，直接读取原始明细数据
• 海量冷数据归档：多年历史明细数据，冷热分层压缩存储成本
• 实时数据计算：低延迟同步、实时大屏，支撑部分实时业务诉求

3.2 数据入仓适用场景

• 标准化T+1离线报表：日常经营统计、部门BI看板、固定维度聚合指标
• 核心合规指标：财务、营收、交易、成本高精度指标，强治理、口径统一
• 高频聚合查询：多表关联、维度汇总宽表，适配高频BI查询场景

四、入湖入仓整体落地流程

4.1 整体架构链路

多源数据源 → 全量/CDC数据同步 → 原始数据入湖 → 湖内清洗加工 → 聚合数据入仓 → 统一引擎对外服务

4.2 流程拓扑图

plaintext 数据源：MySQL/Oracle/日志文件/业务附件 ↓ 同步层：DataX全量初始化、Flink CDC增量监听 ↓ 数据湖ODS层：Hudi/Iceberg 原始落盘、快照留存、冷热分层 ↓ 加工层：Spark/Flink 清洗、去重、增量合并、维度补全 ↓ 分支1（湖能力）：实时大屏、AI建模、数据回溯、明细查询 分支2（仓能力）：聚合汇总 → Hive DWM/DWS 入仓固化 ↓ 统一查询：Trino/Presto 同时兼容湖表、仓表查询 ↓ 业务应用：BI报表、算法平台、数据对账、审计回溯

4.3 分层流程说明

• ODS原始层：所有原始数据统一入湖，保留完整原貌，开启版本快照
• DWD明细层：湖内完成清洗、增量合并，替代Hive全量重刷任务
• DWM/DWS汇总层：湖内明细聚合统计后写入Hive，兼容原有离线报表
• 应用层：明细/实时/AI走湖，离线指标/BI看板走仓，Trino统一查询

五、数据湖与数据仓库核心区别

5.1 核心差异对比

• 数据类型：数据湖支持全类型数据，数据仓库仅支持结构化数据
• Schema机制：数据湖读时解析、支持演进；数据仓库写时校验、结构固定
• 事务能力：数据湖支持ACID增删改查；数据仓库无事务、仅覆盖写入
• 回溯能力：数据湖原生时间旅行回溯；数据仓库无原生回溯能力
• 存储成本：数据湖冷热分层、低成本归档；数据仓库仅高价温热存储
• 业务场景：数据湖适配实时、增量、AI、海量归档；数据仓库适配标准化离线报表

5.2 落地核心原则

• 原始明细入湖，聚合指标入仓
• 变更数据入湖，固定口径入仓
• 冷量数据入湖，温热指标入仓

六、落地核心代码实现

6.1 Hudi入湖建表语句（增量更新+快照回溯）

CREATETABLEhive_ods_order_hudi(order_id string,user_id string,order_statusint,amountdecimal(10,2),create_time string,update_time string)PARTITIONEDBY(dt string)STOREDASHUDI TBLPROPERTIES('hoodie.table.name'='hive_ods_order_hudi','hoodie.datasource.write.recordkey.field'='order_id','hoodie.datasource.write.partitionpath.field'='dt','hoodie.datasource.write.precombine.field'='update_time','hoodie.datasource.write.operation'='upsert','hoodie.enable.time.travel'='true','hoodie.keep.max.commits'='30');

6.2 Iceberg入湖建表语句（Schema演进+统一查询）

CREATETABLEhive_ods_user_log_iceberg(log_id string,user_id string,event_type string,event_json string,create_timetimestamp)PARTITIONEDBY(dt string)STOREDASICEBERG TBLPROPERTIES('format-version'='2','vacuum.min-retention'='7');

6.3 湖表时间回溯查询代码

-- Hudi 指定时间快照回溯查询SELECT*FROMhive_ods_order_hudiFORSYSTEM_TIMEASOFTIMESTAMP'2026-06-01 00:00:00'WHEREdt='2026-06-01';-- Iceberg 历史快照回溯查询SELECT*FROMhive_ods_user_log_icebergFORSYSTEM_TIMEASOF'2026-06-01 00:00:00'WHEREdt='2026-06-01';

6.4 Spark湖转仓汇总代码

spark.read.format("hudi").load("/warehouse/hive_ods_order_hudi").filter("dt >= '2026-06-01'").groupBy("dt","order_status").agg(count("order_id").alias("order_cnt"),sum("amount").alias("total_amount")).write.mode("overwrite").partitionBy("dt").saveAsTable("hive_dws_order_summary");

6.5 Trino湖仓统一查询代码

SELECTa.dt,a.order_cnt,a.total_amount,b.order_id,b.user_idFROMhive_dws_order_summary aLEFTJOINhive_ods_order_hudi bONa.dt=b.dtWHEREa.dt='2026-06-01';

七、最终落地规范

• 原始日志、CDC增量、大批量变更、AI样本、历史冷数据全部入湖
• 聚合汇总、核心指标、标准化BI报表、合规对账数据全部入仓
• 高频更新业务表统一使用Hudi/Iceberg湖表，替换Hive全量重刷任务
• 存量Hive汇总表保留，实现新旧架构平滑过渡
• 统一使用Trino/Presto查询引擎，实现湖仓一体化查询