
Answer-first summary for fast verification
Answer: Configure a new table with all the requisite fields and new names and use this as the source for the customer-facing application; create a view that maintains the original data schema and table name by aliasing select fields from the new table.
The data engineering team needs to modify an aggregate table's schema without disrupting other teams. Option B addresses this by creating a new table with the required schema and a view that aliases fields to maintain the original schema. This allows the customer-facing application to use the new table while other teams continue using the view, which references the new table. This minimizes interruptions and avoids increasing the number of tables (only one new table and a view are added). Option D is incorrect because replacing the original table with a view that re-runs the aggregation query would increase compute costs, contradicting the goal of reducing costs. Other options either disrupt existing users (A, E) or fail to sync changes effectively (C).
Author: LeetQuiz Editorial Team
Ultimate access to all questions.
No comments yet.
To minimize organizational disruption while meeting new requirements for a customer-facing application, how can the data engineering team rename and add fields to an aggregate table (used by multiple teams) while minimally interrupting other teams in the organization without increasing the number of tables that need to be managed?
(Note: The solution should maintain compatibility with existing BI dashboards, ML models, analytical queries, and other downstream workloads while addressing the specific needs of the customer-facing application.)
A
Send all users notice that the schema for the table will be changing; include in the communication the logic necessary to revert the new table schema to match historic queries.
B
Configure a new table with all the requisite fields and new names and use this as the source for the customer-facing application; create a view that maintains the original data schema and table name by aliasing select fields from the new table.
C
Create a new table with the required schema and new fields and use Delta Lake's deep clone functionality to sync up changes committed to one table to the corresponding table.
D
Replace the current table definition with a logical view defined with the query logic currently writing the aggregate table; create a new table to power the customer-facing application.
E
Add a table comment warning all users that the table schema and field names will be changing on a given date; overwrite the table in place to the specifications of the customer-facing application.