Iceberg en Nessie maken datawijzigingen veiliger
Git gaf applicatieteams een manier om iets te proberen zonder main te breken. Datateams hebben lang op het equivalent gewacht.
Ik draai Iceberg met Nessie als catalogus nu al een tijd. Wat mij overtuigde was niet time travel of het bestandsformaat. Het was kunnen zeggen probeer het op een branch en dat ook echt menen.
Branches zijn het hele punt
Schemawijziging, backfill, een partitieschema waar je niet zeker van bent: doe het op een branch, richt een testjob op die branch en kijk wat eruit komt. Stroomafwaarts merkt niemand iets tot je merget. Het alternatief was vroeger een volledige kopie van de tabel, of een heel voorzichtige WHERE en een nacht slaap die je toch niet ging krijgen.
-- Spark SQL with the Nessie extensions enabled.
CREATE BRANCH IF NOT EXISTS backfill_orders IN nessie FROM main;
USE REFERENCE backfill_orders IN nessie;
-- Run the backfill here. Nobody reading main sees any of it.
INSERT OVERWRITE nessie.sales.orders
SELECT * FROM nessie.staging.orders_backfill;
-- Compare, check the downstream reads, then promote.
MERGE BRANCH backfill_orders INTO main IN nessie;
-- When someone says the numbers changed:
SELECT snapshot_id, committed_at, operation
FROM nessie.sales.orders.snapshots
ORDER BY committed_at DESC;Snapshots maken van discussies diffs
Als iemand zegt dat de cijfers veranderd zijn, vergelijk je snapshot 4 met snapshot 5 in plaats van te reconstrueren wat de pipeline afgelopen dinsdag deed. db.table.snapshots opvragen duurt twee seconden en heeft me een paar lange gesprekken bespaard.
Promoveren hoort onopvallend te zijn
Merge de branch, controleer of de stroomafwaartse reads nog werken en bewaar het vorige snapshot-id ergens waar je het snel terugvindt. Als een release een runbook nodig heeft en twee mensen die naar een dashboard staren, heeft de branch zijn werk niet gedaan.
Het loont waar dingen vaak veranderen
De opzet is het waard zolang contracten nog bewegen, tabellen blijven evolueren of er elke maand nieuwe consumers bijkomen. Bij een tabel die al drie jaar dezelfde zes kolommen heeft is het vooral overhead. Niet alles heeft een versiebeheerde catalogus nodig, en doen alsof van wel is precies hoe platforms zwaar worden.