V rokoch 2022 – 2023 sme cez partnerskú spoločnosť pracovali na analytickej časti projektu optimalizácie štátnych informačných systémov. Dáta boli po migrácii v PostgreSQL a analytici sa na ne chceli pozrieť skôr, než by sa stihol pripraviť klasický BI projekt, ktorý zvyčajne znamená mesiace výberu nástroja, licencií a návrhu dátového skladu. Postavili sme preto proof of concept na Apache Superset nad existujúcou databázou. Článok je pre IT a dátové tímy, ktoré zvažujú podobný krok: čo Superset dá hneď, kde sú riziká a ako z prototypu dostať zadanie pre skutočné BI.

Proof of concept nie je malé BI

Cieľom proof of conceptu je zistiť, ktoré dáta, pre koho, v akej podobe a ako často ľudia naozaj potrebujú. Nie je to hotový reporting. Superset sa na to hodí: je to otvorený projekt Apache Software Foundation pod licenciou Apache 2.0, bez licenčných poplatkov, a pripája sa priamo na existujúcu relačnú databázu. Rozdiel medzi nástrojom na prieskum a hotovým BI treba vysvetliť vedeniu hneď na začiatku. Inak sa prototyp posudzuje podľa kritérií, ktoré nemal splniť, alebo sa potichu zmení na produkčný systém bez prevádzky a zálohovania.

Čo Superset dá hneď a čo treba pripraviť

Pre každý databázový systém potrebuje Superset ovládač a dialekt knižnice SQLAlchemy. PostgreSQL patrí medzi bežne podporované. Po pripojení databázy má analytik k dispozícii SQL Lab, editor SQL s prehliadačom schém, históriou a uloženými dotazmi. Z výsledku dotazu sa dá rovno urobiť graf, ako trvalý zdroj pre grafy a dashboardy však musí byť dotaz uložený ako dataset. Pre analytika, ktorý vie SQL, je to použiteľné okamžite.

Pre ľudí bez SQL je ťažisko inde, v datasetoch. Fyzický dataset je zaregistrovaná tabuľka alebo pohľad, virtuálny dataset je definovaný SQL dotazom. Nad datasetom má Superset tenkú sémantickú vrstvu: vypočítané stĺpce (výrazy nad jednotlivými riadkami, bez agregačných funkcií), metriky (agregácie, napríklad podiel dvoch súčtov), označenie stĺpcov ako časových, filtrovateľných alebo dimenzií a certifikáciu metrík. Pripraviť datasety so zrozumiteľne pomenovanými stĺpcami a metrikami bola v našom proof of concepte väčšina práce.

Definície dôležitých ukazovateľov sa oplatí držať na jednom mieste. Ak si každý analytik napíše vlastný virtuálny dataset s vlastným výpočtom, po pár týždňoch existuje niekoľko rôznych čísel pre ten istý ukazovateľ. Opakovane používanú logiku je lepšie presunúť do pohľadu v databáze, kde sa dá verzovať a revidovať ako kód, a v Supersete nad ním definovať metriky.

Výkon: analytika nemá zaťažovať produkciu

Ťažké dotazy nad produkčnou databázou boli prvé miesto, kde sa to zadrhávalo. Možnosti, ktoré pomáhajú, a ich kompromisy:

  • Replika len na čítanie. V PostgreSQL režim hot standby povoľuje na replike iba čítanie. Dokumentácia PostgreSQL však upozorňuje na konflikty: keď replika potrebuje aplikovať zmenu z primárneho servera, dlhý dotaz môže byť po uplynutí nastaveného oneskorenia zrušený. Parameter hot_standby_feedback konflikty čistenia odstráni za cenu odkladania čistenia mŕtvych riadkov na primárnom serveri. Pre analytiku sa preto oplatí iné nastavenie repliky než pre repliku určenú na vysokú dostupnosť.
  • Materializované pohľady pre najčastejšie otázky. Uložia výsledok dotazu a obnovujú sa príkazom REFRESH MATERIALIZED VIEW. Analytik vidí stav k poslednému obnoveniu a to treba na dashboarde povedať.
  • Cache výsledkov. V predvolenej konfigurácii Superset dáta grafov do cache neukladá. Treba ju zapnúť a dokumentácia ako úložisko odporúča Redis. Platnosť sa nastavuje pri grafe, datasete alebo databáze, inak platí predvolená hodnota.
  • Asynchrónne dotazy. Dlhé dotazy v SQL Lab presahujú bežný časový limit webovej požiadavky. Superset ich vie spúšťať na workeroch Celery, potrebuje však sprostredkovateľa správ (dokumentácia odporúča Redis alebo RabbitMQ) a úložisko výsledkov. Asynchrónny režim sa zapína pri každej databáze zvlášť. Pre malý proof of concept to často netreba, pri veľkých objemoch áno.

Prístupové práva: roly, datasety a riadky

Superset má vstavané roly Admin, Alpha, Gamma, sql_lab a Public. Admin má všetky práva, Alpha vidí všetky zdroje dát, ale nespravuje prístupy iných, Gamma je pre konzumentov a vidí len zdroje, ku ktorým dostala prístup ďalšou rolou, sql_lab otvára SQL Lab. Dve vlastnosti treba poznať vopred. Prístup k databáze znamená prístup ku všetkým jej datasetom. A kto má prístup k datasetu, vidí aj publikované dashboardy, ktoré ho používajú, pokiaľ nie je zapnuté riadenie prístupu priamo na úrovni dashboardov.

Filtre na úrovni riadkov (row-level security) sa priraďujú k datasetu a k rolám a Superset ich pridá do podmienky WHERE dotazu, ktorý generuje. Na dotazy písané ručne v SQL Lab sa však uplatnia len vtedy, keď je zapnutý príznak RLS_IN_SQLLAB, ktorý je podľa konfigurácie Supersetu v štádiu testovania a v predvolenom stave vypnutý. Kto má mať obmedzený pohľad na riadky, nemá dostať SQL Lab nad tou istou databázou. Spoľahlivejšie je mať obmedzenie aj v samotnej databáze: samostatného databázového používateľa len na čítanie s prístupom iba k analytickej schéme alebo k pripraveným pohľadom.

Vo verejnej správe k tomu pristupuje ochrana osobných údajov. Analytici zriedka potrebujú identifikovať konkrétnu osobu a zásada minimalizácie údajov z čl. 5 GDPR hovorí pre agregované alebo pseudonymizované pohľady namiesto surových tabuliek. Práva navrhnuté pred spustením sa dajú preniesť do BI projektu. Dopĺňať ich, keď si používatelia zvykli vidieť všetko, je ťažšie.

Nasadenie: predvolené nastavenia nie sú produkčné

  • Tajný kľúč aplikácie (SECRET_KEY) podpisuje relácie a šifruje citlivé údaje v metadátovej databáze. Má byť náhodný a mimo repozitára. S predvoleným kľúčom Superset od verzie 2.1 odmietne štartovať a na jeho výmenu má dokumentovaný postup s prešifrovaním uložených údajov.
  • Inštalácia cez docker compose vytvára účet admin s heslom admin a dokumentácia výslovne uvádza, že takáto inštalácia nie je pripravená na produkciu. Pred sprístupnením ďalším ľuďom treba predvolený účet zmeniť a používať osobné účty, ideálne napojené na správu identít organizácie.
  • Metadátová databáza: predvolená je SQLite, ktorú dokumentácia na produkciu dôrazne neodporúča. Patrí sem PostgreSQL alebo MySQL so zálohovaním, lebo sú v nej datasety, metriky, dashboardy aj oprávnenia.
  • Sieť: Superset za reverznou proxy s HTTPS, analytická databáza dostupná len zo servera Supersetu a nie z celej siete. Politiku Content Security Policy, ktorú Superset predvolene zapína, nechať zapnutú.
  • Pripojenie len na čítanie: databázový používateľ bez práv na zápis a v nastavení databázy v Supersete vypnuté povolenie iných než SELECT príkazov v SQL Lab (nastavenie allow_dml), napríklad UPDATE, DELETE či CREATE. Dve nezávislé poistky sú lepšie ako jedna.
  • Vkladanie dashboardov do inej aplikácie (embedding) ide cez knižnicu Supersetu a krátkodobý hosťovský token vydaný na serveri, ktorý môže niesť aj filtre riadkov. Povolené domény treba nastaviť explicitne, prázdny zoznam podľa dokumentácie povolí ľubovoľný pôvod. Pre proof of concept to väčšinou netreba.

Postup proof of conceptu a meranie úspechu

  • Otázky namiesto dashboardov: zozbierať od analytikov konkrétne otázky, ktoré dnes riešia exportmi, a vybrať malý počet s najvyššou hodnotou a dostupnými dátami.
  • Inventár dát: ku každej otázke tabuľky, kľúče, aktuálnosť dát a citlivosť (osobné alebo inak chránené údaje).
  • Datasety a metriky: fyzické datasety nad pripravenými pohľadmi, stĺpce pomenované jazykom používateľov, metriky s popisom výpočtu. Virtuálne datasety len tam, kde pohľad v databáze nedáva zmysel.
  • Prístupy pred dátami: kto dostane SQL Lab, kto len dashboardy, aké filtre riadkov. Schváliť s vlastníkom dát skôr, než sa pozvú používatelia.
  • Krátke kolá: pravidelne ukazovať analytikom, čo pribudlo, a zapisovať otázky, na ktoré Superset nestačil, aj s dôvodom.
  • Dohodnutý koniec: proof of concept má mať vopred dané trvanie a kritériá a skončiť rozhodnutím, nie sa predlžovať.

Kritériá úspechu sa dohodnú pred začiatkom. Užitočné sú tieto: koľko z vybraných otázok sa dá zodpovedať bez ručného exportu, za aký čas analytik dostane odpoveď v porovnaní s doterajším postupom, či sa používatelia k nástroju po prvom týždni vracajú a ktoré otázky ostali nezodpovedané a prečo (chýbajúce dáta, výkon, práva, zložitosť). Počet postavených dashboardov úspech nemeria.

U nás mali analytici za dva týždne prístup k dátam, ktoré predtým dostávali v exportoch raz mesačne. Zároveň sa ukázalo, ktoré otázky sa pýtajú najčastejšie.

Kde Superset nestačí

  • Správa dát (governance): Superset nie je dátový katalóg. Pôvod dát, vlastníctvo a schvaľovanie definícií ukazovateľov treba riešiť inde. Certifikácia metriky v datasete je označenie, nie schvaľovací proces.
  • Dátový sklad: Superset sa pýta databázy, ktorú mu dáte. Integráciu viacerých zdrojov, historizáciu a čistenie dát nerobí. Ak otázky analytikov potrebujú spájať systémy, je to práca pre dátovú vrstvu, nie pre vizualizačný nástroj.
  • Verzovanie: dashboardy, grafy a datasety sa dajú exportovať a importovať ako ZIP so súbormi YAML a uložiť do repozitára. Revízia zmien a presun medzi prostrediami je však vlastný proces. Dokumentácia zatiaľ nevydanej verzie opisuje históriu verzií grafov a dashboardov s obmedzeným uchovaním, ani tá však revíziu nenahrádza.
  • Samoobsluha pre ľudí bez SQL: v rozhraní na tvorbu grafov zvládnu filtrovanie, zoskupovanie a výber metrík nad pripraveným datasetom. S príslušnými oprávneniami vedia aj zaregistrovať existujúcu tabuľku alebo pohľad ako dataset bez písania SQL. Spojenie tabuliek či zložitejšie výpočty však zvyčajne potrebujú pripravenú dátovú vrstvu alebo SQL. Ak takí ľudia tvoria väčšinu používateľov, hodnotu určuje kvalita datasetov, nie nástroj.
  • Prevádzka: produkčný Superset je webový server, metadátová databáza, cache, workery, zálohy a aktualizácie. Niekto ich musí mať na starosti.

Z proof of conceptu k zadaniu BI projektu

Najčastejšie otázky analytikov sa u nás stali základom požiadaviek na skutočný BI projekt. Výstup proof of conceptu má preto byť dokument, nielen bežiaci nástroj. Mal by obsahovať:

  • zoznam otázok zoradený podľa frekvencie a skupín používateľov,
  • slovník ukazovateľov s presným výpočtom, prevzatý z metrík v datasetoch,
  • požiadavky na aktuálnosť dát a orientačné objemy a časy odozvy, ktoré boli v prototype prijateľné,
  • model prístupových práv vrátane filtrov riadkov a zaobchádzania s osobnými údajmi,
  • zoznam zdrojov, ktoré v prototype chýbali, a otázok, ktoré pre ne ostali nezodpovedané,
  • rozhodnutie, čo z prototypu ostáva v prevádzke a kto ho bude spravovať, alebo že sa vypne.

Proof of concept projekt nenahradil, ale spresnil jeho zadanie. To sa potom opieralo o otázky, ktoré analytici naozaj kládli, a nie o odhady. Ak máte dáta v relačnej databáze a ľudí, ktorí ich chcú vidieť, odporúčame začať časovo ohraničeným prieskumom s jasnými kritériami, prístupmi navrhnutými vopred a pripojením len na čítanie. O veľkom BI potom rozhodnete až s vedomím, čo potrebujete.