Iseteeninduslik andmete uuendamine Microsoft Fabricus

Andmed uuenevad tavaliselt ajakava järgi. Öösiti loetakse allikatest andmed sisse, hommikuks on aruanded värsked ja enamiku igapäevaste protsesside jaoks on see täiesti piisav. Ette tuleb aga hetki, kus ajakavast ei piisa ja uuendust on vaja täpselt siis, kui miski on päriselt valmis. Kõige selgem näide on kuu sulgemine: raamatupidamine on kanded kinnitanud ja finantskontroller vajab numbreid kohe, mitte homme hommikul.

Ajakava seda hetke ei tea. Tulemuseks on tavaliselt üks kahest halvast. Kas uuendatakse liiga vara ja aruanne näitab poolikuid numbreid, mis tuleb hiljem uuesti üle vaadata. Või jäädakse ootama andmeinseneri, kes selle käsitsi käivitab - ja siis sõltub kuu sulgemine ühe inimese kalendrist.

Power BI-s ei olnud seda seni mõistlikult võimalik lahendada. Aruandest sai käivitada ainult semantic model’i (aruande aluseks oleva andmemudeli) värskenduse, mitte kogu ahelat, mis toob andmed allikast kohale. Iga lahendus, kus nupp käivitas päris koodi, eeldas Power BI-st väljaspool asuvat taristut - Power Automate’i, Logic Appsi või oma veebirakendust - ja koos sellega Azure’i rakenduse registreerimist, teenusekontot ning saladuste hoiustamist ja vahetamist. See ei olnud enam seadistus, vaid eraldi IT-projekt.

2026. aasta märtsis jõudis translytical task flows üldisesse saadavusse ja koos kahe teise Fabricu uuendusega saab kogu ahela nüüd platvormi sees kokku panna. Kolm asja, mis nüüd koos töötavad:

• Translytical task flows lubab panna Power BI aruandesse nupu, mis käivitab koodi. Nupp elab aruandes, kasutaja ei pea kuhugi mujale minema.
• User Data Functions on lühikesed Python-funktsioonid, mis jooksevad Fabricu sees ja millel on juba olemas ühendus Fabricu enda ressurssidega. Just see kaotab vajaduse eraldi Azure’i rakenduse ja saladuste haldamise järele.
• OneLake events koos Activatoriga lubab failisündmuse - näiteks uue faili tekkimise - suunata reeglisse, mis käivitab mõne teise Fabricu objekti, näiteks andmevoo.

Kokku tähendab see, et uuenduse käivitab see, kes numbreid vajab - siis, kui eelnev töö on päriselt valmis. Kuu sulgemine ei sõltu enam ühe inimese kalendrist. Ahela ehitamine ja kontrollreeglid jäävad endiselt andmeinseneri tööks, aga käivitamiseks teda enam vaja ei ole.

Edasi läheb tehniliseks. Vaatame, kuidas ahel kokku käib, kus esimene katse tavaliselt katki läheb ja mida on enne päris kasutust veel vaja.

Ahel tervikuna

Lahendus on sündmuspõhine ja asünkroonne. Loogiliselt näeb see välja nii:

Power BI aruande nupp (translytical task flow)
  -> User Data Function
       -> kirjutab TÜHJA marker-faili OneLake'i
          (nt Files/refresh_requests/full__mari__20260811T0940Z.flag)
  -> OneLake FileCreated sündmus
       -> Activatori reegel (filter: kas tee algab õige kaustaga)
            -> käivitab Data Pipeline'i
                 -> samaaegsuse kaitse
                 -> andmete sissevedu allikast
                 -> transformatsioon (nt bronze -> silver -> gold)
                 -> valideerimine
                 -> SQL analytics endpointi metaandmete sync
                 -> semantic model'i värskendus
                 -> logi kirje "valmis"

Kasutaja jaoks on see üks klikk ja umbes 15-20 minuti pärast on aruanne uus. Selle lihtsuse taga on väike hajussüsteem, mille osad ei tea üksteisest midagi peale ühe marker-faili.

Miks peab ahel olema asünkroonne

Kogu ülejäänud disain tuleneb ühest numbrist. User Data Functionsil on päringu täitmise ajalimiit 240 sekundit (avaliku endpointi kaudu kutsudes 100 sekundit). Andmeahel, mis veab andmed allikast ja viib nad läbi mitme kihi, võtab kümneid minuteid. Funktsioon ei tohi seega andmevoo lõppu oodata - ta jõuaks enne ise otsa saada.

Funktsioon teeb ainult üht: jätab märkme, et uuendust sooviti, ja lõpetab kohe. Ülejäänu käivitab sündmus.

Sellest tuleb üks praktiline järeldus, mis on kerge kahe silma vahele jätta. Nupu seadetes (Format button > Action) tuleb välja lülitada valik Refresh the report after a successful outcome. Funktsioon lõpetab sekunditega - hetkel, mil päris töö alles algab - ja sisselülitatud seade värskendaks aruande just siis. Kasutaja näeks edukat teadet ja vanu numbreid. See on kõige halvem võimalik signaal, sest süsteem ei ole lihtsalt aeglane, vaid ütleb valet.

Tagasiside peab tulema mujalt: eraldi kontroll-tabelist, mida aruanne ise kuvab.

Funktsioon, mis jätab märkme

Funktsioon on lühem, kui esimese hooga arvata oskaks. Ta valideerib sisendi, kirjutab tühja faili ja tagastab lause, mille kasutaja aruandes ära näeb.

import datetime
import fabric.functions as fn

udf = fn.UserDataFunctions()

@udf.connection(argName="markerLakehouse", alias="<Lakehouse'i alias>")
@udf.context(argName="callContext")
@udf.function()
def request_refresh(
    markerLakehouse: fn.FabricLakehouseClient,
    callContext: fn.UserDataFunctionContext,
    refreshType: str,
) -> str:
    if refreshType not in ("full", "rebuild"):
        raise fn.UserThrownError(
            "Tundmatu uuenduse tüüp.", {"refreshType": refreshType}
        )

    # kes vajutas - läheb failinimesse ja sealt logi-tabelisse
    requester = callContext.executing_user["PreferredUsername"]
    now = datetime.datetime.now(datetime.timezone.utc)
    stamp = now.strftime("%Y%m%dT%H%M%SZ")

    directory = markerLakehouse.connectToFiles()
    marker = directory.get_file_client(
        f"refresh_requests/{refreshType}__{requester}__{stamp}.flag"
    )
    marker.create_file()   # null-pikkusega fail: täpselt üks sündmus
    marker.close()
    directory.close()

    return (
        "Uuendus on tellitud. "
        "Aruande staatuse-plokk näitab, kui see valmis saab."
    )

Kolm asja selles koodis väärivad eraldi märkimist.

Parameetrite nimed peavad olema camelCase ja alakriipsu ei tohi neis olla. refreshType töötab, refresh_type ei tööta. Funktsiooni enda nimes on alakriips lubatud, parameetris mitte. Samamoodi on context reserveeritud sõna, mida parameetri nimeks panna ei saa - siin on ta seetõttu callContext.

Funktsioon peab tagastama stringi, muidu ei saa teda aruande nupu külge üldse ühendada. See on hea koht, kuhu panna lause, mida kasutaja näeb.

create_file() teeb null-pikkusega faili ühe operatsiooniga. See ei ole stiili-küsimus, vaid kogu mustri alus - miks, sellest kohe.

Andmevoo poolel on samad asjad olemas parameetritena, mille väärtused ta failinimest välja loeb:

Kuus kohta, kus esimene katse untsu läheb

1. Marker-fail peab olema tühi. Sisuga faili kirjutamine tähendab objektisalvestuses tavaliselt mitut operatsiooni - loomine, sisu lisamine, kinnitamine - ja iga operatsioon võib tekitada oma sündmuse. Iga sündmus käivitaks oma andmevoo jooksu. Tühi fail on üks operatsioon, üks sündmus, üks jooks. Sellepärast on koodis create_file() ja mitte upload_data().

2. Parameetrid pane failinimesse. Kuna fail on tühi, ei saa parameetrit sisus edasi anda. Sündmus ise suvalisi kasutaja-parameetreid ei kanna, aga ta kannab faili teed. Kodeeri vajalik failinimesse - eespool olevas näites uuenduse tüüp, tellija ja ajatempel - ja lase andmevool see teest välja parsida. Lihtne ja töökindel.

3. Samaaegsuse kaitse ei ole valikuline. Kaks kasutajat vajutavad nuppu minutilise vahega ja kaks paralleelset jooksu hakkavad kirjutama samu tabeleid. Andmevoo esimene samm peab seetõttu pärima Fabricu Job Scheduler API-st, kas mõni konkureeriv jooks juba käib:

GET /v1/workspaces/{workspaceId}/items/{itemId}/jobs/instances
    (baas: https://api.fabric.microsoft.com)

-> vaata jookse, mille status on veel lõpetamata
-> kui mõni neist algas varem kui praegune jooks, lõpeta ise

Reegel “varaseim võidab” on lihtsam kui järjekord ja praktikas piisav. Üks nüanss, mida dokumentatsioon ei ütle: töö registreerimine API-s ei ole hetkeline. Enne pärimist on vaja lühikest ooteaega, suurusjärgus 10-15 sekundit, muidu ei näe kaks peaaegu korraga startinud jooksu teineteist ja mõlemad lähevad edasi. Kui samu tabeleid kirjutab mitu eri andmevoogu, peab kaitse olema nende ülene, mitte iga voo enda sees.

4. Kontroll-tabel on ainus tagasiside-kanal. Andmevoog kirjutab alguses rea “algas” ja lõpus rea “lõppes”, juurde staatus, kestus ja tellija. Aruanne kuvab sellest “viimati uuendatud” ja jooksva töö oleku. Kaks konksu:

• Ajavöönd. API-d annavad ajad UTC-s (startTimeUtc, endTimeUtc). Teisenda need kohalikku aega juba transformatsioonis. Kaart, mis näitab tunni või kahe võrra valet aega, kaotab usalduse kiiremini kui aeglane uuendus.
• Rippuma jäänud jooksud. Jooks, mis ootamatult sureb, ei kirjuta kunagi rida “lõppes” ja jääb igaveseks olekusse “käib”. Lahendus: iga uue jooksu alguses märgi vanad lõpetamata read hüljatuks. Samaaegsuse kaitse tagab niikuinii, et aktiivne jooks on korraga üks.

5. Sunni metaandmete sync enne mudeli värskendust. Kui semantic model loeb andmeid Lakehouse’i SQL analytics endpointi kaudu, käib metaandmete sünkroniseerimine taustaprotsessina, mis loeb Delta logisid. Tavatingimustes on viivitus alla minuti, aga see kõigub sekunditest minutiteni. Kui andmevoog kirjutab tabelid ja käivitab kohe mudeli värskenduse, võib mudel lugeda veel vana pilti.

Kõige salakavalam ilming on see, et “viimati uuendatud” aeg hüppab ette, aga numbrid jäävad vanaks - aruanne jääb terve tsükli võrra maha ja keegi ei saa aru, miks. Lahendus on andmevoos eraldi samm vahetult enne värskendust. Fabricus on selleks olemas natiivne Refresh SQL Endpoint tegevus; pildil olevas ahelas teeb selle töö ära notebook.

Sellel sammul on üks omadus, millega tuleb arvestada: kui Lakehouse’i kirjutatakse samal ajal, võib sünkroniseerimine lukukonflikti tõttu ebaõnnestuda. Microsofti soovitus on hoida ahelas ainult üks selline samm, töötluse päris lõpus - tõrkeid see ära ei kaota, aga vähendab neid tuntavalt.

6. Korista markerid ära. Iga klikk jätab faili maha. Andmevoo lõppu käib samm, mis need kustutab, muidu kasvab kaust vaikselt täis.

Õigused - koht, kus muster on kõige elegantsem

Aruande tarbija vajab funktsiooni-objektil Execute õigust. Ainult aruande lugemisõigusest ei piisa: nupp annab siis vea. Tasub teada, et objekti jagamine annab vaikimisi ainult Read õiguse ja Execute tuleb eraldi juurde anda. Praktikas on mõistlik anda see turvagrupile, mitte inimeste kaupa - vastasel juhul on iga uue kolleegi puhul vaja meeles pidada, et keegi peab kuskile klõpsama.

Tarbija ei vaja aga mingeid õigusi Lakehouse’ile, andmevoole ega Activatorile. Marker-faili kirjutamine käib funktsiooni enda ühenduse identiteediga, mitte aruannet vaatava inimese omaga.

Tulemus on see, et äri saab käivitada raske andmeahela, ilma et talle antaks ligipääsu toorandmetele või töövahenditele. Turvalisuse mõttes on see oluliselt parem kui alternatiiv, kus kasutajale antakse tööruumis laiad õigused, et üks nupp tööle hakkaks.

Miks mitte lasta funktsioonil andmevoogu otse käivitada

Ilmne alternatiiv marker-failile oleks lasta funktsioonil kutsuda REST API kaudu andmevoog otse käima. See töötab, aga toob tagasi kõik selle, mille eest me põgenesime: Azure’i rakenduse registreerimine, service principal, saladuse hoiustamine ja selle vahetamine. Ehk püsiv halduskoormus ja sõltuvus IT-st.

Siin on ka konkreetne piirang, mida tasub teada: dokumentatsiooni järgi ei toeta User Data Functionsi hallatud ühendused service principal’i, managed identity’t ega workspace identity’t. See kitsendab otsekutsumise varianti veelgi.

Marker-fail ja sündmus hoiavad kogu ahela Fabricu sees - null Azure’i rakendust, null saladust, null IT-piletit. Hind on üks kaudne samm ja veidi suurem viide käivitumisel. Ahelas, mis niikuinii kestab kakskümmend minutit, on see hea vahetus.

Mitu nuppu, üks logi

Praktikas tekib kiiresti vajadus rohkem kui ühe nupu järele. Tüüpiliselt kaks: täisuuendus, mis veab andmed allikast uuesti sisse ja ehitab kõik ümber, ning ümberehitus, mis allikast midagi ei tõmba, vaid ehitab olemasolevast uuesti. Teine on tunduvalt kiirem ja sobib siis, kui muutus mõni käsitsi hallatav sisendfail.

Muster on lihtne: eraldi andmevood, eraldi funktsioonid ja eraldi nupud, aga üks jagatud logi-tabel veeruga, mis ütleb, kumb neist käivitati. Nii näeb aruandes eraldi, millal kumbki asi viimati uuenes. Samaaegsuse kaitse peab neid vastastikku välistama, sest lõpuks kirjutavad mõlemad samu tabeleid.

Mida on enne päris kasutust veel vaja

• Värskenduse identiteet. Kui semantic model’i värskendus käib ühe inimese isikliku konto alt, katkeb kogu ahel siis, kui tema parool või mitmeastmeline autentimine muutub - või kui ta ettevõttest lahkub. Päris kasutuses kuulub sinna teenuskonto või workspace identity.
• Valideerimine andmevoo sees. Kui uuenduse käivitab äri ise, ei ole enam kedagi, kes numbreid vahepeal vaataks. Andmevoog peab ise kontrollima ridade arvud ja võtme-invariandid ning katkestama, kui midagi on paigast ära. Katkenud jooks on parem kui vaikselt vale aruanne.
• Vigade nähtavus. Kontroll-tabel peab kuvama ka ebaõnnestumise. Kasutaja, kes uuenduse tellis, peab teada saama, et see ei õnnestunud - muidu ta lihtsalt vaatab vanu numbreid ja usub neid.

Kokkuvõte

See ei ole “lohista nupp aruandele”. Asünkroonsus, samaaegsus ja lõpp-järjekindlus on päris inseneriprobleemid ja neid tuleb päriselt lahendada, mitte ümbert mööda minna. Ahel, mille osad üksteisest ei tea, on ka raskem silmaga jälgida kui üks skript, mis kõike ise teeb.

Teisest küljest ei ole see ka suur ettevõtmine. Osad on kõik Fabricu sees, ükski neist ei nõua eraldi taristut ja kogu asja saab üks inimene paari päevaga kokku panna. Ja tulemus on selline, mida ärikasutaja märkab: kuu on lukus, ta vajutab nuppu ja veerand tundi hiljem näitab aruanne uusi numbreid.

Andmevoogude ehitus Microsoft Fabricu sees on üks Klaarixi teenustest. Kui teie aruannete värskus sõltub praegu sellest, millal keegi jõuab need käivitada, siis vaadake meie andmeinseneeria paketti.