Pathway 部署到 GCP：基于 Google Cloud Run 的逐步部署指南（Live Data Framework 实战）

本文基于 Pathway 官方文档 GCP 部署指南 整理并扩充：讲解如何将一个部署在 GitHub 仓库中的 Pathway Live Data Framework Web 服务，通过 Google Cloud Run + Cloud Build 以容器化方式持续部署到 GCP。读完本文，你可以独立完成从创建 Google Cloud 项目、配置 Cloud Run 服务，到用 curl 验证线上接口、并通过代码推送触发自动重新部署的完整流程，同时理解 Pathway 容器化部署背后的机制（PATHWAY_SPAWN_ARGS、REST 连接器等）在源码中的对应实现。

方案定位：为什么是 Cloud Run

Google Cloud Platform（GCP）提供了一整套云端计算服务，其中 Cloud Run 是一个让你“在可扩展的基础设施上运行容器”的计算平台。Pathway 官方文档的原话是：把 Pathway 应用部署到 GCP 的难度，与部署任何一个已 Docker 化的应用没有区别——因为 Pathway Live Data Framework 应用本质上就是一个标准 Python 服务，只需 Dockerfile 即可容器化，Cloud Run 负责后续的构建、扩缩容与流量管理。

在 Pathway 的云端部署体系中，本文对应的 GCP 方案与另外几种常见云方案处于同一层级，官方在 云端部署总览 中把它们并列列出：

• Google Cloud（本文主题，基于 Cloud Run + Cloud Build 持续部署）；
• AWS：可参考同目录的 AWS Fargate 部署指南；
• Azure：可参考同目录的 Azure ACI 部署指南；
• 需要多机分布式（Kubernetes StatefulSet）规模时，则属于 Pathway Enterprise 的范畴，总览文档中说明分布式部署“假定以 stateful set 形式部署、所有 pod 都在位才能正常工作”。

本文聚焦单容器 Web 服务这一最常见场景：应用代码 + Dockerfile 放在 GitHub 仓库，Cloud Build 在每次 push 后自动构建镜像并滚动更新 Cloud Run 修订版（revision）。

前置条件

按原文档列出的要求，开始之前你需要准备：

1. 一个 Google 账号；
2. 一个 GitHub 账号；
3. 一个包含 Pathway 应用代码和 Dockerfile 的 GitHub 项目。

原文档提示：为了方便起步，可以直接 fork 官方的演示仓库（dockerized-pathway-webservice，官方在文档中给出的演示项目，本仓库内不含该仓库内容）。

注意（原文档原文）：无论你使用的是 Gmail 还是 Google Workspace 账号，都可以免费试用 Cloud Run。Google 可能要求你填写账单信息，但试用期结束后不会自动扣费。

仓库中同类云端部署示例的目录结构可以帮你理解“一个可部署的 Pathway 应用长什么样”。以 AWS Fargate 部署示例 为例，核心只有三个文件：

# examples/projects/aws-fargate-deploy/Dockerfile
FROM python:3.10

COPY ./launch.py launch.py
COPY ./requirements.txt requirements.txt

RUN pip install -r requirements.txt

CMD ["python", "launch.py"]

配合 requirements.txt 安装依赖，容器启动时执行 launch.py。GCP 的 Cloud Run 方案不要求你手写这种启动脚本（Cloud Build 直接按 Dockerfile 构建），但这种“基础 Python 镜像 + 应用代码 + 依赖”的结构，正是所有 Pathway 云端部署示例（包括 Azure ACI 示例）的共同骨架。

第一步：创建 Google Cloud 项目

1. 打开 GCP Console 的项目创建页面（console.cloud.google.com/projectcreate），填写一个易读的友好项目名称，点击 Create。

这一步之后，你的资源（Cloud Run 服务、Cloud Build 构建历史、日志、账单）都会挂在这个项目下，后续所有控制台操作都依赖顶部的“当前项目选择器”。

第二步：创建 Cloud Run 服务

项目创建完成后，进入 Cloud Run 控制台（console.cloud.google.com/run），确认左上角选中的是你刚创建的项目，然后按下述 6 个子步骤操作（对应原文档中 gcr_step_2 ~ gcr_step_7 的截图流程）：

1. 点击 Create Service（创建服务）按钮；
2. 选择 "Continuously deploy from a repository"（从仓库持续部署），然后点击 Set up with Cloud Build；
3. 指向存放你应用的 GitHub 仓库，点击 Next。

   注意（原文档原文）：Google 可能会提示你启用额外的 API，此时直接点击 Enable 并稍等片刻即可。如果尚未完成身份验证，在仓库提供方处选择 Github 并完成授权； 在弹出的输入框中粘贴你的仓库标识（官方文档示例中填写的是 https://github.com/pathway-labs/realtime-indexer-qa-chat 这类仓库地址）。

4. 构建类型选择 Dockerfile，保存更改。

   注意（原文档原文）：如果你使用的是自定义仓库，可以自行调整 Dockerfile 的路径；

5. 认证类型选择 "Allow unauthenticated invocations"（允许未认证调用）。对于对外提供数据的索引/问答类服务（如演示仓库的 {"input": "..."} 接口），这是必要的，否则外部 curl 请求会被 401 拒绝。生产环境建议改为需要 IAM 令牌或 API 密钥，并自行管理密钥分发；
6. 在容器资源（container resources）部分，把内存提高到至少 1 GiB，然后点击 Create。

内存 ≥ 1 GiB 这一点值得留意：Pathway 引擎本身是内存型流处理引擎，默认最小内存配置在 Cloud Run 上跑不满是有现实原因的。仓库中其他云部署示例也可以佐证这一量级——AWS Fargate 示例 注册任务定义时申请的是 cpu: 2048 / memory: 8192（2 vCPU、8 GiB），Azure ACI 示例 则申请 cpu=1, memory_in_gb=1.5。GCP 文档给的“至少 1 GiB”可以视为轻量 Web 服务的起步线，实际负载请按数据规模上调。

部署为什么能自动完成：容器背后的 Pathway 机制

上面的步骤只涉及控制台点击，真正让“GitHub 仓库 → 线上服务”成立的是两个机制，都可以从源码中印证：

1. Cloud Build 持续部署：选择“Continuously deploy from a repository”后，Cloud Run 由 Cloud Build 驱动，监听仓库的推送事件，构建 Dockerfile 中的镜像并生成新的 revision（见下文“部署代码变更”一节）。

2. Pathway 的容器化启动约定：从仓库源码看，Pathway 的 CLI 支持通过环境变量 PATHWAY_SPAWN_ARGS 在容器启动时自动克隆指定仓库并执行其中的流水线。见 python/pathway/cli.py：

cli_spawn_arguments = os.environ.get("PATHWAY_SPAWN_ARGS")
# ...
logging.warning("PATHWAY_SPAWN_ARGS variable is unspecified, exiting...")

仓库内各云部署示例正是按这个约定写的。例如 examples/projects/azure-aci-deploy/launch.py 中向容器注入的环境变量：

{
    # Doesn't need to be changed
    "name": "PATHWAY_SPAWN_ARGS",
    "value": "--repository-url https://github.com/pathway-labs/airbyte-to-deltalake python main.py",
}

即“容器起来后，Pathway 运行时按 PATHWAY_SPAWN_ARGS 拉取代码仓库并运行 main.py”。GCP 的 Cloud Run 流程中这一约定通常由你仓库里的 Dockerfile / 启动命令直接体现（演示仓库的入口即如此组织），理解它的意义在于：你在仓库里改了 app.py 并推送，等价于改了线上容器的行为，这是后文“提交即部署”能成立的底层原因。

另外，Pathway 应用暴露 HTTP 接口依赖其内置的 REST 连接器，实现位于 python/pathway/io/http/_server.py。从源码结构看，该模块基于 aiohttp 构建异步 Web 服务，并内置 CORS、访问日志（_LoggingContext 记录 method、route、耗时、状态码等）与自动生成的 OpenAPI 文档（_ENGINE_TO_OPENAPI_TYPE 将 Pathway 列类型映射为 OpenAPI 类型）。这意味着部署到 Cloud Run 后，你的服务天然带有 HTTP 接入层、请求日志与接口文档能力，不需要额外引入 Web 框架。

测试你的部署

部署完成后，Cloud Run 控制台会在服务名旁显示绿色标记，表示服务已就绪。此时复制服务的 URL，用 curl 验证（原文档给出的命令，<YOUR-URL> 替换为你复制到的服务地址）：

curl -X POST -d '{"input": "hello, world"}' <YOUR-URL>

该命令对应演示仓库（dockerized-pathway-webservice）的 REST 端点：POST 一个 JSON body，其中 input 字段由 REST 连接器 按端点 schema 解析为流水线输入，引擎处理后返回结果。如果你的 curl 有响应且内容符合预期，说明“GitHub 仓库 → Cloud Build 构建 → Cloud Run 容器 → REST 接口”整条链路已经打通。

部署代码变更（持续部署）

成功部署示例应用后，你就可以通过修改 app.py 调整流水线了。操作方式就是标准的 Git 工作流：

1. 本地修改 app.py（或仓库中其他文件）；
2. commit 并 push 到 GitHub；
3. Cloud Build 会自动检测到仓库变化，开始构建镜像并部署新版本；
4. 在 Cloud Run 控制台的 Revisions（修订版） 标签页下可以监控构建与滚动更新过程——每次部署产生一个新 revision，旧 revision 保留，便于排查问题时回看历史版本。

原文档结论部分也强调：借助 Google Cloud Build 的持续部署能力，应用变更可以在“数秒内”开始走部署流程（实际完成时间取决于镜像构建耗时）。

删除 Web 服务

如果这只是一个试验性的服务，随时可以清理以避免继续占用配额：

1. 回到 Cloud Run 控制台（console.cloud.google.com/run）；
2. 选中目标服务，点击 Delete 按钮。

删除服务不会删除你的 GitHub 仓库，也不会影响项目下的其他资源；再次部署只需重复本文的“创建 Cloud Run 服务”步骤。

相关方案与延伸阅读

• 同一部署目录下的兄弟文档：AWS Fargate 部署、Azure ACI 部署、云端部署总览（总览中还提到 Render 等 PaaS 工具以及 Azure Event Hubs + Pathway 的实时数据应用案例）；
• 用户指南中收录了同一篇 GCP 文档的另一份位置：docs/2.developers/4.user-guide/60.deployment/15.gcp-deploy.md；
• 仓库内可运行的云端部署示例代码：examples/projects/aws-fargate-deploy、examples/projects/azure-aci-deploy（含 launch.py、requirements.txt、Dockerfile，展示用 SDK 编程式部署 Pathway 容器的完整写法）；
• 若你的应用是模板类项目，仓库中的模板骨架（如 examples/templates/el-pipeline/app.py 中通过 pw.load_yaml 加载 app.yaml 再 pw.run 的入口组织方式）可作为编写可部署 app.py 的参照；
• 需要横向扩展到多机分布式部署时，参见 云端部署总览 中关于 Pathway Enterprise 与 Kubernetes stateful set 的说明。

小结：将 Pathway Live Data Framework 应用部署到 GCP 的全部要点是——仓库里准备好应用与 Dockerfile，在 GCP Console 创建项目，在 Cloud Run 中选择“从仓库持续部署”并指向 Dockerfile，内存设为至少 1 GiB，允许未认证调用；之后用 curl 验证接口，通过 push 代码触发自动重部署，并在 Revisions 页监控版本。整个过程与你部署任意一个 Docker 化的 Python Web 服务没有本质区别，而仓库内的 PATHWAY_SPAWN_ARGS 约定与 REST 连接器源码则解释了这套“提交即上线”体验背后的实现机制。