テーマ： 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