Kad ne možete mijenjati ni upit ni shemu

Dobavljač velikim američkim trgovinskim lancima daje svojim kupcima uvid u vlastite podatke o prodaji. Kupci otvore ThoughtSpot, postave pitanje i vide svoje brojke. Ne znaju da iza toga stoji skladište podataka, i ne treba ni da znaju.

Izvještaj najvećeg kupca trajao je preko petnaest minuta. Dvije stvari se nisu smjele dirati da bi se to popravilo.

Upiti. ThoughtSpot ih generiše iz onoga što korisnik klikne. Nema upita koji bi se prepisao, jer upit ne postoji dok neko ne postavi pitanje.

Shema. Kupci su imali sačuvane odgovore građene na postojećoj strukturi. Preimenuj kolonu i pokvarit ćeš izvještaje na koje se ljudi oslanjaju, u nalogu koji ti ne administriraš.

Šta to isključuje

Prepisivanje upita. Denormalizacija prema obrascu pristupa. Premodeliranje tabela. Dodavanje hinta. To su standardni potezi, i svi pretpostavljaju upravo dvije stvari koje ne smiješ pomjeriti.

Ostaje jedan put: zadrži površinu identičnom i zamijeni ono na šta pokazuje. Upit stiže na isto ime, shema izgleda kako je oduvijek izgledala, a ispod se odgovor više ne računa u trenutku pitanja.

Izračunaj unaprijed, ne računaj ponovo

Tri inkrementalno osvježavana materialized viewa nosila su izvještaj velikog kupca — dnevni point-of-sale, dnevne narudžbe, dnevne isporuke — sa zavisnim viewovima iznad njih, jer se na ThoughtSpot strani ništa nije moglo optimizovati:

CREATE MATERIALIZED VIEW mv_pos_daily
  DISTKEY (retailer_id)
  SORTKEY (sale_date, retailer_id)
  AUTO REFRESH NO
AS
SELECT retailer_id, store_id, sku, sale_date,
       SUM(units)   AS units,
       SUM(revenue) AS revenue
FROM   pos_transactions
GROUP  BY 1, 2, 3, 4;

Osvježavaju se jednom dnevno. To zvuči kao kompromis a nije: podaci ispod nastaju u dnevnom ritmu, pa je period od dvadeset četiri sata prirodan, a ne ustupak. Vrijedi rano pitati treba li ikome zaista svježije od toga, jer odgovor odlučuje cijeli vaš dizajn, a obično je ne.

Ključevi birani iz upita, ne iz sheme

Redshift je kolonaran i distribuiran, i dva fizička izbora odlučuju hoće li biti brz ili samo skup.

Ključ DISTKEY odlučuje kako se redovi raspoređuju po čvorovima. Pogriješi u njemu i svaki join premješta podatke između mašina prije nego išta može odgovoriti. Ključ SORTKEY odlučuje šta se može preskočiti — sa pravim ključem engine čita blokove za raspon datuma i ostalo ignoriše; sa pogrešnim čita sve pa naknadno filtrira.

Oba su birana iz upita koje sistem zaista izvršava, a ne iz toga kako je shema nacrtana. To su različiti spiskovi. Shema sugeriše join po primarnom ključu; log pokazuje da se u praksi sve filtrira po trgovcu i datumu. Čitaj log.

Unaprijed izračunat odgovor može biti tiho pogrešan

Ovo je dio koji pristup čini dovoljno sigurnim da se pusti u rad. Materialized view je odgovor izračunat ranije — ako se raziđe sa izvorom, sistem ne pada nego laže, i niko to ne primijeti dok neko na sastanku ručno ne uporedi dvije brojke.

Zato postoji validacijska skripta koja provjerava viewove u odnosu na ono što bi izvorni upit vratio:

-- isti prozor I ista granulacija na obje strane; sve što se vrati je neslaganje
SELECT retailer_id, sale_date, mv.units AS mv_units, src.units AS src_units
FROM (
  SELECT retailer_id, sale_date, SUM(units) AS units
  FROM   mv_pos_daily
  WHERE  sale_date >= DATEADD(day, -7, CURRENT_DATE)
  GROUP  BY 1, 2
) mv
FULL OUTER JOIN (
  SELECT retailer_id, sale_date, SUM(units) AS units
  FROM   pos_transactions
  WHERE  sale_date >= DATEADD(day, -7, CURRENT_DATE)
  GROUP  BY 1, 2
) src USING (retailer_id, sale_date)
WHERE  DECODE(mv.units, src.units, 1, 0) = 0;

Ta skripta je razlika između optimizacije i rizika. Računanje unaprijed bez provjere je samo brži način da se pogriješi.

Sa petnaest minuta na dvije desetine sekunde

Brojka nije zanimljiva kao višekratnik. Zanimljiva je zbog granice koju prelazi.

Pragovi vremena odziva Jakoba Nielsena drže se već trideset godina: oko 0,1 sekunde djeluje trenutno, oko jedne sekunde održava čovjekov tok misli netaknutim, a deset sekundi je krajnja granica zadržane pažnje. Petnaest minuta uopšte nije na toj skali. Petnaestominutni izvještaj nije alat nego zahtjev — pokrenete ga pa odete raditi nešto drugo, i pokrenete ga samo kad već znate šta hoćete.

Ispod sekunde isti izvještaj postaje nešto što istražuješ. Promijeni filter, pogledaj drugi period, uporedi dvije kategorije, sve unutar jednog razgovora sa kolegom. Niko za to nije morao biti obučavan. Nije to isti proizvod koji radi brže; to je drugi proizvod.

Gdje sve ovo još važi

Svaki put kad površina pripada nekom drugom. BI alat, integracija partnera, javni API ugovor, sačuvani izvještaji klijenta, verzija mobilne aplikacije na čije ažuriranje nikoga ne možete natjerati.

Instinkt je da se površina ispregovara — zahtjev za izmjenu sheme, prozor za migraciju, obavijest kupcima da ažuriraju sačuvane izvještaje. Ponekad je to ispravno. Češće košta tri mjeseca tuđe dobre volje da bi se kupila izmjena koja ti nije trebala, jer je isto ubrzanje bilo dostupno ispod, gdje niko nije morao ni na šta pristati.

Ovo je nastalo iz gradnje Redshift skladišta podataka ispod BI površine koja se nije mogla mijenjati, za dobavljača čiji kupci čitaju vlastite podatke. Pročitajte studiju →