Korvaako tekoäly datainsinöörit? [Video ja tietokilpailu]

Lyhyt vastaus: Tekoäly ei korvaa datainsinöörejä kokonaan; se automatisoi toistuvaa työtä, kuten SQL-koodien luonnostelua, prosessien telineiden rakentamista, testejä ja dokumentointia. Jos roolisi on enimmäkseen vähän omistajuutta vaativa ja tikettipohjainen työ, se on alttiimpi; jos puolestaan ​​​​vastuussasi on luotettavuus, määritelmät, hallinta ja häiriöihin reagointi, tekoäly pääasiassa nopeuttaa toimintaasi.

Keskeiset tiedot:

Vastuullisuus: Aseta etusijalle tulosten vastuu, äläkä vain koodin nopeaa tuottamista.

Laatu: Rakenna testejä, havainnoitavuutta ja sopimuksia, jotta prosessit pysyvät luotettavina.

Hallinto: Pidä yksityisyys, käyttöoikeuksien hallinta, säilytys ja tarkastuslokit ihmisten omistuksessa.

Väärinkäytön estäminen: Käsittele tekoälyn tuotoksia luonnoksina; tarkista ne välttääksesi epäilyttävät virheet.

Roolien vaihto: Käytä vähemmän aikaa mallipohjaisten asioiden kirjoittamiseen ja enemmän aikaa kestävien järjestelmien suunnitteluun.

Jos olet viettänyt yli viisi minuuttia datatiimien lähellä, olet kuullut kertosäkeen – joskus kuiskattuna, joskus juonenkäänteenä kokouksen aikana: Korvaako tekoäly datainsinöörit?

Ja… ymmärrän kyllä. Tekoäly voi luoda SQL:ää, rakentaa provisions-käskyjä, selittää pinonjäljityksiä, luonnostella tietokantamalleja ja jopa ehdottaa varastokaavoja hämmentävän varmasti. GitHub Copilot SQL:lle Tietoja tietokantamalleista GitHub Copilot
Tuntuu kuin katsoisi trukin oppivan jonglööraamaan. Vaikuttavaa, hieman hälyttävää, etkä ole täysin varma, mitä se tarkoittaa työssäsi 😅

Mutta totuus on otsikkoakin epäselvempi. Tekoäly muuttaa datatekniikkaa täysin. Se automatisoi tylsät, toistettavat osat. Se nopeuttaa "tiedän mitä haluan, mutta en muista syntaksia" -hetkiä. Se myös synnyttää aivan uudenlaista kaaosta.

Eli esitetään se kunnolla, ilman optimismia tai paniikkia.

Artikkelit, joita saatat haluta lukea tämän jälkeen:

🔗 Korvaako tekoäly radiologit?
Miten kuvantamisen tekoäly muuttaa työnkulkua, tarkkuutta ja tulevaisuuden rooleja.

🔗 Korvaako tekoäly kirjanpitäjät?
Katso, mitkä kirjanpitotehtävät tekoäly automatisoi ja mitkä jäävät ihmisen tehtäväksi.

🔗 Korvaako tekoäly investointipankkiirit?
Ymmärrä tekoälyn vaikutus kauppoihin, tutkimukseen ja asiakassuhteisiin.

🔗 Korvaako tekoäly vakuutusagentit?
Opi, miten tekoäly mullistaa vakuutusten myöntämisen, myynnin ja asiakastuen.

Miksi kysymys "tekoäly korvaa datainsinöörit" nousee jatkuvasti pintaan 😬

Pelko tulee hyvin tietystä paikasta: datatekniikassa on paljon toistettavaa työtä.

• SQL:n kirjoittaminen ja uudelleenjärjestely

• Sisäänkirjausskriptien luominen

• Kenttien yhdistäminen kaavasta toiseen

• Testien ja perusdokumentaation luominen

• Putkilinjan vikojen virheenkorjaus, jotka ovat… tavallaan ennustettavissa

Tekoäly on epätavallisen hyvä toistettavissa kaavoissa. Ja suuri osa datatekniikasta on juuri sitä - kaavoja pinottuna kaavojen päälle. GitHub Copilot -koodiehdotuksia

Myös työkaluekosysteemi "piilottaa" jo monimutkaisuutta:

• Hallitut ELT-liittimet Fivetran-dokumentaatio

• Palvelimeton laskenta AWS Lambda (palvelimeton laskenta)

• Yhden napsautuksen varaston käyttöönotto

• Automaattisen skaalauksen orkestrointi Apache Airflow -dokumentaatio

• Deklaratiiviset muunnoskehykset Mikä on dbt?

Joten kun tekoäly ilmestyy, se voi tuntua viimeiseltä palaselta. Jos pino on jo abstraktoitu ja tekoäly voi kirjoittaa liimauskoodin… mitä jää jäljelle? 🤷

Mutta tässä on asia, jonka ihmiset ohittavat: datatekniikka ei ole pääasiassa kirjoittamista. Kirjoittaminen on helppo osa. Vaikea osa on saada hämärä, poliittinen ja muuttuva liiketoimintatodellisuus käyttäytymään luotettavan järjestelmän tavoin.

Ja tekoäly kamppailee edelleen tuon hämärän kanssa. Ihmisilläkin on vaikeuksia – he vain improvisoivat paremmin.

Mitä datainsinöörit oikeasti tekevät koko päivän (epäilyttävä totuus) 🧱

Ollaanpa rehellisiä – työnimike ”Data Engineer” kuulostaa siltä kuin rakentaisit rakettimoottoreita puhtaasta matematiikasta. Käytännössä rakennat luottamusta.

Tyypillinen päivä on vähemmän "uusien algoritmien keksimistä" ja enemmän:

• Neuvottelut ylävirran tiimien kanssa datamääritelmistä (tuskallista, mutta välttämätöntä)

• Mittarin muuttumisen syiden (ja sen todenperäisyyden) selvittäminen

• Kaavion ajautumisen ja "joku lisäsi sarakkeen keskiyöllä" -yllätysten käsittely

• Putkilinjojen idempotentin, palautettavan ja havaittavan varmistaminen

• Kaiteiden luominen, jotta alavirran analyytikot eivät vahingossa rakenna turhia koontinäyttöjä

• Kustannusten hallinta, jotta varastostasi ei tule rahanloukkua 🔥

• Käyttöoikeuksien suojaaminen, auditointi, vaatimustenmukaisuus ja säilytyskäytännöt GDPR-periaatteet (Euroopan komissio) Tallennusrajoitukset (ICO)

• Luomme datatuotteita, joita ihmiset voivat oikeasti käyttää ilman, että he lähettävät sinulle yksityisviestejä (20 kysymystä)

Suuri osa työstä on sosiaalista ja operatiivista:

• "Kuka omistaa tämän pöydän?"

• "Onko tämä määritelmä edelleen pätevä?"

• "Miksi CRM vie kaksoiskappaleita?"

• "Voimmeko lähettää tämän mittarin johtajille ilman häpeää?" 😭

Tekoäly voi toki auttaa osittain tässä. Mutta sen korvaaminen kokonaan on… vaikeaa.

Mikä tekee datatekniikan roolista vahvan? ✅

Tämä osio on tärkeä, koska korvaavista tehtävistä puhuttaessa oletetaan yleensä, että datainsinöörit ovat pääasiassa "tuotantoputken rakentajia". Se on kuin olettaisi, että kokit pääasiassa "pilkkovat vihanneksia". Se on osa työtä, mutta ei itse työ.

Vahva versio datainsinööristä tarkoittaa yleensä, että hän pystyy tekemään suurimman osan näistä:

• Suunnittele muutosta varten
  . Data muuttuu. Tiimit muuttuvat. Työkalut muuttuvat. Hyvä insinööri rakentaa järjestelmiä, jotka eivät romahda joka kerta, kun todellisuus aivastaa.

• Määrittele sopimukset ja odotukset
  Mitä "asiakas" tarkoittaa? Mitä "aktiivinen" tarkoittaa? Mitä tapahtuu, kun rivi saapuu myöhässä? Sopimukset estävät kaaosta paremmin kuin hienostunut koodi. Avoimen datan sopimusstandardi (ODCS) ODCS (GitHub)

• Rakenna havaittavuus kaikkeen.
  Ei vain "toimiko se", vaan "toimiko se oikein". Tuoreus, volyymipoikkeamat, nollaräjähdykset, jakauman muutokset. Datan havaittavuus (Dynatrace) Mitä on datan havaittavuus?

• Tee kompromisseja kuin aikuinen:
  Nopeus vs. oikeellisuus, kustannukset vs. latenssi, joustavuus vs. yksinkertaisuus. Täydellistä putkea ei ole, on vain putkia, joiden kanssa voi elää.

• Muunna liiketoiminnan tarpeet kestäviksi järjestelmiksi.
  Ihmiset kysyvät mittareita, mutta he tarvitsevat datatuotteen. Tekoäly voi luonnostella koodin, mutta se ei voi taianomaisesti tunnistaa liiketoiminnan miinoja.

• Pidä data hiljaa.
  Paras kohteliaisuus data-alustalle on se, ettei siitä puhuta. Tapahtumaton data on hyvää dataa. Kuten putkityöt. Sen huomaa vasta, kun se pettää. 🚽

Jos teet näitä asioita, kysymys "Korvaako tekoäly datainsinöörit?" alkaa kuulostaa... hieman omituiselta. Tekoäly voi korvata tehtäviä, ei omistajuutta.

Missä tekoäly jo auttaa datainsinöörejä (ja se on todella hienoa) 🤖✨

Tekoäly ei ole vain markkinointia. Hyvin käytettynä se on aito voiman moninkertaistaja.

1) Nopeampi SQL ja muunnostyö

• Monimutkaisten liitosten piirtäminen

• Ikkunafunktioiden kirjoittaminen, joita et halua ajatella

• Selkokielisen logiikan muuttaminen kyselyrunkoiksi

• Rumien kyselyiden uudelleenmuotoilu luettaviksi CTE-lomakkeiksi GitHub Copilot for SQL

Tämä on valtavaa, koska se vähentää "tyhjän sivun" vaikutusta. Sinun on silti validoitava, mutta aloitat 70 prosentista 0 prosentin sijaan.

2) Virheenkorjaus ja perussyyn selvittäminen

Tekoäly on kohtuullinen seuraavissa asioissa:

• Virheilmoitusten selittäminen

• Vinkkejä mistä etsiä

• Suosittelemme "tarkista kaavion epäsuhta" -tyyppisiä vaiheita GitHub Copilotissa
  Se on kuin väsymätön nuorempi insinööri, joka ei koskaan nuku ja joskus valehtelee itsevarmasti 😅

3) Dokumentaatio ja tietokatalogin rikastaminen

Automaattisesti luotu:

• Sarakkeiden kuvaukset

• Mallien yhteenvedot

• Sukulinjan selitykset

• ”Mihin tätä taulukkoa käytetään?” luonnostelee DBT-dokumentaation

Se ei ole täydellinen, mutta se rikkoo dokumentoimattomien putkistojen kirouksen.

4) Testaa telineet ja tarkista ne

Tekoäly voi ehdottaa:

• Perusnollatestit

• Ainutlaatuisuustarkistukset

• Viittausehdon ideat

• ”Tämän mittarin ei pitäisi koskaan laskea” -tyyppiset väitteet DBT-datatesteissä Suuret odotukset: Odotukset

Jälleen kerran – sinä päätät edelleen, millä on merkitystä, mutta se nopeuttaa rutiinivaiheita.

5) Putkilinjan "liimaus"-koodi

Konfigurointipohjat, YAML-rakenteet, orkestrointi-DAG-luonnokset. Ne ovat toistuvia ja tekoäly syö toistuvia asioita aamiaiseksi 🥣 Apache Airflow -DAGit

Missä tekoäly edelleen kamppailee (ja tämä on sen ydin) 🧠🧩

Tämä on tärkein osa, koska se vastaa korvauskysymykseen oikealla tekstuurilla.

1) Epäselvyys ja määritelmien vaihtelu

Liiketoimintalogiikka on harvoin selkeää. Ihmiset muuttavat mielensä kesken lauseen. ”Aktiivisesta käyttäjästä” tulee ”aktiivinen maksava käyttäjä”, josta tulee ”aktiivinen maksava käyttäjä, pois lukien hyvitykset joskus”... tiedäthän miten se menee.

Tekoäly ei voi omistaa tätä monitulkintaisuutta. Se voi vain arvailla.

2) Vastuullisuus ja riski

Kun prosessi katkeaa ja kojelauta näyttää hölynpölyä, jonkun on tehtävä seuraavaa:

• triage

• viestiä vaikutuksesta

• korjaa se

• estää uusiutumisen

• kirjoita ruumiinavaus

• päättää, voiko yritys edelleen luottaa viime viikon lukuihin

Tekoäly voi auttaa, mutta se ei voi olla merkityksellisellä tavalla vastuullinen. Organisaatiot eivät toimi fiiliksen – ne toimivat vastuun varassa.

3) Systeeminen ajattelu

Data-alustat ovat ekosysteemejä: tiedonkeruu, tallennus, transformaatiot, orkestrointi, hallinta, kustannusten hallinta, palvelutasosopimukset. Muutos yhdessä tasossa aiheuttaa aaltoja. Apache Airflow -konseptit

Tekoäly voi ehdottaa paikallisia optimointeja, jotka aiheuttavat globaalia tuskaa. Se on kuin korjaisi narisevan oven poistamalla sen kokonaan 😬

4) Tietoturva, yksityisyys, vaatimustenmukaisuus

Tässä kohtaa korvaavat fantasiat kuolevat.

• Käyttöoikeuksien hallinta

• Rivitason suojaus Snowflake-rivien käyttöoikeuskäytännöt BigQuery-rivitason suojaus

• Henkilökohtaisten tietojen käsittely NIST Privacy Frameworkissa

• Säilytyssäännöt Säilytysrajoitus (ICO) EU:n ohjeet säilytyksestä

• Auditointilokit NIST SP 800-92 (lokien hallinta) CIS Control 8 (auditointilokien hallinta)

• Tietojen säilytysrajoitukset

Tekoäly voi laatia käytäntöjä, mutta niiden turvallinen toteuttaminen on todellista insinöörityötä.

5) ”Tuntemattomat tuntemattomat”

Tietoturvaloukkaukset ovat usein arvaamattomia:

• Toimittajan API muuttaa semantiikkaa hiljaa

• Aikavyöhykeoletus kääntyy päälaelleen

• Täyttö kopioi osion

• Uudelleenyritysmekanismi aiheuttaa kaksoiskirjoituksia

• Uusi tuoteominaisuus tuo mukanaan uusia tapahtumamalleja

Tekoäly on heikompi, kun tilanne ei ole tunnettu kaava.

Vertailutaulukko: mikä vähentää mitä käytännössä 🧾🤔

Alla on käytännönläheinen näkemys. Ei "työkaluja, jotka korvaavat ihmisiä", vaan työkaluja ja lähestymistapoja, jotka supistavat tiettyjä tehtäviä.

Huomaa, mitä puuttuu: rivi, jossa lukee ”paina painiketta poistaaksesi datainsinöörit”. Joo… sitä riviä ei ole olemassa 🙃

Joten… korvaako tekoäly datainsinöörit vai muuttaako se vain roolia? 🛠️

Tässä on ei-dramaattinen vastaus: tekoäly korvaa osia työnkulusta, ei ammattia.

Mutta se muokkaa roolia uudelleen. Ja jos jätät sen huomiotta, tunnet puristuksen.

Mitä muutoksia:

• Vähemmän aikaa kaavamaisten tekstien kirjoittamiseen

• Vähemmän aikaa dokumenttien etsimiseen

• Enemmän aikaa tarkasteluun, validointiin ja suunnitteluun

• Enemmän aikaa sopimusten ja laatuodotusten määrittelyyn Avoimen datan sopimusstandardi (ODCS)

• Enemmän aikaa yhteistyöhön tuote-, tietoturva- ja rahoitusalalla

Tämä on hienovarainen muutos: datatekniikka keskittyy vähemmän "putkien rakentamiseen" ja enemmän "luotettavan datatuotejärjestelmän rakentamiseen"

Ja hiljaisella käänteellä sanottuna, se on arvokkaampaa, ei vähemmän.

Myös – ja sanon tämän, vaikka se kuulostaa dramaattiselta – tekoäly lisää niiden ihmisten määrää, jotka voivat tuottaa dataartefakteja, mikä lisää tarvetta sille, että joku pitää koko jutun järjissä. Enemmän tuotostetta tarkoittaa enemmän mahdollista sekaannusta. GitHub Copilot

Se on kuin antaisi kaikille porakoneen. Hienoa! Nyt jonkun pitäisi valvoa "älä poraa vesiputkeen" -sääntöä 🪠

Uusi taitopino, joka pysyy arvokkaana (vaikka tekoälyä on kaikkialla) 🧠⚙️

Jos haluat käytännöllisen ”tulevaisuudenkestävän” tarkistuslistan, se näyttää tältä:

Järjestelmäsuunnittelun ajattelutapa

• Muutosten kestävä datamallinnus

• Erä- ja suoratoistoratkaisujen väliset kompromissit

• Latenssi-, kustannus- ja luotettavuusajattelu

Tiedon laadun suunnittelu

• Sopimukset, validoinnit, poikkeamien havaitseminen Avoimen datan sopimusstandardi (ODCS) Datan havaittavuus (Dynatrace)

• Palvelutasosopimukset (SLA), palvelutasosopimukset (SLO), tapauksiin reagointitavat

• Perimmäisen syyn analyysi kurinalaisesti (ei fiiliksien avulla)

Hallinto- ja luottamusarkkitehtuuri

• Käyttömallit

• Auditoitavuudessa NIST SP 800-92 (lokinhallinta)

• Sisäänrakennettu tietosuoja NIST:n tietosuojakehys

• Tiedon elinkaaren hallinta EU:n ohjeistus tietojen säilyttämisestä

Alusta-ajattelu

• Uudelleenkäytettävät mallit, kultaiset polut

• Standardoidut mallit Fivetranin datan syöttämiseen, muunnoksiin ja testaukseen

• Itsepalvelutyökalut, jotka eivät sula

Kommunikointi (kyllä, todellakin)

• Selkeiden dokumenttien kirjoittaminen

• Määritelmien yhdenmukaistaminen

• Sano "ei" kohteliaasti mutta päättäväisesti

• Kompromissien selittäminen kuulostamatta robotilta 🤖

Jos pystyt tekemään nämä, kysymys "Korvaako tekoäly datainsinöörit?" muuttuu vähemmän uhkaavaksi. Tekoälystä tulee sinun tukirankasi, ei korvaajasi.

Realistisia skenaarioita, joissa jotkut datatekniikan roolit kutistuvat 📉

Okei, nopea todellisuustarkistus, koska eihän tässä ole pelkkää auringonpaistetta ja emoji-konfetteja 🎉

Jotkut roolit ovat näkyvämpiä:

• Puhtaasti vain nielemiseen tarkoitetut roolit, joissa kaikki on vakioliittimiä Fivetran-liittimet

• Tiimit, jotka käyttävät enimmäkseen toistuvia raportointiprosesseja minimaalisilla toimialueen vivahteilla

• Organisaatiot, joissa datatekniikkaa kohdellaan kuin "SQL-apinoita" (ankaraa, mutta totta)

• Matalan omistajuuden roolit, joissa työ on vain tikettejä ja kopiointia

Tekoäly ja hallitut työkalut voivat pienentää näitä tarpeita.

Mutta sielläkin korvaaminen näyttää yleensä tältä:

• Vähemmän ihmisiä tekee samaa toistuvaa työtä

• Enemmän painoarvoa alustan omistajuudelle ja luotettavuudelle

• Siirtyminen kohti ajatusta "yksi henkilö voi tukea useampaa putkistoa"

Joten kyllä ​​– henkilöstömäärän muutokset voivat tapahtua. Roolit kehittyvät. Tittelit vaihtuvat. Se on totta.

Silti roolin korkean omistajuuden ja luottamuksen versio pysyy yllä.

Loppuyhteenveto 🧾✅

Korvaako tekoäly datainsinöörit? Ei sillä siistillä ja kokonaisvaltaisella tavalla, kuin ihmiset kuvittelevat.

Tekoäly:

• automatisoi toistuvia tehtäviä

• koodauksen, virheenkorjauksen ja dokumentoinnin nopeuttaminen GitHub Copilot for SQL dbt -dokumentaatio

• alentaa putkistojen tuotantokustannuksia

Mutta datatekniikka on pohjimmiltaan kyse:

• vastuuvelvollisuus

• järjestelmän suunnittelu

• luottamus, laatu ja hallintotapa Avoimen datan sopimusstandardi (ODCS) NIST:n tietosuojakehys

• hämärän liiketoimintatodellisuuden kääntäminen luotettaviksi datatuotteiksi

Tekoäly voi auttaa siinä… mutta se ei "omista" sitä.

Jos olet datainsinööri, siirtyminen on yksinkertaista (ei helppoa, mutta yksinkertaista):
keskity omistajuuteen, laatuun, alusta-ajatteluun ja viestintään. Anna tekoälyn hoitaa perusasiat, kun sinä hoidat tärkeät osat.

Ja joo - joskus se tarkoittaa aikuisena olemista huoneessa. Ei glamouria. Hiljaisen voimakasta kylläkin 😄

Korvaako tekoäly datainsinöörit?
Se korvaa joitakin tehtäviä, järjestelee hierarkiaa uudelleen ja tekee parhaista datainsinööreistä entistä arvokkaampia. Se on todellinen tarina.

Käytännön esimerkki: Tekoälyavusteisen dataputken tarkastelutyönkulun rakentaminen 🛠️

Skenaario

Kuvittele pieni verkkokauppayritys, jossa on yksi datainsinööri, kaksi analyytikkoa ja hyvin tuttu ongelma: taloushallintapaneeli kaatuu jatkuvasti aina, kun maksupalveluntarjoaja muuttaa kentän nimeä.

Tiimi ei halua tekoälyn "omistavan" prosessia. Se olisi riskialtista. Sen sijaan he käyttävät tekoälyä ensimmäisen luonnoksen avustajana rutiininomaisissa mutta tärkeissä töissä: DBT-mallirunkojen kirjoittamisessa, testien ehdottamisessa, dokumentaation laatimisessa ja tarkistuslistan luomisessa koodin tarkistusta varten.

Ihmisen datainsinöörin vastuulla on edelleen lopullinen suunnittelu, datamääritelmät, käyttöoikeussäännöt ja tuotantokäyttöönotto. Tekoäly yksinkertaisesti nopeuttaa monimutkaista välivaihetta.

Mitä työnkulku tarvitsee

Ennen tekoälyn käyttöä tiimi antaa sille riittävästi kontekstia, jotta siitä on hyötyä:

• Nykyinen maksutaulukon kaava

• Tavoitetason talousmittareiden määritelmät, kuten ”nettoliikevaihto”, ”hyvityksen määrä” ja ”maksettu maksu”

• DBT-mallien nimeämiskäytännöt

• Esimerkkejä hyväksytyistä testeistä

• Lyhyt datasopimus maksusyötteelle

• Henkilötietojen, epäonnistuneiden maksujen, kaksoiskappaleiden ja myöhässä saapuneiden tietueiden käsittelysäännöt

• Näyte aiemmista tapahtumista, mukaan lukien mikä meni pieleen ja miten se korjattiin

Avain ei ole "pyydä tekoälyä rakentamaan prosessi". Se on liian epämääräistä.

Vahvempi lähestymistapa on: ”Tässä ovat sääntömme, tässä on skeema, tässä on odotettu käyttäytyminen. Laadi luonnos jostakin, mitä voimme tarkastella.”

Esimerkkiohje

Autat laatimaan maksudatallemme DBT-mallia. Käytä alla olevaa kaavaa ja sääntöjä luodaksesi ensimmäisen kierroksen mallin, ehdotetut DBT-testit ja dokumentaatiohuomautukset.

Mallin on laskettava päivittäinen selvitetty tuotto order_id:n ja payment_provider:n perusteella. Sulje pois epäonnistuneet maksut, sulje pois testitapahtumat ja vähennä hyvitykset vain, kun refund_status = "vahvistettu".

Älä keksi sarakkeita. Jos pakollinen sarake puuttuu, listaa se kohtaan ”Kysymykset ihmisen tarkastettavaksi” arvaamisen sijaan.

Ehdota myös testejä ainutlaatuisuuden, null-arvojen, hyväksyttyjen arvojen ja tuottojen kohtuullisuuden varmistamiseksi. Merkitse kaikki logiikka, joka voi vaikuttaa talousraportointiin.

Kuinka testata sitä

Järkevä testi on pieni ja tarkoituksella arkipäiväinen:

• Anna tekoälylle yksi tunnetusti toimiva maksukaava ja tarkista, välttääkö se kenttien keksimisen.

• Anna sille yksi kaava, josta puuttuu refund_status-sarake, ja katso, esittääkö se kysymyksen arvailun sijaan.

• Suorita luotu SQL-komento testiympäristössä olevaa tietojoukkoa vasten, älä tuotantoympäristöä vasten.

• Vertaa tulostetta 20 manuaalisesti tarkistettuun maksutietueeseen.

• Pyydä analyytikkoa ja datainsinööriä tarkistamaan määritelmät ennen yhdistämistä.

• Lisää hyväksytyt testit CI:hen, jotta putki tarkistaa itseään käyttöönoton jälkeen.

Tärkeintä on testata tekoälyä eniten pelkäämiesi vikamuotojen osalta: keksityt sarakkeet, väärä tulologiikka, puuttuva hyvitysten käsittely ja hiljaiset kaksoisrivit.

Tulos

Havainnollistava tulos: perustuu kolmen esimerkkiprosessin muutostehtävän ajoitukseen ennen tämän työnkulun käyttöä ja sen jälkeen.

Ennen tekoälyn käyttöä insinööri käytti noin 5 tuntia 30 minuuttia muutosta kohden: noin 2 tuntia SQL:n kirjoittamiseen, 1 tunnin testien luomiseen, 45 minuuttia dokumenttien kirjoittamiseen ja loput reunatapausten tarkistamiseen rahoitusosastolta.

Kun tekoälyä käytettiin vain ensimmäisiin luonnoksiin, saman tyyppinen muutos kesti noin 2 tuntia 10 minuuttia. Suurin säästö tuli testialustoista ja dokumentaatioluonnoksista, jotka lyhenivät tunnista 45 minuutista noin 25 minuuttiin.

Ihmisen tekemä tarkistusvaihe kesti silti noin 45 minuuttia, eikä sitä pitäisi poistaa.

Kolmivaiheisessa testissä tekoäly ehdotti 18 tarkistusta. Insinööri hyväksyi niistä 11, muokkasi viittä ja hylkäsi kaksi, koska ne olettivat liiketoimintasääntöjen olevan virheellisiä. Hylkäysten määrällä on merkitystä: se osoittaa, että työnkulkua on tarkistettava, ei sokeaa luottamusta.

Mikä voi mennä pieleen

Tekoäly voi saada putkiston näyttämään täydellisemmältä kuin se on.

Yleisiä vikakohtia ovat:

• Uskottavien kuulosttavien sarakkeiden keksiminen

• Hyvitysten, takaisinperintöjen ja epäonnistuneiden maksujen käsittely samalla tavalla

• Puuttuva aikavyöhyke päivittäisissä tuloissa

• Ehdotetaan yleisiä testejä, jotka eivät paljasta rahoitusvirheitä

• Dokumentaation kirjoittaminen, joka kuulostaa varmalta, mutta peittää epävarmuuden

• Tietosuojasääntöjen unohtaminen, kun esimerkkidata sisältää asiakastietoja

Hyvä sääntö: tekoäly voi luonnostella mallin, mutta ihmisen on hyväksyttävä määritelmät, rahalogiikka, käyttöoikeuksien hallinta ja tuotantoon pääsy.

Käytännöllinen noutoruoka

Tekoälyn arvokas versio datatekniikassa ei ole "korvaa datainsinööri", vaan "poista tyhjä sivu ja tarkista asia sitten perusteellisesti".

Se tarkoittaa nopeampaa SQL:ää, nopeampia testejä ja parempaa ensivaiheen dokumentaatiota, samalla kun insinöörillä on edelleen vastuu siitä, millä on eniten merkitystä: onko data oikein, luotettavaa, turvallista ja selitettävissä.

Usein kysytyt kysymykset

Korvaako tekoäly datainsinöörit kokonaan?

Useimmissa organisaatioissa tekoäly todennäköisemmin ottaa haltuunsa tiettyjä tehtäviä kuin poistaa roolin kokonaan. Se voi nopeuttaa SQL-koodin luonnostelua, testiputken rakentamista, dokumentaation ensimmäisiä läpikäyntejä ja perustestien luomista. Mutta datatekniikkaan liittyy myös omistajuus ja vastuuvelvollisuus sekä epämääräinen työ, jolla saadaan sekava liiketoimintatodellisuus toimimaan luotettavan järjestelmän tavoin. Nämä osat tarvitsevat edelleen ihmisiä päättämään, mikä on "oikeaa", ja ottamaan vastuun, kun asiat menevät pieleen.

Mitä datatekniikan osia tekoäly jo automatisoi?

Tekoäly suoriutuu parhaiten toistettavissa tehtävissä: SQL:n luonnostelussa ja uudelleenjärjestelyssä, tietokannan mallirunkojen luomisessa, yleisten virheiden selittämisessä ja dokumentaation rungon luomisessa. Se voi myös tukea testejä, kuten null- tai ainutlaatuisuustarkistuksia, ja luoda mallipohjaista "liimakoodia" orkestrointityökaluille. Voitto on vauhti – aloitat lähempänä toimivaa ratkaisua – mutta sinun on silti validoitava oikeellisuus ja varmistettava, että se sopii ympäristöösi.

Jos tekoäly voi kirjoittaa SQL:ää ja projekteja, mitä datainsinööreille jää?

Paljon: datasopimusten määrittelyä, skeemavaihteluiden käsittelyä ja sen varmistamista, että putket ovat idempotentteja, havaittavissa ja palautettavissa. Datainsinöörit käyttävät aikaa mittareiden muutosten tutkimiseen, suojakaiteiden rakentamiseen jatkokäyttäjille sekä kustannus- ja luotettavuuskompromissejen hallintaan. Työ riippuu usein luottamuksen rakentamisesta ja data-alustan pitämisestä "hiljaisena" eli riittävän vakaana, jotta kenenkään ei tarvitse ajatella sitä päivittäin.

Miten tekoäly muuttaa datainsinöörin jokapäiväistä työtä?

Se tyypillisesti vähentää vakiomuotoisten asioiden ja "hakujen" tarvetta, joten käytät vähemmän aikaa kirjoittamiseen ja enemmän aikaa tarkasteluun, validointiin ja suunnitteluun. Tämä muutos siirtää roolin kohti odotusten, laatustandardien ja uudelleenkäytettävien mallien määrittelyä sen sijaan, että koodaisit kaiken käsin. Käytännössä teet todennäköisesti enemmän kumppanuustyötä tuotteen, tietoturvan ja talouden parissa – koska teknisen tuotoksen luominen helpottuu, mutta sen hallinta vaikeutuu.

Miksi tekoälyllä on vaikeuksia epäselvien liiketoimintamääritelmien, kuten "aktiivinen käyttäjä", kanssa?

Koska liiketoimintalogiikka ei ole staattista tai tarkkaa – se muuttuu projektin aikana ja vaihtelee sidosryhmän mukaan. Tekoäly voi laatia tulkinnan, mutta se ei voi ottaa vastuuta päätöksestä, kun määritelmät kehittyvät tai ristiriitoja ilmenee. Tietojenkäsittelytiede vaatii usein neuvottelua, oletusten dokumentointia ja epämääräisten vaatimusten muuttamista kestäviksi sopimuksiksi. Tämä "ihmisen tekemä yhdenmukaistamistyö" on keskeinen syy siihen, miksi rooli ei katoa, vaikka työkalut kehittyvät.

Voiko tekoäly hoitaa tiedonhallintaa, yksityisyyttä ja vaatimustenmukaisuutta turvallisesti?

Tekoäly voi auttaa käytäntöjen laatimisessa tai lähestymistapojen ehdottamisessa, mutta turvallinen toteutus vaatii silti todellista suunnittelua ja huolellista valvontaa. Hallinto sisältää käyttöoikeuksien hallinnan, henkilötietojen käsittelyn, säilytyssäännöt, tarkastuspolut ja joskus sijaintirajoitukset. Nämä ovat riskialttiita alueita, joilla "melkein oikein" ei ole hyväksyttävää. Ihmisten on suunniteltava säännöt, varmistettava niiden täytäntöönpano ja oltava vastuussa vaatimustenmukaisuuden tuloksista.

Mitkä taidot pysyvät arvokkaina datainsinööreille tekoälyn kehittyessä?

Järjestelmien resilienssiä tekevät taidot: järjestelmäsuunnittelun ajattelu, datan laadun suunnittelu ja alustalähtöinen standardointi. Sopimukset, havainnoitavuus, tapauksiin reagointitavat ja kurinalainen perussyyanalyysi tulevat entistä tärkeämmiksi, kun useammat ihmiset voivat luoda dataan liittyviä esineitä nopeasti. Myös viestinnästä tulee erottava tekijä – määritelmien yhdenmukaistaminen, selkeiden dokumenttien kirjoittaminen ja kompromissien selittäminen ilman draamaa on tärkeä osa datan luotettavuuden säilyttämistä.

Mitkä datatekniikan roolit ovat eniten alttiita tekoälyn ja hallittujen työkalujen riskeille?

Roolit, jotka keskittyvät kapeasti toistuvaan tiedonkeruuseen tai standardiraportointiputkiin, ovat alttiimpia, varsinkin kun hallitut ELT-liittimet kattavat useimmat lähteet. Vähäomisteinen, tikettipohjainen työ voi kutistua, koska tekoäly ja abstraktio vähentävät putkikohtaista työmäärää. Mutta tämä tarkoittaa yleensä sitä, että toistuvia tehtäviä tekeviä ihmisiä on vähemmän, eikä sitä, että "tietoinsinöörejä ei ole ollenkaan". Korkean omistajuuden omaavat roolit, jotka keskittyvät luotettavuuteen, laatuun ja luottamukseen, pysyvät kestävinä.

Miten minun pitäisi käyttää työkaluja, kuten GitHub Copilot tai dbt, tekoälyn kanssa aiheuttamatta kaaosta?

Käsittele tekoälyn tuotosta luonnoksena, älä päätöksenä. Käytä sitä kyselyrunkojen luomiseen, luettavuuden parantamiseen tai datapohjaisten testien ja dokumenttien tukemiseen ja validoi ne sitten todellista dataa ja reunatapauksia vasten. Yhdistä se vahvoihin käytäntöihin: sopimuksiin, nimeämisstandardeihin, havaittavuustarkistuksiin ja tarkistuskäytäntöihin. Tavoitteena on nopeampi toimitus tinkimättä luotettavuudesta, kustannusten hallinnasta tai hallinnasta.

Viitteet

1. Euroopan komissio - Tietosuojan selitys: GDPR:n periaatteet - commission.europa.eu

2. Tietosuojavaltuutetun toimisto (ICO) - Tallennusrajoitus - ico.org.uk

3. Euroopan komissio - Kuinka kauan tietoja voidaan säilyttää ja onko niitä tarpeen päivittää? - commission.europa.eu

4. Yhdysvaltain kansallinen standardi- ja teknologiainstituutti (NIST) - Tietosuojakehys - nist.gov

5. NIST:n tietoturvaresurssikeskus (CSRC) - SP 800-92: Opas tietoturvalokien hallintaan - csrc.nist.gov

6. Internet-tietoturvakeskus (CIS) - Auditointilokien hallinta (CIS-kontrollit) - cisecurity.org

7. Snowflaken dokumentaatio - Rivien käyttöoikeuskäytännöt - docs.snowflake.com

8. Google Cloud -dokumentaatio - BigQueryn rivitason suojaus - docs.cloud.google.com

9. BITOL - Avoimen datan sopimusstandardi (ODCS) v3.1.0 - bitol-io.github.io

10. BITOL (GitHub) - Avoimen datan sopimusstandardi - github.com

11. Apache Airflow - Dokumentaatio (vakaa) - airflow.apache.org

12. Apache Airflow - DAGit (ydinkäsitteet) - airflow.apache.org

13. dbt Labsin dokumentaatio - Mikä on dbt? - docs.getdbt.com

14. dbt Labs -dokumentaatio - Tietoja dbt-malleista - docs.getdbt.com

15. dbt Labsin dokumentaatio - Dokumentaatio - docs.getdbt.com

16. dbt Labs -dokumentaatio - Datatestit - docs.getdbt.com

17. dbt Labs -dokumentaatio - dbt:n semanttinen kerros - docs.getdbt.com

18. Fivetranin dokumentaatio - Aloittaminen - fivetran.com

19. Fivetran - Liittimet - fivetran.com

20. AWS-dokumentaatio - AWS Lambda -kehittäjän opas - docs.aws.amazon.com

21. GitHub - GitHub-kopiopilotti - github.com

22. GitHub-dokumentaatio - Koodiehdotusten hankkiminen IDE-ympäristössäsi GitHub Copilotin avulla - docs.github.com

23. Microsoft Learn - GitHub Copilot for SQL (VS Code -laajennus) - learn.microsoft.com

24. Dynatrace-dokumentaatio - Datan havaittavuus - docs.dynatrace.com

25. DataGalaxy - Mitä on datan havaittavuus? - datagalaxy.com

26. Great Expectations -dokumentaatio - Odotusten yleiskatsaus - docs.greatexpectations.io

Löydä uusimmat tekoälytuotteet virallisesta tekoälyavustajakaupasta

Tietoa meistä