Azure Function 处理大 Parquet 文件的内存优化方案

azure function 默认消费计划内存受限，加载 570 mb parquet 文件易触发 oom（退出码 137），根本解决路径是升级至 premium 计划并合理配置内存，辅以流式读取与分块处理策略。

在 Azure Functions 中直接使用 pd.read_parquet(io.BytesIO(blob_data.readall())) 加载大型 Parquet 文件（如 570 MB）极易导致进程因内存耗尽而崩溃（Python 进程退出码 137），这是消费级（Consumption）计划固有的资源限制所致——其单实例最大内存仅约 1.5 GB（实际可用更低），且不可配置。

✅ 首选解决方案：迁移到 Premium 计划
Azure Functions Premium 计划支持手动指定实例规格（如 EP1/EP2/EP3），其中：

• EP1：3.5 GB 内存 / 1 vCPU
• EP2：7 GB 内存 / 2 vCPU
• EP3：14 GB 内存 / 4 vCPU

✅ 操作建议：将函数应用部署到 EP2 或更高规格，并在 host.json 中启用扩展性优化（如 “extensionBundle”: {“id”: “Microsoft.Azure.Functions.ExtensionBundle”, “version”: “[4.*, 5.0.0)” }），确保 PyArrow 和 Pandas 版本兼容 Parquet 列式读取。

? 辅助优化：避免一次性全量加载
即使升级计划，也推荐采用内存友好的读取方式，尤其当后续逻辑支持分批处理时：

import pyarrow.parquet as pq import io  def read_parquet_streaming(storage_account_name, container_name, blob_name):     container_client = connect_with_blob()     blob_client = container_client.get_blob_client(container_name=container_name, blob=blob_name)      # 流式下载 + 分块读取（不缓存完整字节）blob_stream = blob_client.download_blob(max_concurrency=10)     parquet_file = pq.ParquetFile(io.BytesIO(blob_stream.readall()))      # 方案 1：按 Row Group 分块读取（推荐，内存可控）dfs = []     for i in range(parquet_file.num_row_groups):         df_chunk = parquet_file.read_row_group(i).to_pandas()         # ✅ 在此处添加转换逻辑，或立即写入下游（如 Cosmos DB、Blob、Event Hub）dfs.append(df_chunk)      # 方案 2：若必须合并为单个 DataFrame（仅当内存充足时）# return pd.concat(dfs, ignore_index=True)      return pd.concat(dfs, ignore_index=True) if dfs else pd.DataFrame()

⚠️ 关键注意事项：

• ❌ 避免 blob_data.readall() 后再 BytesIO —— 此操作已在内存中复制全部原始 字节，双倍开销；
• ✅ 使用 pq.ParquetFile 直接解析，利用 Parquet 的元数据跳过无关列 / 行组；
• ⚙️ 在 function_app.py 中设置合理的超时（Premium 计划支持最长 60 分钟）：

  // function.json "configuration": {"timeout": "00:10:00"}

• ? 确保已安装兼容版本：pyarrow>=12.0.0, pandas>=2.0.0, 并在 requirements.txt 显式声明。

? 总结 ：消费计划本质不适合大文件 ETL 场景。 升级 Premium 实例是必要前提；在此基础上，结合 PyArrow 的行组级读取、延迟计算与结果流式输出（如写入临时 Blob 或触发 Durable Function 继续处理），才能构建稳定、可伸缩的数据管道。