[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# Jobs and job triggers\n\nA *job* is an action that Sensitive Data Protection runs to either scan content for\nsensitive data or calculate the risk of re-identification.\nSensitive Data Protection creates and runs a job resource whenever you tell it to\ninspect your data.\n\nThere are currently two types of Sensitive Data Protection jobs:\n\n- *Inspection jobs* inspect your content for sensitive data according to your criteria and generate summary reports of where and what type of sensitive data exists.\n- *Risk analysis jobs* analyze de-identified data and return metrics about the likelihood that the data can be re-identified.\n\nYou can schedule when Sensitive Data Protection runs jobs by creating *job\ntriggers*. A job trigger is an event that automates the creation of\nSensitive Data Protection jobs to scan Google Cloud storage repositories,\nincluding Cloud Storage buckets, BigQuery tables, and\nDatastore kinds.\n\nJob triggers enable you to schedule scan jobs by setting intervals at which\neach trigger goes off. They can be configured to look for new findings since\nthe last scan run to help monitor changes or additions to content, or to\ngenerate up-to-date findings reports. Scheduled triggers run on an interval\nthat you set, from 1 day to 60 days.\n\n\u003cbr /\u003e\n\n| **Note:** Prematurely canceling an operation midway through a job still incurs costs for the portion of the job that was completed. For more information about billing, see [Sensitive Data Protection pricing](https://cloud.google.com/sensitive-data-protection/pricing).\n\n\u003cbr /\u003e\n\nNext steps\n----------\n\nMore information about how to create, edit, and run jobs and job triggers in\nthe following topics:\n\n- [Creating Sensitive Data Protection inspection jobs and job\n triggers](/sensitive-data-protection/docs/creating-job-triggers)\n- [Measuring re-identification and disclosure risk](/sensitive-data-protection/docs/compute-risk-analysis) (Covers risk analysis jobs.)\n\nIn addition, the following quickstart is available:\n\n- [Quickstart creating a Sensitive Data Protection job\n trigger](/sensitive-data-protection/docs/quickstart-create-job-trigger)\n\nThe `JobTrigger` object\n-----------------------\n\nA job trigger is represented in the DLP API by the\n[`JobTrigger`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers)\nobject.\n\n### Job trigger configuration fields\n\nEach `JobTrigger` contains several configuration fields, including:\n\n- The trigger's name and display name, and a description.\n- A collection of [`Trigger`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers#trigger) objects, each of which contains a [`Schedule`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers#schedule) object, which defines the scan recurrence in seconds.\n- An [`InspectJobConfig`](/sensitive-data-protection/docs/reference/rest/v2/InspectJobConfig) object, which contains the configuration information for the triggered job.\n- A [`Status`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers#status) enumeration, which indicates whether the trigger is currently active.\n- Timestamp fields representing creation, update, and last run times.\n- A collection of [`Error`](/sensitive-data-protection/docs/reference/rest/v2/Error) objects, if any were encountered when the trigger was activated.\n\n### Job trigger methods\n\nEach `JobTrigger` object also includes several built-in methods. Using these\nmethods you can:\n\n- Create a new job trigger: [`projects.jobTriggers.create`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers/create)\n- Update an existing job trigger: [`projects.jobTriggers.patch`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers/patch)\n- Delete an existing job trigger: [`projects.jobTriggers.delete`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers/delete)\n- Retrieve an existing job trigger, including its configuration and status: [`projects.jobTriggers.get`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers/get)\n- List all existing job triggers: [`projects.jobTriggers.list`](/sensitive-data-protection/docs/reference/rest/v2/projects.jobTriggers/list)\n\nJob latency\n-----------\n\nThere are no service level objectives (SLO) guaranteed for jobs and job\ntriggers. Latency is affected by several factors, including the amount of data\nto scan, the storage repository being scanned, the type and number of infoTypes\nyou are scanning for, the region where the job is processed, and the computing\nresources available in that region. Therefore, the latency of inspection jobs\ncan't be determined in advance.\n\nTo help reduce job latency, you can try the following:\n\n- If [sampling](/sensitive-data-protection/docs/inspecting-storage#sampling) is available for your job or job trigger, enable it.\n- Avoid enabling infoTypes that you don't need. Although the following are\n useful in certain scenarios, these infoTypes can make requests run much more\n slowly than requests that don't include them:\n\n - `PERSON_NAME`\n - `FEMALE_NAME`\n - `MALE_NAME`\n - `FIRST_NAME`\n - `LAST_NAME`\n - `DATE_OF_BIRTH`\n - `LOCATION`\n - `STREET_ADDRESS`\n - `ORGANIZATION_NAME`\n- Always specify infoTypes explicitly. Do not use an empty infoTypes list.\n\n- If possible, use a different processing region.\n\nIf you're still having latency issues with jobs after trying these techniques,\nconsider using\n[`content.inspect`](/sensitive-data-protection/docs/reference/rest/v2/projects.content/inspect) or\n[`content.deidentify`](/sensitive-data-protection/docs/reference/rest/v2/projects.content/deidentify)\nrequests instead of jobs. These methods are covered under the Service Level\nAgreement. For more information, see [Sensitive Data Protection Service Level\nAgreement](/sensitive-data-protection/sla-20201006).\n\nLimit scans to only new content\n-------------------------------\n\nYou can configure your job trigger to automatically set the timespan date for\nfiles stored in [Cloud Storage](/storage) or\n[BigQuery](/bigquery). When you set the\n[`TimespanConfig`](/sensitive-data-protection/docs/reference/rest/v2/InspectJobConfig#timespanconfig)\nobject to auto-populate, Sensitive Data Protection only scans data that was\nadded or modified since the trigger last ran: \n\n ...\n timespan_config {\n enable_auto_population_of_timespan_config: true\n }\n ...\n\nFor BigQuery inspection, only rows that are at least three hours old\nare included in the scan. See the [known\nissue](/sensitive-data-protection/docs/known-issues#bq-timespan) related to this\noperation.\n\nTrigger jobs at file upload\n---------------------------\n\nIn addition to the support for job triggers---which is built into\nSensitive Data Protection---Google Cloud also has a variety of other\ncomponents that you can use to integrate or trigger Sensitive Data Protection\njobs. For example, you can use [Cloud Run functions](/functions) to\ntrigger a Sensitive Data Protection scan every time a file is uploaded to\nCloud Storage.\n\nFor information about how to set up this operation, see [Automating the\nclassification of data uploaded to\nCloud Storage](/sensitive-data-protection/docs/automating-classification-of-data-uploaded-to-cloud-storage)."]]