nerdexam
Google

PROFESSIONAL-DATA-ENGINEER · Question #357

You created an analytics environment on Google Cloud so that your data scientist team can explore data without impacting the on-premises Apache Hadoop solution. The data in the on-premises Hadoop…

The correct answer is D. Copy the ORC files on Cloud Storage, then create external BigQuery tables for the data scientist team. Option D is correct because copying ORC files to Cloud Storage and creating external BigQuery tables lets data scientists query the data in-place using familiar SQL - BigQuery supports ORC format natively and respects Hive partitioning, so no data transformation or import is…

Submitted by lucia.co· Mar 30, 2026Designing data processing systems

Question

You created an analytics environment on Google Cloud so that your data scientist team can explore data without impacting the on-premises Apache Hadoop solution. The data in the on-premises Hadoop Distributed File System (HDFS) cluster is in Optimized Row Columnar (ORC) formatted files with multiple columns of Hive partitioning. The data scientist team needs to be able to explore the data in a similar way as they used the on-premises HDFS cluster with SQL on the Hive query engine. You need to choose the most cost-effective storage and processing solution. What should you do?

Options

  • AImport the ORC files to Bigtable tables for the data scientist team.
  • BImport the ORC files to BigQuery tables for the data scientist team.
  • CCopy the ORC files on Cloud Storage, then deploy a Dataproc cluster for the data scientist team.
  • DCopy the ORC files on Cloud Storage, then create external BigQuery tables for the data scientist team.

How the community answered

(21 responses)
  • A
    5% (1)
  • B
    24% (5)
  • C
    10% (2)
  • D
    62% (13)

Explanation

Option D is correct because copying ORC files to Cloud Storage and creating external BigQuery tables lets data scientists query the data in-place using familiar SQL - BigQuery supports ORC format natively and respects Hive partitioning, so no data transformation or import is needed. This is the most cost-effective approach since you avoid the storage duplication cost of importing/converting data and only pay for queries run against it.

Why the distractors fail:

  • A (Bigtable): Bigtable is a NoSQL key-value store optimized for low-latency reads/writes, not SQL analytics - it doesn't support SQL queries or ORC files natively.
  • B (BigQuery import): Importing ORC files into BigQuery tables works technically, but duplicates storage costs (you're paying for both Cloud Storage and BigQuery managed storage) and requires an ETL step, making it less cost-effective than external tables.
  • C (Dataproc cluster): Deploying a Dataproc cluster replicates an on-prem Hive/Hadoop setup and works fine, but you pay for the cluster even when idle - it's more expensive and operationally heavier than serverless BigQuery external tables.

Memory tip: Think "external = no copy, no convert, no extra cost" - when the question asks for cost-effective SQL analytics on existing files in GCS, external BigQuery tables are almost always the answer because BigQuery reads the source files directly without charging for managed storage.

Topics

#BigQuery External Tables#Cloud Storage#Hadoop Migration#Cost Optimization

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full PROFESSIONAL-DATA-ENGINEER Practice