数仓存储不了视频，数据湖管不好质量？制造企业湖仓一体架构详解
【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总（持续更新）
📌 文章摘要
针对制造企业传统数仓无法承载非结构化数据、数据湖质量难管控的普遍痛点，结合智联工坊虚拟工厂实战场景，从数据类型、架构对比、业务落地、技术选型四个维度，讲透湖仓一体的核心价值与落地路径。方案对标 GB/T 39116-2020 智能制造标准，可直接作为企业数据平台建设的参考方案。
目录
开篇：数仓人躲不开的灵魂拷问
兄弟们，你们有没有遇到过这种场景？
领导说：“把设备日志、监控视频、传感器时序数据都放到数仓里，我要做综合分析。”
你第一反应是：“领导，数仓存不了视频啊……”
领导说：“那你们搞的那个什么湖，不是啥都能存吗？”
你说：“数据湖能存，但查起来慢得要命，而且数据质量没法保证。”
领导沉默了，你也沉默了。
当时我的第一反应是：这不科学啊……
数仓和数据湖明明都是存数据的，为什么一个存不了非结构化数据，一个管不好数据质量？
制造业的数据量越来越大，类型越来越多，传统的数仓架构正在被现实狠狠打脸。而湖仓一体，就是解决这个矛盾的答案。
本文要解决的问题：用最通俗的方式，讲清楚“湖仓一体是什么、为什么制造企业需要它、它到底解决了什么痛点”。
适合谁读：正在为数据平台架构发愁的数仓工程师、数据架构师，以及想理解技术选型逻辑的IT管理者。
脱敏声明：本文部分场景基于虚拟工厂“智联工坊”的实际业务需求提炼，所有数据均已脱敏处理。
正文
一、制造企业的数据现状：三种数据，三座大山
在智联工坊，生产制造过程中产生的数据大概可以分为三类：
| 数据类型 | 典型来源 | 格式特点 | 数据量级 |
|---|---|---|---|
| 结构化数据 | ERP订单、MES工单、设备台账 | 二维表，固定schema | TB级 |
| 半结构化数据 | 设备日志、JSON配置文件、XML工艺文件 | 有结构但字段不固定 | TB级 |
| 非结构化数据 | 监控视频、质检图片、设备音频、PDF图纸 | 无固定格式 | PB级 |
传统数仓的困境：数仓只认结构化数据。半结构化需要强行解析，非结构化直接拒之门外。
传统数据湖的困境：数据湖来者不拒，但数据质量全凭自觉——没有ACID事务，没有Schema校验，写入的数据经常“烂尾”。
这就是制造企业数据平台的“三座大山”：结构化数据管得过来，半结构化数据勉强能处理，非结构化数据直接放弃。
二、数据湖 vs 数据仓库：两个时代的两种思路
为了理解湖仓一体，得先搞清楚数据湖和数据仓库到底有什么区别。
| 维度 | 数据仓库（传统） | 数据湖（Hadoop时代） |
|---|---|---|
| 存什么 | 只存结构化数据 | 存一切数据（结构化+半结构化+非结构化） |
| 什么时候建模 | 写入前建模（Schema-on-Write） | 读取时建模（Schema-on-Read） |
| 数据质量 | 高（ETL清洗后才入库） | 低（原始数据直接入湖，质量靠下游保证） |
| 事务支持 | 支持ACID事务 | 不支持（写入时无事务保证） |
| 查询性能 | 快（经过优化和索引） | 慢（需要全量扫描或额外建表） |
| 典型场景 | 固定报表、BI分析、经营决策 | 数据探索、机器学习、日志分析 |
用一个比喻帮助理解：
-
数据仓库：像超市。商品上架前已经分类、贴标、定价，顾客（业务）来了直接拿。缺点是只能放标品。
-
数据湖：像仓库。什么东西都能往里面堆，原材料、半成品、成品混在一起。优点是啥都能放，缺点是想找东西时，得先翻一遍。
三、制造企业为什么“又想要湖，又想要仓”
回到智联工坊的场景：
场景一：设备预测性维护（上层 AI 落地案例：设备故障排查全链路 Agent）
我们需要把设备传感器数据（时序数据）和设备维修记录（结构化数据）、设备图纸（PDF）、故障音频（非结构化）放在一起分析。
-
只有数仓：图纸和音频放不进去
-
只有数据湖：没法保证维修记录和传感器数据的关联一致性
两个单独都不行。
场景二：质量追溯（延伸阅读：数据质量自动化巡检落地方案）
一批产品出了问题，需要从订单→工单→设备参数→质检图像→维修记录全链路追溯。
-
结构化数据（订单、工单）用数仓查，秒级响应
-
非结构化数据（质检图像）在数据湖里，需要全文检索
如果分两套系统，业务需要写两套查询逻辑，还要自己拼结果。
这也是痛点。
场景三：实时监控 + 历史分析
车间的设备状态需要实时监控（流式计算），同时需要做历史趋势分析（批处理）。
-
数据湖擅长批处理（历史分析）
-
数仓擅长结构化查询（实时监控的存储层）
制造企业的数据需求，天然就“既要又要”：既要数仓的规范性和性能，又要数据湖的灵活性和容量。
这就是湖仓一体出现的根本原因。
四、湖仓一体：把数仓的“规矩”和数据湖的“包容”结合起来
湖仓一体的核心思想并不复杂：用数据湖的存储底座，加上数据仓库的管理能力。
说白了就是：存数据的介质是数据湖（低成本、高容量），但上层加了一层“管理”让数据变得规范、可查、可信。
一张图帮助理解：
湖仓一体让制造企业可以：
| 需求 | 怎么实现 |
|---|---|
| 存视频/图片/日志 | 数据湖底层存储，不限格式 |
| 保证数据一致性 | ACID事务层，写入不出错 |
| 快速查询结构化数据 | 元数据管理层，建索引、分区、优化 |
| 统一查询接口 | 一套SQL引擎，查所有数据 |
| 流批一体 | 一套架构支持实时+离线 |
说白了就是：能存一切，存了不乱，查得快，用得放心。
五、智联工坊的湖仓一体实践方向
结合智联工坊的实际业务，湖仓一体架构将在以下场景落地：
| 业务场景 | 当前痛点 | 湖仓一体方案 |
|---|---|---|
| 设备预测性维护 | 传感器数据+维修记录+图纸分散在3套系统 | 统一入湖，一张表关联所有 |
| 质量追溯 | 订单→工单→质检→维修链路断裂 | 全链路数据贯通，一键追溯 |
| OEE综合分析 | 设备数据与订单数据无法关联 | 结构化+时序数据统一建模 |
| 智能质检 | 图片无法入库，只能存路径 | 图片直接入湖，与结构化数据关联 |
| 供应链协同 | 供应商数据格式各异，难整合 | 半结构化数据直接入湖，按需解析 |
六、技术选型速览
| 组件 | 选型方向 | 说明 |
|---|---|---|
| 存储底座 | HDFS / OSS | 低成本、高可靠的对象存储 |
| 表格式 | Apache Iceberg / Hudi / Delta Lake | 湖仓一体的核心：ACID + 时间旅行 + Schema演化 |
| 计算引擎 | Spark / Flink | 批处理用Spark，流处理用Flink |
| 查询引擎 | Trino / Doris | 交互式查询，低延迟 |
| 调度系统 | DolphinScheduler | 离线任务编排 |
总结：湖仓一体不是技术噱头，是制造企业的现实需要
怕你忘了，我再啰嗦一遍：制造企业的数据是混合的（结构化+半结构化+非结构化），传统的数仓装不下所有数据，传统的数据湖管不好数据质量。湖仓一体不是概念炒作，是制造企业数据平台演进的必然方向。
三个核心认知：
-
数据仓库的“规矩”和数据湖的“包容”不是对立的，而是互补的。 湖仓一体把两者的优势结合起来，让制造企业既能存一切数据，又能保证数据质量。
-
制造企业的数据痛点天然适合湖仓一体。 设备日志、传感器时序、质检图片、维修记录——数据类型的多样性，决定了单一架构无法满足所有需求。
-
湖仓一体是技术演进，不是推倒重来。 对于已有数仓的企业，湖仓一体可以看作“数仓能力的外延”——存储层升级、查询层统一、管理层增强。
智能工厂对标：本方案对应GB/T 39116-2020中“数据资源”能力域（辅域）——实现多元化数据资产的统一管理和高效利用，为智能制造的数据驱动决策奠定基础。
系列导航
互动与交流
我先抛个砖：之前服务的一家离散制造工厂，数仓用了 5 年，上了 AI 质检后图片数据存不下，最后走了湖仓一体的升级路线。你们有没有遇到过类似的架构瓶颈？评论区聊聊。
咱们一起交流——说实话，数仓架构选型这件事，没有标准答案，只有最适合的答案。
关于作者
制造业数据与AI践行者老蒋，23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战，全源码开源。
标签：#制造业数据 #数据架构 #湖仓一体 #数据仓库 #数据湖 #数据治理 #智能制造
更多推荐
11
0- 0
已为社区贡献13条内容
所有评论(0)