Data Engineering ZoomcampBigQuery ML 模型导出与 TensorFlow Serving 容器化部署实战指南【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp导读本指南基于 Data Engineering Zoomcamp 第 3 周「数据仓库」模块的进阶内容见 03-data-warehouse/extract_model.md 与配套视频「Deploying Machine Learning model from BigQuery」完整讲解如何将 BigQuery 中训练好的机器学习模型tip_model导出到 Cloud Storage再通过gsutil拉取到本地最终借助 TensorFlow Serving 镜像以 Docker 容器方式对外提供 REST 预测服务。读完本文你将掌握「SQL 训练模型 → 导出 → 容器化部署 → HTTP 在线推理」的端到端实战链路能够把 BigQuery ML 训练的模型无缝迁移到自有基础设施上运行。一、背景为什么要把模型从 BigQuery 中搬出来在 05-machine-learning-in-bigquery 中我们已经用纯 SQL 在 BigQuery 内完成了模型的全生命周期准备特征表yellow_tripdata_ml、训练线性回归模型tip_model、用ML.EVALUATE评估、用ML.PREDICT预测、用ML.EXPLAIN_PREDICT解释甚至用hparam_range做了超参调优。全部语句都沉淀在 big_query_ml.sql 中。然而 BigQuery ML 的优势数据不离仓、SQL 建模也带来了一个限制模型只能通过 BigQuery 的 SQL 接口来调用。当你需要把模型集成到自己的业务系统、以低延迟服务外部请求时就需要把模型「搬出去」。这正是本主题的价值把 BigQuery 中训练的模型导出为标准 TensorFlow SavedModel 格式再通过 TensorFlow Serving 在 Docker 容器中部署让模型变成一个可通过 HTTP 调用的独立服务。本指南的操作步骤遵循 Google 官方的 BigQuery ML 模型导出教程export-model-tutorial。二、前置条件与整体流程开始前需要准备一个已完成gcloud auth login认证的 Google Cloud 环境本模块视频演示中已登录拥有taxi-rides-ny项目和nytaxi数据集访问权限已按 05-machine-learning-in-bigquery 训练好tip_model模型本地安装 Docker可拉取tensorflow/serving镜像。整体流程分为五个阶段导出用bq命令将 BigQuery 模型导出到 Cloud Storage 存储桶拉取用gsutil把模型从存储桶复制到本地目录编排按 TensorFlow Serving 要求的目录结构模型名/版本号摆放模型文件启动用 Docker 运行tensorflow/serving镜像并挂载模型目录调用通过 REST API 查询模型元信息并发送预测请求。三、第一步用 bq 命令导出模型到 Cloud Storage登录认证完成后使用 BigQuery 命令行工具bq将模型导出到云存储桶bq --project_id taxi-rides-ny extract -m nytaxi.tip_model gs://taxi_ml_model/tip_model命令要点参数含义--project_id taxi-rides-ny指定模型所在的项目 IDGCP 项目级资源与 BigQuery 数据集taxi-rides-ny.nytaxi对应extract -m表示执行的是模型model导出而非表table导出-m是--model的缩写nytaxi.tip_model模型在数据集nytaxi下的名称即taxi-rides-ny.nytaxi.tip_modelgs://taxi_ml_model/tip_model目标 Cloud Storage 存储桶路径模型将以tip_model文件夹的形式出现在taxi_ml_model桶中导出完成后打开 Cloud Storage 控制台的taxi_ml_model存储桶即可在 OBJECTS 标签页看到名为tip_model/的文件夹——这就是 BigQuery ML 导出模型的落盘形态。四、第二步用 gsutil 将模型复制到本地模型文件现在在云端存储桶里接下来把它复制到本地机器mkdir /tmp/model gsutil cp -r gs://taxi_ml_model/tip_model /tmp/modelgsutil cp -r会递归复制整个tip_model目录。复制完成后/tmp/model目录下就是导出的模型文件。从复制输出可以看到BigQuery ML 导出的模型本质是一个TensorFlow SavedModel包含assets、variables以及若干元数据文件如saved_model.pb。variables目录存放训练得到的权重saved_model.pb是计算图定义assets存放模型运行所需的附加资源——这正是它能被 TensorFlow Serving 直接加载的原因。五、第三步搭建 TensorFlow Serving 要求的目录结构TensorFlow Serving 对模型目录布局有严格约定顶层是模型名目录其下每个子目录对应一个整数版本号如1、2Serving 通过版本号管理模型的加载与热更新。因此执行mkdir -p serving_dir/tip_model/1 cp -r /tmp/model/tip_model/* serving_dir/tip_model/1第一行创建serving_dir/tip_model/1serving_dir是服务目录可放在项目目录或任意临时目录tip_model是模型名1是版本号第二行将/tmp/model/tip_model/下所有文件复制进版本目录1中。最终目录结构为serving_dir/ └── tip_model/ └── 1/ ├── saved_model.pb ├── assets/ └── variables/六、第四步拉取镜像并启动 TensorFlow Serving 容器先拉取官方 Serving 镜像再运行容器docker pull tensorflow/servingdocker run -p 8501:8501 \ --mount typebind,sourcepwd/serving_dir/tip_model,target/models/tip_model \ -e MODEL_NAMEtip_model -t tensorflow/serving 启动参数逐项拆解参数作用-p 8501:8501将容器内 8501 端口映射到宿主机 8501 端口REST API 由此端口对外提供服务--mount typebind,source\pwd/serving_dir/tip_model,target/models/tip_model| 将宿主机上的服务目录绑定挂载到容器内/models/tip_model/models 是 TensorFlow Serving 默认的模型根目录-e MODEL_NAMEtip_model通过环境变量告诉 Serving 要加载哪个模型对应挂载目录名-t分配伪终端便于在后台运行并查看日志让容器在后台运行注意source使用反引号包裹的pwd是为了动态获取当前工作目录的绝对路径避免相对路径导致的挂载失败。启动成功后可用docker ps确认tensorflow/serving容器处于运行状态。关于 Serving 端口的小知识TensorFlow Serving 通常暴露两个端口8500 用于 gRPC8501 用于 REST/HTTP。本教程使用 8501 端口配合curl即可完成预测调用无需额外安装客户端库。七、第五步检查模型元信息TensorFlow Serving 内置 REST API 端点GET http://localhost:8501/v1/models/{MODEL_NAME}用于查询模型状态。浏览器或 Postman 访问http://localhost:8501/v1/models/tip_model响应会返回 JSON其中model_version_status字段显示版本1的状态为AVAILABLE、错误码为空——表示模型已成功加载、可以接受预测请求。该端点也是排查「模型未加载 / 目录结构错误 / 版本不可用」等问题的第一站。八、第六步发送预测请求预测端点格式为POST http://localhost:8501/v1/models/{MODEL_NAME}:predict请求体使用 TensorFlow Serving 的标准 JSON 结构instances数组中的每个元素是一行特征。向tip_model发起预测curl -d {instances: [{passenger_count:1, trip_distance:12.2, PULocationID:193, DOLocationID:264, payment_type:1,fare_amount:20.4,tolls_amount:0.0}]} \ -X POST http://localhost:8501/v1/models/tip_model:predict请求特征与 big_query_ml.sql 中训练模型时的列一一对应字段值说明passenger_count1乘客数数值特征trip_distance12.2行程距离数值特征PULocationID193上车地点 ID字符串/类别特征DOLocationID264下车地点 ID字符串/类别特征payment_type1支付方式字符串/类别特征fare_amount20.4车费数值特征tolls_amount0.0过路费数值特征对应这条行程模型预测出约3.2 美元的小费如果将payment_type改为2现金支付再次请求预测小费金额会大幅下降到约0.26 美元——这与训练数据中「现金支付几乎不给小费」的规律一致也验证了模型确实学到了支付方式这一关键特征的影响。九、要点回顾训练与部署的完整闭环至此整个闭环已经打通在 BigQuery 中用 SQL 训练线性回归模型tip_model见 big_query_ml.sql模型创建语句CREATE OR REPLACE MODEL ... model_typelinear_reg用bq extract -m将模型导出到 Cloud Storage用gsutil cp拉取到本地按「模型名/版本号」目录结构组织文件用docker run启动tensorflow/serving容器并提供 REST 服务通过curl/Postman 调用:predict端点完成在线推理。本方案的工程价值在于训练阶段充分利用 BigQuery 的「数据不离仓 SQL 建模」便捷性部署阶段则将模型标准化为 TensorFlow SavedModel交给 TensorFlow Serving 这一通用推理框架托管——两者通过标准的模型导出/加载协议衔接模型可以随时脱离 BigQuery 生态部署在任何能跑 Docker 的环境中。十、延伸部署到生产环境的注意事项以下要点基于本仓库实战流程推断供生产化落地时参考存储桶权限bq extract要求运行账号对目标存储桶有写入权限建议使用专用服务账号并遵循最小权限原则版本管理与热更新TensorFlow Serving 按目录下的整数版本号识别模型放置新的版本目录如2后Serving 会自动加载新版本并支持平滑切换便于模型迭代容器资源预测服务对内存与 CPU 有要求生产环境建议结合容器编排如 Kubernetes设置资源限制与副本数输入校验REST API 只做基础校验生产环境建议在服务前置一层输入校验与特征转换保证请求特征与训练时完全一致包括类型本模型的类别特征需以字符串形式传入。相关资源05-machine-learning-in-bigquery模型训练、评估、解释与超参调优的完整 SQL 教程是本文的建模前置环节big_query_ml.sql上述教程对应的全部可执行 SQL 语句03-data-warehouse/README.md第 3 周模块总览包含本主题视频入口与 BigQuery ML 参考资料链接官方 BigQuery ML 模型导出教程export-model-tutorial本文步骤的权威出处【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Data Engineering Zoomcamp：BigQuery ML 模型导出与 TensorFlow Serving 容器化部署实战指南
Data Engineering ZoomcampBigQuery ML 模型导出与 TensorFlow Serving 容器化部署实战指南【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp导读本指南基于 Data Engineering Zoomcamp 第 3 周「数据仓库」模块的进阶内容见 03-data-warehouse/extract_model.md 与配套视频「Deploying Machine Learning model from BigQuery」完整讲解如何将 BigQuery 中训练好的机器学习模型tip_model导出到 Cloud Storage再通过gsutil拉取到本地最终借助 TensorFlow Serving 镜像以 Docker 容器方式对外提供 REST 预测服务。读完本文你将掌握「SQL 训练模型 → 导出 → 容器化部署 → HTTP 在线推理」的端到端实战链路能够把 BigQuery ML 训练的模型无缝迁移到自有基础设施上运行。一、背景为什么要把模型从 BigQuery 中搬出来在 05-machine-learning-in-bigquery 中我们已经用纯 SQL 在 BigQuery 内完成了模型的全生命周期准备特征表yellow_tripdata_ml、训练线性回归模型tip_model、用ML.EVALUATE评估、用ML.PREDICT预测、用ML.EXPLAIN_PREDICT解释甚至用hparam_range做了超参调优。全部语句都沉淀在 big_query_ml.sql 中。然而 BigQuery ML 的优势数据不离仓、SQL 建模也带来了一个限制模型只能通过 BigQuery 的 SQL 接口来调用。当你需要把模型集成到自己的业务系统、以低延迟服务外部请求时就需要把模型「搬出去」。这正是本主题的价值把 BigQuery 中训练的模型导出为标准 TensorFlow SavedModel 格式再通过 TensorFlow Serving 在 Docker 容器中部署让模型变成一个可通过 HTTP 调用的独立服务。本指南的操作步骤遵循 Google 官方的 BigQuery ML 模型导出教程export-model-tutorial。二、前置条件与整体流程开始前需要准备一个已完成gcloud auth login认证的 Google Cloud 环境本模块视频演示中已登录拥有taxi-rides-ny项目和nytaxi数据集访问权限已按 05-machine-learning-in-bigquery 训练好tip_model模型本地安装 Docker可拉取tensorflow/serving镜像。整体流程分为五个阶段导出用bq命令将 BigQuery 模型导出到 Cloud Storage 存储桶拉取用gsutil把模型从存储桶复制到本地目录编排按 TensorFlow Serving 要求的目录结构模型名/版本号摆放模型文件启动用 Docker 运行tensorflow/serving镜像并挂载模型目录调用通过 REST API 查询模型元信息并发送预测请求。三、第一步用 bq 命令导出模型到 Cloud Storage登录认证完成后使用 BigQuery 命令行工具bq将模型导出到云存储桶bq --project_id taxi-rides-ny extract -m nytaxi.tip_model gs://taxi_ml_model/tip_model命令要点参数含义--project_id taxi-rides-ny指定模型所在的项目 IDGCP 项目级资源与 BigQuery 数据集taxi-rides-ny.nytaxi对应extract -m表示执行的是模型model导出而非表table导出-m是--model的缩写nytaxi.tip_model模型在数据集nytaxi下的名称即taxi-rides-ny.nytaxi.tip_modelgs://taxi_ml_model/tip_model目标 Cloud Storage 存储桶路径模型将以tip_model文件夹的形式出现在taxi_ml_model桶中导出完成后打开 Cloud Storage 控制台的taxi_ml_model存储桶即可在 OBJECTS 标签页看到名为tip_model/的文件夹——这就是 BigQuery ML 导出模型的落盘形态。四、第二步用 gsutil 将模型复制到本地模型文件现在在云端存储桶里接下来把它复制到本地机器mkdir /tmp/model gsutil cp -r gs://taxi_ml_model/tip_model /tmp/modelgsutil cp -r会递归复制整个tip_model目录。复制完成后/tmp/model目录下就是导出的模型文件。从复制输出可以看到BigQuery ML 导出的模型本质是一个TensorFlow SavedModel包含assets、variables以及若干元数据文件如saved_model.pb。variables目录存放训练得到的权重saved_model.pb是计算图定义assets存放模型运行所需的附加资源——这正是它能被 TensorFlow Serving 直接加载的原因。五、第三步搭建 TensorFlow Serving 要求的目录结构TensorFlow Serving 对模型目录布局有严格约定顶层是模型名目录其下每个子目录对应一个整数版本号如1、2Serving 通过版本号管理模型的加载与热更新。因此执行mkdir -p serving_dir/tip_model/1 cp -r /tmp/model/tip_model/* serving_dir/tip_model/1第一行创建serving_dir/tip_model/1serving_dir是服务目录可放在项目目录或任意临时目录tip_model是模型名1是版本号第二行将/tmp/model/tip_model/下所有文件复制进版本目录1中。最终目录结构为serving_dir/ └── tip_model/ └── 1/ ├── saved_model.pb ├── assets/ └── variables/六、第四步拉取镜像并启动 TensorFlow Serving 容器先拉取官方 Serving 镜像再运行容器docker pull tensorflow/servingdocker run -p 8501:8501 \ --mount typebind,sourcepwd/serving_dir/tip_model,target/models/tip_model \ -e MODEL_NAMEtip_model -t tensorflow/serving 启动参数逐项拆解参数作用-p 8501:8501将容器内 8501 端口映射到宿主机 8501 端口REST API 由此端口对外提供服务--mount typebind,source\pwd/serving_dir/tip_model,target/models/tip_model| 将宿主机上的服务目录绑定挂载到容器内/models/tip_model/models 是 TensorFlow Serving 默认的模型根目录-e MODEL_NAMEtip_model通过环境变量告诉 Serving 要加载哪个模型对应挂载目录名-t分配伪终端便于在后台运行并查看日志让容器在后台运行注意source使用反引号包裹的pwd是为了动态获取当前工作目录的绝对路径避免相对路径导致的挂载失败。启动成功后可用docker ps确认tensorflow/serving容器处于运行状态。关于 Serving 端口的小知识TensorFlow Serving 通常暴露两个端口8500 用于 gRPC8501 用于 REST/HTTP。本教程使用 8501 端口配合curl即可完成预测调用无需额外安装客户端库。七、第五步检查模型元信息TensorFlow Serving 内置 REST API 端点GET http://localhost:8501/v1/models/{MODEL_NAME}用于查询模型状态。浏览器或 Postman 访问http://localhost:8501/v1/models/tip_model响应会返回 JSON其中model_version_status字段显示版本1的状态为AVAILABLE、错误码为空——表示模型已成功加载、可以接受预测请求。该端点也是排查「模型未加载 / 目录结构错误 / 版本不可用」等问题的第一站。八、第六步发送预测请求预测端点格式为POST http://localhost:8501/v1/models/{MODEL_NAME}:predict请求体使用 TensorFlow Serving 的标准 JSON 结构instances数组中的每个元素是一行特征。向tip_model发起预测curl -d {instances: [{passenger_count:1, trip_distance:12.2, PULocationID:193, DOLocationID:264, payment_type:1,fare_amount:20.4,tolls_amount:0.0}]} \ -X POST http://localhost:8501/v1/models/tip_model:predict请求特征与 big_query_ml.sql 中训练模型时的列一一对应字段值说明passenger_count1乘客数数值特征trip_distance12.2行程距离数值特征PULocationID193上车地点 ID字符串/类别特征DOLocationID264下车地点 ID字符串/类别特征payment_type1支付方式字符串/类别特征fare_amount20.4车费数值特征tolls_amount0.0过路费数值特征对应这条行程模型预测出约3.2 美元的小费如果将payment_type改为2现金支付再次请求预测小费金额会大幅下降到约0.26 美元——这与训练数据中「现金支付几乎不给小费」的规律一致也验证了模型确实学到了支付方式这一关键特征的影响。九、要点回顾训练与部署的完整闭环至此整个闭环已经打通在 BigQuery 中用 SQL 训练线性回归模型tip_model见 big_query_ml.sql模型创建语句CREATE OR REPLACE MODEL ... model_typelinear_reg用bq extract -m将模型导出到 Cloud Storage用gsutil cp拉取到本地按「模型名/版本号」目录结构组织文件用docker run启动tensorflow/serving容器并提供 REST 服务通过curl/Postman 调用:predict端点完成在线推理。本方案的工程价值在于训练阶段充分利用 BigQuery 的「数据不离仓 SQL 建模」便捷性部署阶段则将模型标准化为 TensorFlow SavedModel交给 TensorFlow Serving 这一通用推理框架托管——两者通过标准的模型导出/加载协议衔接模型可以随时脱离 BigQuery 生态部署在任何能跑 Docker 的环境中。十、延伸部署到生产环境的注意事项以下要点基于本仓库实战流程推断供生产化落地时参考存储桶权限bq extract要求运行账号对目标存储桶有写入权限建议使用专用服务账号并遵循最小权限原则版本管理与热更新TensorFlow Serving 按目录下的整数版本号识别模型放置新的版本目录如2后Serving 会自动加载新版本并支持平滑切换便于模型迭代容器资源预测服务对内存与 CPU 有要求生产环境建议结合容器编排如 Kubernetes设置资源限制与副本数输入校验REST API 只做基础校验生产环境建议在服务前置一层输入校验与特征转换保证请求特征与训练时完全一致包括类型本模型的类别特征需以字符串形式传入。相关资源05-machine-learning-in-bigquery模型训练、评估、解释与超参调优的完整 SQL 教程是本文的建模前置环节big_query_ml.sql上述教程对应的全部可执行 SQL 语句03-data-warehouse/README.md第 3 周模块总览包含本主题视频入口与 BigQuery ML 参考资料链接官方 BigQuery ML 模型导出教程export-model-tutorial本文步骤的权威出处【免费下载链接】data-engineering-zoomcampData Engineering Zoomcamp is a free 9-week course on building production-ready data pipelines. Join the course here 项目地址: https://gitcode.com/GitHub_Trending/da/data-engineering-zoomcamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考