A city open-data portal needs cleaned assessor tables stored for repeated GPU analytics reads. Which storage choice best supports efficient columnar access?
Select an answer to reveal the explanation.
Short Explanation
Assessor tables get reread like a well-worn zoning map—you want a format built for columnar grabs, not a giant text dump. Parquet keeps cleaned civic tables tight and GPU-friendly for those repeat scans.
Full Explanation
A city open-data portal storing cleaned assessor tables for repeated GPU analytics reads should write those tables as columnar Parquet so RAPIDS and related tools can scan needed columns efficiently. Parquet preserves types, supports compression, and enables column projection—exactly the access pattern of municipal assessor analytics that repeatedly touch a subset of parcel fields. As a lake format for cleaned civic tables, it outperforms text and nested document dumps for GPU-oriented rereads. Storing each nightly extract as a single nested JSON document per parcel fails by concept: nested JSON is row-oriented and parse-heavy, defeating columnar scans. Keeping only human-readable CSV on a shared drive fails because repeated GPU jobs pay text parse and weak typing costs. Serializing entire DataFrames with Python pickle fails as a long-term lake format: it is language-locked, often insecure for untrusted files, and poorly suited to selective columnar reads across tools. Exam caveat: Parquet helps efficient access but still needs a sane partition layout and schema contract; a single enormous unpartitioned file can limit prune-ability. Operational check: land a cleaned assessor extract as Parquet, run a RAPIDS read selecting a few columns, compare wall time and bytes read against CSV and JSON baselines, and standardize Parquet as the portal’s analytics-ready assessor format.