Thema: analytics
-
Langsam veränderliche Dimensionen: überschreiben, eine Zeile hinzufügen oder eine Spalte hinzufügen
Ändert sich ein Dimensionsattribut (eine Kundin zieht um, ein Produkt wird neu klassifiziert), überschreibt Typ 1 den Wert und verliert die Historie, Typ 2 fügt unter einem neuen Surrogatschlüssel eine neue Zeile mit Gültig-ab- und Gültig-bis-Datum sowie einem Aktuell-Flag hinzu, und Typ 3 behält den vorherigen Wert in einer zusätzlichen Spalte. Snapshot-Werkzeuge setzen Typ 2 um, indem sie bei jedem Lauf einen Aktualisierungszeitstempel oder eine Menge von Spalten vergleichen.
-
Differential Privacy in einem Absatz, und wo sie nicht passt
Differential Privacy begrenzt, wie stark der Datensatz einer einzelnen Person die Ausgabeverteilung eines Abfragemechanismus verändern kann, indem kalibriertes Rauschen hinzugefügt und jede Antwort einem Budget belastet wird; sie passt zu wiederholten aggregierten Veröffentlichungen über grosse Populationen und passt nicht zu Datensätzen auf Einzelfallebene, kleinen Gruppen, exakten Operationen oder einmaligen internen Analysen.
-
ETL versus ELT: Wo die Transformation läuft und was das ändert
ETL transformiert Daten in einer separaten Engine, bevor sie ins Ziel geladen werden; ELT lädt zuerst die Rohdaten und transformiert sie mit der eigenen Verarbeitung des Zielspeichers. Die Wahl entscheidet, wo Rechenleistung bezahlt wird, welche Rohdaten im Warehouse landen und wie leicht sich eine Transformation erneut ausführen lässt.
-
Grundlagen spaltenorientierter Speicherung: wie eine Parquet-Datei aufgebaut ist und warum analytische Lesezugriffe weniger Daten berühren
Eine Parquet-Datei ist eine Folge von Row Groups, von denen jede pro Spalte einen Column Chunk enthält; jeder Chunk ist in Pages unterteilt, die die Einheit für Kodierung und Kompression bilden. Die Metadaten stehen am Ende, sodass eine lesende Stelle zunächst den Footer öffnet, nur die benötigten Spalten auswählt und Row Groups sowie Pages anhand ihrer Min/Max-Statistiken überspringt. Die spaltenweise Anordnung ist es, die Dictionary- und Lauflängenkodierungen wirksam macht.
-
Welcher Anteil ausgelieferter Features wird 90 Tage nach der Veröffentlichung noch genutzt, und was geschah mit den ungenutzten und ihren Flags?
Offene Frage: Feature-Flag-Werkzeuge wie Unleash versehen ein Flag mit einer erwarteten Lebensdauer und markieren es nach deren Ablauf automatisch als potenziell veraltet – das deckt das Flag ab, nicht aber das Feature dahinter. Bei Produkten, die die Feature-Nutzung nachverfolgen: Welcher Anteil der in einem Jahr veröffentlichten Features hatte nach 90 Tagen noch nennenswerte Nutzung, was geschah mit dem Rest (entfernt, versteckt, beibehalten), und folgten ihre Flags und ihr Code dieser Entscheidung?
-
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.
Maschinenlesbar: JSON