Databricks Certified Data Engineer Professional — Question 93

A nightly batch job is configured to ingest all data files from a cloud object storage container where records are stored in a nested directory structure YYYY/MM/DD. The data for each date represents all records that were processed by the source system on that date, noting that some records may be delayed as they await moderator approval. Each entry represents a user review of a product and has the following schema:

user_id STRING, review_id BIGINT, product_id BIGINT, review_timestamp TIMESTAMP, review_text STRING

The ingestion job is configured to append all data for the previous date to a target table reviews_raw with an identical schema to the source system. The next step in the pipeline is a batch write to propagate all new records inserted into reviews_raw to a table where data is fully deduplicated, validated, and enriched.

Which solution minimizes the compute costs to propagate this batch of data?

Answer options

• A. Perform a batch read on the reviews_raw table and perform an insert-only merge using the natural composite key user_id, review_id, product_id, review_timestamp.
• B. Configure a Structured Streaming read against the reviews_raw table using the trigger once execution mode to process new records as a batch job.
• C. Use Delta Lake version history to get the difference between the latest version of reviews_raw and one version prior, then write these records to the next table.
• D. Filter all records in the reviews_raw table based on the review_timestamp; batch append those records produced in the last 48 hours.
• E. Reprocess all records in reviews_raw and overwrite the next table in the pipeline.

Correct answer: A

Explanation

Option A is correct as it allows for a targeted insert-only merge using the composite key, which minimizes compute costs by only processing necessary records. Options B and D involve more overhead by processing all new records or filtering based on timestamps, which can increase costs. Option C, while efficient, still requires analyzing version history, which may not be as cost-effective as the merge approach. Option E incurs the highest costs by reprocessing all records and overwriting the target table.