数据中心年耗水量不超一家餐厅？从冷却架构与WUE指标看真相

如果把云厂商建数据中心这件事看成一套工程系统，最近最容易被误解的说法之一，就是“某个数据中心的年耗水量，不超过一家本地餐厅”。

Microsoft CEO Satya Nadella 在谈及威斯康星 Fairwater 数据中心时用了这个对比。它听起来很直观，但落到数据中心从业者眼里，这句话其实把一个涉及冷却方式、气候条件、计量口径和运维监控的复杂问题，压缩成了一个日常类比。本文不打算评价这项表态的公关效果，而是想从技术侧拆开看：数据中心的水耗从哪里来？什么样的冷却设计可以做到低耗水？所谓“一年用水量不比一家餐厅多”应该如何量化、如何验证，以及作为技术人员，我们该怎么设计和监控这样一套系统。

1. 事件背景：一句话背后的数据中心命题

1.1 威斯康星 Fairwater 数据中心与那个类比

Microsoft 在威斯康星布局的数据中心项目被称为 Fairwater。根据公开信息，该项目在推进过程中，当地社区关注的焦点之一，是数据中心可能会消耗大量水资源。于是便有了“Fairwater 数据中心年耗水量不高于一家本地餐厅”的说法。

这句类比天然带有传播属性，因为它用“餐厅”这个日常对象替代了抽象的数字。对大多数普通人来说，“百万加仑”或“几万立方米”都很难形成感知，但“比一家餐厅还少”立刻有了画面感。

不过，要判断这句话是否成立，我们得先搞清楚两个问题：

• 这家“本地餐厅”一年到底用多少水？
• 这座数据中心的用水边界里，包不包括冷却塔补水和加湿用水？

如果数据中心采用的是完全没有蒸发式散热环节的冷却系统，那它的直接水耗确实可能低到“接近一座普通办公楼”，而不是数据中心的传统印象。

1.2 为什么数据中心的水耗会引起关注

传统数据中心在很多人印象里是“电老虎”，因为服务器、网络设备、UPS、空调都需要用电。但过去十年里，越来越多的注意力开始转向水。

原因很直接：数据中心产生的热量巨大，而很多大型机房的散热依赖冷却塔或蒸发冷却。这个过程需要消耗大量水。尤其在美国西部、中东、新加坡等水资源紧张的地区，数据中心的新建项目经常要面对“与居民抢水”的舆论压力。

从行业数据看，一个采用湿式冷却塔的大型数据中心，每年的补水量不是一个小数字。即便在相对湿润的地区，水费、水质处理、排污和环保合规也会成为运维成本的一部分。

因此，威斯康星 Fairwater 的说法之所以有新闻价值，是因为它指向了一种正在兴起的行业趋势：新建数据中心在设计阶段就开始做“减法”，减少甚至取消蒸发冷却环节，只用空气完成大部分散热。

1.3 技术人员可以从这条新闻里学到什么

对开发、运维和基础设施工程师而言，我们不能只记住新闻标题里的传播话术。值得深挖的是三件事：

1. 水耗如何产生，又如何在冷却系统内部流转。
2. 用什么指标评估“数据中心不耗水”。
3. 在真实机房环境中，如何部署水表、电表、温度和湿度传感器，把“不耗水”落到数据上。

所以，本文后面会从原理讲到代码示例。我们会搭建一个餐厅用水量模型，也会给出数据中心直接用水量的计算脚本，再用 SQL 和 Python 演示一套简化的水效监控系统。这样，下次看到“年耗水量相当于一家餐厅”的说法时，你至少知道从哪个口径去拆解它。

2. 数据中心为什么耗水：先建立技术框架

2.1 热量从哪来

数据中心内部的热量来源主要有两类：

• IT 设备：服务器 CPU、GPU、内存、硬盘、网卡在工作时几乎把输入电能全部转换为热能。
• 基础设施设备：UPS、配电柜、空调内机、照明等自身也会产生热负荷，但相比 IT 设备是次要部分。

一台 500W 的服务器满载运行，每小时就会向机房排出接近 500Wh 的热量。一个大型数据中心动辄有数万甚至数十万台服务器，总热负荷非常可观。无论使用什么冷却方式，本质都是“把机房里的热量搬出去”。

2.2 冷却是用水核心

机房冷却系统有不同类型，用水量差异极大。

以最常见的冷冻水系统为例，机房内空气经过 CRAH 或 AHU 时，被冷冻水盘管降温。冷冻水本身在冷水机组里循环，冷水机组把热量给到冷却水系统，冷却水再把热量通过冷却塔排放到室外。

关键点在于冷却塔。

冷却塔通常使用“湿式散热”：热水经过填料时与空气接触，一部分水蒸发吸热，从而把热量带走。蒸发过程不会损耗“水量”本身吗？当然会。蒸发掉的那部分水需要不断补充，再加上风吹损失和排污，耗水量就随之产生。

在一个中型数据中心里，冷却塔补水量可能占到整个园区直接用水量的 80% 以上。所以，只要冷却系统没有“湿表面”，数据中心的耗水量就会明显下降。

2.3 PUE 与 WUE：衡量效率的两把尺子

数据中心行业常用 PUE 评价能效。

PUE = 数据中心总用电量 / IT 设备用电量

理想情况下，PUE 接近 1，说明所有电几乎全部输送给 IT 设备，基础设施自身消耗很小。

但 PUE 没有包含水。于是人们又引入 WUE，即 Water Usage Effectiveness。

WUE = 数据中心总用水量 / IT 设备用电量

常见单位是 L/kWh，意思是每消耗 1kWh 的 IT 电能，需要耗多少升水。注意，不同企业的统计口径可能不同。有的 WUE 只统计冷却水，有的会统计全园区生活用水，有的还会把发电过程的水耗折算进去。

因此，看 WUE 时不能只盯数值，先要确认分母是 IT 用电还是总用电，分子是“现场用水”还是“全生命周期用水”。

3. 从高耗水到低耗水：冷却技术演进与原理

3.1 传统冷冻水系统的用水逻辑

早期的中大型数据中心普遍采用冷冻水系统，标准的散热链路是：

IT 设备 → 机房空气 → 冷冻水盘管 → 冷水机组 → 冷却水循环 → 冷却塔 → 室外大气

冷却塔里的水不断喷淋到填料上，风机把室外空气抽过填料，让水流表面的水分子蒸发。水蒸发会吸收汽化潜热，于是循环水的温度就降了下来。

冷却塔的问题在于：蒸发要消耗大量水，而且水蒸发后钙镁离子浓度升高，需要排污并补充新水。为了保持水质，还需要投放阻垢剂、杀菌剂等化学药剂。

这种架构在电力便宜、水资源充足的地区很成熟，但在缺水地区会受到严格限制。

3.2 蒸发冷却与间接蒸发冷却

除了开式冷却塔，很多数据中心还会采用“蒸发冷却”或“绝热冷却”。

直接蒸发冷却的原理比较简单：让室外热空气经过湿膜或喷淋水雾，水分蒸发会降低空气温度。不过，直接把加湿后的空气送进机房，会带来湿度控制问题。

间接蒸发冷却则把室内空气和室外空气隔离：室外空气先经过湿表面蒸发降温，室内回风再通过换热器把热量传递给室外侧冷空气。这样既利用了蒸发的降温能力，又避免湿空气直接进入机房。

间接蒸发冷却确实能降低能耗，但它并不是完全零水耗。只要系统里还有“湿膜”或“喷淋”，就需要补水。只有把蒸发环节完全关闭，或设计成“干模式优先”时，水耗才可能趋近于零。

3.3 全空气干冷却：不靠水也能降温

所谓“不靠水的冷却”，通常依赖的是空气侧经济器，也就是 Free Cooling：

• 当室外温度足够低时，把经过过滤的室外冷空气直接送进机房。
• 如果担心空气质量或湿度波动，可以使用间接空气侧换热器。
• 当室外温度偏高时，再启动机械制冷盘管作为补充。

冷却是为了维持机柜进风温度在合理范围内。现代 IT 设备的允许进风温度范围已经比过去宽松很多，只要送风温度不超过 27°C 甚至 32°C，大多数服务器都能正常运行。

因此，在威斯康星这种冬季漫长、夏季相对温和的气候区域，设计一个“以空气冷却为主、机械制冷为辅”的园区，完全有机会把冷却塔从系统中移除。没有冷却塔，也就没有每年成千上万立方米的水耗。

3.4 Fairwater 场景下的气候条件与设计判断

威斯康星属于明显的大陆性湿润气候，冬季寒冷，冷空气时间长，这正好是风侧经济器和干式冷却最喜欢的条件。

如果 Fairwater 数据中心选择的是“干冷却”路线，那它的耗水来源会大大缩减，主要只剩下：

• 办公区卫生间用水；
• 厨房或保洁用水；
• 消防系统测试后的补水和排水；
• 极少数特殊场景下的加湿用水。

其中员工生活用水和运维频次密切相关，但和机房规模关系不大。也就是说，一个大机房如果采用零蒸发冷却设计，用水量可能更接近同人数规模的普通办公楼，而不像传统数据中心。

当然，Microsoft 并不会在新闻稿中把所有技术细节公开，我们只能从公开说法和行业趋势推断。技术上的关键点是：低水耗数据中心并非靠某一个“神奇设备”实现，而是从系统架构上取消/替代了大量需要水的散热环节。

4. 量化“年耗水不高于一家本地餐厅”

4.1 先把估算模型说清楚

为了验证那个类比，我们建立两个估算模型：

1. 本地餐厅年用水量。
2. 一座“无蒸发冷却”数据中心的基础设施直接用水量。

估算需要设定合理参数，但参数并不是官方数据。这里的目标是演示思路：只要边界清楚，任何人都能用脚本或 Excel 算一遍。

餐厅用水量主要来自：

• 顾客用餐区冲洗、洗手；
• 后厨清洗、洗碗机；
• 食品加工和烹饪；
• 卫生间。

数据中心直接用水量主要来自：

• 员工办公生活用水；
• 保洁和景观用水；
• 消防测试/空调加湿等杂项。

我们先用 Python 写出餐厅模型。下面的代码刻意简化成可读形式，方便你自己修改参数。

4.2 使用 Python 估算餐厅用水量

# restaurant_water_model.py # 假设条件：一家中等规模本地餐厅 # 日均顾客数：150 人 # 人均综合用水量：25 升/人/天（含后厨清洗、洗手、冲厕等） # 后厨设备清洁与食材加工：每天额外 500 升 # 洗碗机/消毒等：每天额外 300 升 # 营业天数：365 天 daily_customers = 150 customer_water_per_person_liter = 25 kitchen_base_liter = 500 dishwasher_liter = 300 days_per_year = 365 daily_customer_liter = daily_customers * customer_water_per_person_liter daily_total_liter = daily_customer_liter + kitchen_base_liter + dishwasher_liter yearly_total_liter = daily_total_liter * days_per_year print("= 本地餐厅年用水估算 =") print(f"日均顾客用水: {daily_customer_liter} L") print(f"日总用水量: {daily_total_liter} L") print(f"年总用水量: {yearly_total_liter} L") print(f"年总用水量: {yearly_total_liter / 1000:.2f} m3")

运行这段脚本，会得到一个类似下面的输出：

= 本地餐厅年用水估算 = 日均顾客用水: 3750 L 日总用水量: 4550 L 年总用水量: 1660750 L 年总用水量: 1660.75 m3

在真实场景中，餐厅规模、洗碗方式、是否使用一次性餐具，都会显著影响结果。这里取 1660 m³ 左右，只是为了把后续数据中心的“可比较量级”讲清楚。

4.3 数据中心用水量计算：从仪表读数到年度汇总

现在我们计算一座低水耗数据中心园区的直接耗水量。假设园区没有冷却塔、没有湿膜蒸发冷却，只在以下环节用水：

• 常驻运维人员 30 人；
• 倒班人员平均每天在园区人数 60 人；
• 每人每天办公及生活用水 25 L；
• 保洁/清洗/消防测试一年 60 m³；
• 加湿系统极少量使用，一年 20 m³。

# data_center_water_model.py # 办公与员工生活用水 onsite_daily_headcount = 60 amenity_water_per_person_day = 25 # L # 杂项用水 cleaning_testing_yearly_m3 = 60 humidification_yearly_m3 = 20 # 算年生活用水量 daily_life_liter = onsite_daily_headcount * amenity_water_per_person_day yearly_life_liter = daily_life_liter * 365 # 统一换算成立方米 yearly_life_m3 = yearly_life_liter / 1000 yearly_total_m3 = yearly_life_m3 + cleaning_testing_yearly_m3 + humidification_yearly_m3 print("= 低水耗数据中心年度直接用水估算 =") print(f"日常人员生活用水: {yearly_life_m3:.2f} m3") print(f"保洁/消防测试等杂项: {cleaning_testing_yearly_m3} m3") print(f"加湿系统杂项: {humidification_yearly_m3} m3") print(f"年总用水量: {yearly_total_m3:.2f} m3")

运行结果：

= 低水耗数据中心年度直接用水估算 = 日常人员生活用水: 547.50 m3 保洁/消防测试等杂项: 60 m3 加湿系统杂项: 20 m3 年总用水量: 627.50 m3

在这个模型下，数据中心年用水约 627 m³，确实比前面模型里 1660 m³ 的本地餐厅要低。

但如果把常驻人数提高到 300 人一天，同时再加 100 m³ 的冷却系统定期冲洗，年用水量就可能超过 2000 m³。换句话说，决定这句话是否成立的关键，不只是机柜数量，而是团队规模和冷却系统有没有“湿表面”。

4.4 定量对比与局限性

可以把两组数字放到一起看：

这个对比只能说“量级合理”。它不能证明官方数据一定准确，因为真实数据需要结合水表读数、员工排班表、冷却系统类型和园区面积。

更重要的是，上述模型里的数据中心不包含冷却塔补水和化学清洗。如果数据中心采用的是间接蒸发冷却加湿模式，即便有几十台间接蒸发空调，单台设备每年补水量也可能达到数十立方米，全年加起来还是可能把总用水量推高到餐厅水平之上。

所以，新闻稿里的“一家本地餐厅”，本质上是一个传播类比。严谨的工程表达应当给出年份、统计边界、水表数量，以及外部温度和湿度条件下的用水波动范围。

5. 数据中心水耗监控：从“喊口号”到“可运维”

5.1 衡量指标与数据采集

要验证一个园区是否真的低水耗，最终离不开计量工具。在运维侧，至少需要采集以下数据：

• 市电总进线和 IT 负载用电量，用来计算 PUE。
• 每个冷却系统区域的水表读数，例如冷却塔补水、加湿器进水、AHU排水。
• 办公区生活用水水表。
• 室外温湿度、室内送风温度、回风温度。
• 冷却水循环流量、补水泵运行状态。

如果条件允许，应把水表读数接入到监控平台，按小时或按天采集，而不只是月底抄一次表。没有实时数据，就没有办法定位“哪一天补水异常”。

5.2 水系统监测表设计（SQL 示例）

下面是一个简化到标准项目可落地的 SQL 表设计。通常至少包含三张表：水表基础信息表、水表日用量表、IT 用电量表。

-- 水表基础表 CREATE TABLE water_meter ( meter_id INT PRIMARY KEY, meter_name VARCHAR(64) NOT NULL COMMENT '水表标识', location VARCHAR(128) NOT NULL COMMENT '安装区域', meter_type VARCHAR(32) NOT NULL COMMENT '冷却塔/加湿/生活水/消防', unit VARCHAR(16) DEFAULT 'm3' COMMENT '计量单位' ); -- 水表日用量表 CREATE TABLE water_daily_reading ( reading_date DATE NOT NULL, meter_id INT NOT NULL, daily_usage_m3 DECIMAL(12,4) NOT NULL, reading_time TIMESTAMP NOT NULL, PRIMARY KEY (reading_date, meter_id) ); -- IT 用电量表 CREATE TABLE it_daily_energy ( stat_date DATE PRIMARY KEY, it_energy_kwh DECIMAL(16,2) NOT NULL, facility_energy_kwh DECIMAL(16,2) NOT NULL );

这个模型把“水表”和“电能”分成两张表维护，后续做 WUE 计算时，只需要按日期 JOIN。

5.3 使用 Python 计算月度 WUE

监控系统把数据存到数据库后，我们可以用 Python 完成 WUE 计算。以下是核心计算片段，重点不是代码技巧，而是指标口径。

# wue_daily_calc.py from datetime import datetime # 示例数据：直接按字典模拟，实际项目可读取数据库 daily_usage_m3 = { "2025-01-01": 1.2, "2025-01-02": 1.1, } it_energy_kwh = { "2025-01-01": 30000, "2025-01-02": 31000, } total_water_m3 = sum(daily_usage_m3.values()) total_it_energy_kwh = sum(it_energy_kwh.values()) # WUE 单位：L/kWh # 1 m3 = 1000 L wue = (total_water_m3 * 1000) / total_it_energy_kwh print(f"统计周期总用水量: {total_water_m3:.2f} m3") print(f"统计周期 IT 用电量: {total_it_energy_kwh:.2f} kWh") print(f"WUE: {wue:.4f} L/kWh")

假设一个统计周期内，园区用水总量是 2.3 m³，IT 用电量是 61000 kWh，那么 WUE 大约是 0.0377 L/kWh。

作为对比，传统湿式冷却塔数据中心的 WUE 通常在 1.0 L/kWh 左右甚至更高。两者差了一个数量级，这就是低水耗冷却架构带来的差异。

5.4 运维侧的低水耗落地思路

如果园区本身没有冷却塔，日常运维重点会从“补水管理”转向“泄漏管理”。比如：

• 关注卫生间和食堂的用水，存在长流水时要及时发现。
• 消防管道每年试水/检修后是否有未排水或泄漏损失。
• 空调加湿系统如果存在，需要关注软化水设备和蒸汽排放量。
• 保洁用水尽量采用低流量清洁设备。
• 室外绿化使用滴灌或回收雨水。

真正降低年耗水的决定，往往在施工图设计阶段已经完成。运营阶段的努力更多是防止“意外用水”。

6. 关于“数据中心低水耗”的常见疑问

很多技术人员第一次接触“不耗水数据中心”时，会有一连串疑问。下面用表格整理几个高频问题。

真实数据中心项目很少只用一种冷却模式，很多园区会采用“风冷优先 + 机械制冷补充”的组合方式。这种设计在春秋季大量使用室外空气，在炎热时段切换到机械制冷，从而在全年平均 PUE 和 WUE 之间取平衡。

7. 可持续数据中心建设的最佳实践

7.1 设计阶段先选冷却架构

如果你的团队正在规划新数据中心，不要一开始就默认采用“冷冻水 + 冷却塔”方案。先回答几个问题：

• 项目所在地每年有多少小时室外温度低于 25°C？
• 当地水源是否紧张？水费单价是多少？
• 当地最高湿球温度和干球温度是多少？
• 机柜功率密度是 5kW/rack 还是 30kW/rack？
• 后期是否考虑液冷服务器？

对于功率密度较低的普通业务机房，空气侧经济器和间接蒸发冷却是成熟方案。对于高密度 AI 训练集群，则可能需要冷板液冷，再配合冷却塔或干冷器。

7.2 运营阶段形成指标闭环

一旦机房上线，工程团队应建立一套可持续指标看板：

• 每台冷却子系统的水表读数。
• 每天、每周、每月 WUE。
• PUE 和 WUE 的联动曲线。
• 漏水告警事件记录。
• 冷却系统启停模式与室外湿球温度关系。

不能只在“世界水日”或媒体采访时才看水表数据。数据中心的可靠性和可持续性都来自持续监控。

指标闭环的价值在于：当某一天 WUE 突然升高，工程师可以快速定位到具体水表，再结合系统运行日志判断是否泄漏、排污阀卡在开启状态或冷却塔风机异常。

7.3 对外沟通时注意量化口径

回到本文开头那句话，如果将来你有机会代表公司发布类似结论，请至少补充以下信息：

• “年度”对应的具体年份。
• 是否只统计现场直接用水。
• 是否包含冷却塔补水和间接蒸发冷却用水。
• 员工生活用水是否计入。
• 餐厅对比模型的用水依据。

技术人员的严谨，应该体现在“能解释每一个数字的来源”。相比一句让人印象深刻但无法验证的类比，透明的量化口径更能帮助数据中心与社区建立长期信任。

8. 下一步可以怎么学

这篇文章本质上是从一条新闻切入，讲了一个完整的工程场景：数据中心热量从哪里来、冷却系统为什么耗水、低水耗设计如何实现、如何用技术和数据验证“不耗水”的说法。

如果你希望进一步深入，可以从几个方向继续：

• 学习数据中心基础设施规范中的温湿度范围，理解服务器对环境的容忍度。
• 研究机房暖通系统图，尤其是 CRAH、AHU、冷却塔、冷水机组之间的连接关系。
• 自己搭建一个简化版数据采集平台：用 SQLite 存水表数据，用 Python 绘制 WUE 曲线。
• 对比不同类型冷却塔的补水量计算公式，理解蒸发损失、风吹损失和排污量差异。

回到文章开头那个类比，真正重要的是：当别人给你一个“数据中心耗水量相当于一家餐厅”的结论时，你知道需要反问一句——“统计口径是什么？冷却系统有没有蒸发环节？”

这么问，比记住一个换算系数有用得多。