Data Engineering Zoomcamp 模块三基于 BigQuery 的数据仓库实战指南【免费下载链接】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 第三模块「Data Warehouse and BigQuery」展开系统讲解数据仓库的核心概念OLTP/OLAP、数据仓库架构、Data Mart、BigQuery 的无服务器特性与定价模型并以纽约出租车数据为例通过真实可运行的 SQL 演示外部表、分区Partitioning与聚簇Clustering的建表与优化效果最后覆盖 BigQuery ML 的建模与模型部署全流程。读完本文你将掌握用 BigQuery 从「建外部表 → 分区聚簇优化 → 成本与性能最佳实践 → SQL 内建机器学习模型 → Docker 部署模型」的完整数据仓库实战链路。模块总览学什么、怎么学03-data-warehouse/README.md是模块三的入口文档它把整个模块组织为「视频课程 可复现 SQL 作业 社区笔记」四部分课程视频共 6 讲覆盖 Data Warehouse 与 BigQuery、Partitioning vs Clustering、Best practices、Internals of BigQuery以及两个进阶主题——BigQuery 机器学习与模型部署可执行 SQL 文件big_query.sql基础查询、外部表、分区聚簇、big_query_ml.sql机器学习建模、big_query_hw.sql作业配套 SQL部署手册extract_model.md从 BigQuery 导出模型并用 Docker 提供服务作业指向 2026 年模块三作业同时配套数据加载脚本社区笔记README 的 Community notes 区块收集了历届学员的公开笔记详见03-data-warehouse/README.md的 details 折叠区。此外cohorts/2027/03-data-warehouse/下还提供了与视频逐讲对应的文字讲义01-data-warehouse-and-bigquery.md至06-deploying-a-machine-learning-model.md本指南将结合这些讲义与仓库源码对 README 中的主题做纵深展开。数据仓库基础OLTP 与 OLAP 的区别在动手使用 BigQuery 之前需要先理解数据仓库在整个数据体系中的定位。数据库按用途分为两大流派OLTPOnline Transaction Processing联机事务处理服务于后端业务系统。多个 SQL 语句打包在一个事务中执行任一语句失败则整体回滚。典型例子是电商下单订单、支付、库存更新要么全部成功、要么全部失败。OLAPOnline Analytical Processing联机分析处理服务于分析场景核心目标是「把大量数据装进去并从中发现隐藏洞察」主要使用者是数据分析师与数据科学家。两种数据库几乎在所有维度上都存在差异二者的对比可用下表概括维度OLTPOLAP目的实时控制与支撑关键业务运营规划、解决问题、辅助决策、发现隐藏洞察数据更新用户触发的短小快速更新通过定时、长时批处理任务周期性刷新数据库设计为效率而规范化Normalized为分析而反规范化Denormalized空间需求归档历史后通常较小因聚合海量数据集通常很大数据仓库架构从数据源到 Data Mart数据仓库Data Warehouse本质上就是一套面向报表与数据分析的 OLAP 方案。一套典型的仓库由原始数据raw data、元数据metadata和汇总数据summary data组成其数据流如下多个数据源运营系统、平面文件、OLTP 数据库等先汇入暂存区staging area再由暂存区写入数据仓库本体最终按主题切分为更小、面向特定业务的Data Mart如采购、销售、库存供不同用户直接访问。仓库的价值在于它的灵活性对分析师而言通过 Data Mart 访问数据是理想形态对数据科学家而言也可以直接读取仓库中的原始数据。BigQuery无服务器的数据仓库BigQuery 是模块使用的数据仓库实现其最大优势是无服务器serverless无需管理任何服务器也无需安装数据库软件。企业自建数据仓库时大量时间都耗在基础设施的创建与维护上而 BigQuery 将软件与基础设施一并托管开箱即用地提供可扩展性与高可用性——从几 GB 起步可平滑扩展到 PB 级。BigQuery 的差异化能力包括通过 SQL 接口直接做机器学习即 BigQuery ML见下文支持**地理空间数据geospatial**处理支持**商业智能BI**类查询。另一个关键设计是存储与计算分离传统架构中单台大服务器同时承载存储与计算数据量增长时整机必须随之扩容BigQuery 则将计算引擎与存储解耦数据放在用户自选的存储如 Cloud Storage上按需分析。这一设计显著降低了成本。定价模型BigQuery 提供两种定价方式按需计费On-demand按扫描/处理的数据量计费每处理 1 TB 数据约 $5固定费率Flat rate按预购的 slotBigQuery 的处理能力单位计费100 个 slot 每月约 $2,000约相当于按需计费下处理 400 TB 的数据量。因此只有当月扫描量远超 200 TB 时固定费率才划算。slot 机制还影响并发表现固定费率下若 100 个 slot 已被 50 个查询占满第 51 个查询必须排队等待而按需计费下 BigQuery 会根据查询需求动态分配更多 slot。另外BigQuery 一般会缓存查询结果模块演示中为得到一致结果通常会关闭缓存。上手 BigQuery查询公共数据集BigQuery 内置大量可开箱即用的公共数据集。模块以纽约 Citi Bike 车站数据为例在搜索栏中按表名找到citibike_stations约 1,584 行、几 KB即可用与big_query.sql第一段一致的 SQL 查询SELECT station_id, name FROM bigquery-public-data.new_york_citibike.citibike_stations LIMIT 100;查询结果会出现在界面底部的结果面板中可导出为 CSV 或继续在 Data Studio 中探索。外部表让 BigQuery 直接读取 Cloud Storage 中的数据模块使用纽约出租车行程数据已上传至 Google Cloud Storage。BigQuery 支持在 GCS 文件上创建外部表external table数据仍存放在 Cloud StorageBigQuery 只保存元数据。界面按「项目project/ 数据集dataset/ 表table」三级组织taxi-rides-ny是项目、nytaxi是数据集、external_yellow_tripdata是表。创建外部表指向 2019、2020 两年的出租车 CSVCREATE OR REPLACE EXTERNAL TABLE taxi-rides-ny.nytaxi.external_yellow_tripdata OPTIONS ( format CSV, uris [ gs://nyc-tl-data/trip data/yellow_tripdata_2019-*.csv, gs://nyc-tl-data/trip data/yellow_tripdata_2020-*.csv ] );创建成功后BigQuery 会自动识别 CSV 的列名、类型与可空性无需手工定义 schema也可手动指定。注意表详情中「长期存储 0 字节、表大小 0 字节、行数 0」——这是外部表的正常表现因为数据在外部系统 GCS 中BigQuery 无法直接获知行数与大小。查询外部表与普通表无异SELECT * FROM taxi-rides-ny.nytaxi.external_yellow_tripdata LIMIT 10;返回结果包含 VendorID、上下车时间、乘客数、行程距离、上下车位置以及费用与总额等字段。如何把数据送进 GCS除了使用课程预置的 GCS 桶仓库还提供了自行上传数据的脚本。03-data-warehouse/extras/目录下的 web_to_gcs.py 会从公开数据源下载各月出租车 CSV用 pandas 按固定 dtypes 读取保证 Parquet 列类型正确转成 Parquet 后上传到 GCS在extras目录执行uv sync安装依赖见 pyproject.toml包含 google-cloud-storage、pandas、pyarrow、python-dotenv、requests、tqdm在.env中设置GCP_GCS_BUCKET与GOOGLE_APPLICATION_CREDENTIALS或使用 Google ADC运行uv run python web_to_gcs.py简洁版或uv run python web_to_gcs_with_progress_bar.py带下载/转换/上传进度条。其中web_to_gcs_with_progress_bar.py的增强点值得注意它会跳过 GCS 中已存在的对象、复用本地已下载的 CSV 与已转换的 Parquet并通过分块读取每块 10 万行流式写入 Parquet避免大文件内存溢出上传时通过storage.blob._MAX_MULTIPART_SIZE与_DEFAULT_CHUNKSIZE调整分片大小以规避大文件超时。脚本默认执行web_to_gcs(2019, green)、web_to_gcs(2020, green)、web_to_gcs(2021, green)其中 2021 年 8 月起文件不存在属正常现象。分区Partitioning按时间裁剪扫描量分区是 BigQuery 最实用的优化手段之一。以 Stack Overflow 问题表含创建日期、标题、标签等列为例若查询大多按日期过滤如「只看 3 月的问题」按创建日期分区后每个日期成为一个独立分区。BigQuery 一旦确认只需读取某天的数据就不会触碰其他分区的数据——处理的数据越少成本越低。回到出租车数据。先复制外部表创建一张非分区表作为对照CREATE OR REPLACE TABLE taxi-rides-ny.nytaxi.yellow_tripdata_non_partitioned AS SELECT * FROM taxi-rides-ny.nytaxi.external_yellow_tripdata;复制数据需要一些时间数据从 GCS 拷入 BigQuery 自有存储。分区表只多一行PARTITION BYCREATE OR REPLACE TABLE taxi-rides-ny.nytaxi.yellow_tripdata_partitioned PARTITION BY DATE(tpep_pickup_datetime) AS SELECT * FROM taxi-rides-ny.nytaxi.external_yellow_tripdata;分区表能正确显示大小约 13–14 GB详情中可见其按tpep_pickup_datetime以「天」为粒度分区。一个快速判断表是否分区的技巧在 schema 视图中非分区表是一整块连续的列分区表的列之间会出现一条分隔线。现在对比两条等价的查询——统计 2019 年 6 月的 VendorID 去重结果SELECT DISTINCT(VendorID) FROM taxi-rides-ny.nytaxi.yellow_tripdata_non_partitioned WHERE DATE(tpep_pickup_datetime) BETWEEN 2019-06-01 AND 2019-06-30;非分区表预计处理1.6 GB几乎是全表数据将表名换成分区表预计处理量骤降至约106 MB重复执行此类查询每次只扫描 106 MB 而非 1.6 GB成本直接随之下降。还可以通过元数据检查各分区的行数分布。每个数据集都有INFORMATION_SCHEMA其中的PARTITIONS视图可查询分区明细SELECT table_name, partition_id, total_rows FROM nytaxi.INFORMATION_SCHEMA.PARTITIONS WHERE table_name yellow_tripdata_partitioned ORDER BY total_rows DESC;该查询能看出哪些日期行数最多示例表中 2019-02-01 最多也可用于排查数据偏斜——某些分区数据量是否明显异常。聚簇Clustering分区内的数据共置聚簇解决的是分区内的数据组织问题。仍以 Stack Overflow 为例表按日期分区后再按标签聚簇则同一分区内相同标签的行会物理相邻存储。由于相关行紧挨在一起BigQuery 可以在分区内部跳过无关数据进一步降低扫描量与查询耗时。创建「既分区又聚簇」的表CREATE OR REPLACE TABLE taxi-rides-ny.nytaxi.yellow_tripdata_partitioned_clustered PARTITION BY DATE(tpep_pickup_datetime) CLUSTER BY VendorID AS SELECT * FROM taxi-rides-ny.nytaxi.external_yellow_tripdata;为何选VendorID作为聚簇列因为该场景下查询总是同时按 vendor id 与上车日期过滤分区与聚簇的组合正好命中这两个过滤条件。表详情页会确认按tpep_pickup_datetime按天分区、按VendorID聚簇。对比两种表在「统计 2019-06-01 至 2020-12-31 之间 Vendor 1 的行程数」上的表现SELECT count(*) as trips FROM taxi-rides-ny.nytaxi.yellow_tripdata_partitioned WHERE DATE(tpep_pickup_datetime) BETWEEN 2019-06-01 AND 2020-12-31 AND VendorID1;运行前 BigQuery 对两张表的预估都是 1.1 GB——预估是近似值聚簇能跳过多少数据只有运行后才知道。实际运行结果仅分区的表处理 1.1 GB分区 聚簇的表只处理约 843.5 MB。这就是聚簇的效果。记住这条经验无论 BigQuery 运行前显示多少都以运行后实际处理的字节数为准。分区还是聚簇取舍标准分区与聚簇并非总是叠加使用选择依据如下成本可预知性分区的成本收益在查询前即可确定按分区列过滤只读部分分区聚簇的收益要到运行后才知道。BigQuery 允许为查询设置成本上限超限则拒绝执行——只有成本可预知即分区时才能用此能力。粒度需要比分区更细的裁剪粒度时用聚簇。管理能力分区支持分区级管理删除分区、在存储间迁移分区聚簇没有。列数聚簇支持多列常用多列过滤/聚合分区只能基于单列。基数Cardinality某列或列组去重值很多时适合聚簇——高基数是分区的障碍因为单表分区数上限为4000。分区选项与粒度创建分区表时可选择分区依据详见cohorts/2027/03-data-warehouse/02-partitioning-vs-clustering.md时间单位列time-unit column基于 timestamp/date 类型的列如出租车上车时间摄取时间ingestion time按行写入时间分区使用伪列_PARTITIONTIME整数范围integer range将整数列按区间切分。时间单位列与摄取时间还支持粒度选择日默认、小时、月、年。日粒度适合中等体量、数据在日期上均匀分布的场景小时粒度适合海量数据按小时处理的场景注意分区数上限 4000可能需要过期策略清理旧分区月/年粒度适合数据量小但日期跨度大的场景。何时聚簇优于分区以下情况应优先选择聚簇分区粒度会导致每个分区数据量过小约小于 1 GB分区数会超过单表 4000 个的上限变更操作mutation频繁触及大部分分区如每隔几分钟写一次。聚簇列的限制与自动重聚簇聚簇最多指定4 列必须是顶层、非重复non-repeated的列可用类型为DATE、BOOLEAN、GEOGRAPHY、INT64、NUMERIC、STRING、DATETIME。列顺序决定排序优先级按 a、b、c 聚簇则先按 a 排、再按 b、再按 c。需要注意分区与聚簇并非零成本小于 1 GB 的小表两者都不会带来明显的性能提升反而因元数据读取与维护增加开销此时不设分区/聚簇更划算。此外随着数据不断写入新行的键范围可能与旧块重叠、削弱排序性质BigQuery 会在后台自动执行自动重聚簇automatic reclustering恢复表的排序属性且不影响查询性能、不额外计费对分区表聚簇在各分区范围内分别维护。BigQuery 最佳实践清单cohorts/2027/03-data-warehouse/03-bigquery-best-practices.md提供了一份围绕「降成本」与「提性能」两个目标的实践清单。成本控制避免SELECT *BigQuery 采用列式存储每列独立存放。显式列出所需列时BigQuery 只读这些列用*则必须读取所有列。只取一两列时这就是「几乎不读」与「读全表」的差别运行前先看预估价格查询编辑器右上角会显示预估费用点击运行前先确认使用分区/聚簇表让 BigQuery 跳过表的大部分数据谨慎使用流式插入streaming inserts会显著推高成本分阶段物化查询结果如果一个 CTEWITH子句在多处复用不要每次重算先跑一次把结果落成表后续步骤直接引用该表。另外BigQuery 会缓存查询结果重复执行相同查询时可直接命中缓存。性能优化始终在分区列或聚簇列上过滤否则已建立的分区/聚簇形同虚设反规范化denormalize数据数仓场景常与 OLTP 相反把相关数据放在一起避免查询时反复 join复杂结构用嵌套/重复列nested/repeated columns在避免彻底反规范化的同时保持相关数据共置合理使用外部数据源从 GCS 等外部源读数据可能比读 BigQuery 自有存储更贵不要过度使用先过滤再 JOIN在 join 之前先缩小数据量不要把WITH当作预编译语句它只是单条查询内的命名子查询不能跨查询复用避免过度分片oversharding把数据拆成大量小表如每天一张表的效果劣于一张分区表。更多提速技巧避免使用 JavaScript 自定义函数UDF用近似聚合函数替代精确函数例如用 HyperLogLog 做去重计数ORDER BY放在查询最后优化 join 顺序把行数最多的表放第一位行数最少的表次之其余按体积递减排列——最大的表会被均匀分布到各节点次大的表会被广播到所有节点。BigQuery 内部原理Colossus、Jupiter 与 Dremel理解 BigQuery 的架构有助于设计自己的数据产品详见cohorts/2027/03-data-warehouse/04-internals-of-bigquery.md。三个核心组件Colossus存储BigQuery 的底层分布式存储采用列式格式价格低廉。存储与计算分离是重大架构决策数据增长只增加廉价的存储成本昂贵的计算只在真正运行查询时发生Jupiter网络连接存储与计算的数据中心网络带宽约每秒 1 TB使存储与计算分离后依然无延迟通信Dremel查询执行引擎把查询拆成树状结构逐层分发执行。列式存储为什么重要记录式row-oriented存储把整行作为一个整体类似 CSV简单易理解列式column-oriented存储则让每一列独立存放。BigQuery 采用列式存储带来的收益巨大对列做聚合更快且数仓查询本来就很少一次取全列——列分开存放后其余列完全不被触碰这也是SELECT *昂贵的原因。Dremel 的查询执行树以SELECT A, COUNT(B) FROM T GROUP BY A为例root server接收查询后改写为SELECT A, SUM(C)把计数变成对下层部分计数的求和切分成切片分发给mixers中间层mixers 再细分给leaf nodesleaf nodes 真正与 Colossus 交互、取数并在各自切片上执行操作结果逐级汇总回 root server。正是这种分布式执行树让 BigQuery 在数据规模增长时依然能线性扩展查询能力。BigQuery ML用 SQL 完成机器学习全流程进阶主题之一是在 BigQuery 内部直接用 SQL 训练、评估、解释和调优机器学习模型脚本见big_query_ml.sql讲义见cohorts/2027/03-data-warehouse/05-machine-learning-in-bigquery.md。本模块以「预测出租车小费金额」的线性回归模型为例。为什么在 BigQuery 里做 MLBigQuery ML 面向数据分析师与管理者只需 SQL 基础 ML 知识无需掌握 Python/Java。另一个优势是数据不离仓——传统流程需要把数据导出到独立系统训练再部署而 BigQuery 直接在仓库内建模型省去导出步骤。提示机器学习对新手而言属于进阶内容若暂时不熟悉可以跳过不影响主流程。定价录制课程时的定价背景数据存储 GB 免费每月前 1 TB 查询免费CREATE MODEL步骤每月前 10 GB 免费。免费额度之后创建线性回归/逻辑回归/聚类/时间序列模型约 $250/TBAutoML、DNN、boosted tree 模型约 $5/TB另加 Vertex AI 训练费用。以上为美国区价格其他区域以官方为准。特征选择与预处理标签要预测的目标是tip_amount。特征从yellow_tripdata_partitioned表中挑选若干列SELECT passenger_count, trip_distance, PULocationID, DOLocationID, payment_type, fare_amount, tolls_amount, tip_amount FROM taxi-rides-ny.nytaxi.yellow_tripdata_partitioned WHERE fare_amount ! 0;WHERE fare_amount ! 0很关键大量行程费用为 0且这些行程小费几乎也为 0会把模型带偏。BigQuery ML 的预处理分自动与手动两种自动预处理包括数值列标准化、类别列 one-hot 编码、数组 multi-hot 编码手动预处理包括分桶bucketization、多项式展开、特征交叉、n-gram、min-max 缩放等。关键陷阱PULocationID、DOLocationID、payment_type虽然存储为整数本质却是类别位置 ID 264 不代表「264 倍」。保持整数类型的话BigQuery 会把它们当数值做标准化而不是 one-hot 编码。因此先建一张把这些列 CAST 成STRING的特征表CREATE OR REPLACE TABLE taxi-rides-ny.nytaxi.yellow_tripdata_ml ( passenger_count INTEGER, trip_distance FLOAT64, PULocationID STRING, DOLocationID STRING, payment_type STRING, fare_amount FLOAT64, tolls_amount FLOAT64, tip_amount FLOAT64 ) AS ( SELECT passenger_count, trip_distance, cast(PULocationID AS STRING), CAST(DOLocationID AS STRING), CAST(payment_type AS STRING), fare_amount, tolls_amount, tip_amount FROM taxi-rides-ny.nytaxi.yellow_tripdata_partitioned WHERE fare_amount ! 0 );字符串列会被自动识别为类别特征并做 one-hot 编码。创建模型CREATE OR REPLACE MODEL taxi-rides-ny.nytaxi.tip_model OPTIONS (model_typelinear_reg, input_label_cols[tip_amount], DATA_SPLIT_METHODAUTO_SPLIT) AS SELECT * FROM taxi-rides-ny.nytaxi.yellow_tripdata_ml WHERE tip_amount IS NOT NULL;model_typelinear_reg选择线性回归算法input_label_cols指定标签列DATA_SPLIT_METHODAUTO_SPLIT让 BigQuery 自动划分训练集与评估集。训练约需 5 分钟评估页会显示误差指标示例中 MSE 约 8、MAE 约 1——模型不算最优但本模块重在演示流程。特征检查、评估、预测与解释BigQuery ML 提供四个配套函数ML.FEATURE_INFO查看模型如何理解每个特征——数值列显示 min/max/mean用于标准化类别列显示类别数SELECT * FROM ML.FEATURE_INFO(MODEL taxi-rides-ny.nytaxi.tip_model);ML.EVALUATE在指定数据集上打分返回误差指标示例中 MAE 约 1、MSE 约 150SELECT * FROM ML.EVALUATE(MODEL taxi-rides-ny.nytaxi.tip_model, (SELECT * FROM taxi-rides-ny.nytaxi.yellow_tripdata_ml WHERE tip_amount IS NOT NULL));ML.PREDICT为数据集追加预测列predicted_tip_amount可与真实tip_amount并排做人工评估SELECT * FROM ML.PREDICT(MODEL taxi-rides-ny.nytaxi.tip_model, (SELECT * FROM taxi-rides-ny.nytaxi.yellow_tripdata_ml WHERE tip_amount IS NOT NULL));ML.EXPLAIN_PREDICT用STRUCT(3 as top_k_features)输出每条预测贡献最大的前 3 个特征示例中三个类别特征——上下车位置与支付方式——对预测影响最大SELECT * FROM ML.EXPLAIN_PREDICT(MODEL taxi-rides-ny.nytaxi.tip_model, (SELECT * FROM taxi-rides-ny.nytaxi.yellow_tripdata_ml WHERE tip_amount IS NOT NULL), STRUCT(3 as top_k_features));超参数调优模型不够理想时标准手段是超参数调优。num_trials控制试验次数、max_parallel_trials控制并行试验数加速整体运行、l1_reg/l2_reg用hparam_range连续范围或hparam_candidates候选列表指定正则化参数搜索空间CREATE OR REPLACE MODEL taxi-rides-ny.nytaxi.tip_hyperparam_model OPTIONS (model_typelinear_reg, input_label_cols[tip_amount], DATA_SPLIT_METHODAUTO_SPLIT, num_trials5, max_parallel_trials2, l1_reghparam_range(0, 20), l2_reghparam_candidates([0, 0.1, 1, 10])) AS SELECT * FROM taxi-rides-ny.nytaxi.yellow_tripdata_ml WHERE tip_amount IS NOT NULL;CREATE MODEL还支持更多选项学习率策略、early stopping、最小相对进步等熟悉 ML 的读者可进一步深挖。模型部署导出 BigQuery ML 模型并用 Docker 提供服务训练好的模型可以脱离 BigQuery 运行步骤见extract_model.md讲义见cohorts/2027/03-data-warehouse/06-deploying-a-machine-learning-model.md。整体思路用bq导出模型到 GCS → 用gsutil拷回本地 → 按 TensorFlow Serving 目录规范组织 → 用 Docker 启动服务 → 通过 HTTP 调用。1. 导出模型到 Cloud Storagegcloud auth login bq --project_id taxi-rides-ny extract -m nytaxi.tip_model gs://taxi_ml_model/tip_model导出完成后tip_model目录会出现在taxi_ml_model桶中。2. 拷贝到本地mkdir /tmp/model gsutil cp -r gs://taxi_ml_model/tip_model /tmp/model导出的 BigQuery 模型本质是一个 TensorFlow 模型包含assets、variables及若干元数据文件。3. 用 TensorFlow Serving Docker 提供服务TensorFlow Serving 要求特定的目录布局以模型名命名的目录内含按版本号编号的子目录。因此创建serving_dir/tip_model/1并把模型文件拷入版本目录mkdir -p serving_dir/tip_model/1 cp -r /tmp/model/tip_model/* serving_dir/tip_model/1 docker pull tensorflow/serving docker 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 端口映射到本机--mount把本地 serving 目录绑定挂载进容器-e MODEL_NAMEtip_model告诉 TensorFlow Serving 服务哪个模型。4. 检查模型状态TensorFlow Serving 暴露 REST API。向http://localhost:8501/v1/models/tip_model发 GET 请求视频中使用 Postman响应应显示 tip_model 版本 1 状态为 AVAILABLE。5. 通过 HTTP 预测向http://localhost:8501/v1/models/tip_model:predictPOST 一条 JSON字段与训练特征一致curl -d {instances: [{passenger_count:1, trip_distance:12.2, PULocationID:193, DOLocationID:264, payment_type:2,fare_amount:20.4,tolls_amount:0.0}]} \ -X POST http://localhost:8501/v1/models/tip_model:predict示例中该行程预测小费约 $3.2把payment_type改成 2 后预测值骤降至约 $0.26。至此完成闭环BigQuery 内用 SQL 训练 → 导出 → Docker 容器中以 REST 服务对外提供预测。模块作业把 2024 年上半年出租车数据搬进 BigQueryREADME 将作业指向 2026 年模块三作业使用2024 年 1 月至 6 月的 Yellow Taxi 行程数据Parquet 格式完成「建外部表 → 建非分区/分区聚簇表 → 对比查询扫描量」的练习。注意本次作业创建外部表时必须使用 PARQUET 格式选项。数据加载可使用配套的 load_yellow_taxi_data.py 脚本它通过google.cloud.storage客户端、以 4 线程并发从公开 CDN 下载 6 个月份的 Parquet 文件每个 8 MB 分块自动创建或校验GCS 桶上传后调用storage.Blob(...).exists()做存在性校验失败自动重试 3 次间隔 5 秒。使用前需准备带GCS Admin权限的 Service Account或通过 gcloud SDK 认证并修改脚本中的BUCKET_NAME。作业配套 SQL 见big_query_hw.sql用 FHV 数据演示了外部表创建、count(*)全表统计、COUNT(DISTINCT(dispatching_base_num))去重统计、非分区表与「按dropoff_datetime分区 按dispatching_base_num聚簇」表的对比查询。延伸资源模块幻灯片链接及全部课程视频入口见 03-data-warehouse/README.md基础 SQL 脚本big_query.sqlML 脚本big_query_ml.sql作业脚本big_query_hw.sql模型导出与部署手册extract_model.md数据上传工具extras/web_to_gcs.py与extras/web_to_gcs_with_progress_bar.py逐讲文字讲义cohorts/2027/03-data-warehouse/下01-data-warehouse-and-bigquery.md至06-deploying-a-machine-learning-model.mdREADME 的 Community notes 区块还汇集了历届学员的社区笔记与 2024 年视频转录稿链接可作为学习参考。【免费下载链接】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），仅供参考