Ar dirbtinis intelektas pakeis duomenų inžinierius?

Ar dirbtinis intelektas pakeis duomenų inžinierius?

Trumpas atsakymas: DI visiškai nepakeis duomenų inžinierių; jis automatizuos pasikartojančius darbus, tokius kaip SQL braižymas, duomenų srauto pastoginė sistema, testavimas ir dokumentavimas. Jei jūsų vaidmuo daugiausia susijęs su mažu atsakomybės lygiu ir bilietų pagrindu atliekamu darbu, jis yra labiau pažeidžiamas; jei esate atsakingi už patikimumą, apibrėžimus, valdymą ir reagavimą į incidentus, DI daugiausia padidina jūsų greitį.

Svarbiausios išvados:

Atsakomybė : pirmenybę teikite atsakomybei už rezultatus, o ne tik greitam kodo kūrimui.

Kokybė : kurkite testus, užtikrinkite stebimumą ir sutarčių kūrimą, kad vamzdynai išliktų patikimi.

Valdymas : privatumą, prieigos kontrolę, duomenų saugojimą ir audito įrašus palaikykite žmonių rankose.

Apsauga nuo netinkamo naudojimo : dirbtinio intelekto rezultatus traktuokite kaip juodraščius; peržiūrėkite juos, kad išvengtumėte klaidingų įsitikinimų.

Paremybių pasikeitimas : mažiau laiko skirkite standartinių tekstų rašymui ir daugiau laiko – patvarių sistemų projektavimui.

Ar dirbtinis intelektas pakeis duomenų inžinierius? Infografika

Jei praleidote daugiau nei penkias minutes su duomenų komandomis, tikriausiai girdėjote šį posakį – kartais pašnibždomis, kartais – tarsi netikėtą siužeto posūkį susitikimo metu: Ar dirbtinis intelektas pakeis duomenų inžinierius?

Ir… suprantu. Dirbtinis intelektas gali generuoti SQL, kurti srautus, paaiškinti steko pėdsakus, parengti duomenų bazių modelius ir netgi siūlyti sandėlio schemas su nerimą keliančiu pasitikėjimu. „GitHub Copilot“, skirtas SQL. Apie duomenų bazių modelius. „GitHub Copilot“.
Jaučiasi lyg stebėtumėte, kaip šakinis krautuvas mokosi žongliruoti. Įspūdinga, šiek tiek nerimą kelianti, ir nesate iki galo tikri, ką tai reiškia jūsų darbui 😅

Tačiau tiesa ne tokia aiški kaip antraštė. Dirbtinis intelektas (DI) visiškai keičia duomenų inžineriją. Jis automatizuoja nuobodžius, pasikartojančius elementus. Jis pagreitina momentus, kai „žinau, ko noriu, bet negaliu prisiminti sintaksės“. Jis taip pat kuria visiškai naujas chaoso rūšis.

Tad išdėstykime viską tinkamai, be optimizmo ar panikos, grasinančios pražūčiai.

Straipsniai, kuriuos galbūt norėsite perskaityti po šio:

🔗 Ar dirbtinis intelektas pakeis radiologus?
Kaip vaizdavimo dirbtinis intelektas keičia darbo eigą, tikslumą ir būsimus vaidmenis.

🔗 Ar dirbtinis intelektas pakeis buhalterius?
Sužinokite, kurias apskaitos užduotis automatizuoja dirbtinis intelektas, o kurias lieka atlikti žmonėms.

🔗 Ar dirbtinis intelektas pakeis investicinius bankininkus?
Supraskite dirbtinio intelekto poveikį sandoriams, tyrimams ir klientų santykiams.

🔗 Ar dirbtinis intelektas pakeis draudimo agentus?
Sužinokite, kaip dirbtinis intelektas transformuoja draudimo rizikos vertinimą, pardavimus ir klientų aptarnavimą.

Kodėl klausimas „DI pakeičia duomenų inžinierius“ nuolat iškyla 😬

Baimė kyla iš labai konkrečios vietos: duomenų inžinerijoje yra daug pasikartojančio darbo .

  • SQL rašymas ir pertvarkymas

  • Įterpimo scenarijų kūrimas

  • Laukų susiejimas iš vienos schemos į kitą

  • Testų ir pagrindinės dokumentacijos kūrimas

  • Derinimo vamzdynų gedimai, kurie yra... gana nuspėjami

Dirbtinis intelektas neįprastai gerai pasikartojančių šablonų srityje. Ir didelė duomenų inžinerijos dalis yra būtent tai – šablonai, sukrauti ant šablonų. „GitHub Copilot“ kodo pasiūlymai

Be to, įrankių ekosistema jau „slepia“ sudėtingumą:

Taigi, kai pasirodo dirbtinis intelektas, jis gali atrodyti kaip paskutinė dalis. Jei stekas jau yra abstrahuotas ir dirbtinis intelektas gali parašyti sujungimo kodą... kas lieka? 🤷

Tačiau štai ką žmonės praleidžia: duomenų inžinerija nėra daugiausia spausdinimas . Spausdinimas yra lengviausia dalis. Sunkiausia yra priversti miglotą, politinę, besikeičiančią verslo realybę elgtis kaip patikimą sistemą.

Ir dirbtinis intelektas vis dar sunkiai sprendžia šią problemą. Žmonėms taip pat sunku – jie tiesiog geriau improvizuoja.

Ką duomenų inžinieriai iš tikrųjų veikia visą dieną (negraži tiesa) 🧱

Būkime atviri – pareigybės pavadinimas „Duomenų inžinierius“ skamba taip, lyg konstruotumėte raketinius variklius remdamiesi gryna matematika. Praktiškai jūs kuriate pasitikėjimą .

Įprasta diena yra mažiau „naujų algoritmų išradimo“ ir daugiau:

  • Derybos su aukštesnio lygio komandomis dėl duomenų apibrėžimų (skausmingos, bet būtinos)

  • Metrikos pasikeitimo priežasčių (ir jos realybės) tyrimas

  • Schemos dreifo tvarkymas ir netikėtumai „kažkas pridėjo stulpelį vidurnaktį“

  • Užtikrinti, kad vamzdynai būtų idempotentiniai, atkuriami ir stebimi

  • Apsauginių turėklų kūrimas, kad tolesni analitikai netyčia nesukurtų nesąmoningų ataskaitų suvestinių

  • Valdyti išlaidas, kad jūsų sandėlis netaptų pinigų laužu 🔥

  • Prieigos užtikrinimas, auditas, atitiktis, saugojimo politika BDAR principai (Europos Komisija) Saugojimo apribojimas (ICO)

  • Kuriame duomenų produktus, kuriuos žmonės galėtų naudoti be asmeninių žinučių (20 klausimų)

Didelė darbo dalis yra socialinė ir operatyvinė:

  • „Kam priklauso šis stalas?“

  • "Ar šis apibrėžimas vis dar galioja?"

  • „Kodėl CRM eksportuoja dublikatus?“

  • „Ar galime be jokio gėdos perduoti šią metriką vadovams?“ 😭

Dirbtinis intelektas, žinoma, gali padėti su tam tikromis dalimis. Tačiau visiškai jį pakeisti yra... sudėtinga.

Kas lemia stiprią duomenų inžinerijos vaidmens versiją? ✅

Šis skyrius svarbus, nes kalbant apie pakeitimą, paprastai daroma prielaida, kad duomenų inžinieriai daugiausia yra „vamzdynų kūrėjai“. Tai tas pats, kas manyti, kad virėjai daugiausia „kapoja daržoves“. Tai yra darbo dalis, bet ne darbas.

Stipri duomenų inžinieriaus versija paprastai reiškia, kad jis gali atlikti daugumą šių užduočių:

  • Kurkite pokyčius.
    Duomenys keičiasi. Komandos keičiasi. Įrankiai keičiasi. Geras inžinierius kuria sistemas, kurios nesugriūva kiekvieną kartą, kai realybė pasimeta. 🤧

  • Apibrėžkite sutartis ir lūkesčius.
    Ką reiškia „klientas“? Ką reiškia „aktyvus“? Kas nutinka, kai eilutė atkeliauja pavėluotai? Sutartys padeda išvengti chaoso labiau nei įmantrus kodas. Atvirųjų duomenų sutarčių standartas (ODCS) ODCS (GitHub).

  • Integruokite stebimumą į viską.
    Ne tik „ar veikė“, bet ir „ar veikė teisingai“. Naujumas, apimties anomalijos, nuliniai sprogimai, pasiskirstymo pokyčiai. Duomenų stebimumas („Dynatrace“). Kas yra duomenų stebimumas?

  • Darykite kompromisus kaip suaugęs žmogus:
    greitis ir tikslumas, kaina ir delsa, lankstumas ir paprastumas. Nėra tobulo srauto, tik srautai, su kuriais galite gyventi.

  • Verslo poreikius paverskite patvariomis sistemomis.
    Žmonės prašo metrikų, bet jiems reikia duomenų produkto. Dirbtinis intelektas gali parašyti kodą, bet negali stebuklingai žinoti verslo minų.

  • Nuslėpkite duomenis.
    Didžiausias duomenų platformos komplimentas yra tai, kad niekas apie ją nekalba. Nesudėtingi duomenys yra geri duomenys. Kaip santechnika. Juos pastebi tik tada, kai jie sugenda.

Jei darote šiuos dalykus, klausimas „Ar dirbtinis intelektas pakeis duomenų inžinierius?“ pradeda skambėti... šiek tiek ne taip. Dirbtinis intelektas gali pakeisti užduotis , o ne nuosavybę .

Kur DI jau padeda duomenų inžinieriams (ir tai išties puiku) 🤖✨

Dirbtinis intelektas yra ne tik rinkodara. Tinkamai naudojamas, jis yra teisėtas jėgos daugiklis.

1) Greitesnis SQL ir transformacijų darbas

  • Sudėtingų jungčių braižymas

  • Langų funkcijų rašymas, apie kurį nenorėtumėte galvoti

  • Paprastos kalbos logikos pavertimas užklausų skeletais

  • Negražių užklausų pertvarkymas į skaitomus CTE GitHub Copilot for SQL

Tai labai svarbu, nes sumažina „tuščio puslapio“ efektą. Vis tiek reikia patvirtinti, bet pradedama nuo 70 %, o ne nuo 0 %.

2) Derinimo ir pagrindinių priežasčių paieškos nuorodos

Dirbtinis intelektas yra tinkamas:

  • Klaidų pranešimų paaiškinimas

  • Patarimai, kur ieškoti

  • Rekomenduojami „schemos neatitikimo patikrinimo“ tipo veiksmai GitHub Copilot
    Tai tarsi nenuilstamas jaunesnysis inžinierius, kuris niekada nemiega ir kartais užtikrintai meluoja 😅

3) Dokumentacijos ir duomenų katalogo praturtinimas

Automatiškai sugeneruota:

  • Stulpelių aprašymai

  • Modelių santraukos

  • Kilmės paaiškinimai

  • „Kam naudojama ši lentelė?“ – rengia DBT dokumentaciją

Tai nėra tobula, bet sulaužo nedokumentuotų vamzdynų prakeiksmą.

4) Pastolių bandymas ir patikrinimas

Dirbtinis intelektas gali pasiūlyti:

Vėlgi – jūs vis tiek sprendžiate, kas svarbu, bet tai pagreitina įprastas dalis.

5) Vamzdynų „klijų“ kodas

Konfigūracijos šablonai, YAML pastoliai, orkestravimo DAG juodraščiai. Šie dalykai yra pasikartojantys, o dirbtinis intelektas pusryčiams valgo pasikartojančius dalykus 🥣 „Apache Airflow“ DAG'ai

Kur dirbtinis intelektas vis dar sunkiai sprendžia problemas (ir tai yra to esmė) 🧠🧩

Ši dalis yra svarbiausia, nes ji atsako į pakeitimo klausimą su tikra tekstūra.

1) Dviprasmybė ir besikeičiantys apibrėžimai

Verslo logika retai kada būna aiški. Žmonės persigalvoja sakinio viduryje. „Aktyvus vartotojas“ tampa „aktyvus mokantis vartotojas“ tampa „aktyvus mokantis vartotojas, išskyrus grąžinimus, išskyrus kartais“... žinote, kaip būna.

Dirbtinis intelektas negali susitaikyti su tuo dviprasmiškumu. Jis gali tik spėlioti.

2) Atskaitomybė ir rizika

Kai nutrūksta vamzdynas ir vykdymo ataskaitų skydelyje rodoma nesąmonė, kažkas turi:

  • triažas

  • pranešti apie poveikį

  • pataisyti

  • užkirsti kelią pasikartojimui

  • parašykite pomirtinį tyrimą

  • nuspręsti, ar įmonė vis dar gali pasitikėti praėjusios savaitės skaičiais

Dirbtinis intelektas gali padėti, bet negali būti prasmingai atskaitingas. Organizacijos veikia ne vadovaudamosi emocijomis – jos veikia vadovaudamosi atsakomybe.

3) Sisteminis mąstymas

Duomenų platformos yra ekosistemos: įtraukimas, saugojimas, transformacijos, orkestravimas, valdymas, sąnaudų kontrolė, SLA. Vieno sluoksnio pokytis sukelia raibulius. „Apache Airflow“ koncepcijos.

Dirbtinis intelektas gali pasiūlyti vietinius optimizavimus, kurie sukelia pasaulinį skausmą. Tai tas pats, kas pataisyti girgždančias duris jas išimant 😬

4) Saugumas, privatumas, atitiktis

Čia miršta pakeitimo fantazijos.

Dirbtinis intelektas gali parengti politikas, bet saugus jų įgyvendinimas yra tikra inžinerija.

5) „Nežinomi nežinomieji“

Duomenų incidentai dažnai yra nenuspėjami:

  • Tiekėjo API tyliai keičia semantiką

  • Laiko juostos prielaida apsiverčia

  • Užpildymas dubliuoja skaidinį

  • Pakartotinio bandymo mechanizmas sukelia dvigubą rašymą

  • Nauja produkto funkcija pristato naujus įvykių modelius

Dirbtinis intelektas yra silpnesnis, kai situacija nėra žinomas modelis.

Palyginimo lentelė: kas ką sumažina praktiškai 🧾🤔

Žemiau pateikiamas praktinis požiūris. Ne „įrankiai, kurie pakeičia žmones“, o įrankiai ir metodai, kurie sumažina tam tikrų užduočių skaičių.

Įrankis / metodas Auditorija Kainos vibracija Kodėl tai veikia
Dirbtinio intelekto kodo kopiliukai (SQL + Python pagalbininkai) GitHub Copilot Inžinieriai, kurie rašo daug kodo Nuo nemokamos iki mokamos Puikiai sekasi kurti pastolius, pertvarkyti elementus, sintaksę... kartais labai savitai pasipuikuoti
Valdomos ELT jungtys Fivetran Komandos pavargo nuo kūrimo integravimo Prenumeratos Pašalina skausmą, kurį sukelia tinkintas rijimas, bet sugenda įdomiais naujais būdais
Duomenų stebėjimo platformos Duomenų stebėjimas („Dynatrace“) Kiekvienas, turintis SLA Vidutinio ir didelio verslo Anksti aptinka anomalijas – pavyzdžiui, dūmų detektorius vamzdynuose 🔔
Transformacijos karkasai (deklaratyvus modeliavimas) dbt Analizės + DE hibridai Paprastai įrankis + skaičiavimas Padaro logiką modulinę ir testuojamą, mažiau „spagečių“
Duomenų katalogai + semantiniai sluoksniai dbt semantinis sluoksnis Organizacijos, kuriose painiava dėl metrikų Priklauso nuo praktikos Apibrėžia „tiesą“ vieną kartą – sumažina nesibaigiančias diskusijas apie metriką
Orkestravimas naudojant šablonus „Apache Airflow“ Platformomis paremtos komandos Atidarymo + operacijų kaina Standartizuoja darbo eigas; mažiau snaigių formos DAG'ų
Dirbtinio intelekto pagalba sukurta dokumentacija (dbt) Komandos, kurios nekenčia rašyti dokumentų Pigus arba vidutinis Kuria „pakankamai gerus“ dokumentus, kad žinios neišnyktų
Automatizuoto valdymo politikos NIST privatumo sistema Reguliuojama aplinka Įmonių sričiai Padeda užtikrinti taisyklių laikymąsi, tačiau vis tiek reikia, kad jas sukurtų žmonės

Atkreipkite dėmesį, ko trūksta: eilutės, kurioje parašyta „paspauskite mygtuką, kad pašalintumėte duomenų inžinierius“. Taip... tos eilutės nėra 🙃

Taigi… ar dirbtinis intelektas pakeis duomenų inžinierius, ar tiesiog pakeis jų vaidmenį? 🛠️

Štai nedramatiškas atsakymas: dirbtinis intelektas pakeis dalį darbo eigos, o ne profesiją.

Bet tai pakeis vaidmenį. O jei tai ignoruosite, pajusite spaudimą.

Kas keičiasi:

  • Mažiau laiko praleidžiama rašant standartinius tekstus

  • Mažiau laiko dokumentų paieškai

  • Daugiau laiko peržiūrai, patvirtinimui, projektavimui

  • Daugiau laiko sutarčių ir kokybės lūkesčių apibrėžimui Atvirųjų duomenų sutarčių standartas (ODCS)

  • Daugiau laiko bendradarbiavimui produktų, saugumo ir finansų srityse

Tai subtilus pokytis: duomenų inžinerija tampa mažiau susijusi su „vamzdynų kūrimu“ ir daugiau su „patikimos duomenų produktų sistemos kūrimu“

Ir tyliai tariant, tai vertingiau, o ne mažiau.

Be to – ir pasakysiu tai net jei tai skambės dramatiškai – dirbtinis intelektas padidina žmonių, galinčių kurti duomenų artefaktus, skaičių , todėl reikia, kad kažkas prižiūrėtų visą sistemą. Didesnė išvestis reiškia daugiau galimos painiavos. „GitHub Copilot“.

Tai tas pats, kas visiems duoti elektrinį grąžtą. Puiku! Dabar kažkas turi užtikrinti, kad būtų taikoma taisyklė „prašau negręžti į vandens vamzdį“ 🪠

Naujas įgūdžių rinkinys, kuris išlieka vertingas (net ir tada, kai visur yra dirbtinis intelektas) 🧠⚙️

Jei norite praktiško „ateičiai atsparaus“ kontrolinio sąrašo, jis atrodo taip:

Sistemos projektavimo mąstysena

  • Duomenų modeliavimas, kuris išlieka pokyčiuose

  • Paketinio ir srautinio perdavimo kompromisai

  • Vėlavimo, kainos ir patikimumo mąstymas

Duomenų kokybės inžinerija

Valdymo ir pasitikėjimo architektūra

Platforminis mąstymas

  • Daugkartinio naudojimo šablonai, auksiniai takai

  • „Fivetran “ duomenų įkėlimo, transformavimo ir testavimo modeliai

  • Savitarnos įrankiai, kurie nesilydo

Bendravimas (taip, tikrai)

  • Aiškių dokumentų rašymas

  • Apibrėžimų suderinimas

  • Mandagiai, bet tvirtai sakyti „ne“

  • Kompromisų paaiškinimas neskambant kaip robotui 🤖

Jei galite tai padaryti, klausimas „Ar dirbtinis intelektas pakeis duomenų inžinierius?“ tampa mažiau grėsmingas. Dirbtinis intelektas tampa jūsų egzoskeletu, o ne pakaitalu.

Realūs scenarijai, kai kai kurie duomenų inžinerijos vaidmenys susitraukia 📉

Gerai, greitas realybės patikrinimas, nes ne viskas tik saulė ir jaustukų konfeti 🎉

Kai kurie vaidmenys yra labiau matomi:

  • Grynai tik įtraukimui skirti vaidmenys, kuriuose viskas yra standartinės jungtys „Fivetran“ jungtys

  • Komandos, daugiausia atliekančios pasikartojančius ataskaitų teikimo procesus su minimaliais srities niuansais

  • Organizacijos, kuriose duomenų inžinerija traktuojama kaip „SQL beždžionės“ (griežta, bet tiesa)

  • Mažos atsakomybės pareigos, kai darbas tėra bilietai ir kopijavimas bei įklijavimas

Dirbtinis intelektas ir valdomi įrankiai gali sumažinti šiuos poreikius.

Bet net ir ten pakeitimas paprastai atrodo taip:

  • Mažiau žmonių atlieka tą patį pasikartojantį darbą

  • Didesnis dėmesys platformos nuosavybei ir patikimumui

  • Poslinkis link „vienas žmogus gali prižiūrėti daugiau vamzdynų“

Taigi, taip – ​​darbuotojų skaičiaus modeliai gali keistis. Pareigos kinta. Pareigos keičiasi. Ši dalis yra tikra.

Vis dėlto išlieka ta vaidmens versija, kurioje dominuoja atsakomybė ir pasitikėjimas.

Baigiamoji santrauka 🧾✅

Ar dirbtinis intelektas pakeis duomenų inžinierius? Ne tokiu švariu ir visapusišku būdu, kaip žmonės įsivaizduoja.

Dirbtinis intelektas (DI) atliks šiuos veiksmus:

Tačiau duomenų inžinerija iš esmės yra apie:

Dirbtinis intelektas gali padėti... bet jis to „nevaldo“.

Jei esate duomenų inžinierius, žingsnis paprastas (ne lengvas, bet paprastas):
sutelkite dėmesį į atsakomybę, kokybę, platforminį mąstymą ir komunikaciją. Leiskite dirbtiniam intelektui tvarkyti standartinius procesus, o jūs – svarbiausias dalis.

Ir taip – ​​kartais tai reiškia būti suaugusiuoju kambaryje. Ne žavinga. Bet tyliai galinga 😄

Ar dirbtinis intelektas pakeis duomenų inžinierius?
Jis pakeis kai kurias užduotis, pertvarkys karjeros laiptus ir geriausius duomenų inžinierius padarys dar vertingesnius. Tokia yra tikroji istorija.

DUK

Ar dirbtinis intelektas visiškai pakeis duomenų inžinierius?

Daugumoje organizacijų dirbtinis intelektas labiau linkęs perimti konkrečias užduotis, o ne visiškai panaikinti vaidmenį. Jis gali paspartinti SQL kūrimą, duomenų srauto pastogę, pirmuosius dokumentacijos bandymus ir pagrindinių testų kūrimą. Tačiau duomenų inžinerija taip pat apima atsakomybę ir atskaitomybę, be to, atlieka nepatrauklų darbą, kad netvarkinga verslo realybė elgtųsi kaip patikima sistema. Šioms dalims vis tiek reikia žmonių, kad jie nuspręstų, kas atrodo „teisinga“, ir prisiimtų atsakomybę, kai kas nors sugenda.

Kokias duomenų inžinerijos dalis dirbtinis intelektas jau automatizuoja?

Dirbtinis intelektas geriausiai veikia atliekant pasikartojančius darbus: rengiant ir pertvarkant SQL, generuojant duomenų bazės modelio skeletus, aiškinant dažniausiai pasitaikančias klaidas ir rengiant dokumentacijos metmenis. Jis taip pat gali paremti tokius testus kaip nulinės vertės arba unikalumo patikrinimai ir generuoti šabloninį „sujungimo“ kodą orkestravimo įrankiams. Laimėtojas yra pagreitis – pradedate arčiau veikiančio sprendimo, – tačiau vis tiek turite patikrinti teisingumą ir užtikrinti, kad jis atitiktų jūsų aplinką.

Jei dirbtinis intelektas gali rašyti SQL ir duomenų srautus, kas lieka duomenų inžinieriams?

Daug: duomenų sutarčių apibrėžimas, schemų dreifo valdymas ir užtikrinimas, kad duomenų srautai būtų idempotentiniai, stebimi ir atkuriami. Duomenų inžinieriai skiria laiko metrikų pokyčių tyrimui, apsauginių barjerų kūrimui tolesniems vartotojams ir sąnaudų bei patikimumo kompromisų valdymui. Darbas dažnai priklauso nuo pasitikėjimo kūrimo ir duomenų platformos „tylios“, t. y. pakankamai stabilios, kad niekam nereikėtų apie tai galvoti kasdien, užtikrinimo.

Kaip dirbtinis intelektas keičia duomenų inžinieriaus kasdienį darbą?

Paprastai tai sutrumpina standartinių tekstų ir „paieškų“ laiką, todėl mažiau laiko praleidžiate rašydami ir daugiau peržiūrėdami, tikrindami ir kurdami dizainą. Šis pokytis nukreipia vaidmenį į lūkesčių, kokybės standartų ir pakartotinai naudojamų modelių apibrėžimą, o ne visko programavimą rankiniu būdu. Praktiškai greičiausiai daugiau bendradarbiausite su produktu, saugumu ir finansais, nes techninę išvestį tampa lengviau kurti, bet sunkiau valdyti.

Kodėl dirbtiniam intelektui sunku suprasti dviprasmiškus verslo apibrėžimus, tokius kaip „aktyvus vartotojas“?

Kadangi verslo logika nėra statiška ar tiksli – ji keičiasi projekto metu ir priklauso nuo suinteresuotųjų šalių. Dirbtinis intelektas gali parengti interpretaciją, bet negali prisiimti atsakomybės už sprendimą, kai apibrėžimai keičiasi arba iškyla konfliktų. Duomenų inžinerija dažnai reikalauja derybų, prielaidų dokumentavimo ir neaiškių reikalavimų pavertimo ilgalaikėmis sutartimis. Šis „žmogaus derinimo“ darbas yra pagrindinė priežastis, kodėl ši pareigybė neišnyksta net ir tobulėjant įrankiams.

Ar dirbtinis intelektas gali saugiai valdyti duomenis, užtikrinti privatumą ir atitikties reikalavimus?

Dirbtinis intelektas gali padėti parengti politikos rengimo programas arba siūlyti metodus, tačiau saugiam įgyvendinimui vis tiek reikalinga reali inžinerija ir kruopšti priežiūra. Valdymas apima prieigos kontrolę, asmens duomenų tvarkymą, saugojimo taisykles, audito taką ir kartais rezidavimo apribojimus. Tai didelės rizikos sritys, kuriose „beveik teisinga“ nėra priimtina. Žmonės turi kurti taisykles, tikrinti jų vykdymą ir prisiimti atsakomybę už atitikties rezultatus.

Kokie duomenų inžinierių įgūdžiai išlieka vertingi tobulėjant dirbtiniam intelektui?

Įgūdžiai, užtikrinantys sistemų atsparumą: sistemų projektavimo mąstymas, duomenų kokybės inžinerija ir platforminis standartizavimas. Sutartys, stebimumas, incidentų reagavimo įpročiai ir drausminga pagrindinių priežasčių analizė tampa dar svarbesnės, kai daugiau žmonių gali greitai generuoti duomenų artefaktus. Bendravimas taip pat tampa skiriamuoju bruožu – apibrėžimų suderinimas, aiškių dokumentų rašymas ir kompromisų paaiškinimas be dramos yra svarbi duomenų patikimumo dalis.

Kuriems duomenų inžinerijos vaidmenims dirbtinis intelektas ir valdomi įrankiai kelia didžiausią pavojų?

Pareigos, siaurai orientuotos į pasikartojantį duomenų įkėlimą arba standartines ataskaitų teikimo sistemas, yra labiau pažeidžiamos, ypač kai valdomos ELT jungtys apima daugumą šaltinių. Mažai atsakomybės reikalaujantis, bilietais pagrįstas darbas gali susitraukti, nes dirbtinis intelektas ir abstrakcija sumažina kiekvienam srautui reikalingas pastangas. Tačiau paprastai tai atrodo kaip mažiau žmonių, atliekančių pasikartojančias užduotis, o ne „nėra duomenų inžinierių“. Didelės atsakomybės pareigos, orientuotos į patikimumą, kokybę ir pasitikėjimą, išlieka ilgalaikės.

Kaip turėčiau naudoti tokius įrankius kaip „GitHub Copilot“ ar „dbt“ su dirbtiniu intelektu nesukeldamas chaoso?

Dirbtinio intelekto išvestį traktuokite kaip juodraštį, o ne sprendimą. Naudokite ją užklausų šablonams generuoti, skaitomumui pagerinti arba duomenų bazių testams ir dokumentams parengti, o tada patikrinkite pagal realius duomenis ir kraštutinius atvejus. Derinkite tai su griežtomis konvencijomis: sutartimis, pavadinimų standartais, stebimumo patikrinimais ir peržiūros praktika. Tikslas – greitesnis pateikimas neaukojant patikimumo, sąnaudų kontrolės ar valdymo.

Nuorodos

  1. Europos Komisija – Duomenų apsaugos paaiškinimas: BDAR principai – commission.europa.eu

  2. Informacijos komisaro biuras (ICO) – Saugojimo apribojimas – ico.org.uk

  3. Europos Komisija – Kiek laiko galima saugoti duomenis ir ar juos reikia atnaujinti? – commission.europa.eu

  4. Nacionalinis standartų ir technologijų institutas (NIST) – Privatumo sistema – nist.gov

  5. NIST kompiuterių saugumo išteklių centras (CSRC) – SP 800-92: Kompiuterių saugumo žurnalų valdymo vadovas – csrc.nist.gov

  6. Interneto saugumo centras (CIS) – Audito žurnalų valdymas (CIS valdikliai) – cisecurity.org

  7. „Snowflake“ dokumentacija – eilučių prieigos politikos – docs.snowflake.com

  8. „Google Cloud“ dokumentacija – „BigQuery“ eilutės lygio saugumas – docs.cloud.google.com

  9. BITOL – Atvirųjų duomenų sutarčių standartas (ODCS) v3.1.0 – bitol-io.github.io

  10. BITOL (GitHub) – Atvirųjų duomenų sutarčių standartas – github.com

  11. „Apache Airflow“ – dokumentacija (stabili) – airflow.apache.org

  12. „Apache Airflow“ – DAG (pagrindinės koncepcijos) – airflow.apache.org

  13. dbt laboratorijų dokumentacija – Kas yra dbt? – docs.getdbt.com

  14. dbt Labs dokumentacija – Apie dbt modelius – docs.getdbt.com

  15. dbt Labs dokumentacija - Dokumentacija - docs.getdbt.com

  16. dbt Labs dokumentacija – duomenų testai – docs.getdbt.com

  17. dbt Labs dokumentacija – dbt semantinis sluoksnis – docs.getdbt.com

  18. „Fivetran“ dokumentacija – Pradžia – fivetran.com

  19. Fivetran – Jungtys – fivetran.com

  20. AWS dokumentacija – AWS Lambda kūrėjo vadovas – docs.aws.amazon.com

  21. „GitHub“ – „GitHub“ kopilotas – github.com

  22. „GitHub“ dokumentai – kodo pasiūlymų gavimas IDE naudojant „GitHub Copilot“ – docs.github.com

  23. „Microsoft Learn“ – „GitHub Copilot for SQL“ (VS kodo plėtinys) – learn.microsoft.com

  24. „Dynatrace“ dokumentacija – duomenų stebimumas – docs.dynatrace.com

  25. DataGalaxy – Kas yra duomenų stebimumas? – datagalaxy.com

  26. „Didžiųjų lūkesčių“ dokumentacija – lūkesčių apžvalga – docs.greatexpectations.io

Raskite naujausią dirbtinį intelektą oficialioje dirbtinio intelekto asistentų parduotuvėje

Apie mus

Atgal į tinklaraštį