A housing-authority waitlist analytics job only needs a few columns and recent rows from a large Parquet dataset on GPU. Which read strategy best limits device memory pressure?
Select an answer to reveal the explanation.
Short Explanation
If you only need recent waitlist fields, do not haul the whole warehouse onto the GPU dock. Push filters and column picks down to Parquet so unused row groups never wake up.
Full Explanation
A housing-authority waitlist analytics job that needs only a few columns and recent rows from a large Parquet dataset should push predicates and column projections so only needed row groups and columns enter GPU memory. Predicate pushdown and column pruning are the read strategies that keep device memory pressure low on wide municipal tables by skipping irrelevant history and unused fields at the storage layer. That is essential when waitlist models touch a thin slice of a much larger civic lake. Loading every column and every historical partition into GPU memory then filtering in Python loops fails by concept: it maximizes device pressure and pays for data you immediately discard. Converting the entire lake to a single dense NumPy array before selecting fields fails by materializing everything host-side and losing Parquet’s selective read benefits. Downloading the full dataset to CSV on a laptop SSD before filtering fails on scale, typing, and needless round-trips. Exam caveat: pushdown only helps when partitions/row-group statistics align with filters; a poorly partitioned waitlist lake may still scan too much until layout matches common predicates. Operational check: issue a RAPIDS/Parquet read with explicit columns and a recent-row predicate, inspect bytes read and peak GPU memory versus a full-table load, and adopt projection-plus-predicate as the standard waitlist extract path.