Answer-first summary for fast verification
Answer: Create a new physical table with the updated schema for the customer-facing application, then replace the original table identifier with a view that aliases the new table's fields to match the original schema.
The most effective way to handle schema evolution in a shared environment is to provide a **stable contract** for existing users via a view. * **Why A is correct**: By creating a new physical table with the required schema (new fields and renamed columns) and then creating a **view** using the original table's name, you ensure that all legacy queries continue to run without modification. The view simply aliases the new column names back to the old names. This minimizes storage overhead (compared to deep clones) and prevents breaking downstream BI or ML workloads. * **Why B is incorrect**: Forcing all users to update their queries is operationally expensive, creates significant friction, and risks breaking production workloads managed by other departments. * **Why C is incorrect**: Deep clones create a full copy of the data, doubling storage costs. Furthermore, keeping two physical tables in sync adds significant complexity to the ETL pipeline. * **Why D is incorrect**: While similar to A, D suggests maintaining two separate tables entirely (or a view of the old logic), which increases the maintenance burden and can lead to data consistency issues if the pipelines diverge.
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
A data engineering team maintains aggregate tables that support BI dashboards, machine learning models, and ad hoc analytics across an organization. A customer-facing application—the only workload directly managed by the data engineering team—requires renaming several existing fields and adding new ones to a shared aggregate table.
Which solution addresses these requirements while minimizing disruption to other teams and avoiding excessive management of multiple tables?
A
Create a new physical table with the updated schema for the customer-facing application, then replace the original table identifier with a view that aliases the new table's fields to match the original schema.
B
Notify all organizational stakeholders of the mandatory schema change and provide documentation on how to refactor their legacy queries to match the updated field names.
C
Utilize Delta Lake's deep clone functionality to create a synchronized copy of the table, applying the schema changes only to the cloned version while keeping the original intact.
D
Replace the current table with a logical view to preserve existing query logic for other teams, while creating an entirely separate, independent physical table to serve the customer-facing application.