Storing the data · Topic 3 of 4

Managing a Data Lake with Cloud Storage and BigLake

Run a data lake on Cloud Storage: zones, discovery, BigLake access control, cost controls, processing with Dataproc, Dataflow and BigQuery, monitoring.

  • 5 min
  • Includes a diagram
In a nutshell
  • Organize the lake into raw, curated and consumption zones.
  • Dataplex discovery publishes Cloud Storage data as queryable tables in the catalog.
  • BigLake delegates file access to a connection, enabling row and column security.

What it is

A data lake keeps large volumes of raw and refined data as files in Cloud Storage, usually in open formats, so many engines can use it. Managing it means making the data discoverable, controlling who can read what, keeping costs in check, processing it efficiently and monitoring its health.

SourcesRaw zoneas deliveredCurated zoneParquet, partitionedBigLake tablesgoverned accessEnginesBigQuery, Spark, Dataflow

How it works

Organizing the lake

Data lake zones: sources land files in a raw zone kept as received, the data is cleaned and typed into a curated zone of Parquet, Avro or Iceberg files, and aggregates and data products in a consumption zone are shared with analysts, BI and other domains through BigLake tables.

ZoneContentsTypical rules
Raw (landing)Files exactly as receivedImmutable, restricted access, colder storage after a period
Curated (refined)Cleaned, typed, deduplicated data in Parquet, Avro or IcebergPartitioned by date folders, broad read access through tables
ConsumptionAggregates and data productsShared with analysts and other domains

Dataplex can organize buckets and datasets into lakes and zones so that metadata, discovery and data quality work across them.

Configuring data discovery

Dataplex discovery scans Cloud Storage data, infers schemas and partitions, and publishes tables that can be queried from BigQuery. The tables appear in the catalog with their technical metadata, where teams add owners, descriptions and glossary terms.

Configuring access

ApproachEffect
IAM on buckets (uniform bucket-level access)All-or-nothing access to files; users can bypass table rules by reading files directly
BigLake tables with a connectionUsers get table permissions only; the connection's service account reads the files
Row access policies and policy tags on BigLake tablesRow and column security over files, enforced for BigQuery and for Spark through the BigQuery Storage Read API

With BigLake, analysts need no access to the bucket. That access delegation is what makes fine-grained security over a lake possible.

CREATE EXTERNAL TABLE `prod-lake.curated.events`
WITH CONNECTION `prod-lake.eu.lake-conn`
WITH PARTITION COLUMNS
OPTIONS (
  format = 'PARQUET',
  uris = ['gs://lake-curated/events/*'],
  hive_partition_uri_prefix = 'gs://lake-curated/events',
  require_hive_partition_filter = TRUE,
  max_staleness = INTERVAL 4 HOUR,
  metadata_cache_mode = 'AUTOMATIC'
);

Metadata caching keeps file listings and statistics so queries do not list millions of objects each time. max_staleness sets how old that cache may be.

Cost controls

LeverSaves
Lifecycle rules or Autoclass on raw dataStorage cost for data that is rarely read
Columnar formats (Parquet) and date-partitioned foldersBytes scanned per query
Compacting many small files into fewer large onesListing overhead and slow reads
require_hive_partition_filterAccidental full scans
BigQuery custom quotas and maximum bytes billedRunaway query costs
Labels and budget alertsVisibility of spend per team

Processing data in the lake

EngineFits
BigQuery over BigLake or Iceberg tablesSQL analytics without loading
Dataproc or Dataproc Serverless for SparkSpark jobs, notebooks, large transformations
DataflowBatch and streaming pipelines writing curated files or tables

A common job converts raw CSV or JSON into partitioned Parquet in the curated zone. That single step usually cuts query cost and time more than any other change.

Exam tip

When stems say "users query the raw CSV files and costs are high", the fix is to convert to a columnar, partitioned format and query through BigLake, not to buy more capacity.

Monitoring the data lake

  • Cloud Monitoring metrics for bucket size, object count and request rates.
  • Cloud Audit Logs for who read or changed data.
  • Dataplex data quality and data profile scans on lake tables, with alerts on failures.
  • Budget alerts and billing export to BigQuery for cost trends.

A worked example

A research company stores 2 PB of instrument output as CSV files. Analysts read the files directly with broad bucket permissions, queries are slow and costly, and one team must see only its own instruments.

The engineer converts the files to date-partitioned Parquet with a Dataproc Serverless batch job. BigLake tables with metadata caching replace direct file access, and bucket access is removed from analysts. A row access policy limits each team to its instruments, and raw CSV moves to Coldline after 90 days.

Raw CSVDataproc ServerlessCurated ParquetBigLake tablerow access policyAnalystsno bucket access

How the exam asks about this

  • "Apply column-level security to Parquet files in Cloud Storage queried from BigQuery and Spark." BigLake tables with policy tags.
  • "Analysts must not read lake files directly but must query them." Remove bucket access and grant access to BigLake tables that use a connection.
  • "Queries over a lake with millions of small files are slow to start." Compact files and enable metadata caching on BigLake tables.

What to remember for the exam

  • Organize the lake into raw, curated and consumption zones.
  • Dataplex discovery publishes Cloud Storage data as queryable tables in the catalog.
  • BigLake delegates file access to a connection, enabling row and column security.
  • Columnar, partitioned files and lifecycle rules are the main cost levers.
  • Monitor with Cloud Monitoring, audit logs and Dataplex data quality scans.
Watch out

Granting analysts read access on the bucket defeats BigLake row and column security, because they can read the files directly.

Common mistakes

Querying raw CSV for everyday analytics. Convert once to partitioned Parquet; every later query is cheaper.

Leaving millions of tiny files. Small files slow listing and reading; compact them.

Treating the lake as ungoverned storage. Without discovery, catalog entries and quality checks, the lake becomes a swamp nobody trusts.

Check yourself

  • Why do BigLake tables allow fine-grained security over files?

    Users are granted access to the table, while a connection's service account reads the files, so users never need bucket permissions.

  • What does BigLake metadata caching improve?

    Query performance, by reusing cached file listings and statistics instead of listing objects on every query, within the max_staleness setting.

  • What is usually the biggest single cost fix for a CSV data lake?

    Converting the files to a columnar, partitioned format such as Parquet so queries scan far fewer bytes.

Topic 3 of 4 in Storing the data

Test yourself on Storing the data

The full Google Cloud Professional Data Engineer question bank has 733 questions, with timed practice exams and an explanation for every answer.

This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.