ArcGIS的ModelBuilder中间结果设为临时文件：多步分析的中间数据自动清理，减少磁盘占用

一、问题的起点：一个多步模型为何会吃掉几十GB磁盘

先从一个具体场景说起。假设我们需要对某市域范围做一次"建设用地适宜性评价"，典型流程大致是：DEM填洼 → 坡度提取 → 坡向提取 → 河流缓冲区 → 道路缓冲区 → 用地类型重分类 → 多因子加权叠加 → 适宜性分级 → 统计汇总。这条链路在ModelBuilder里通常会有8到12个处理节点，每个节点都会在磁盘上落一个数据集。

如果研究区是中等规模（比如5000平方公里、30米分辨率），单个栅格数据集动辄几百MB；若是高分辨率（5米或1米）或大范围区域，单个中间栅格达到数GB并不罕见。一条十步链路跑下来，中间数据累计占用几十GB磁盘是常态。更麻烦的是，这些数据在模型跑完之后就"没用了"——它们既不是最终成果，也不会被后续人工分析引用，却实实在在躺在工作空间里。

笔者在多个GIS工程团队中观察到一个共性现象：新手建模者习惯为每个工具都手动指定输出路径，理由是"看得见、好排查"；而资深建模者则倾向于让中间结果"隐身"。这背后其实是一个关于数据生命周期管理的认知差异，而非简单的操作习惯问题。

本文评述：磁盘占用只是表象，真正的成本在于"认知负担"与"执行开销"。当工作空间里堆满几十个命名混乱的中间数据集时，模型调试、成果交付、数据备份都会变得困难。临时数据机制的价值，不仅是省磁盘，更是让模型的"输入—处理—输出"边界变得清晰。

从ESRI官方文档的表述看，地理处理框架从早期版本就引入了"托管数据"与"非托管数据"的概念区分（Esri, ArcGIS Desktop Help: Managed vs. Unmanaged Data）。托管数据由地理处理框架负责创建、管理和清理，非托管数据则由用户自行负责。中间数据机制正是"托管"理念在ModelBuilder层面的延伸。本文评述：这一设计思路与数据库领域的"临时表"、编程语言中的"局部变量作用域"高度同构，本质都是用作用域来约束资源生命周期。

二、临时数据的设计哲学：从"托管"到"非托管"的边界

2.1 地理处理框架的数据所有权模型

要理解中间数据，先要理解ArcGIS地理处理框架对"数据所有权"的划分。框架把数据分成三类：

• 输入数据（Input）：用户提供的源数据，框架只读不写，绝不删除。
• 输出数据（Output）：用户显式指定的成果数据，框架负责创建，但清理责任在用户。
• 中间数据（Intermediate）：框架在模型内部生成、仅供后续步骤消费的临时数据，框架负责创建与清理。

这个三分法看似简单，却解决了一个长期困扰工作流引擎的难题：如何在不牺牲可调试性的前提下，实现资源的自动回收。如果所有数据都由用户管理，模型会变得臃肿；如果全部自动管理，用户又无法检查中间结果。中间数据机制给出了一个折中——默认自动清理，但允许用户"显式声明保留"。

2.2 与数据库临时表、函数局部变量的类比

从计算机科学的视角看，中间数据机制与几个经典概念高度相似：

概念	所属领域	生命周期	与中间数据的对应
临时表（Temporary Table）	关系数据库	会话结束即销毁	模型运行结束即清理
局部变量（Local Variable）	编程语言	函数返回即释放	步骤完成后可被回收
中间文件（Intermediate File）	编译系统	链接完成即删除	模型执行完毕即删除
临时工作空间（Scratch Workspace）	ArcGIS	可配置的清理策略	中间数据的物理落点

笔者认为：这种跨领域的同构性并非巧合，而是"资源作用域"这一通用设计原则在不同系统中的具体表现。理解这一点，有助于我们预判中间数据机制的行为边界——比如，当模型被嵌套调用时，内层模型的中间数据作用域如何界定，就是一个值得深究的问题。

2.3 为什么"默认清理"是更合理的设计

有一种观点认为，中间数据应该默认保留，方便用户检查每一步结果。但ESRI选择了默认清理，本文评述这一选择是合理的，理由有三：

1. 可调试性有替代方案。ModelBuilder支持单步运行、添加中间数据为模型参数、使用"数据检查器"等方式，无需依赖磁盘上的中间文件。
2. 磁盘是稀缺资源。尤其在企业级地理处理服务器（ArcGIS GeoProcessing Server）场景下，磁盘I/O往往是瓶颈。
3. 符合"最小惊讶原则"。用户运行一个模型，期待的是得到最终成果，而不是一堆附带文件。

三、中间数据机制的技术解剖：标记、路径与生命周期

3.1 中间数据的判定逻辑

在ModelBuilder中，一个数据是否被判定为"中间数据"，取决于它是否满足以下条件：该数据不是模型参数（Model Parameter），且没有被任何"非中间"的消费者引用。换句话说，如果某个输出只被模型内部的后续工具使用，而不会被模型外部（如另一个模型、脚本、人工操作）引用，它就有资格成为中间数据。

ArcGIS Pro的模型构建器提供了一个直观的视觉标识：中间数据在模型图上以"虚线椭圆"或特定图标显示，与普通数据元素区分。用户也可以右键元素，勾选"Intermediate"（中间数据）属性来手动标记。

3.2 临时文件夹的定位与配置

中间数据并非"不落盘"，而是落到一个特定的临时位置。这个位置的确定遵循以下优先级：

优先级从高到低：
1. 模型环境设置中的 scratchWorkspace（临时工作空间）
2. 地理处理环境设置中的 scratchWorkspace
3. 系统默认临时目录（如 Windows 的 %TEMP%，Linux 的 /tmp）
4. ArcGIS 安装目录下的 ArcGISDefaultDB（部分版本）

在ArcGIS Pro中，可以通过"分析"选项卡 → "环境" → "工作空间" → "临时工作空间"来配置。本文评述：把临时工作空间配置到高速SSD或独立磁盘分区，是提升多步模型性能的一个低成本手段。因为中间数据的读写频率远高于最终成果，将其放在I/O性能更好的介质上，收益明显。

3.3 生命周期的三个阶段

中间数据的生命周期可以划分为三个阶段：

阶段	触发时机	系统行为
创建（Create）	上游工具执行完成	在临时工作空间生成数据集
消费（Consume）	下游工具读取该数据	数据被读取，仍驻留磁盘
清理（Cleanup）	模型运行结束或失败	框架删除临时数据集

需要特别注意的是"清理"阶段的触发条件。根据ESRI文档，中间数据的清理发生在模型运行成功完成之后，而非每个步骤完成之后。这意味着在模型运行过程中，所有中间数据会同时存在于磁盘上，峰值占用可能很高。本文评述：这是当前机制的一个局限——它实现的是"运行级"清理，而非"步骤级"清理。对于超长链路模型，峰值磁盘占用仍可能成为问题。

四、实操路径：把中间结果设为临时文件的完整步骤

4.1 方法一：依赖自动判定（推荐）

最省事的方式是让ModelBuilder自动判定。操作要点：

1. 在模型构建器中，为每个工具的输出指定一个路径（可以是临时工作空间，也可以是任意位置）。
2. 确保该输出没有被设置为模型参数（右键元素，取消勾选"Model Parameter"）。
3. 确保该输出没有被模型外部的任何工具或脚本引用。
4. 保存模型后，ModelBuilder会自动将符合条件的输出标记为中间数据（视觉上呈虚线框）。

这种方式的优点是零配置、不易出错；缺点是判定逻辑对用户是"黑盒"，当模型结构复杂时，用户可能不确定某个数据是否真的被标记为中间数据。

4.2 方法二：手动标记中间数据

当自动判定不符合预期时，可以手动干预：

1. 在模型画布上右键目标数据元素。
2. 选择"属性"（Properties）。
3. 在"常规"选项卡中，勾选或取消勾选"中间数据"（Intermediate）选项。
4. 点击确定，模型图上该元素会相应改变显示样式。

本文评述：手动标记的价值在于显式表达建模者的意图。当模型需要交付给团队其他成员时，显式标记比依赖自动判定更可靠，因为它把"这个数据是临时的"这一知识固化在了模型文件里。

4.3 方法三：通过环境变量统一控制

对于大型项目，逐个标记中间数据效率低下。可以通过设置模型级别的环境变量来统一管理：

# 在模型属性 → 环境 中设置
scratchWorkspace = "D:\GP_Scratch"   # 指向高速SSD
workspace = "E:\Project_Data"        # 项目数据目录
# 可选：设置临时数据的保留策略（部分版本支持）
# overwriteOutput = true

需要说明的是，ArcGIS不同版本对临时工作空间的支持程度有差异。ArcGIS Pro 2.x之后的环境管理更为统一，建议以Pro版本为准。

4.4 一个完整的多步模型配置示例

以"坡度—坡向—缓冲区—叠加"四步模型为例，配置要点如下：

步骤	工具	输出路径	是否中间数据
1	Slope	%scratchWorkspace%\slope_tmp	是
2	Aspect	%scratchWorkspace%\aspect_tmp	是
3	Buffer	%scratchWorkspace%\buffer_tmp	是
4	Weighted Overlay	E:\Project_Data\result	否（最终成果）

配置完成后，模型运行结束，%scratchWorkspace%下的三个临时数据集会被自动清理，只有result保留。

五、自动清理的触发条件与失效场景排查

5.1 正常触发清理的条件

中间数据被自动清理，需要同时满足：模型运行成功结束；中间数据未被锁定（无其他进程占用）；临时工作空间可写；且该数据确实被框架识别为中间数据。任何一条不满足，清理就可能失败。

5.2 常见失效场景

场景	现象	排查方向
模型运行中断	中间数据残留	手动清理临时工作空间
数据被ArcMap/Pro锁定	删除失败	关闭占用该数据的工程
中间数据被误设为模型参数	不清理	取消"Model Parameter"勾选
临时工作空间指向只读目录	创建或清理失败	改为可写目录
嵌套模型中内层数据被外层引用	不清理	检查模型依赖关系

本文评述："模型运行中断导致中间数据残留"是最常见的坑。因为清理动作绑定在"成功结束"事件上，一旦模型报错退出，临时数据就会留在磁盘上。工程实践中，建议在临时工作空间目录下建立一个定期清理脚本，或者使用ArcGIS Pro的"清理临时数据"工具手动处理。

5.3 一个实用的清理脚本

# 使用 arcpy 清理临时工作空间中的残留数据
import arcpy
import os

scratch = arcpy.env.scratchWorkspace
if scratch and os.path.exists(scratch):
    for item in os.listdir(scratch):
        full_path = os.path.join(scratch, item)
        try:
            if arcpy.Exists(full_path):
                arcpy.Delete_management(full_path)
                print(f"已删除: {item}")
        except Exception as e:
            print(f"删除失败 {item}: {e}")
else:
    print("临时工作空间未配置或不存在")

这段脚本可以放在模型运行前的预处理步骤中，也可以作为独立的维护工具定期执行。

六、性能实测：临时化前后的磁盘与耗时对比

6.1 测试设计说明

为了量化临时数据机制的效果，笔者设计了一组对照测试。需要说明的是，以下数据为模拟测试数据，基于典型硬件配置（Intel i7-12700、32GB内存、NVMe SSD、Windows 11、ArcGIS Pro 3.2）和标准测试数据集（某市30米DEM，约5000平方公里）估算得出，实际数值会因硬件、数据、版本而异。

6.2 对照测试结果

指标	全部保留中间数据	中间数据临时化	变化
峰值磁盘占用	约 18.6 GB	约 18.6 GB（运行中）	运行中相同
运行后残留占用	约 18.6 GB	约 0.4 GB	↓ 97.8%
总运行耗时	约 42 分钟	约 41 分钟	基本持平
重复运行10次累计残留	约 186 GB	约 4 GB	↓ 97.8%

本文评述：这组数据揭示了一个关键事实——临时数据机制主要优化的是"运行后残留"，而非"运行中峰值"。对于单次运行，磁盘峰值占用并不会降低；但对于需要反复调试、批量运行的场景，累计节省的磁盘空间非常可观。这也印证了前文关于"运行级清理"的判断。

6.3 为什么运行耗时基本持平

有读者可能会问：既然中间数据仍要落盘，为什么临时化不会更快？原因在于，中间数据的读写路径与普通数据相同，都是"写磁盘—读磁盘"。临时化改变的是清理策略，而非存储策略。如果要真正减少I/O，需要把中间数据放到内存工作空间（in_memory），这是下一节讨论的内容。

七、进阶策略：内存工作空间、迭代模型与嵌套模型

7.1 内存工作空间（in_memory）的协同使用

ArcGIS提供了一个特殊的工作空间in_memory，数据存放在内存而非磁盘。将中间数据写入in_memory，可以显著减少磁盘I/O。但需要注意：

• in_memory容量受物理内存限制，大数据集可能溢出。
• in_memory中的数据在ArcGIS会话结束后消失，不具备持久性。
• 部分工具不支持in_memory输出。

本文评述：in_memory与临时数据机制是互补关系，而非替代关系。理想策略是：小数据集优先走in_memory，大数据集走临时工作空间。两者结合，才能同时优化I/O和磁盘占用。

7.2 迭代模型中的临时数据

在迭代器（如For、While、Iterate Feature Classes）驱动的模型中，每一轮迭代都会产生中间数据。如果这些数据被标记为临时，框架会在整个模型运行结束后统一清理，而非每轮迭代后清理。这意味着迭代100次，可能积累100份中间数据。

应对策略：在迭代模型内部，使用"收集值"（Collect Values）工具将每轮结果汇总，或者显式地在每轮迭代后调用Delete工具清理上一轮数据。后者需要一定的脚本能力，但效果更可控。

7.3 嵌套模型中的作用域问题

当一个模型（子模型）被另一个模型（父模型）调用时，子模型的中间数据作用域如何界定？根据ESRI文档和笔者的实测，子模型的中间数据会在子模型运行结束后被清理，前提是这些数据没有被父模型引用。如果父模型需要子模型的某个输出，该输出就不能是子模型的中间数据。

这是一个容易出错的点。笔者建议：在设计嵌套模型时，明确区分"子模型对外暴露的接口"和"子模型内部使用的临时数据"，前者设为模型参数，后者设为中间数据。

八、常见坑位与工程经验清单

8.1 坑位一：临时工作空间指向网络路径

把临时工作空间配置到网络共享目录（UNC路径）会导致严重的性能问题，因为中间数据的读写会经过网络。本文评述：临时工作空间必须放在本地高速磁盘上，这是硬性要求，不是优化建议。

8.2 坑位二：临时数据与最终成果同名

如果中间数据的名称与最终成果相同，且路径也相同，可能导致覆盖或清理错误。建议为中间数据统一添加前缀（如tmp_），便于识别。

8.3 坑位三：模型参数误设为中间数据

如果一个数据既是模型参数，又被标记为中间数据，行为会变得不确定。不同ArcGIS版本的处理方式可能不同。建议：模型参数绝不标记为中间数据。

8.4 坑位四：临时数据被外部脚本引用

如果模型外部的Python脚本引用了某个中间数据的路径，该数据在模型运行结束后被清理，脚本就会报错。解决方案：要么把该数据设为模型参数，要么在脚本中改用最终成果。

8.5 工程经验清单

• ✅ 临时工作空间放在本地SSD，独立分区更佳。
• ✅ 中间数据统一命名前缀，便于识别和清理。
• ✅ 模型参数与中间数据严格区分。
• ✅ 定期清理临时工作空间，防止残留累积。
• ✅ 嵌套模型明确接口边界。
• ✅ 迭代模型注意每轮数据的清理。
• ❌ 不要把临时工作空间设在网络路径。
• ❌ 不要依赖"运行中断后自动清理"。

九、前沿预判：云原生地理处理中的临时数据管理

9.1 从本地磁盘到对象存储

随着ArcGIS Enterprise、ArcGIS Online以及各类云原生地理处理平台（如Google Earth Engine、Microsoft Planetary Computer）的普及，地理处理的执行环境正在从"本地单机"转向"云端分布式"。在这一背景下，临时数据的管理逻辑也在发生变化。

在云环境中，中间数据通常存放在对象存储（如AWS S3、Azure Blob Storage）中，而非本地磁盘。清理策略也从"模型运行结束即删除"演变为"基于生命周期规则（Lifecycle Policy）的定时清理"。本文评述：这是临时数据管理从"应用层"下沉到"基础设施层"的体现。应用不再关心清理时机，而是通过声明式的生命周期规则来管理。

9.2 容器化与无服务器计算的影响

在容器化（Docker/Kubernetes）和无服务器（Serverless）地理处理场景中，中间数据的生命周期往往与容器实例绑定。容器销毁，临时数据随之消失。这种"天然清理"机制，反而比传统的磁盘清理更彻底。

但这也带来新问题：如果容器在执行中途崩溃，临时数据可能残留在持久化卷（Persistent Volume）上。因此，云原生场景下仍需要配套的清理策略。

9.3 对ModelBuilder用户的启示

即便短期内不迁移到云端，理解云原生的临时数据管理思路也有价值。它提示我们：临时数据管理的本质是"生命周期契约"——在数据创建时，就明确它的预期存活时间。这种思维方式，可以反过来指导我们在本地ModelBuilder中更规范地设计数据流。

十、结语：把"数据卫生"当作建模的第一性原则

回到文章开头的问题：一个多步模型为何会吃掉几十GB磁盘？答案不在于某个工具的低效，而在于数据生命周期管理的缺失。中间数据机制提供的，正是一套轻量、内建、符合直觉的解决方案。

本文的核心主张可以概括为一句话：把"数据卫生"当作建模的第一性原则。就像程序员会自觉管理内存、数据库管理员会定期清理日志一样，GIS建模者也应该养成"中间数据临时化"的习惯。这不是一项高深的技术，而是一种工程素养。

最后，推荐几个延伸学习资源：

• Esri官方文档：Intermediate data in ModelBuilder（ArcGIS Pro Help）
• Esri培训视频：ModelBuilder Essentials（Esri Academy）
• 社区教程：Managing Scratch Workspace in ArcGIS Pro（Esri Community Blog）
• 视频教程：B站搜索"ArcGIS ModelBuilder 中间数据"相关实操演示