GUI mot kode - hva skal jeg velge for datatransformasjon?

Datatransformasjon er en viktig del av ELT-prosessen. GUI og kode er to vanlige alternativer for datatransformasjon, men hva bør du velge? I denne artikkelen vil vi diskutere fordeler og ulemper og hjelpe deg med å bestemme hva som passer best for dine behov.

Hva er ETL og ELT?

ETL står for “Extract, Transform, Load” og refererer til en dataintegrasjonsprosess der data hentes fra forskjellige kilder, transformeres til ønsket format og lastes inn i et målsystem.

ELT står for “Extract, Load, Transform” og refererer til en lignende prosess, men der transformasjonen skjer etter at rådataene er lagret. ELT har blitt populært delvis på grunn av at skybasert lagring og analyseverktøy har blitt rimeligere og mer kraftfulle. Dette har hatt to konsekvenser. For det første er skreddersydde ETL-pipeliner ikke lenger egnet til å håndtere en stadig økende variasjon og volum av data som skapes av skybaserte tjenester. For det andre har selskaper nå råd til å lagre og behandle all sin ustrukturerte data i skyen. De trenger ikke lenger å redusere eller filtrere data under transformasjonsfasen.

Den viktigste årsaken er imidlertid at vi nå vil ønsker å ta vare på rådata, og modellere de til de use casene vi har. Vi utfører nå “T”-transformasjonen etter at vi har hentet og lastet inn dataene. For rapporteringsformål lager vi kanskje transformasjoner til de ulike lagene i et datavarehus basert på samordning av brukstilfeller og tilhørende datamodellering. For analyseformål lager vi transformasjoner etter behov. Rekkefølgen på de tre bokstavene har kanskje endret seg, men hva de betyr har ikke det.

Utvikling innen verktøy for ETL og ELT

Det finnes mange verktøy tilgjengelige i dag for å utføre “E” (extract), “L” (load) og “T” (transform). Noen verktøy dekker hele kjeden (ELT), mens andre dekker bare deler av den (f.eks. kun T).

Eksempler på aktører som dekker alt innen ELT inkluderer Informatica, IBM og Oracle, samt nyere løsninger som Matillion og Talend. De store skyplattformene som Azure, Google Cloud og AWS har også egne løsninger som dekker hele spennet av oppgaver. De fleste av disse løsningene er bygget opp basert på grafiske grensesnitt og “drag-and-drop”.

Vi har også nyere løsninger som spesialiserer seg på å utføre én eller to av disse oppgavene godt. F.eks. har vi løsninger som Airflow, Prefect og Dagster for orkestrering (Load). “E” og “L” har blitt mer sofistikerte over tid med forhåndsbygde tilkoblinger for alle typer kilder og mål.

Det har gått litt trått med utvikling innen datatransformasjon, men de siste årene har vi fått løsninger som dbt, Delta Live Tables og Dataform. Spesielt har dbt fått en stor tilhengerskare, også i Norge.

Krav til effektiv utvikling og forvaltning av datatransformasjoner

Vi mener at alle valg bør baseres på våre behov. Så hva ønsker vi oss fra et transformasjonsverktøy?

Generelt ser vi at fagområdet for data og analyse gradvis har beveget seg mot programvareutvikling. Vi ønsker fleksibilitet til å kunne lage hva som helst, støtte til å utvikle mest mulig effektivt, og god oversikt slik at vi kan forvalte logikken effektivt.

Backend-utviklere innen programvareutvikling jobber smidig og basert på DevOps-prinsipper (you build it, you run it). De er vant til at all logikk er kode, at kode kan gjenbrukes, at vi har kontroll gjennom CI/CD, og ikke minst at vi kan automatisere testing, dokumentasjon og gjentagende oppgaver.

Vi ønsker det samme for data og analyse.

Fordeler og ulemper med GUI mot kode for datatransformasjon i ELT-prosessen

GUI for datatransformasjon i ELT-prosessen

Fordeler med GUI

• Krever mindre opplæring for ikke-tekniske brukere å bygge basic transformeringsjobber, flere kan bruke verktøyene som ikke har SQL-erfaring
• Enkelt å løse enkle/små use-case
• Grafisk representasjon foretrekkes av noen

Ulemper med GUI

• Alle pipelines må lages “fra scratch” og testes/vedlikeholdes/videreutvikles separat, blir mer utfordrende når prosjektet vokser
• GUI er begrenset av funksjonene som er tilgjengelige, og kan ikke håndtere komplekse transformasjoner. Funksjonaliteten dekker ofte bare 70-80% av behovene (avhengig av verktøy), må ofte skrive kode på siden
• “Low-code”-verktøy har egen syntax som må læres
• Ikke alltid like godt integrert med CI/CD-pipelines
• Mindre portabilitet, større byttekost
• Begrenset innebygget funksjonalitet knyttet til automatisk testing, orkestrering og dokumentasjon

Kode for datatransformasjon i ELT-prosessen

Fordeler med kode

• Gir fleksibilitet i å realisere mange behov/use case knyttet til transformasjon (mange bibliotek støttet, kan tilpasse)
• Enklere å vedlikeholde (har alt i kode vs kode+GUI)
• Gir mulighet for mer effektiv utvikling gjennom automatisering og gjenbruk av kode
• AI-basert datakvalitet og datatransformasjon øker farten til utviklere vil på kort sikt være enklere tilgjengelig gjennom kodebaserte verktøy
• Lett å finne tekniske ressurser som kan kode (SQL, Python, ++)
• Integrerer mot underliggende prosesseringsmotorer, gir portabilitet
• Integrerer godt mot CI/CD-pipelines og testverktøy
• Ofte mer effektiv kode/prosessering

Ulemper med kode

• Kode krever at brukerne har en viss grad av teknisk kunnskap og kan kreve opplæring om de ikke har erfaring med bruk av makroer, SQL eller Python.
• Koding kan ta lengre tid enn GUI når det gjelder enkle transformasjoner.
• Krever at teamet har ressurser med dypere teknisk kompetanse
• Mer arbeid med initielt oppsett

Hva skal jeg velge for datatransformasjon?

Begge tilnærmingene har sine fordeler og ulemper, og valget vil avhenge av dine spesifikke behov. “Det kommer an på” er som vanlig svaret.

Små organisasjoner med begrenset teknisk kompetanse & enkle transformasjoner bør velge GUI

Hvis du har enkle transformasjoner som ikke krever mye teknisk kunnskap, kan GUI være det beste alternativet. GUI gir en enkel og intuitiv måte å utføre datatransformasjon på, selv for ikke-tekniske brukere. Det kan også spare tid, da du ikke trenger å skrive kode. Mindre organisasjoner der use casene er enkle kan gjerne bruke verktøy som Data Factory og Alteryx - som representerer Low code/no code.

Større organisasjoner med teknisk kompetanse & varierte behov for transformasjoner bør velge kode

Hvis du har mer komplekse transformasjoner som krever høyere nøyaktighet eller automatisering, kan kode være det beste alternativet. Kode gir mer fleksibilitet og presisjon i transformasjonsprosessen og gir muligheten til å automatisere prosessen. Større organisasjoner som har “proffe” utviklermiljøer bør i størst mulig grad benytte kode. I hvert fall for de offisielle dataflytene.

Superbrukere i linja vil i stor grad også kunne bruke kodebaserte verktøy - og elske det. Dataflyt som er under testing og utforskning, eller som ikke er kritiske, kan utvikles i low-code/no-code-verktøy om ønskelig.

FAQ

Hvilke use case er datatransformasjonsverktøy best egnet for?

Datatransformasjonsverktøy er skal sørge for at vi skaper data som er brukbare innen både rapportering og analyse. Disse verktøyene støtter transformasjon fra rådata til foredlede data, som er felles for mange ulike brukergrupper og brukere. Rådata transformeres basert på datamodellering, som er spesielt viktig innen use case forbundet med datavarehus og rapportering.

Er det nødvendig å ha teknisk kunnskap for å bruke kode for datatransformasjon i ELT-prosessen?

Ja, det krever vanligvis en viss grad av teknisk kunnskap å bruke kode for datatransformasjon i ELT-prosessen. Men - heldigvis krever det kunnskap om programmeringsspråk som mange kan fra før - SQL og Python. Det er også viktig å huske at datamodelleringskunnskap er viktig uavhengig av type verktøy.

Kan vi bruke både kode-baserte og GUI-baserte datatransformasjonsverktøy?

Ja, store virksomheter vil sannsynligvis ha flere verktøy som gjør det samme. Om dere kan velge vil det være lurt å standardisere på færrest mulig verktøy. Flere verktøy vil kreve ekstra oppsett av CI/CD-pipelines, overvåkning mv, og gir økt kompleksitet. Ikke minst krever flere verktøy duplisert kompetanse.

Hvem vil være brukerne av et datatransformasjonsverktøy?

Brukerne av datatransformasjonsverktøy, både GUI- og kodebaserte, vil være data engineers, analytical engineers, BI-utviklere og forretningsanalytikere.

Bør data scientists benytte et datatransformasjonsverktøy?

Delvis. Data scientists som benytter metoder som maskinlæring og nevrale nett trenger andre verktøy for å bearbeide data. De bruker ofte notebooks, som Jupyter, for å jobbe stegvis med kode og dokumentasjon, ofte i Python.

Når de har funnet ut at analysene gir verdi og skal ut i produksjon, anbefaler vi å flytte den generelle modelleringen og datatransformasjonen som andre use case kan ha glede av, inn i den felles kodebasen forvaltet i datatransformasjonsverktøyet. Dette kan gjøres av data engineers, ML engineers eller data scientists.

Data scientists bistår ofte også i utvikling av dataflyter og rapportering. Da må de følge prinsipper, prosesser og verktøyvalg som gjelder for denne type use case, uavhengig av stillingstittel.

Hvilke verktøy er vanligst å bruke for kode-basert datatransformasjon?

Akkurat nå er disse verktøyene mest populære innen kode-basert datatransformasjon:

1. dbt (dbt Labs) (ikke knyttet mot en spesifikk dataplattform eller skytjeneste)
2. Delta live tables (kun på Databricks som prosesseringsmotor)
3. Dataform (kun på Google Cloud)