首页电脑使用google it automation with python google python代码规范

google it automation with python google python代码规范

圆圆2025-08-13 19:01:39次浏览条评论

最常用且方便的python库是google-cloud-bigquery,而pandas-gbq则更适合依赖pandas dataframes的工作流;2. pandas-gbq是google-cloud-bigquery的高层封装,支持将sql查询结果直接读入dataframe或将dataframe写入bigquery表;3. 安装需执行pip install pandas pandas-gbq google-auth-oauthlib db-dtypes;4. 读取数据使用pd.read_gbq()并传入sql查询语句和项目id;5. 写入数据使用df.to_gbq()并指定目标表、项目id及if_exists策略('fail'、'replace'、'append');6. google-cloud-bigquery提供底层全面api,适合资源管理和复杂作业,pandas-gbq则聚焦于与dataframe的无缝集成;7. 性能优化关键包括避免select *、尽早过滤、利用分区与聚簇表、在bigquery中完成聚合、控制数据量与内存使用;8. 大数据量写入时可依赖pandas-gbq内部通过gcs临时存储的机制,并确保区域一致以减少延迟;9. 认证推荐使用默认应用凭据(dac),可通过gcloud auth application-default login配置本地认证;10. 可通过设置google_application_credentials环境变量指向服务账号密钥文件实现自动认证;11. 显式认证可通过from google.oauth2 import service_account加载json密钥文件创建credentials对象;12. 常见权限包括bigquery job user、data viewer、data editor,涉及gcs时还需storage相关权限;13. 调试权限问题需检查认证配置、项目id、iam角色及数据集/表级权限是否正确分配。使用pandas-gbq操作bigquery时应结合其高层便利性与底层优化原则,合理选择认证方式并确保权限完备,以实现高效安全的数据交互。

Python怎样操作Google BigQuery?pandas-gbq

Python操作Google BigQuery,最常用也最方便的库无疑是

google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制,而如果你的工作流大量依赖pandas DataFrames,那么
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制简直是神器,它能让你丝滑地在BigQuery和DataFrame之间进行数据传输与操作。

解决方案

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制库为Python用户提供了一种极其简洁的方式来与Google BigQuery进行交互,尤其当你习惯了用pandas处理数据时。它本质上是
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制库的一个高层封装,让你能直接将SQL查询结果读入DataFrame,或者将DataFrame内容写入BigQuery表。

使用它非常直接:

立即学习“Python免费学习笔记(深入)”;

首先,你需要安装必要的库:

pip install pandas pandas-gbq google-auth-oauthlib db-dtypes
登录后复制

db-dtypes
登录后复制是最近为了更好的类型兼容性而推荐安装的。

读取BigQuery数据到DataFrame:

你可以直接执行SQL查询,并将结果加载到pandas DataFrame中。

import pandas as pdfrom google.oauth2 import service_account # 如果需要显式认证# 假设你已经通过gcloud CLI进行了认证,或者设置了GOOGLE_APPLICATION_CREDENTIALS环境变量# 否则,你需要提供项目ID和认证凭据project_id = "你的GCP项目ID" # 替换成你的项目ID# 示例1: 从BigQuery表读取数据query_table = f"""SELECT    col1,    col2,    col3FROM    `{project_id}.your_dataset.your_table`WHERE    date_column >= '2023-01-01'LIMIT 1000"""df_from_bq = pd.read_gbq(query_table, project_id=project_id, dialect='standard')print("从BigQuery读取的数据:")print(df_from_bq.head())# 示例2: 如果你的认证文件是JSON,可以这样加载# credentials_path = "path/to/your/service_account_key.json"# credentials = service_account.Credentials.from_service_account_file(credentials_path)# df_from_bq_auth = pd.read_gbq(query_table, project_id=project_id, credentials=credentials)
登录后复制

dialect='standard'
登录后复制通常是推荐的,因为BigQuery默认使用标准SQL。

将DataFrame写入BigQuery表:

将本地DataFrame写入BigQuery同样简单。你可以指定目标数据集和表名,以及处理表已存在时的策略(如追加、覆盖或报错)。

# 创建一个示例DataFramedata = {    'name': ['Alice', 'Bob', 'Charlie'],    'age': [30, 24, 35],    'city': ['New York', 'Los Angeles', 'Chicago']}df_to_bq = pd.DataFrame(data)# 写入BigQuerydataset_id = "your_dataset" # 替换成你的数据集IDtable_id = "new_users_data" # 替换成你希望创建的表名# if_exists 参数:# 'fail': 如果表已存在,则抛出ValueError。# 'replace': 如果表已存在,则删除并重新创建。# 'append': 如果表已存在,则将数据追加到现有表中。df_to_bq.to_gbq(    destination_table=f"{dataset_id}.{table_id}",    project_id=project_id,    if_exists='append' # 或者 'replace', 'fail')print(f"数据已成功写入BigQuery表:{project_id}.{dataset_id}.{table_id}")
登录后复制

在实际应用中,

if_exists='append'
登录后复制非常常见,尤其是在增量数据加载场景。

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制与
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制库有什么区别和联系?

说实话,我刚开始接触BigQuery的时候也对这两个库的关系有点迷糊。简单来说,

google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制是Google官方提供的Python客户端库,它提供了非常底层且全面的API接口,让你能够直接操作BigQuery的各种资源,比如创建数据集、管理表、运行批处理作业、甚至进行流式插入等等。它的粒度非常细,你可以精确控制每一个BigQuery API调用。

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制呢,它其实是建立在
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制之上的一个“便利层”或者说“包装器”。它的核心目标是让BigQuery的数据操作与pandas DataFrames无缝衔接。你可以把它想象成一个翻译官,把你的DataFrame操作请求,翻译成
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制能理解的API调用,然后再把BigQuery返回的结果,整理成DataFrame格式。

所以,它们的关系是:

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制是
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制的“用户”,它利用了后者的能力来完成自己的任务。

什么时候用哪个呢?

我个人经验是,如果你的核心需求是:

把SQL查询结果直接变成DataFrame进行分析。把一个DataFrame快速上传到BigQuery作为新表或追加到现有表。做一些探索性数据分析(EDA),或者简单的ETL(抽取-转换-加载)流程,其中“转换”部分主要在pandas里完成。那么,
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制无疑是首选,它代码量少,上手快,效率高。

但如果你需要:

对BigQuery资源进行精细化管理(比如动态创建数据集、修改表结构、管理分区和聚簇)。运行复杂的异步查询作业,或者需要监控作业状态。进行大规模的流式数据插入(虽然
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制内部也会处理大DataFrame的写入,但
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制提供了更直接的流式API)。处理非常大的查询结果集,不希望一次性全部加载到内存中(
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制允许你以迭代器方式获取结果)。编写更健壮、更具弹性的生产级ETL管道,可能涉及错误重试、作业状态检查等。那么,你就需要深入到
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制库了。很多时候,我会在一个项目中同时使用它们:
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制负责快速的数据导入导出和探索,而
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制则用于更底层的资源管理和复杂作业调度。使用
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制操作BigQuery时,有哪些常见的性能考量和优化技巧?

性能这块,特别是涉及到BigQuery,你首先要记住一个核心点:BigQuery是按查询扫描的数据量收费的。所以,性能优化很多时候也意味着成本优化。

SQL查询优化是基石:

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制只是把你的SQL语句发给BigQuery执行,所以BigQuery本身的查询优化原则完全适用。

只选择你需要的列: 避免
SELECT *
登录后复制登录后复制,特别是对于宽表。这能显著减少扫描的数据量。尽早过滤数据: 使用
WHERE
登录后复制登录后复制子句在查询开始阶段就筛选掉不必要的数据。例如,如果只需要最近一年的数据,就加上日期过滤条件。利用分区表和聚簇表: 如果你的表是按日期或其他维度分区的,查询时在
WHERE
登录后复制登录后复制子句中包含分区列,BigQuery就能跳过不相关的分区,大大减少扫描量。聚簇表则能进一步优化在聚簇列上的过滤和聚合性能。避免全表扫描: 尽量利用索引(虽然BigQuery没有传统意义上的索引,但分区和聚簇起到了类似作用)。聚合操作先在BigQuery完成: 如果你最终只需要聚合后的结果(比如总销售额、平均值),尽量在SQL查询中完成
GROUP BY
登录后复制和聚合函数,而不是把原始大量数据拉到pandas里再聚合。这能大幅减少传输的数据量和内存消耗。

数据量与内存:

pd.read_gbq
登录后复制登录后复制会将查询结果全部加载到内存中形成DataFrame。如果你的查询结果有几十GB甚至上百GB,你的本地机器内存很可能吃不消。

分批处理: 如果你必须处理大量数据,考虑在BigQuery中将数据分批,或者在
pd.read_gbq
登录后复制登录后复制中设置
chunksize
登录后复制参数(虽然
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制对大结果集有内部优化,但外部控制有时更灵活)。内存优化数据类型:
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制会尽量推断最佳的pandas数据类型,但你也可以在读取后手动优化,比如将整数列转换为更小的整数类型(
int8
登录后复制,
int16
登录后复制等),或将浮点数转换为
float32
登录后复制,这能节省大量内存。考虑Dask或PySpark: 对于真正超出单机内存限制的数据量,你可能需要跳出pandas的范畴,考虑使用Dask或PySpark等分布式计算框架,它们可以直接与
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制库结合,在集群上处理数据。

写入性能(

df.to_gbq
登录后复制):

to_gbq
登录后复制在内部会把DataFrame数据打包并上传到BigQuery。对于非常大的DataFrame(比如几百万行以上),这个过程可能会比较慢。考虑中间GCS存储: 对于超大数据写入,BigQuery推荐通过Google Cloud Storage (GCS) 进行批量加载。
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制在内部也会为大文件使用GCS作为临时存储。确保你的GCS桶和BigQuery数据集在同一区域,可以减少延迟。数据类型匹配: 确保DataFrame列的数据类型与BigQuery目标表的列类型尽可能匹配,可以减少BigQuery在写入时进行类型转换的开销。

网络延迟: 确保你的代码运行环境和BigQuery数据集位于相同的Google Cloud区域,或者至少是地理上相近的区域,可以显著减少数据传输的延迟。

我遇到过最常见的性能问题就是“把BigQuery当成了关系型数据库来用”,习惯性地

SELECT *
登录后复制登录后复制然后拉到本地处理。后来才意识到,BigQuery是为大规模分析而生的,它的优化哲学和传统OLTP数据库完全不同。改变这种思维模式,是性能优化的第一步。

如何处理
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制操作中的认证和权限问题?

认证和权限,这绝对是初次使用Google Cloud服务时最容易“卡壳”的地方,没有之一!

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制(以及底层的
google-cloud-bigquery
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制)需要明确知道你是谁,以及你被允许做什么。

主要有几种认证方式:

默认应用凭据 (Default Application Credentials, DAC): 这是最推荐也最方便的方式。

在GCP环境中运行: 如果你的Python代码运行在Google Cloud的虚拟机(Compute Engine)、Cloud Functions、App Engine、Google Kubernetes Engine (GKE)等服务上,通常会自动使用该服务关联的服务账号作为凭据。你只需要确保这个服务账号拥有访问BigQuery的相应权限(比如
BigQuery Data Editor
登录后复制登录后复制登录后复制、
BigQuery Job User
登录后复制登录后复制登录后复制等)。在本地开发: 在本地开发时,你可以通过Google Cloud SDK的
gcloud auth application-default login
登录后复制登录后复制命令来生成用户凭据。这个命令会在你的用户目录下创建一个凭据文件,Python客户端库会自动找到并使用它。
gcloud auth application-default login
登录后复制通过环境变量: 你也可以将服务账号密钥文件的路径设置到
GOOGLE_APPLICATION_CREDENTIALS
登录后复制登录后复制环境变量中。
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your/service_account_key.json"
登录后复制

然后你的Python代码就无需显式传递凭据了:

import pandas as pddf = pd.read_gbq("SELECT * FROM `your_project.your_dataset.your_table`")
登录后复制

我个人非常喜欢这种方式,因为它让代码变得更简洁,也更安全,因为你不需要把密钥路径硬编码在代码里。

服务账号密钥文件: 当你无法使用DAC,或者需要在非GCP环境(比如本地开发、其他云提供商的服务器)中,以特定的服务账号身份运行代码时,可以显式加载服务账号密钥文件。

你需要先在GCP IAM & Admin中创建一个服务账号,并为它生成一个JSON格式的密钥文件。

然后在代码中加载这个密钥文件来创建凭据对象:

from google.oauth2 import service_accountimport pandas as pdcredentials_path = "/path/to/your/service_account_key.json"credentials = service_account.Credentials.from_service_account_file(credentials_path)project_id = "your_gcp_project_id"query = "SELECT * FROM `your_dataset.your_table` LIMIT 10"df = pd.read_gbq(query, project_id=project_id, credentials=credentials)
登录后复制

这种方式虽然明确,但需要妥善保管密钥文件,避免泄露。

用户凭据(OAuth):

pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制也支持通过浏览器进行用户认证(OAuth流程),这在一些交互式会话中可能有用,但对于自动化脚本来说,通常不推荐。

权限问题:

仅仅认证通过还不够,你还需要确保你认证的身份(无论是服务账号还是用户账号)拥有足够的IAM权限来执行你想要的操作。常见的BigQuery相关权限包括:

BigQuery Job User
登录后复制登录后复制登录后复制 (
bigquery.jobs.create
登录后复制登录后复制): 运行查询、加载数据等BigQuery作业的必需权限。
BigQuery Data Viewer
登录后复制登录后复制 (
bigquery.tables.getData
登录后复制登录后复制): 从BigQuery表中读取数据的权限。
BigQuery Data Editor
登录后复制登录后复制登录后复制 (
bigquery.tables.updateData
登录后复制,
bigquery.tables.create
登录后复制,
bigquery.tables.delete
登录后复制): 修改、创建、删除BigQuery表中数据的权限。
BigQuery Data Owner
登录后复制: 对数据集拥有完全控制权。
Storage Object Viewer
登录后复制/
Storage Object Creator
登录后复制: 如果
pandas-gbq
登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制登录后复制在内部使用GCS作为临时存储来处理大文件,那么你的服务账号也需要有相应的GCS读写权限。

调试权限问题:

当遇到“Permission denied”错误时,我的排查步骤通常是:

检查认证是否成功: 确认
gcloud auth application-default login
登录后复制登录后复制是否已执行,或者
GOOGLE_APPLICATION_CREDENTIALS
登录后复制登录后复制环境变量是否正确设置,或者服务账号密钥文件路径是否正确且文件内容有效。确认
project_id
登录后复制是否正确: 有时候会不小心写错项目ID。检查服务账号/用户账号的IAM权限: 这是最常见的坑。去GCP控制台的IAM & Admin页面,找到你正在使用的服务账号或用户,查看它被授予了哪些角色。确保它有
BigQuery Job User
登录后复制登录后复制登录后复制,以及根据你的操作是读是写,相应地有
BigQuery Data Viewer
登录后复制登录后复制或
BigQuery Data Editor
登录后复制登录后复制登录后复制。如果涉及GCS,也检查GCS相关的权限。特定数据集/表的权限: 权限可能是在项目级别,也可能是在数据集或表级别。确保你的账号在目标数据集或表上有足够的权限。

说实话,权限问题就像个黑盒,直到你找到那个缺失的

bigquery.tables.getData
登录后复制登录后复制或
bigquery.jobs.create
登录后复制登录后复制权限,一切才会豁然开朗。耐心排查,通常都能解决。

以上就是Python怎样操作Google BigQuery?pandas-gbq的详细内容,更多请关注乐哥常识网其它相关文章!

Python怎样操作
为 WooCommerce 我的账户订单页面添加具有唯一 CSS 类的操作按钮
相关内容
发表评论

游客 回复需填写必要信息