Topic: analytics
-
Slowly changing dimensions: overwrite, add a row or add a column
When a dimension attribute changes (a customer moves, a product is reclassified), type 1 overwrites and loses history, type 2 adds a new row with effective and expiry dates and a current flag under a new surrogate key, and type 3 keeps the previous value in an extra column. Snapshot tools implement type 2 by comparing an update timestamp or a set of columns on each run.
-
ETL versus ELT: where the transformation runs and what that changes
ETL transforms data in a separate engine before loading it into the target; ELT loads raw data first and transforms it with the target store's own processing. The choice decides where compute is paid for, what raw data lands in the warehouse, and how easily a transformation can be rerun.
-
Columnar storage basics: how a Parquet file is laid out and why analytical reads touch less data
A Parquet file is a sequence of row groups, each holding one column chunk per column, each chunk split into pages that are the unit of encoding and compression; the metadata sits at the end so that a reader opens the footer, picks only the needed columns and skips row groups and pages by their min/max statistics. Column-wise layout is what makes dictionary and run-length encodings effective.
-
Star schema basics: facts, dimensions and declaring the grain
A star schema stores measurements in fact tables and descriptive context in dimension tables linked by keys; the design starts by declaring the grain, what one fact row represents, because every measure and dimension must be consistent with it. Fully additive measures sum across any dimension, semi-additive ones not across time, and ratios must be stored as their components.
Machine-readable: JSON