Publishing Reports with Looker and Data Studio

Deploying and securing Looker (opens in a new tab) models and Explores means defining business metrics once in governed code and controlling who can see and share them. Looker is a business intelligence platform where data teams describe tables, joins, and business logic in a lightweight modeling language called LookML, and Looker generates SQL from that LookML when a user opens a Look, Explore, or dashboard. This creates a fixed dependency chain: the Explore depends on model and view files, the generated SQL depends on the Explore, and results flow back from the database to the visualization.

1.1LookML Models, Views, and Explores as a Governed Layer

LookML models, views, and Explores form the governed layer that controls what users can query and how joins behave. A model file names the database connection and declares which Explores are available, while a view file defines the dimensions, measures, and field logic for a table or derived table. An Explore combines one or more views into a queryable starting point, so traffic flows from the user-selected Explore to the joined views to the database as generated SQL.

Supporting project files extend governance beyond tables and joins. Dashboard, document, data, project manifest, locale strings, Explore, and data test files store reusable content, connection settings, translations, and validation rules alongside models and views. The object browser in the Looker integrated development environment (IDE) exposes these objects and their hierarchy, which lets developers trace how a field in an Explore depends on its parent view and model.

1.2Development and Deployment With Git Version Control

Looker development with Git version control separates personal work from shared content through isolated branches and ordered promotion. A developer works in Development Mode on an isolated Git branch, and only after commit and deployment does that content become visible in Production Mode for all users. This order prevents untested LookML from changing business metrics for consumers.

A standard deployment workflow moves through ordered steps where each step depends on the prior one:

1. Set up and test Git connection: Connect the LookML project to its remote Git repository.
2. Configure version control settings: Set branch and repository options for the project.
3. Configure webhook deploy secret: Secure automated deployment signals from the repository.
4. Branch, commit, and deploy: Create a branch in Development Mode, commit changes, and deploy the branch to Production Mode.

Teams can start a model by generating a basic LookML model automatically, by creating a new project and configuring the model manually, or by building with the visual modeling canvas that creates LookML through drag-and-drop. Looker Blocks are prebuilt LookML data models maintained by the domain team that knows the underlying data model, and consumers incorporate those Blocks directly into their dashboards.

1.3Secure Database Connections and SQL Development

A secure Looker database connection defines the trust boundary between Looker and the warehouse, so the connection must be secured before any model is published. Secure access starts with encrypted connections in transit, a tunnel server for any Secure Shell (SSH) tunnel connection, and an allow list that permits only Google-specific internet protocol (IP) addresses for external access. The database grant for the Looker connection follows the principle of least privilege, and Google is not given write access or administrative access to customer databases.

SQL Runner is the Looker tool for issuing SQL directly against that connection to debug queries, inspect database functions, and build derived tables. Data flows from SQL Runner to the database and back as raw results, separate from the governed path where data flows from an Explore through generated SQL. Developers use SQL Runner to validate logic first, then encode the validated logic into LookML views and Explores so consumers inherit the same joins and calculations.

1.4Access Control With User Attributes and Model Security

Looker access control combines identity authentication with data-level filtering enforced in the model. The access_filter parameter works together with user attributes to apply row-level, column-level, or field-level security by user or user group, so two users querying the same Explore receive different rows based on their attribute values. Dataset security applied in the Looker model provides the additional model-level boundary that limits which Explores and fields are visible at all.

Operational hardening reduces who can bypass those controls and how often controls are reviewed:

• Limit administrator, developer, and SQL Runner privileges to the minimum necessary users.
• Authenticate users with two-factor authentication or Security Assertion Markup Language (SAML)-supported single sign-on (SSO).
• Restrict the login_special_email permission to a maximum of two users when SSO is used.
• Prevent sharing with excluded third-party services and prevent exposure to support or professional services teams without proper controls.
• Audit users, groups, permissions, roles, application programming interface (API) keys, public links, and sharing settings at least quarterly.

1.5Curated Distribution With Blocks, Action Hub, and Scheduled Delivery

Curated distribution moves governed results from Looker to consumers through dashboards, scheduled deliveries, and built-in destinations. Looker Action Hub provides a secure cloud environment for sending data from dashboards directly into built-in destinations, which keeps the transfer inside a managed path instead of an insecure API integration. Scheduled email delivery must not attach sensitive content directly; Looker is configured to redirect email recipients to the Looker instance where recipients must log in to access the content.

Secure sharing also limits persistence and third-party exposure around delivery. Cache query results are stored for only the minimum time necessary for the dataset and use case, and public links are restricted by policy. Sensitive data is not shared with a third party unless a business associate agreement (BAA) is in place, is never sent through technical support chat, and any permitted use of aggregated sensitive data by a third party is recorded in maintained logs.

Automating and operationalizing reporting pipelines means using versioned, scheduled orchestration to refresh datasets and publish reports without manual steps. On Google Cloud, pipelines run as part of an enterprise data management and analytics platform (opens in a new tab) where Cloud Build builds and promotes reporting templates, Managed Service for Apache Airflow and Cloud Dataflow orchestrate movement and transformation, and Cloud Scheduler or Cloud Run functions trigger batch refreshes on a schedule or event. Refreshed data flows from source systems through the orchestrated pipeline to destinations such as BigQuery tables, Cloud Storage buckets, or Drive folders where visualizations and reports read them.

2.1Automated Dataset Refresh and Report Delivery

Automated dataset refresh uses an artifact pipeline and an orchestrator that work together to keep reports current. The artifact pipeline builds all necessary resources for ingestion and moves the resources to the location where services can access them, and the artifact pipeline creates the container artifacts that the orchestrator uses. The data ingestion process then uses Managed Airflow and Dataflow to orchestrate the movement and transformation of data within the data domain.

A production refresh follows an ordered promotion path from commit to execution:

1. Git commit triggers build: A Git Commit command triggers a Cloud Build pipeline that validates code and configuration.
2. Cloud Build stages artifacts: Cloud Build copies the template and any associated configuration files to Cloud Storage.
3. Continuous delivery promotes artifacts: Artifacts from a passing build are copied to preproduction for end-to-end tests, and the production environment is updated only after those tests pass.
4. Orchestrator launches execution: Managed Service for Apache Airflow runs batch jobs within a workflow, Cloud Scheduler schedules batch jobs, or an event invokes a function that launches a new Dataflow job.
5. Data lands for reporting: Transformed data flows from the Dataflow job to the reporting dataset in BigQuery or to Cloud Storage for CSV and Sheets-based delivery.

Batch pipelines support direct continuous deployment as a new Dataflow job, while streaming pipelines are more complex because the team must decide how to replace or update an existing streaming pipeline. If a streaming pipeline cannot be updated in place, the team coordinates multiple Dataflow jobs in parallel to minimize business disruption during the cutover. The CI/CD pipeline itself depends on proper identities and roles, because the pipeline needs access to the source code repository and to external services including Google Cloud to build, test, deploy, and run Dataflow jobs and Cloud Run functions.

2.2Version Control, CI/CD, and Lifecycle Management for Reporting Assets

Version control, CI/CD, and lifecycle management for reporting assets keep every report, template, and dataset definition repeatable and auditable. Developers merge code frequently into a shared Git repository, and test automation runs the test suite on each commit in conjunction with a build tool like Maven to provide rapid feedback and prevent regressions. Code that passes unit tests and integration tests is packaged into deployment artifacts from a passing build, and those artifacts are stored in a bucket hosted in the deployment environment project such as preproduction or production.

The deployment artifacts created from a passing build vary by how pipelines are launched:

• Self-executing JAR: Apache Beam Java SDK pipeline code packaged into a self-executing JAR file stored in the environment bucket.
• Classic Templates JSON template: A JSON template file that defines templated execution for reuse across environments.
• Template dependencies: The JAR file for the pipeline plus an optional metadata template used with Classic Templates.

Promotion is hardened through provenance and storage controls rather than manual changes. Teams enforce provenance with the Supply-chain Levels for Software Artifacts (SLSA) framework and Binary Authorization, verify that a specific build system created a container image, and allow deployment only when images pass vulnerability and promotion checks. For stored reports, Cloud Storage lifecycle controls manage retention and deletion, regional buckets replicate synchronously across zones while dual-region and multi-region buckets replicate asynchronously for higher availability, and buckets used for report delivery must not retain a retention policy that would block updates until the retention period passes.

Report delivery destinations differ by format and sharing model, so the destination determines the access setup:

If Uniform Bucket Level Access is used, Domain Restricted Sharing can prevent adding the required principals to the bucket project and Cross Project Service Account policy can prevent adding the service account. The supported workaround is to request Google default handling for the folder or project holding the bucket, or to create an internal group containing the principals and grant that group the required permissions.

2.3Cost, Performance, and Reliability Monitoring for Visualizations

Cost, performance, and reliability monitoring for visualizations uses Cloud Logging, Cloud Monitoring, and Cloud Audit Logs to observe pipeline health and publishing activity. Cloud Logging provides visibility into system activity and helps enable detection of anomalies, while Cloud Monitoring tracks key signals and events that can identify suspicious activity or performance degradation. Dashboards in the Google Cloud console provide details about sources, builds, artifacts, deployments, and runtimes, including build provenance and Software Bill of Materials (SBOM) dependency lists.

Audit coverage separates control-plane changes from data reads, which matters for governed reporting. Admin Activity audit logs are enabled by default for all Google Cloud services used in the architecture and record API calls that modify configuration or metadata. Data Access audit logs are enabled by default for BigQuery and can be enabled for other services to track reads of configuration, metadata, or user-provided resource data, and Cloud Logging can be regionalized to store log data in a specified region for residency needs. For pipeline reliability, BigQuery stores loaded data synchronously in two zones within the specified region, Cloud Run functions run regionally with traffic load-balanced across zones and continue through a zone outage but stop during a region outage, and Pub/Sub publishers use flow control and retry settings to absorb transient spikes in message traffic without failing refresh jobs.

Configuring and managing Data Studio (opens in a new tab) for enterprise reporting means connecting governed data sources to reusable dashboards and controlling access, performance, and distribution. Data Studio is a self-service business intelligence platform for building and consuming visualizations, dashboards, and reports on Google Cloud. Data Studio connects directly to Google Cloud Platform data such as BigQuery tables, views, and custom queries, Apigee analytics and monetization data, and logs exported to BigQuery from services like reCAPTCHA and Backup and DR. A premium version, Data Studio Pro, adds enterprise capabilities including permissions management with Identity and Access Management (IAM), team workspaces for collaboration, a mobile app, and technical support.

3.1Connecting Data Studio to BigQuery and Other GCP Sources

Connecting Data Studio to BigQuery and other GCP sources means authorizing Data Studio and pointing it at a project-scoped dataset, table, view, or custom query. A BigQuery table stores data in rows and columns, while a view is a virtual table defined by a SQL query that runs dynamically, and a custom query lets analysts modify data or select only a subset of fields before visualizing. Connecting to a table or view requires a BigQuery project, a dataset that organizes and controls access to tables, and a specific table or view, including support for date-partitioned and multi-day tables.

The BigQuery connector (opens in a new tab) fetches data through an ordered workflow from report creation to canvas placement:

1. Create report: Sign in to Data Studio, click Create, select Report, and open the Add data to report panel.
2. Select connector: Select the BigQuery connector to create a new embedded data source, or open the My data sources tab to reuse a data source that was created before or shared with you.
3. Configure access: Choose connection parameters for a table or view or enter custom SQL, selecting separate projects for data access and billing when needed.
4. Add to canvas: Click Add, and Data Studio places a table connected to the data source on the report canvas.

Projects organize Google Cloud resources and determine where query costs are billed when reports exceed BigQuery free limits. The connector offers Recent Projects, My Projects, and Shared Projects options, so teams can query data in one project while billing costs to a different project. Access requires a Google Cloud project with an associated billing account, because BigQuery is a paid platform and Data Studio queries can incur query processing or storage costs.

Other GCP integrations follow the same pattern of authorizing Data Studio and pointing it at a project-scoped dataset. For Apigee, the flow authorizes Data Studio, enters the Apigee organization ID, which is the same as the Google Cloud project ID, and clicks Connect to expose analytics fields for reporting. For reCAPTCHA, platform logs for assessment operations are enabled, exported through a logging sink to a new partitioned BigQuery dataset, and then bound to the reCAPTCHA Data Studio template. For Backup and DR, logs routed to BigQuery are visualized through a template URL that passes project ID and dataset ID for each source, such as Job Details, Protected Data Resource, Backup Jobs Summary, and Daily Schedule Compliance.

3.2Managing Access with IAM Roles and Credential Models

Managing access with IAM roles and credential models determines whose permissions are used when a Data Studio chart queries BigQuery. To query BigQuery data, an identity needs BigQuery Data Viewer (roles/bigquery.dataViewer) to read data and metadata and BigQuery Job User (roles/bigquery.jobUser) to run query jobs in the billing project. To connect Apigee data, the connector requires roles/apigee.analyticsEditor, and to set up reCAPTCHA dashboards, setup requires reCAPTCHA Enterprise Admin (roles/recaptchaenterprise.admin).

Who must hold the BigQuery roles depends on the data credentials mode chosen for the data source:

When credentials are set to the current user, that user is the datasource credential owner and sees a BigQuery icon on dashboard elements that links directly to Job details in BigQuery. Only the report owner can view data by default unless others are granted permission, and deleting the Google Cloud project prevents Data Studio from querying because the data source is associated with that project.

3.3Governing Enterprise Deployments with Controls and Audit

Governing enterprise deployments with controls and audit defines network boundaries, residency limits, and audit trails around BigQuery execution. If an organization uses VPC Service Controls, the Data Studio service account must have egress and ingress rules that allow bigquery.googleapis.com and bigquerydatatransfer.googleapis.com. Data Studio Integration for Apigee (opens in a new tab) is currently not supported for organizations with data residency enabled, so residency-constrained Apigee organizations must keep analytics in the Apigee UI.

Every Data Studio query to BigQuery can be audited through the INFORMATION_SCHEMA.JOBS view using labels attached to each job. Data Studio labels each job with requestor set to looker_studio, plus looker_studio_report_id and looker_studio_datasource_id that match the IDs at the end of Data Studio report and data source URLs. Administrators query jobs from the last 7 days by filtering on the requestor label to list report and data source URLs, or filter further by a specific report ID and data source ID to list creation time and job ID for jobs produced by that report.

3.4Optimizing Performance and Handling Built-In Metrics

Optimizing performance and handling built-in metrics balances faster dashboards with row limits and automatic fields. BigQuery BI Engine improves Data Studio report performance while reducing compute costs, and teams reserve BI Engine capacity for dashboards that need faster response. Exploring query results from the BigQuery console creates dashboards backed by temporary tables stored for up to 24 hours, and charts built this way can visualize a maximum of 5,000 rows. In full Data Studio reports backed by BigQuery datasets, up to 2 million rows can be viewed and up to 750,000 rows can be exported from a chart, and reports refresh automatically at intervals that can be changed through data freshness settings.

The BigQuery connector also provides automatic fields that simplify enterprise metrics. Every BigQuery data source includes a Record Count metric that counts records or verifies total rows returned by a query. When Data Studio encounters a table generated by Google Analytics BigQuery Export, it shows a Google Analytics icon and automatically creates many standard Google Analytics metrics as calculated fields. Data Studio can display BigQuery GEOGRAPHY polygon data with Google Maps, which supports geospatial boundaries such as census tracts, and a dedicated troubleshooting guide covers connector errors and limitations when charts fail to load.

3.5Sharing, Publishing, and Reusing Reports

Sharing, publishing, and reusing reports controls whether recipients can view or edit a report for internal and external stakeholders. Sharing opens the report, selects Share, enters email or Google Group addresses, chooses view or edit access, and sends the invitation. Prebuilt templates accelerate reuse: the Apigee API Platform template, the reCAPTCHA dashboard template (opens in a new tab) for threats like scraping, account takeovers, and payment fraud, and the Backup and DR template for job, compliance, and protected-resource reports all provide customizable charts that can be copied from view-only access.

Published reports support distribution beyond interactive viewing. Dashboards can be shared by email, exported as CSV or individual sheets, downloaded as PDF and PNG files, and scheduled for automatic delivery over email. For advanced use cases such as scheduling, emailing, customizing, and sharing, teams make their own copy with Edit and share and then manage data freshness for refresh cadence. Data Studio is available at no charge for viewing and creating reports, while BigQuery access through Data Studio is billed with no charge for the first 1 TiB processed per month.

Key Facts

• Looker generates SQL from LookML models, views, and Explores, so traffic flows from the user-selected Explore to the joined views to the database as generated SQL.
• Looker development uses Development Mode on an isolated Git branch and promotes to Production Mode only after commit and deployment.
• Looker access_filter with user attributes enforces row-level, column-level, or field-level security so different users querying the same Explore receive different rows.
• Data Studio Owner's credentials require BigQuery roles only for the data source owner, while Viewer's credentials require every viewer to hold BigQuery Data Viewer and BigQuery Job User.
• Data Studio labels every BigQuery job with requestor set to looker_studio plus report and data source IDs auditable for the last 7 days through INFORMATION_SCHEMA.JOBS.