GEE非商业版配额制落地：4月27日前必须完成的申请与调整

你打开 Google Earth Engine 代码编辑器右上角或者 Cloud Console 的配额页面多半已经挂了一条提醒非商业版正式引入计算配额制度分区申请需要在 4 月 27 日前完成。第一眼看到时我以为是普通的产品更新仔细读完才发现这次是动真格的——以前是“注册就能跑跑到顶再说”现在是“先申请配额、再按档运行”整个使用节奏都得跟着调整。这篇文章把我自己调研、实测、跟几位做遥感项目的开发者讨论下来的结论整理一遍。内容包括这次配额制度到底改了哪些底层逻辑、分级档位怎么选、4 月 27 日前必须完成的申请动作、配额下来之后工作流要怎么改以及我踩过的一轮坑。无论你是学生、科研人员还是偶尔用 GEE 做点数据可视化的开发者这篇文章都能帮你少走弯路。1. 配额制的底层逻辑变了从“抢位置”变成“按月分工位”1.1 过去 GEE 怎么分配算力现在改成什么Google Earth Engine 的实际算力分配一直有一套后台机制在管。早期开发者注册之后基本是共享一个大池子你提交一个任务系统根据当前集群负载、任务优先级和资源余量动态调度。高峰期任务排队低峰期几乎秒跑大家感知到的只是一个“够用但不保证”的资源池。这次非商业版的调整相当于把这个隐形的共享池改成显性的分级配额。每个账号、每个云项目会有对应的容量档位按月度计算额度划给你。你在代码编辑器里跑分析、跑Export、反复getInfo都会计入这个额度的消耗。超出部分要么排队等待要么需要申请更高档位不再是无感动态抢占。用个生活类比以前 GEE 是个公共自习室谁能占到座位谁就学高峰期全靠抢延迟高低看运气。现在改成预约制工位按月给你分配固定的使用时长和桌面你要在这个额度内安排自己的学习计划。好处是可预期坏处是过去那种“随便戳一戳、反正不要钱”的随意感没有了。1.2 这次非商业版调整真正影响到的三类人第一类是个人学习和 Demo 玩家。没事跑个 NDVI、画个年度水体变化图单次计算量不大总体配额消耗很低这类用户受冲击最小基本感知不到变化。第二类是科研人员和高校课题组。他们往往要跑整个省甚至全国的时序影像一跑就是几百上千景批量导出预处理产品、逐年的时间序列分析、多源数据融合这类工作负载直接面对配额上限。不夸张地说几个大任务如果放同一天跑很容易把月度容量吃掉很大一块。第三类是给企业做遥感咨询、数据产品交付的开发者。严格来说这些人已经不算典型的“非商业版”用户因为你把结果卖给了客户使用目的已经超出非商业条款。GEE 这次把非商业和商业边界重新强调等于逼着这部分人重新评估自己的项目归属。别心存侥幸我认识的同行里已经有人的商业项目在迁移到商业条款后才恢复正常配额。这次调整最需要留意的不是“限制变多了”而是“资源分配模型变了”过去你不需要预估自己一个月要跑多少现在申请的时候就要说清楚。那些习惯粗放使用的人接下来会明显难受。2. 分级配额的四档怎么选拿你的典型任务对号入座2.1 四档容量对应什么任务体量官方配额申请页面会列出几个档位不同地区和账号状态看到的名称、容量可能有差异但大致会覆盖下面四种量级轻量档适合教学演示、小型区域单期影像分类、偶尔导出几景 Landsat 或 Sentinel-2 图。典型用户是本科生课程作业、兴趣开发者。科研档适合省级/洲级尺度的年度时序分析、定期更新植被指数、每月的批量影像导出。典型用户是高校课题组、非营利研究机构。高容量档适合全国尺度拼接、多源遥感数据Landsat Sentinel 气象再分析的融合处理、每天运行大量导出任务的团队。定制档适合数据服务商、商业级产品研发往往对应商业条款配额和计费方式单独谈。注意这里说的“档位”是参考定位不是替官方下结论。你在申请页面上会看到明确的每月计算容量数值通常以 Earth Engine Units也就是 EEU 为计量单位不同档位的配额量级可能从三位数到四位数不等。不要只盯数字要拿数字倒推你的任务负载匹配度才是核心。2.2 选档决策表三种典型任务怎么落位我把自己的实测经验和常见工作任务整理成下面的对照表你直接对号入座典型工作负载建议档位理由偶尔看影像、画一个区域的分类图、课程作业轻量档单次计算量小总配额消耗低完全够用每月分析一两个省的 NDVI 时序、定期导出几十景影像科研档需要一定的并发余量但不需要全国级吞吐全国尺度的土地覆盖分类、时序变化检测、多数据源融合高容量档任务量大且长尾导出对容量消耗明显面向 B 端客户的影像服务、规模化数据交付定制档/商业条款非商业版按条款本来就覆盖不了这种用途2.3 选大档的隐性成本很多人第一反应是“我要选最大的档免得以后不够用”。我劝你先冷静。选大档的确能在短时间内给你更多容量但随之而来的问题是审批关注度更高可能被要求补充更多用途说明如果关联的是商业项目可能直接触发商业计费条款还有你真拿高容量跑轻量任务等于浪费自己的审批信用。更合理的思路先按你过去 30 天的真实用量估算取 1.5 到 2 倍作为缓冲然后申报对应档位。等跑一两个月后台数据会让你对准确用量有更清楚的认识再考虑要不要升级。3. 4 月 27 日前按顺序做完这四件事申请不会翻车3.1 第一步确认身份你是个人学习还是机构科研申请配额前先想清楚你当前使用 GEE 的目的是什么。个人学习用途走非商业免费申请流程高校科研、非营利组织也要明确是“非商业研究”且不能把结果直接变成商业收入。这个身份判断不只影响你填表还会影响后续条款合规。我有一个很实际的建议先把你自己最典型的两个工作负载写下来例如“每月用 Landsat 8 做某保护区植被覆盖度评估导出 20 景影像”或“每周用 Sentinel-2 做城市不透水面变化监测”。写下来之后你后面填申请时会顺畅很多因为很多字段你直接抄自己写的就行。3.2 第二步在 GEE 和 Cloud Console 里完成项目绑定现在 GEE 使用 Cloud 项目作为资源归属单位。你需要在代码编辑器右上角查看当前关联的云项目如果没有创建一个空的 Cloud Project不产生费用但要保证它启用 Earth Engine API。然后进入 Cloud Console在配额页面搜索 Earth Engine 相关配额查看你当前项目的配额设置。这一步经常卡住的点在于你的 GEE 账号和 Cloud 项目不在同一个组织下或者项目权限不够。我踩过的坑是用个人号给一个非管理员项目申请页面直接提示无权限换项目管理员身份才正常显示申请入口。3.3 第三步把申请单当立项书来写分级申请里最花时间的不是点按钮而是用途描述。我见过太多人只填一句“used for research”这种申请被退回或者被延迟审批的概率很高。你要把下面几项写清楚具体研究/工作背景是哪个领域、哪个区域的研究为什么需要 GEE主要数据集Landsat、Sentinel-2、MOD13Q1 等数据量大就如实写处理流程例如“对 2015—2025 年逐月影像做时序分解计算突变点”预估月消耗例如“每月导出 200GB 预处理数据运行 30—50 个批处理任务”。申请提交流程走完后官方会给你一个处理单号通常在几天内给出结果。我见过最快一小时通过的也见过两周才批下来的。临近截止日大家都在赶着提交审批速度可能会变慢所以不要拖到最后两天。3.4 第四步备份资产与脚本给最重的任务挪个窝申请期间你不能保证配额立即生效所以不要把关键任务压在配额审批上。要把当前用得最勤的脚本复制一份到本地或 GitHub把常用的 FeatureCollection、训练样本等 Asset 导出备份避免云项目变更导致数据访问断档如果已经预估到某个大任务跑不动可以先把它拆成小区域等配额确认后再恢复完整运行。这一步的意义是防止“等待期手痒嘴急”你申请一提交旧的不限流模式随时可能切换中间哪怕有一天配额没生效你的批处理任务也可能大面积失败。备份是廉价的保险别省。4. 配额下来后我的导出与调度流程改了这三处4.1 从“一次全跑”改成“分块排队”过去我导出全国尺度的产品习惯一次性把几百个 Task 全部提交让后端自己排队。配额时代这个做法非常危险大批 Task 并发启动会在短时间内消耗大量容量额度一旦中间有 Task 因超时或数据问题失败你等于白烧了那段计算量。现在我的做法是把全国范围按省或按经纬度格网拆分每次同时提交 5 到 10 个导出任务完成一批再放下一批。实测下来总耗时不一定变长因为任务失败率显著下降重跑成本也低得多。你可以在代码里做一个简单的任务队列控制循环提交 Task 前先查询已有任务的state等完成数量降下来再补充新任务。4.2 导出路径从 Drive 改成云端对象存储再拉回本地以前导出到 Google Drive 很方便现在我开始优先用对象存储。原因很简单对象存储更适合大批量文件而且能用标准工具批量拉取到本地不依赖 Drive 的容量限制。流程变成Export.image.toCloudStorage把影像写到存储桶然后在本地用gsutil同步或者写一个简单的同步脚本定时拉取。这个改法对配额消耗也有好处同样的计算量导出到对象存储比 Drive 更稳定失败后的重试成本更低不会因为存储错误反复重算。如果你只用少量数据继续 Drive 问题不大但涉及几十上百个文件时对象存储真的省心很多。4.3 把轻量统计从云端getInfo挪到本地 Python很多开发者习惯在代码编辑器里跑一句image.reduceRegion(...).getInfo()立刻拿均值、面积等统计结果。这种交互式用法很方便但也会产生真实计算消耗。配额制度下我养成了另一个习惯轻量统计尽量在本地做。具体来说先用geemap或xarray在 Python 环境读取影像数据子集再用本地的 pandas、numpy 做统计。只有必须用 GEE 全分辨率算的时候我才回到云端。这样做的收益非常明显本地循环不占 GEE 配额还能用上更灵活的数据处理库。哪怕你只减少一半的无谓getInfo一个月的额度消耗都能明显降下来。5. 配额时代最容易踩的坑我已经替你踩过一轮5.1 项目没绑定云服务申请直接卡住第一次提交配额申请我卡在“No eligible Cloud Project”这个提示上。原因是我在 GEE 代码编辑器里的账号没有在 Cloud Console 里创建或绑定项目。这个绑定不是可选项是硬前置。解决办法先创建 Cloud 项目启用 Earth Engine API然后在 GEE 里把“当前项目”切换过去。整个过程不涉及付费但要用有权限的账号操作。如果你有多个项目确定哪个是你 GEE 脚本实际跑的项目。配额是挂在项目上的不是挂在个人账号上的。很多人申请完才发现自己脚本跑在 A 项目配额却申请在 B 项目白忙一场。5.2 大批并发导出任务失败配额照样被扣这是最让我肉疼的坑。之前跑一个全国拼接任务一次性提交 80 个 Export其中十几个因内存溢出失败。事后看配额明细失败任务同样消耗了计算额度。我的经验是宁可把任务拆得更细也不要盲目并发。一个任务失败后它的中间消耗是沉没成本小任务重跑便宜大任务重跑痛。另外注意bestEffort: true这个参数。它听起来像是“尽力而为”实际效果是放宽像素限制、可能选用更高缩放级别计算量可能翻倍。用在局部小区域无所谓用在大型导出任务上配额烧得飞快。我现在的原则是大任务显式设置maxPixels和scale不用bestEffort。5.3 循环里反复getInfo额度烧得最快有段时间我写了一个循环遍历 12 个月的影像每个月都调用getInfo拿面积最后拼成趋势表。这个代码逻辑没错但配额制度下效率极低每次getInfo都是一次完整的计算往返。12 次循环吃掉的计算量可以跑完一整景分类图。解决办法有两个把统计逻辑放进一个map式的聚合里或者直接导出一个小的属性表让 GEE 直接返回结构化结果。如果只是交互式看看用evaluate回调也比getInfo更合理至少不会阻塞整个线程。这个习惯改过来配额消耗能低 30% 以上。5.4 公共数据集重复计算十遍另一个隐蔽的浪费同一个公共数据集每次用临时影像重新加载并计算哪怕结果完全一样。比如你反复计算同一个区域的月度降水累计每次从原始 Climate 数据开始算配额就等于白烧。正确做法把中间产品保存为 Asset。像“预处理后的 NDVI 时序”“掩膜后的水体产品”这类会被反复引用的结果跑一次导出成 Asset后续任务直接引用。前期多花一次导出时间长期省的是成倍的重复计算量。这条规则在配额制度之前只是“建议”现在已经是“刚需”了。6. 最后说点个人经验申请单写得像样比等配额更快6.1 别一上来就申高容量在配额申请这件事上我见过太多人想一步到位结果提交后迟迟没有回音。后来我总结经验第一档申请你去写“我就跑个实验”审批看重的是真实用途高容量申请对应的是高使用预期材料不够扎实很容易被搁置。与其申高档迟迟不批不如先按实际用量申一个中等档位跑顺了再续。6.2 给 4 月 27 日之后的次日留点缓冲截止日期压着大家的心但我建议你在 4 月 27 日前就把系统切到配额状态不要等到最后一刻。这样如果申请被退回或需要补材料你还有两三天时间补救。另外配额生效的初期后台数据可能和你预估的不一致留出缓冲期来校准自己的任务容量预估远比当天临时抱佛脚强。6.3 一个可以长期受益的工作习惯最后分享一个我在配额制度后养成的习惯每周末花五分钟看一眼后台的当月容量消耗和任务成功/失败比例。如果发现失败率高就再拆细任务如果某个月的容量快见底就主动把不紧急的批量任务挪到下个月。这件事听起来很简单但大多数开发者真的不会去做。配额制度不是要限制谁而是逼着我们重新理解“算力是一种资源”这个事实——早一点掌握它的节奏后续就能少很多被动。