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.

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ą:

• Tvarkomų ELT jungčių „Fivetran“ dokumentai

• Be serverio skaičiavimas AWS Lambda (be serverio skaičiavimas)

• Sandėlio paruošimas vienu spustelėjimu

• Automatinio mastelio keitimo orkestravimo „Apache Airflow“ dokumentai

• Deklaratyvios transformacijos sistemos. Kas yra dbt?

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:

• Pagrindiniai nuliniai testai

• Unikalumo patikrinimai

• Referencinio vientisumo idėjos

• „Šis rodiklis niekada neturėtų mažėti“ stiliaus teiginiai DBT duomenų testai Didieji lūkesčiai: lūkesčiai

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.

• Prieigos kontrolė

• Eilučių lygio saugumas „Snowflake“ eilučių prieigos politikos „BigQuery“ eilučių lygio saugumas

• Asmeniškai identifikuojamų duomenų tvarkymas pagal NIST privatumo sistemą

• Saugojimo taisyklės. Saugojimo apribojimas. ES gairės dėl saugojimo.

• Audito žurnalai NIST SP 800-92 (žurnalų valdymas) CIS Control 8 (audito žurnalų valdymas)

• Duomenų saugojimo apribojimai

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

• Sutartys, patvirtinimai, anomalijų aptikimas Atvirųjų duomenų sutarčių standartas (ODCS) Duomenų stebimumas („Dynatrace“)

• SLA, SLO, incidentų reagavimo įpročiai

• Pagrindinės priežasties analizė su drausme (ne vibracijomis)

Valdymo ir pasitikėjimo architektūra

• Prieigos šablonai

• Audituojamumas NIST SP 800-92 (žurnalų valdymas)

• Privatumas pagal dizainą NIST privatumo sistema

• Duomenų gyvavimo ciklo valdymas ES gairės dėl saugojimo

Platforminis mąstymas

• Daugkartinio naudojimo šablonai, auksiniai takai

• Standartizuoti „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:

• automatizuoti pasikartojančias užduotis

• paspartinkite kodavimą, derinimą ir dokumentavimą „GitHub Copilot for SQL dbt“ dokumentacija

• sumažinti vamzdynų gamybos sąnaudas

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

• atskaitomybė

• sistemos projektavimas

• pasitikėjimas, kokybė ir valdymas Atvirųjų duomenų sutarčių standartas (ODCS) NIST privatumo sistema

• miglotos verslo realybės pavertimas patikimais duomenų produktais

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.

Realaus pasaulio pavyzdys: dirbtinio intelekto pagrindu sukurtos duomenų srauto peržiūros darbo eigos kūrimas 🛠️

Scenarijus

Įsivaizduokite mažą el. prekybos įmonę su vienu duomenų inžinieriumi, dviem analitikais ir labai gerai žinoma problema: finansų ataskaitų sritis užstringa, kai tik mokėjimų teikėjas pakeičia lauko pavadinimą.

Komanda nenori, kad dirbtinis intelektas „valdytų“ visą procesą. Tai būtų rizikinga. Vietoj to, jie naudoja dirbtinį intelektą kaip pirmojo juodraščio asistentą įprastiems, bet svarbiems darbams: DBT modelio skeletų rašymui, testų siūlymui, dokumentacijos rengimui ir kodo peržiūros kontrolinio sąrašo sudarymui.

Galutinis projektas, duomenų apibrėžimai, prieigos taisyklės ir diegimas gamybinėje aplinkoje vis tiek priklauso duomenų inžinieriui. Dirbtinis intelektas tiesiog pagreitina sudėtingą tarpinį etapą.

Ko reikia darbo eigai

Prieš naudodama dirbtinį intelektą, komanda pateikia jam pakankamai konteksto, kad jis būtų naudingas:

• Esama mokėjimų lentelės schema

• Tikslinių finansų metrikų apibrėžimai, pvz., „grynosios pajamos“, „grąžinamoji suma“ ir „atliktas mokėjimas“

• DBT modelių pavadinimų suteikimo konvencijos

• Patvirtintų bandymų pavyzdžiai

• Trumpa mokėjimų srauto duomenų sutartis

• Asmens duomenų, nepavykusių mokėjimų, dublikatų ir pavėluotai gautų įrašų tvarkymo taisyklės

• Ankstesnių incidentų pavyzdys, įskaitant tai, kas nutiko ir kaip tai buvo ištaisyta

Esmė ne ta, kad „paprašykite dirbtinio intelekto sukurti kanalą“. Tai pernelyg miglota.

Stipresnis požiūris yra toks: „Štai mūsų taisyklės, štai schema, štai laukiamas elgesys. Sukurkite projektą, kurį galėtume peržiūrėti.“

Instrukcijos pavyzdys

Jūs padedate rengti mūsų mokėjimų duomenų DBT modelį. Norėdami sukurti pirmojo etapo modelį, siūlomus DBT testus ir dokumentacijos pastabas, naudokite toliau pateiktą schemą ir taisykles.

Modelis turi apskaičiuoti dienos atsiskaitytas pajamas pagal order_id ir payment_provider. Neįtraukti nepavykusių mokėjimų, neįtraukti bandomųjų operacijų ir atimti grąžinimus tik tada, kai refund_status = „confirmed“.

Nekurkite naujų stulpelių. Jei trūksta privalomo stulpelio, užuot spėlioję, nurodykite jį skiltyje „Klausimai žmogui peržiūrėti“.

Taip pat siūlykite unikalumo, nulinių reikšmių, priimtų reikšmių ir pajamų pagrįstumo testus. Pažymėkite bet kokią logiką, kuri galėtų turėti įtakos finansinėms ataskaitoms.

Kaip tai išbandyti

Protingas testas yra mažas ir sąmoningai kasdieniškas:

• Pateikite dirbtiniam intelektui vieną žinomą ir gerą mokėjimo schemą ir patikrinkite, ar ji vengia kurti laukus.

• Pateikite vieną schemą su trūkstamu refund_status stulpeliu ir pažiūrėkite, ar ji užduoda klausimą, o ne spėlioja.

• Paleiskite sugeneruotą SQL su parengtiniu duomenų rinkiniu, o ne gamybiniu.

• Palyginkite išvestį su 20 rankiniu būdu patikrintų mokėjimo įrašų.

• Prieš sujungiant, paprašykite analitiko ir duomenų inžinieriaus peržiūrėti apibrėžimus.

• Pridėkite priimtus testus prie CI, kad srautas ir toliau tikrintų save po diegimo.

Svarbu išbandyti dirbtinį intelektą su tomis gedimo rūšimis, kurių labiausiai bijote: išgalvotais stulpeliais, neteisinga pajamų logika, trūkstamu grąžinimo tvarkymu ir tyliomis pasikartojančiomis eilutėmis.

Rezultatas

Iliustracinis rezultatas: pagrįstas trijų pavyzdinių srauto keitimo užduočių laiko matavimu prieš ir po šio darbo eigos naudojimo.

Prieš pradėdamas naudoti dirbtinį intelektą, inžinierius kiekvienam pakeitimui atlikti skirdavo apie 5 valandas 30 minučių: maždaug 2 valandas rašė SQL, 1 valandą kūrė testus, 45 minutes rašė dokumentus, o likusias valandas tikrino kraštutinius atvejus su finansų skyriumi.

Kadangi dirbtinis intelektas buvo naudojamas tik pirmiesiems juodraščiams, tokio paties tipo pakeitimas užtruko apie 2 valandas 10 minučių. Didžiausias sutaupymas buvo pasiektas rengiant bandomuosius pastolius ir dokumentacijos juodraščius – jų trukmė sutrumpėjo nuo 1 valandos 45 minučių iki maždaug 25 minučių.

Žmogaus atlikta peržiūra vis tiek užtruko apie 45 minutes, todėl jo nereikėtų pašalinti.

Trijų užduočių teste dirbtinis intelektas pasiūlė 18 patikrinimų. Inžinierius priėmė 11, redagavo 5 ir atmetė 2, nes jie manė, kad verslo taisyklės nėra teisingos. Šis atmetimų skaičius yra svarbus: jis įrodo, kad reikia peržiūrėti darbo eigą, o ne aklai pasitikėti.

Kas gali nutikti ne taip

Dirbtinis intelektas gali padaryti vamzdyną išsamesnį, nei yra iš tikrųjų.

Dažniausi gedimo taškai:

• Išgalvoti stulpelius, kurie skamba įtikinamai

• Grąžinimų, grąžinamųjų mokėjimų ir nepavykusių mokėjimų traktavimas kaip tas pats dalykas

• Dienos pajamų trūkstamos laiko juostos problemos

• Siūlomi bendriniai testai, kurie neaptinka finansinių klaidų

• Rašyti dokumentus, kurie skamba užtikrintai, bet slepia netikrumą

• Privatumo taisyklių pamiršimas, kai pavyzdiniuose duomenyse yra kliento duomenų

Gera taisyklė: dirbtinis intelektas gali sukurti modelio projektą, bet žmogus turi patvirtinti apibrėžimus, pinigų logiką, prieigos kontrolę ir gamybos išleidimą.

Praktiškas išsinešimui skirtas maistas

Vertinga dirbtinio intelekto versija duomenų inžinerijoje nėra „pakeisti duomenų inžinierių“. Tai „pašalinti tuščią puslapį ir atidžiai jį peržiūrėti“.

Tai reiškia greitesnį SQL, greitesnius testus ir geresnę pirmojo etapo dokumentaciją, o inžinierius vis tiek atsako už svarbiausią dalį: ar duomenys yra teisingi, patikimi, saugūs ir paaiškinami.

---

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