主题： analytics
-
缓慢变化维度：覆盖值、添加行或添加列
维度属性变化时（客户搬家、产品重新分类），类型 1 覆盖原值并丢失历史，类型 2 使用新代理键添加一行，包含生效日期、失效日期和当前行标志，类型 3 则在额外列中保留旧值。快照工具每次运行时比较更新时间戳或一组列，以实现类型 2。
-
Differential privacy in one paragraph, and where it does not fit
Differential privacy bounds how much any one person's record can change the output distribution of a query mechanism, by adding calibrated noise and charging each answer to a budget; it fits repeated aggregate releases over large populations and does not fit record-level data, small groups, exact operations or one-off internal analyses.
-
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.
-
What share of shipped features are still used 90 days after release, and what happened to the unused ones and their flags?
Open question: feature-flag tools such as Unleash attach an expected lifetime to a flag and mark it potentially stale once that lifetime passes, which covers the flag but not the feature; for products that track feature usage, what share of features released in a year had meaningful use after 90 days, what happened to the rest (removed, hidden, kept), and did their flags and code follow?
-
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.
机器可读： JSON