从数据库到数据湖

传统工业信息化把数据存进关系数据库：设备台账、工艺参数、生产工单各占一摊。随着物联网普及，产线上每天涌来海量的时序点、日志、图片、音视频，关系数据库装不下也处理不动，于是数据湖的概念进入工业领域：用廉价的对象存储把原始数据全部收进来，需要时再按需加工。

数据湖的价值是"先存后理"：数据先低成本沉淀，业务模式想清楚了再建模。但它也带来老问题——没有治理的数据湖会退化成数据沼泽，谁也找不到、谁也不敢用。

本文核心知识点
  • 湖仓一体数据湖的存储 + 数仓的治理。
  • 分层设计原始层、明细层、服务层。
  • 入湖同步批量 + 实时两条通道。
  • 治理闭环元数据、质量、血缘。

湖仓一体是当下的主流答案：底层的湖负责容纳所有格式的数据，上层的仓负责定义表结构、保障质量和性能，让数据既便宜又可信。

工业数据湖配图：深蓝渐变背景上高低错落的蓝色数据柱与服务器机柜，上方悬浮多个数据库圆柱图标，发光线条汇聚连接的扁平科技插画
数据湖把散落的数据收进来，湖仓一体再把它们变成资产。

湖仓一体架构

湖仓一体（Lakehouse）架构的核心是在对象存储之上加一层开放式表格式，常见的是 Iceberg 和 Hudi。它们把一批文件组织成一张可事务操作的"表"，支持 ACID、时间旅行和增量读取，让数据湖具备了数仓的可靠性和查询能力。

  • 存储层：对象存储或 HDFS，统一放原始与加工后的数据。
  • 表格式层：Iceberg/Hudi 管理表元数据和文件清单。
  • 计算层：Spark、Flink 做批流计算，查询引擎做即席分析。
  • 服务层：统一元数据服务，对外暴露表和 API。

工业场景里，实时数据（设备点位）和批量数据（日报、工单）要一起进来。湖仓一体天然支持"流批一体"：同一套表结构，流作业实时写入，批作业周期性补算，两边的数据能够对账一致。

数据分层与目录

湖里的数据要分层组织，每一层有清晰的职责和消费对象，这是防止数据沼泽的第一道防线。

# 数据湖分层目录示例
/raw/           # 原始层：原样接入，不改动
/raw/equipment/plc-20261027.parquet
/dwd/           # 明细层：清洗加工，统一口径
/dwd/equipment_metric/
/dws/           # 服务层：面向业务的汇总与宽表
/dws/product_yield_daily/

原始层只做归档，保留设备原始报文和采集快照；明细层做去重、补全、标准化，形成可信的明细数据；服务层面向具体业务，生成报表宽表、指标表和特征表。每一层都登记到元数据目录，写清楚负责人、更新频率和数据口径。

数据入湖与同步

入湖是数据湖运转的第一环。工业数据来源多样：MES 数据库、PLC 点位、时序库导出、文件上传，需要批量与实时两条同步通道。

// 实时入湖：Kafka 到 Iceberg 的流作业示意
DataStream stream = kafkaSource("equipment_metrics");
IcebergSink sink = IcebergSink.forTable(metricTable)
    .upsert(true)              // 按主键更新
    .build();
stream.upsertInto(sink);

批通道适合日报、工单这类低频数据，用调度框架定时抽取；实时通道适合设备点位，用 Kafka 加流处理接入。两条通道都要做断点续传和幂等写入，任务重启不能造成数据重复或丢失。入湖后要做行数对账：源端计数和湖内计数定期比对，差异即告警。