数据湖不只是堆盘：openEuler 在存储架构里，干了哪些“底层但关键”的事【华为根技术】

数据湖不只是堆盘：openEuler 在存储架构里，干了哪些“底层但关键”的事

一、先说句扎心的：数据湖慢，真不全是存储的锅

很多团队一聊数据湖，第一反应是：

• HDFS 慢
• 对象存储延迟高
• 小文件地狱
• 元数据压力大

于是开始：

• 换引擎
• 上缓存
• 加算力

但我这些年踩下来，越来越清楚一件事：

数据湖性能的“地基”，很大一部分其实在操作系统层。

而这，正是 openEuler 开始“显山露水”的地方。

二、openEuler 在数据湖里，到底扮演什么角色？

我们先把角色摆正。

openEuler 不是：

• 数据湖引擎
• 元数据服务
• 存储系统本身

它干的是一件听起来很“幕后”的事：

让存储、网络、CPU、IO，在“数据湖这种极端负载”下，不再互相拖后腿。

一句话总结：

数据湖是“长期、高并发、混合负载”的典型代表，而 openEuler 是为这种负载“量身调过教参”的 OS。

三、从 IO 说起：数据湖为什么特别“折磨操作系统”？

先别谈 openEuler，先看数据湖的 IO 特征：

数据湖 IO 的三个“反人类”点

1. 小文件多 + 大文件也多
2. 顺序读写 + 随机访问并存
3. 白天查询，晚上批处理

这对 OS 来说意味着什么？

• 页缓存命中率极不稳定
• IO 调度器很容易选错策略
• 一不小心就把 OLAP 拖成“抖音加载圈”

四、openEuler 的第一个杀招：IO 调度与 NUMA 的深度调优

1️⃣ IO 调度不再“一刀切”

openEuler 在企业级发行版中，非常强调 按设备 / 场景选择 IO 调度策略。

比如：

cat /sys/block/sdb/queue/scheduler

你会发现：

• 对 NVMe：更偏向 none / mq-deadline
• 对 HDD：优化 bfq 场景

在数据湖节点上，我们常见的组合是：

• 元数据盘：低延迟优先
• 数据盘：吞吐优先

openEuler 的好处在于：

默认策略已经接近“生产建议值”，而不是通用桌面策略。

2️⃣ NUMA 感知，对大规模节点太重要了

数据湖节点常见配置：

• 2 路 / 4 路 CPU
• 内存 256GB 起
• 多块 NVMe

openEuler 在 NUMA 调度上的一个优势是：

• 更激进地避免跨 NUMA 访问
• 对 IO 线程、存储进程的亲和性更友好

你在 Spark / Presto / Trino 节点上，会明显感受到：

尾延迟下降，比平均性能提升更明显。

五、文件系统层：不是“用不用”，而是“怎么用”

很多人以为：

“数据湖都用对象存储了，文件系统不重要。”

这是个非常危险的误解。

openEuler + 本地文件系统的真实作用

在数据湖架构里，本地盘通常用来：

• 缓存
• Shuffle
• 临时计算结果
• 元数据加速

openEuler 在 XFS / EXT4 的大文件 & 并发场景调优 上，积累了大量经验。

比如，针对 XFS：

mount -o noatime,nodiratime,logbufs=8 /dev/nvme0n1 /data

这些参数，在数据湖节点上非常“值钱”。

六、容器 + 数据湖：openEuler 的“隐形加分项”

现在的数据湖，早就不是“裸 Spark + 裸 HDFS”了：

• Spark on K8s
• Trino on K8s
• Flink on K8s

而 openEuler 在 容器底座 这块，做得非常克制但扎实。

1️⃣ cgroup 与 IO 隔离更稳

在混合负载集群里：

• 查询型任务
• 批处理任务
• 元数据服务

如果 IO 不隔离，结局基本只有一个：

互相拖死。

openEuler 对 cgroup v2 的支持，让你在数据湖里真正做到：

# 给 OLAP 查询更高 IO 权重
io.weight=1000

而不是“写了参数，实际没啥效果”。

2️⃣ 对 Ceph / 对象存储更友好

openEuler 在云场景里，天然就是 Ceph 的“老搭档”。

在数据湖里常见组合：

• Ceph RGW → 对象存储
• CephFS → 共享文件系统
• 本地 NVMe → 缓存 / Shuffle

openEuler 在网络栈、内存管理上的稳定性，
对 Ceph 这种“又吃 IO 又吃网络”的组件非常关键。

七、openEuler 在数据湖里的“工程型创新”

我想强调一点：

openEuler 的创新，不是“我发明了一个新概念”，
而是“我把坑提前填了”。

几个我印象很深的点：

✔ 更适合长期运行的大内存场景

• 内存碎片控制更好
• page cache 行为更可控

✔ 对异构算力更友好

• ARM + x86 混合集群
• 为国产算力适配的数据湖节点

✔ 可观测性“从 OS 层就开始”

• perf
• eBPF
• 内核级指标

你在排查数据湖性能问题时，
不会一上来就“怀疑人生”。

八、一个真实落地场景（简化版）

我们在一个 PB 级数据湖里，做过这样的调整：

• OS：openEuler
• 存储：Ceph + NVMe
• 计算：Spark / Trino

优化路径不是“换引擎”，而是：

1. openEuler IO & NUMA 调优
2. 本地缓存盘参数优化
3. 容器 IO 隔离

结果是：

• P95 查询延迟 ↓ 30%
• 高峰期抖动明显减少
• 运维告警数量直线下降

没有一个“黑科技”，但全是工程真功夫。

九、Echo_Wish 的一点个人思考

说句心里话。

这些年我们聊了太多：

• 新架构
• 新引擎
• 新格式

但越来越多的现实告诉我：

当系统规模上来之后，
决定成败的，往往是那些“你以为已经解决的问题”。

openEuler 在数据湖里的价值，恰恰就在这里：

• 不抢风头
• 不造噱头
• 但在关键时候，不掉链子

如果你现在正在做：

• 数据湖平台
• 湖仓一体
• 云原生大数据

我真心建议你一句：

别只盯着上层架构，
抽点时间，把 OS 当成“第一层架构”重新审视一遍。