A mobile app emits event records whose optional attributes change frequently. Which format and load approach lets the warehouse absorb new optional attributes without breaking the pipeline?
Show answer and explanation
Answer: B
Avro and Parquet embed their schema, so readers know the field names and types. Adding optional fields is a backward-compatible change. When loading into BigQuery, allowing field additions on load jobs lets the table gain new nullable columns instead of failing. Fixed CSV columns break on new fields, regex parsing of logs is brittle, and fixed-width binary has no built-in way to evolve its layout.
Why the other options are wrong
- A. Fixed CSV columns cannot accept an extra attribute, so each new field causes load failures until someone edits the schema by hand.
- C. Regular expressions break whenever the log layout shifts, and they carry no schema, so new attributes are silently dropped or cause parse errors.
- D. A wiki page is documentation, not enforcement. Fixed-width records have no mechanism for adding fields, so any layout change breaks every reader.