[null,null,["最后更新时间 (UTC)：2025-07-25。"],[[["\u003cp\u003eEarth Engine offers interactive and batch processing environments for different types of data computations.\u003c/p\u003e\n"],["\u003cp\u003eInteractive processing is best suited for small, quick tasks with immediate results, while batch processing handles large, complex analyses asynchronously.\u003c/p\u003e\n"],["\u003cp\u003eThe interactive environment features standard and high-volume endpoints, catering to different latency and throughput requirements.\u003c/p\u003e\n"],["\u003cp\u003eBatch processing tasks are managed via a queue and can be monitored, prioritized, and cancelled using various interfaces.\u003c/p\u003e\n"],["\u003cp\u003eTask failures are handled automatically with retries, or marked as failed if the issue is persistent.\u003c/p\u003e\n"]]],["Earth Engine offers *interactive* and *batch* environments. Interactive, or synchronous, processing is for small, quick requests, using standard or high-volume endpoints. Standard is for latency-sensitive applications, while high-volume is for automated, simple queries with higher latency and less caching. Batch, or asynchronous, processing handles large datasets via tasks, submitted to a queue with priority and time ordering. Tasks transition through states like `READY`, `RUNNING`, `COMPLETED`, or `FAILED`, with automatic retries for intermittent failures. Users can manage tasks through various interfaces.\n"],null,["# Processing Environments\n\nEarth Engine has different environments for processing data: *interactive* and\n*batch*. These two environments (or \"realms\") handle different types of queries\nand have very different performance characteristics, so it's important to\nunderstand when and how to use each.\n| **Note:** Project-level request limits apply to both interactive and batch processing requests. See the [Earth Engine quotas](/earth-engine/guides/usage) page.\n\nInteractive environment\n-----------------------\n\n| **Key Term:** *Interactive* - run computations synchronously and include the output directly in the response.\n\nAlso called the \"synchronous\" or \"online\" stack, this environment is optimized\nfor answering small requests which finish quickly (responses are limited to tens\nof megabytes of data and must finish processing within five minutes). Many\nrequests can be made in parallel up to the [quota\nlimits](/earth-engine/guides/usage).\n\n### Endpoints\n\nThe interactive environment is composed of different API endpoints: *standard*\nand *high volume*.\n\n#### Standard endpoint\n\nThe standard endpoint is appropriate for most human-driven usage, and it's what\npowers the Code Editor and Earth Engine Apps. Specifically, this endpoint is\nbest suited for latency-sensitive applications which involve a low volume of\nconcurrent, non-programmatic requests.\n\n#### High-volume endpoint\n\nThe high-volume endpoint is designed to handle a higher volume\nof requests in parallel than the standard endpoint. Key differences include:\n\n- **Higher latency**: The high-volume endpoint has higher average latency per request.\n- **Less caching**: It provides less caching of intermediate results, so complex queries may require more compute time.\n- **Best for automated, small queries**: The high-volume endpoint excels at handling many programmatic requests, but is most suitable for simple queries that don't require aggregation (like fetching tiles from prebuilt images).\n\nFor complex analyses that need efficient caching, the standard API endpoint may\nbe preferable. The high-volume endpoint is optimized for high-throughput,\nlow-computation tasks. Complex queries typically require more\n[EECU-time](https://developers.google.com/earth-engine/guides/computation_overview#eecus)\nwhen using the high-volume endpoint than they do in the regular online endpoint.\n\n##### Use of the high-volume endpoint\n\n### Python client\n\nWhen initializing the `earthengine` library, pass in an `opt_url` parameter\nand set it to\n`https://earthengine-highvolume.googleapis.com`.\nAs always, be sure to also pass in proper credentials and specify the Cloud\nproject. For example: \n\n ee.Initialize(\n credentials=credentials,\n project='my-project',\n opt_url='https://earthengine-highvolume.googleapis.com'\n )\n\n### JavaScript client\n\nWhen initializing the `earthengine` library using\n[`ee.initialize()`](/earth-engine/apidocs/ee-initialize),\npass `https://earthengine-highvolume.googleapis.com`\nfor the first parameter.\n\n### REST API\n\nDirect your REST requests to\n`https://earthengine-highvolume.googleapis.com`\n(instead of `https://earthengine.googleapis.com`,\nas shown in the\n[REST API Quickstart](/earth-engine/reference/Quickstart#accessing-and-testing-your-credentials),\nfor example).\n\nBatch environment\n-----------------\n\n| **Key Term:** *Batch* - run computations asynchronously and output results for later access (in Google Cloud Storage, the Earth Engine asset store, etc.).\n\nAlso called the \"asynchronous\" or \"offline\" stack, this environment is optimized\nfor high-latency parallel processing of large amounts of data. Requests are\nsubmitted as tasks to batch processing endpoints, usually by calling data\n[import](/earth-engine/guides/image_upload) or\n[export](/earth-engine/guides/exporting) functions (e.g., `Export.*` and\n`ee.batch.*`) from the Earth Engine client libraries. Each batch task has a\nmaximum lifetime of ten days. Each project supports [up to 3000 pending\ntasks](/earth-engine/guides/usage#task_queue_length), but each individual user\nis limited to a small number of [concurrently running\ntasks](/earth-engine/guides/usage#concurrent_batch_tasks).\n\n### Task lifecycle\n\nTasks are submitted to a queue and ordered by their priority\n(highest first) and submission time (earliest first). Tasks change from the\n`SUBMITTED` (queued) state to the `RUNNING` state when they're assigned to a\n*batch processor* . Each processor is responsible for orchestrating a varying\nnumber of *batch workers* to run the computation and produce the task's results.\nThe number of workers for a task is determined by the EE service's ability to\nparallelize the job and is not user-configurable.\n\nWhen using a Cloud project, tasks are visible to anyone with the project-level\npermission to list tasks. If the project is\n[registered](/earth-engine/guides/access#a-role-in-a-cloud-project) for paid\nEarth Engine access, tasks are organized in a project-wide queue; if the project\nis registered for unpaid (research) access, tasks are scheduled independently\nfor each individual but still visible across users of the project.\n\nTasks complete successfully when they create the necessary artifacts (Earth\nEngine assets, files in Google Cloud Storage, etc.).\n\n### Task management\n\nTasks can be viewed and cancelled using the following interfaces:\n\n- [Tasks page in the Cloud Console](https://console.cloud.google.com/earth-engine/tasks)\n - Enables task management at the Cloud project level. Going forward, this is the main user interface for managing tasks.\n- [Task Manager page](https://code.earthengine.google.com/tasks)\n - This interface shows tasks at the user and project level, and supports filtering by task name.\n- [Code Editor Tasks Tab](/earth-engine/guides/playground#tasks-tab)\n - Allows for monitoring tasks alongside a Code Editor script.\n- [`ListOperations` endpoint](/earth-engine/apidocs/ee-data-listoperations) and [`task` command](/earth-engine/guides/command_line#task)\n - Best for programmatically viewing and managing tasks.\n\n### Task failures\n\nIf a task fails for a reason which won't be fixed by retrying (e.g., the data\nare invalid), the task will be marked as `FAILED` and won't be run again.\n\nIf a task fails for a reason which could be intermittent (e.g., it timed out\nwhen running a computation), Earth Engine will automatically attempt to retry it\nand populate the `retries` field. Tasks can fail up to five times, and the final\nfailure will cause the entire task to be marked as `FAILED`.\n\n### Task ID\n\nEach task has an alphanumeric ID of the form `3DNU363IM57LNU4SDTMB6I33`. These\ncan be viewed or obtained through our [task management](#task_management)\ninterfaces. If you are starting tasks programmatically, you get the task ID from\n[`ee.data.newTaskId`](/earth-engine/apidocs/ee-data-newtaskid). When requesting\nhelp to debug an export or ingestion task, provide this task ID as a copyable\nstring (not a screenshot).\n\n### List of task states\n\nTasks can have the following `state` values:\n\n- `UNSUBMITTED`, still pending on the client\n- `READY`, queued on the server\n- `RUNNING`, currently running\n- `COMPLETED`, completed successfully\n- `FAILED`, completed unsuccessfully\n- `CANCEL_REQUESTED`, still running but has been requested to be cancelled (i.e., not a guarantee that the task will be cancelled)\n- `CANCELLED`, cancelled by the owner\n\n### Task priority\n\nTask priority is a mechanism for controlling the order of tasks in the queue.\nHigher priority tasks get scheduled before other pending tasks with lower\npriorities, regardless of their submission time. The default task priority is\n100.\n\nThe ability to set other priorities (higher or lower) on export tasks is only\navailable for users of [projects that are registered for paid Earth Engine\naccess](/earth-engine/guides/access#a-role-in-a-cloud-project). Changing the\npriority of an export task doesn't affect how it's scheduled relative to any\nimport tasks, since the two types of tasks are scheduled separately.\n\n#### Example: using task priorities\n\nConsider the following task list, where tasks 1-5 are submitted in their\nnatural order with the default priority. They run in the order they were\nsubmitted, since the priorities are all the same, and, since [two batch\nprocessing slots](/earth-engine/guides/usage#concurrent_batch_tasks) are\navailable for this project, two run concurrently (the first and second\nsubmitted). \n\n Task name State Priority\n ---------------------------------------\n MyDefaultTask5 READY 100\n MyDefaultTask4 READY 100\n MyDefaultTask3 READY 100\n MyDefaultTask2 RUNNING 100\n MyDefaultTask1 RUNNING 100\n\nSubmitting a new task, `MyHighPriorityTask1`, won't affect the running tasks: \n\n Task name State Priority\n ---------------------------------------\n MyHighPriorityTask READY 500\n MyDefaultTask5 READY 100\n MyDefaultTask4 READY 100\n MyDefaultTask3 READY 100\n MyDefaultTask2 RUNNING 100\n MyDefaultTask1 RUNNING 100\n\nAfter one of the running tasks completes, the pending task with the highest\npriority will run (in this case, our high-priority task): \n\n Task name State Priority\n -----------------------------------------\n MyHighPriorityTask RUNNING 500\n MyDefaultTask5 READY 100\n MyDefaultTask4 READY 100\n MyDefaultTask3 READY 100\n MyDefaultTask2 COMPLETED 100\n MyDefaultTask1 RUNNING 100"]]
