Räätälöity ELT-työkalu integraatioihin

Mistä kyse

ETL vs. ELT — lyhyesti. ETL (Extract-Transform-Load) oli aikanaan vakio, koska datavarastot olivat hitaita ja kalliita: oli järkevää muuntaa data putkessa ennen latausta ja ladata vasta valmis lopputulos. ELT (Extract-Load-Transform) kääntää järjestyksen: data viedään raakana ensin datavarastoon ja jalostetaan siellä SQL:llä. Moderni pilvi­datavarasto jaksaa tämän helposti, ja hyödyt ovat merkittäviä: putki on yksinkertaisempi, raakadata säilyy debugattavissa, jalostus­logiikka on versioitavissa SQL-tiedostoina ja muutos toiseen rakenteeseen tapahtuu ilman uutta latausta.

Lähtötilanne

Asiakkaan raportointi nojasi Azure Data Factory -kopiointi­ajoihin, jotka siirsivät tietoa jäsenrekisteri­järjestelmän REST-rajapinnasta data­varastoon. Kun toimittaja päivitti rajapinnan sivutus­mallia, ADF ei enää osannut hakea kuin ensimmäisen sivun — mutta mikään ei näkynyt rikki: data “tuli”, vain vanhentuneena. Hälytys­kelloja ei ollut. Osa analyyseista oli kuukausi­tolkulla väärällä datalla ennen havaintoa.

Tehty ratkaisu

Suunnittelin ja toteutin Python-pohjaisen ELT-työkalun joka korvaa ADF:n. Työkalu pyörii Container App Jobina aikataulutetusti (tai manuaalisesti tarvittaessa), lataa raakadatan omaan skeemaan ja jalostaa sen SQL:llä raportointi­näkymiksi. Keskeisiä suunnittelu­päätöksiä:

• Blue-green-swap jokaiselle taululle. Uusi data ladataan rinnakkais­tauluun; onnistumisen jälkeen vanhan päälle tehdään atominen rename. Analyytikko ei näe välitilaa.
• Tuoreus näkyviin. Yhden näkymän kysely ops.v_freshness kertoo mistä hetkestä minkäkin taulun data on — ja status­sivu näyttää sen ei-tekniselle valvojalle punainen/keltainen/vihreä -tilana, jotta hiljainen vanhentuminen ei toistu.
• ADF-parity kärsivällisyydelle. Kun toimittajan rajapinta ruuhkautuu hetkellisesti, meidän client odottaa 30 sekunnin välein, yhteensä jopa tunnin per pyyntö — sama tarina kuin asiakkaan tutussa tooling­issa, jotta 100 % onnistuminen on oikeasti saavutettavissa eikä “96 % riittää”.
• Per-näkymä-vikaeristys + second-pass. Yhden taulun ongelma ei kaada muita; epäonnistuneet kierretään vielä kerran ensi­kierroksen jälkeen 30 s tauon jälkeen. Transient-ruuhkat eivät päädy “failed”-riveiksi vaan saavat toisen mahdollisuuden.
• Infrastruktuuri koodina läpikotaisin. Terraform + GitHub Actions OIDC — ei manuaalisia portal­muutoksia, ei salaisuuksia CI-lokeissa, terraform destroy + terraform apply rakentaa ympäristön uudestaan nollasta.

Lopputulos

Uudet ja vanhat ajot pyörivät hetken rinnakkain, jolloin rivit voitiin verrata SQL-tasolla ennen kuin cutover tehtiin. Asiakas sai:

• Luotettavan data-päivityksen oman monitorointi­näkymän kera, jolloin poikkeukset havaitaan heti eikä kuukausien päästä.
• Dokumentoidun, auditoitavan ja re-deployattavan kokonaisuuden — tekninen velka ei synny vaan sitä vähennetään.
• Tuotemaisen alustan jonka voi per-deployment istuttaa toiselle samankaltaiselle organisaatiolle — asiakas­spesifinen konfiguraatio tulee Terraform-muuttujista, ei koodista.

Projekti kattoi kokonaisvaltaisen kaaren konsepti­työstä tuotantoon: arkkitehtuuri­valinnat, tekninen toteutus, deployment, testaus, monitorointi ja dokumentaatio — samalla pitäen silmällä myöhemmän skaalautumisen ja tuotteistuksen.