Database Reference
In-Depth Information
"reason": "invalid"
}
],
"state": "DONE"
}
}
Job Statistics
The jobStatistics sub-message is the simplest part of the job object.
As you probably have guessed, jobStatistics reports various statistics
about how the job has run. For instance, it includes startTime , which is
the time in milliseconds since 1/1/1970 that the job started. (That is, the
state went from PENDING to RUNNING .) It also includes endTime , which is
the time that the job completed.
Other fields are specific to the type of job that was run, but we'll call out one
here: totalBytesProcessed . For Query jobs, this is the number of bytes
that were read from the source tables, which is a number that is directly
related to the cost you get charged to run the query. See the “BigQuery
Billing and Quotas” section later in this chapter for how the total bytes
processed number can be interpreted.
Job Access Control
To run a job, a user must be a member of the project team, in any role
(reader, editor, or owner). But what do we mean by user? A user can be
anyone with a Google account, which includes GMail accounts and Google
Apps For Your Domain accounts. A user might be a service account that
runs on behalf of an application but is considered to be a user by BigQuery
for authentication purposes. A user may or may not be an end user who
is using a web app. For example, in our sensor data application, visitors
to the website may trigger BigQuery queries to be run, but they are not
members of the project team. Instead, the application itself authenticates to
BigQuery (via the service account), which then runs the queries and displays
the results to the user.
There is one additional user requirement to run a job: The user must have
the rights to operate on the data used by the job. If you want to run a job that
creates a table, you must have write access on the table's enclosing dataset.
It doesn't matter which project that table is in—you could be running the
Search WWH ::




Custom Search