Vai mākslīgais intelekts aizstās datu inženierus?

Īsa atbilde: mākslīgais intelekts neaizstās datu inženierus pilnībā; tas automatizēs atkārtotus darbus, piemēram, SQL rasēšanu, cauruļvadu sastatņu veidošanu, testus un dokumentāciju. Ja jūsu loma galvenokārt ir saistīta ar darbu ar zemu atbildības līmeni un pieprasījumu balstītu darbu, tā ir vairāk pakļauta riskam; ja jūs atbildat par uzticamību, definīcijām, pārvaldību un incidentu reaģēšanu, mākslīgais intelekts galvenokārt padara jūs ātrāku.

Galvenie secinājumi:

Atbildība: Prioritāti piešķiriet atbildībai par rezultātiem, ne tikai ātrai koda izveidei.

Kvalitāte: Izveidojiet testus, novērojamību un līgumus, lai cauruļvadi saglabātu uzticamību.

Pārvaldība: Saglabājiet privātuma, piekļuves kontroles, saglabāšanas un audita ierakstus cilvēku pārziņā.

Aizsardzība pret ļaunprātīgu izmantošanu: AI rezultātus uztveriet kā melnrakstus; pārskatiet tos, lai izvairītos no pārliecinātām kļūdām.

Lomu maiņa: veltiet mazāk laika standarta tekstu rakstīšanai un vairāk laika izturīgu sistēmu projektēšanai.

Ja esat pavadījis vairāk nekā piecas minūtes datu komandu aprindās, esat dzirdējuši atkārtojumu – dažreiz čukstus, dažreiz tos izskanot sanāksmes laikā kā negaidītu sižeta pavērsienu: Vai mākslīgais intelekts aizstās datu inženierus?

Un… es saprotu. Mākslīgais intelekts var ģenerēt SQL, veidot cauruļvadus, izskaidrot kaudzes izsekošanas datus, uzzīmēt datubāzes modeļus un pat ieteikt noliktavas shēmas ar satraucošu pārliecību. GitHub Copilot SQL. Par datubāzes modeļiem. GitHub Copilot.
Sajūta ir tāda, it kā vērotu, kā iekrāvējs mācās žonglēt. Iespaidīgi, nedaudz satraucoši, un tu neesi pilnībā pārliecināts, ko tas nozīmē tavam darbam 😅

Taču patiesība nav tik skaidra kā virsrakstā. Mākslīgais intelekts pilnībā maina datu inženieriju. Tas automatizē garlaicīgās, atkārtojamās daļas. Tas paātrina "es zinu, ko vēlos, bet nevaru atcerēties sintaksi" momentus. Tas arī rada pavisam jauna veida haosu.

Tāpēc izklāstīsim to pareizi, bez optimisma un panikas, kas liek domāt par nākotni.

Raksti, kurus jūs varētu vēlēties izlasīt pēc šī raksta:

🔗 Vai mākslīgais intelekts aizstās radiologus?
Kā attēlveidošanas mākslīgais intelekts maina darbplūsmu, precizitāti un nākotnes lomas.

🔗 Vai mākslīgais intelekts aizstās grāmatvežus?
Skatiet, kurus grāmatvedības uzdevumus mākslīgais intelekts automatizē un kurus veic cilvēki.

🔗 Vai mākslīgais intelekts aizstās investīciju baņķierus?
Izprotiet mākslīgā intelekta ietekmi uz darījumiem, pētniecību un klientu attiecībām.

🔗 Vai mākslīgais intelekts aizstās apdrošināšanas aģentus?
Uzziniet, kā mākslīgais intelekts pārveido apdrošināšanas, pārdošanas un klientu atbalsta procesus.

---

Kāpēc atkal un atkal parādās jautājums “Mākslīgais intelekts aizstāj datu inženierus” 😬

Bailes rodas no ļoti konkrētas vietas: datu inženierijā ir daudz atkārtojama darba.

• SQL rakstīšana un refaktorēšana

• Pārsūtīšanas skriptu veidošana

• Lauku kartēšana no vienas shēmas uz citu

• Testu un pamata dokumentācijas izveide

• Cauruļvada kļūmju atkļūdošana, kas ir… diezgan paredzamas

Mākslīgais intelekts ir neparasti labs atkārtojamu modeļu jomā. Un liela daļa datu inženierijas ir tieši tāda — modeļi, kas sakrauti pēc modeļiem. GitHub Copilot koda ieteikumi

Turklāt rīku ekosistēma jau “slēpj” sarežģītību:

• Pārvaldītie ELT savienotāji Fivetran dokumentācija

• Bezserveru skaitļošana AWS Lambda (bezserveru skaitļošana)

• Noliktavas nodrošināšana ar vienu klikšķi

• Automātiskās mērogošanas orķestrēšanas Apache Airflow dokumentācija

• Deklaratīvās transformācijas ietvari. Kas ir dbt?

Tātad, kad parādās mākslīgais intelekts, tas var šķist kā pēdējais gabals. Ja kaudze jau ir abstrahēta un mākslīgais intelekts var uzrakstīt savienojošo kodu… kas atliek? 🤷

Bet lūk, ko cilvēki aizmirst: datu inženierija galvenokārt nav rakstīšana. Rakstīšana ir vieglā daļa. Grūtākā daļa ir panākt, lai neskaidra, politiska, mainīga biznesa realitāte uzvestos kā uzticama sistēma.

Un mākslīgais intelekts joprojām cīnās ar šo miglu. Arī cilvēkiem ir grūtības — viņi vienkārši labāk improvizē.

---

Ko datu inženieri patiesībā dara visu dienu (neglamūrīgā patiesība) 🧱

Būsim atklāti – amata nosaukums “Datu inženieris” izklausās tā, it kā jūs būvētu raķešu dzinējus no tīras matemātikas. Praksē jūs veidojat uzticību.

Tipiska diena ir mazāk “jaunu algoritmu izgudrošanas” un vairāk:

• Sarunas ar augšupējām komandām par datu definīcijām (sāpīgas, bet nepieciešamas)

• Izpēte, kāpēc mainījās rādītājs (un vai tas ir reāls)

• Shēmas nobīdes apstrāde un pārsteigumi “kāds pievienoja kolonnu pusnaktī”

• Nodrošināt, ka cauruļvadi ir idempotenti, atgūstami un novērojami

• Aizsargbarjeru izveide, lai lejupējie analītiķi nejauši neveidotu bezjēdzīgus informācijas paneļus

• Izmaksu pārvaldība, lai jūsu noliktava nekļūtu par naudas dedzināšanas liesmu 🔥

• Piekļuves nodrošināšana, auditēšana, atbilstība, saglabāšanas politikas GDPR principi (Eiropas Komisija) Glabāšanas ierobežojums (ICO)

• Datu produktu izveide, ko cilvēki var faktiski izmantot, nesūtot jums DM 20 jautājumus

Liela daļa darba ir sociāla un operatīva:

• "Kam pieder šis galds?"

• "Vai šī definīcija joprojām ir derīga?"

• "Kāpēc CRM eksportē dublikātus?"

• "Vai mēs varam bez kauna nosūtīt šo metriku vadītājiem?" 😭

Mākslīgais intelekts, protams, var palīdzēt ar daļu no tā. Taču tā pilnīga aizstāšana ir… sarežģīta.

---

Kas veido spēcīgu datu inženiera amata versiju? ✅

Šī sadaļa ir svarīga, jo runājot par aizstāšanu, parasti tiek pieņemts, ka datu inženieri galvenokārt ir “cauruļvadu veidotāji”. Tas ir līdzīgi kā pieņemt, ka pavāri galvenokārt “sasmalcina dārzeņus”. Tā ir daļa no darba, bet tas nav darbs.

Spēcīga datu inženiera versija parasti nozīmē, ka viņš var paveikt lielāko daļu no šīm darbībām:

• Dizains pārmaiņām
  . Dati mainās. Komandas mainās. Rīki mainās. Labs inženieris veido sistēmas, kas nesabrūk katru reizi, kad realitāte šķauda.

• Definējiet līgumus un cerības
  Ko nozīmē “klients”? Ko nozīmē “aktīvs”? Kas notiek, ja rinda pienāk ar nokavēšanos? Līgumi novērš haosu labāk nekā izsmalcināts kods. Atvērto datu līgumu standarts (ODCS) ODCS (GitHub)

• Iebūvējiet novērojamību visā.
  Ne tikai “vai tas darbojās”, bet arī “vai tas darbojās pareizi”. Svaigums, apjoma anomālijas, nulles sprādzieni, sadalījuma nobīdes. Datu novērojamība (Dynatrace). Kas ir datu novērojamība?

• Atrodiet kompromisus kā pieaugušais –
  ātrums pretstatā pareizībai, izmaksas pretstatā latentumam, elastība pretstatā vienkāršībai. Nav ideāla cauruļvada, ir tikai cauruļvadi, ar kuriem varat sadzīvot.

• Pārveidojiet biznesa vajadzības izturīgās sistēmās.
  Cilvēki pieprasa metrikas, bet viņiem ir nepieciešams datu produkts. Mākslīgais intelekts var izveidot kodu, bet tas nevar maģiski zināt biznesa mīnas.

• Datu noslēpumā glabāšana.
  Lielākais kompliments datu platformai ir tas, ka neviens par to nerunā. Nelieli dati ir labi dati. Tāpat kā santehnika. Tos pamana tikai tad, kad tie sabojājas.

Ja jūs darāt šīs lietas, jautājums “Vai mākslīgais intelekts aizstās datu inženierus?” sāk izklausīties… nedaudz nepareizi. Mākslīgais intelekts var aizstāt uzdevumus, nevis īpašumtiesības.

---

Kur mākslīgais intelekts jau palīdz datu inženieriem (un tas ir patiesi lieliski) 🤖✨

Mākslīgais intelekts nav tikai mārketings. Pareizi izmantots, tas ir leģitīms spēka reizinātājs.

1) Ātrāks SQL un transformāciju darbs

• Sarežģītu savienojumu rasēšana

• Logu funkciju rakstīšana, par kurām nevēlaties domāt

• Vienkāršas valodas loģikas pārvēršana vaicājumu skeletos

• Neglītu vaicājumu pārveidošana lasāmos CTE GitHub Copilot for SQL

Tas ir ļoti svarīgi, jo samazina “tukšas lapas” efektu. Jums joprojām ir jāveic validācija, taču sāciet ar 70%, nevis 0%.

2) Kļūdu novēršana un pamatcēloņu navigācija

Mākslīgais intelekts ir pienācīgs šādās jomās:

• Kļūdu ziņojumu skaidrojums

• Ieteikums, kur meklēt

• Iesaka “pārbaudiet shēmas neatbilstību” tipa darbības GitHub Copilot
  Tas ir kā nenogurstošs jaunākais inženieris, kurš nekad neguļ un dažreiz pārliecināti melo 😅

3) Dokumentācija un datu kataloga bagātināšana

Automātiski ģenerēts:

• Kolonnu apraksti

• Modeļu kopsavilkumi

• Līnijas skaidrojumi

• “Kam šī tabula tiek izmantota?” izstrādā DBT dokumentācijas

Tas nav perfekts, bet tas lauž nedokumentētu cauruļvadu lāstu.

4) Sastatņu pārbaude un pārbaude

Mākslīgais intelekts var ierosināt:

• Pamata nulles testi

• Unikalitātes pārbaudes

• Atsauces integritātes idejas

• “Šim rādītājam nekad nevajadzētu samazināties” stila apgalvojumi DBT datu testos Lielās cerības: cerības

Atkal – jūs joprojām izlemjat, kas ir svarīgi, taču tas paātrina rutīnas daļas.

5) Cauruļvada “līmes” kods

Konfigurācijas veidnes, YAML sastatnes, orķestrācijas DAG melnraksti. Tas viss atkārtojas, un mākslīgais intelekts brokastīs ēd atkārtojumus 🥣 Apache Airflow DAG

---

Kur mākslīgais intelekts joprojām cīnās (un šī ir tā būtība) 🧠🧩

Šī ir vissvarīgākā daļa, jo tā atbild uz aizstāšanas jautājumu ar īstu tekstūru.

1) Neskaidrības un mainīgas definīcijas

Biznesa loģika reti kad ir skaidra. Cilvēki maina savas domas teikuma vidū. “Aktīvs lietotājs” kļūst par “aktīvs maksājošs lietotājs”, kļūst par “aktīvs maksājošs lietotājs, izņemot atmaksas, izņemot dažreiz”... jūs jau zināt, kā tas ir.

Mākslīgais intelekts nevar pieņemt šo neskaidrību. Tas var tikai minēt.

2) Atbildība un risks

Kad cauruļvads pārtrūkst un izpildes panelī tiek rādītas muļķības, kādam ir jāveic šādas darbības:

• triāža

• paziņot ietekmi

• salabot to

• novērst atkārtošanos

• uzrakstīt autopsiju

• izlemt, vai uzņēmums joprojām var uzticēties pagājušās nedēļas skaitļiem

Mākslīgais intelekts var palīdzēt, bet tas nevar būt jēgpilni atbildīgs. Organizācijas nedarbojas, vadoties pēc vibrācijām, bet gan pēc atbildības.

3) Sistēmiskā domāšana

Datu platformas ir ekosistēmas: uzņemšana, glabāšana, transformācijas, orķestrēšana, pārvaldība, izmaksu kontrole, SLA. Izmaiņas vienā slānī rada viļņošanos. Apache Airflow koncepcijas.

Mākslīgais intelekts var ierosināt lokālas optimizācijas, kas rada globālas sāpes. Tas ir kā salabot čīkstošas ​​durvis, tās noņemot 😬

4) Drošība, privātums, atbilstība

Šeit aizstāšanas fantāzijas iet bojā.

• Piekļuves kontrole

• Rindu līmeņa drošība Snowflake rindu piekļuves politikas BigQuery rindu līmeņa drošība

• Personu identificējošas informācijas apstrāde NIST privātuma ietvarā

• Saglabāšanas noteikumi. Uzglabāšanas ierobežojums (ICO). ES norādījumi par saglabāšanu.

• Audita liecības NIST SP 800-92 (žurnālu pārvaldība) CIS Control 8 (audita žurnālu pārvaldība)

• Datu glabāšanas ierobežojumi

Mākslīgais intelekts var izstrādāt politikas, bet to droša ieviešana ir īsta inženierija.

5) “Nezināmie nezināmie”

Datu incidenti bieži vien ir neparedzami:

• Pārdevēja API nemanāmi maina semantiku

• Laika joslas pieņēmums apgriežas otrādi

• Aizpildījums dublē nodalījumu

• Atkārtotas rakstīšanas mehānisms izraisa dubultu ierakstīšanu

• Jauna produkta funkcija ievieš jaunus notikumu modeļus

Mākslīgais intelekts ir vājāks, ja situācija nav zināms modelis.

---

Salīdzināšanas tabula: kas praksē samazina ko 🧾🤔

Zemāk ir sniegts praktisks skatījums. Nevis “rīki, kas aizstāj cilvēkus”, bet gan rīki un pieejas, kas samazina noteiktu uzdevumu apjomu.

Rīks/pieeja	Auditorija	Cenas vibrācija	Kāpēc tas darbojas
AI koda koppiloti (SQL + Python palīgi) GitHub Copilot	Inženieri, kas raksta daudz koda	No gandrīz bezmaksas līdz maksas	Lieliski prot sastatņot, pārveidot, veidot sintakses… dažreiz ļoti specifiskā veidā pašapmierināti
Pārvaldītie ELT savienotāji Fivetran	Komandas ir nogurušas no ēku pievienošanas	Abonēšanas iespējas	Novērš pielāgotas norīšanas sāpes, bet pārtrauc jautros jaunos veidos
Datu novērojamības platformas Datu novērojamība (Dynatrace)	Ikviens, kam pieder SLA	Vidējais un lielais uzņēmums	Agrīni atklāj anomālijas — piemēram, dūmu detektorus cauruļvadiem 🔔
Transformācijas ietvari (deklaratīvā modelēšana) dbt	Analītikas + DE hibrīdi	Parasti rīks + skaitļošanas	Padara loģiku modulāru un pārbaudāmu, mazāk "spageti"
Datu katalogi + semantiskie slāņi dbt Semantiskais slānis	Organizācijas ar metrikas apjukumu	Praksē atkarīgs no	Vienreiz definē “patiesību” — samazina nebeidzamās metriskās debates
Orķestrēšana ar veidnēm Apache Airflow	Platformām orientētas komandas	Atvēršanas + darbību izmaksas	Standartizē darbplūsmas; mazāk sniegpārsliņu formas DAG
Ar mākslīgo intelektu atbalstīta dokumentācija, dbt dokumentu ģenerēšana	Komandas, kurām nepatīk rakstīt dokumentus	Lēti līdz mēreni	Veido “pietiekami labus” dokumentus, lai zināšanas neizzustu
Automatizētas pārvaldības politikas NIST privātuma ietvars	Regulētās vides	Uzņēmuma līmeņa	Palīdz ieviest noteikumus, taču noteikumu izstrādei joprojām ir nepieciešami cilvēki

Ievērojiet, kas trūkst: rinda ar uzrakstu “nospiediet pogu, lai noņemtu datu inženierus”. Jā… šīs rindas nav 🙃

---

Tātad… vai mākslīgais intelekts aizstās datu inženierus vai vienkārši mainīs lomu? 🛠️

Lūk, nedramatiska atbilde: mākslīgais intelekts aizstās daļu darbplūsmas, nevis profesiju.

Bet tas mainīs lomu. Un, ja jūs to ignorēsiet, jūs jutīsiet spiedienu.

Kas mainās:

• Mazāk laika standarta teksta rakstīšanai

• Mazāk laika dokumentu meklēšanai

• Vairāk laika pārskatīšanai, validēšanai, projektēšanai

• Vairāk laika līgumu un kvalitātes prasību definēšanai Atvērto datu līgumu standarts (ODCS)

• Vairāk laika sadarbībai produktu, drošības un finanšu jomā

Šī ir smalkā maiņa: datu inženierija vairs nav tik daudz par “cauruļvadu veidošanu” un vairāk par “uzticamas datu produktu sistēmas izveidi”

Un klusā pavērsienā tas ir vērtīgāk, nevis mazāk.

Tāpat — un es to teikšu pat tad, ja tas izklausās dramatiski — mākslīgais intelekts palielina to cilvēku skaitu, kuri var radīt datu artefaktus, kas palielina nepieciešamību pēc kāda, kas visu procesu uzturētu saprāta robežās. Lielāka izvade nozīmē lielāku potenciālu apjukumu. GitHub Copilot

Tas ir kā visiem iedot elektrisko urbi. Lieliski! Tagad kādam ir jāuzrauga noteikums "lūdzu, nerurbt ūdensvadā" 🪠

---

Jaunais prasmju klāsts, kas saglabā savu vērtību (pat ar mākslīgo intelektu visur) 🧠⚙️

Ja vēlaties praktisku “nākotnes prasībām atbilstošu” kontrolsarakstu, tas izskatās šādi:

Sistēmas dizaina domāšana

• Datu modelēšana, kas pārdzīvo pārmaiņas

• Paketes un straumēšanas kompromisi

• Latentuma, izmaksu un uzticamības domāšana

Datu kvalitātes inženierija

• Līgumi, validācijas, anomāliju noteikšana Atvērto datu līgumu standarts (ODCS) Datu novērojamība (Dynatrace)

• SLA, SLO, incidentu reaģēšanas paradumi

• Cēloņu analīze ar disciplīnu (nevis vibrācijām)

Pārvaldības un uzticēšanās arhitektūra

• Piekļuves modeļi

• Auditējamība NIST SP 800-92 (žurnālu pārvaldība)

• Privātums pēc noklusējuma NIST privātuma ietvars

• Datu dzīves cikla pārvaldība ES vadlīnijas par datu saglabāšanu

Platformas domāšana

• Atkārtoti lietojamas veidnes, zelta ceļi

• Standartizēti Fivetran dbt datu uzņemšanas, transformāciju un testēšanas modeļi

• Pašapkalpošanās instrumenti, kas nekūst

Komunikācija (jā, tiešām)

• Skaidru dokumentu rakstīšana

• Definīciju saskaņošana

• Sakot “nē” pieklājīgi, bet stingri

• Izskaidrojot kompromisus, neizklausoties pēc robota 🤖

Ja jūs to varat izdarīt, jautājums “Vai mākslīgais intelekts aizstās datu inženierus?” kļūst mazāk draudīgs. Mākslīgais intelekts kļūst par jūsu eksoskeletu, nevis jūsu aizstājēju.

---

Reālistiski scenāriji, kuros dažas datu inženierijas lomas sarūk 📉

Labi, ātra realitātes pārbaude, jo tā nav tikai saule un emocijzīmju konfeti 🎉

Dažas lomas ir vairāk pakļautas:

• Tikai uzņemšanai paredzētas lomas, kurās viss ir standarta savienotāji Fivetran savienotāji

• Komandas, kas galvenokārt veic atkārtotus atskaišu veidošanas procesus ar minimālām jomas niansēm

• Organizācijas, kurās datu inženierija tiek uzskatīta par “SQL pērtiķiem” (skarbi, bet patiesi)

• Zemas atbildības lomas, kur darbs ir tikai biļetes un kopēšana un ielīmēšana

Mākslīgais intelekts kopā ar pārvaldītiem rīkiem var samazināt šīs vajadzības.

Bet pat tur nomaiņa parasti izskatās šādi:

• Mazāk cilvēku veic vienu un to pašu atkārtoto darbu

• Lielāks uzsvars uz platformas īpašumtiesībām un uzticamību

• Pāreja uz "viena persona var atbalstīt vairāk cauruļvadu"

Tātad, jā — darbinieku skaita modeļi var mainīties. Lomas attīstās. Amats mainās. Šī daļa ir reāla.

Tomēr saglabājas šīs lomas versija, kas paredz augstu atbildības uzņemšanos un uzticēšanos.

---

Noslēguma kopsavilkums 🧾✅

Vai mākslīgais intelekts aizstās datu inženierus? Ne tādā tīrā un pilnīgā veidā, kā cilvēki to iedomājas.

Mākslīgais intelekts veiks sekojošo:

• automatizēt atkārtotus uzdevumus

• paātrināt kodēšanu, atkļūdošanu un dokumentēšanu GitHub Copilot SQL dbt dokumentācijai

• samazināt cauruļvadu ražošanas izmaksas

Bet datu inženierija būtībā ir par:

• atbildība

• sistēmas dizains

• uzticēšanās, kvalitāte un pārvaldība Atvērto datu līgumu standarts (ODCS) NIST privātuma ietvars

• neskaidras biznesa realitātes pārvēršana uzticamos datu produktos

Mākslīgais intelekts var ar to palīdzēt… bet tas tam "nepieder".

Ja esat datu inženieris, šis solis ir vienkāršs (ne viegls, bet vienkāršs):
koncentrējieties uz īpašumtiesībām, kvalitāti, platformas domāšanu un komunikāciju. Ļaujiet mākslīgajam intelektam pārvaldīt standarta darbības, kamēr jūs rūpējaties par svarīgākajām daļām.

Un jā — dažreiz tas nozīmē būt pieaugušajam telpā. Nevis glauniem. Tomēr klusi spēcīgiem 😄

Vai mākslīgais intelekts aizstās datu inženierus?
Tas aizstās dažus uzdevumus, pārveidos karjeras kāpnes un padarīs labākos datu inženierus vēl vērtīgākus. Tā ir patiesība.

Reālās pasaules piemērs: AI atbalstītas datu plūsmas pārskatīšanas darbplūsmas izveide 🛠️

Scenārijs

Iedomājieties nelielu e-komercijas uzņēmumu ar vienu datu inženieri, diviem analītiķiem un ļoti pazīstamu problēmu: finanšu informācijas panelis pārstāj darboties ikreiz, kad maksājumu pakalpojumu sniedzējs maina lauka nosaukumu.

Komanda nevēlas, lai mākslīgais intelekts (MI) “pārņemtu” cauruļvadu. Tas būtu riskanti. Tā vietā viņi izmanto MI kā pirmā melnraksta palīgu ikdienas, bet svarīgam darbam: DBT modeļa skeletu rakstīšanai, testu ieteikšanai, dokumentācijas izstrādei un koda pārskatīšanas kontrolsaraksta izveidei.

Cilvēka datu inženieris joprojām ir atbildīgs par galīgo dizainu, datu definīcijām, piekļuves noteikumiem un ieviešanu ražošanas vidē. Mākslīgais intelekts vienkārši paātrina sarežģīto vidusposmu.

Kas nepieciešams darbplūsmai

Pirms mākslīgā intelekta izmantošanas komanda sniedz tam pietiekamu kontekstu, lai tas būtu noderīgi:

• Esošā maksājumu tabulas shēma

• Mērķa finanšu rādītāju definīcijas, piemēram, “neto ieņēmumi”, “atmaksas summa” un “nokārtotais maksājums”

• DBT modeļu nosaukšanas konvencijas

• Apstiprinātu testu piemēri

• Īss datu līgums maksājumu plūsmai

• Noteikumi par personas datu apstrādi, neveiksmīgiem maksājumiem, dublikātiem un novēlotiem ierakstiem

• Iepriekšējo incidentu paraugs, tostarp par to, kas nogāja greizi un kā tas tika novērsts

Galvenais nav "lūgt mākslīgajam intelektam izveidot cauruļvadu". Tas ir pārāk neskaidri.

Spēcīgāka pieeja ir šāda: “Šeit ir mūsu noteikumi, šeit ir shēma, šeit ir paredzamā uzvedība. Izveidojiet kaut ko tādu, ko mēs varam pārskatīt.”

Instrukcijas piemērs

Jūs palīdzat izstrādāt DBT modeli mūsu maksājumu datiem. Izmantojiet tālāk norādīto shēmu un noteikumus, lai izveidotu pirmās kārtas modeli, ieteiktos DBT testus un dokumentācijas piezīmes.

Modelim ir jāaprēķina ikdienas ieņēmumi pēc pasūtījuma_id un maksājuma_pakalpojuma sniedzēja. Izslēdziet neveiksmīgos maksājumus, izslēdziet testa darījumus un atņemiet atmaksas tikai tad, ja atmaksas_statuss = “apstiprināts”.

Neizdomājiet jaunas kolonnas. Ja trūkst obligātas kolonnas, norādiet to sadaļā “Jautājumi cilvēkam pārskatīšanai”, nevis minējiet.

Iesakiet arī unikalitātes, nulles vērtību, pieņemto vērtību un ieņēmumu pamatotības testus. Atzīmējiet jebkuru loģiku, kas varētu ietekmēt finanšu pārskatu sniegšanu.

Kā to pārbaudīt

Saprātīgs tests ir mazs un apzināti ikdienišķs:

• Dodiet mākslīgajam intelektam vienu zināmu labu maksājumu shēmu un pārbaudiet, vai tā izvairās no lauku izdomāšanas.

• Dodiet tai vienu shēmu ar trūkstošu refund_status kolonnu un pārbaudiet, vai tā uzdod jautājumu, nevis minējumu.

• Palaidiet ģenerēto SQL attiecībā pret izstrādes stadijā esošo datu kopu, nevis ražošanas vidi.

• Salīdziniet izvadi ar 20 manuāli pārbaudītiem maksājumu ierakstiem.

• Pirms apvienošanas palūdziet analītiķim un datu inženierim pārskatīt definīcijas.

• Pievienojiet pieņemtos testus CI, lai cauruļvads pēc izvietošanas turpinātu sevi pārbaudīt.

Svarīgi ir pārbaudīt mākslīgo intelektu uz kļūmju režīmiem, no kuriem jūs visvairāk baidāties: izdomātas kolonnas, nepareiza ieņēmumu loģika, trūkstoša atmaksas apstrāde un klusas dublētas rindas.

Rezultāts

Ilustratīvais rezultāts: balstīts uz trīs parauga cauruļvada maiņas uzdevumu laika noteikšanu pirms un pēc šīs darbplūsmas izmantošanas.

Pirms mākslīgā intelekta izmantošanas inženieris katrai izmaiņai veltīja aptuveni 5 stundas 30 minūtes: aptuveni 2 stundas SQL rakstīšanai, 1 stundu testu izveidei, 45 minūtes dokumentu rakstīšanai un pārējo laiku – perifēro gadījumu pārbaudei ar finanšu nodaļu.

Tā kā mākslīgais intelekts tika izmantots tikai pirmajiem melnrakstiem, tāda paša veida izmaiņu veikšanai bija nepieciešamas aptuveni 2 stundas un 10 minūtes. Vislielākais ietaupījums tika panākts, izstrādājot testa sastatnes un dokumentācijas melnrakstus, kuru veikšanai nepieciešamais laiks samazinājās no 1 stundas un 45 minūtēm līdz aptuveni 25 minūtēm.

Cilvēka veiktā pārskatīšana joprojām aizņēma aptuveni 45 minūtes, un to nevajadzētu noņemt.

Trīs uzdevumu testā mākslīgais intelekts ieteica 18 pārbaudes. Inženieris pieņēma 11, rediģēja 5 un noraidīja 2, jo tās pieņēma, ka biznesa noteikumi nav patiesi. Noraidījumu skaits ir svarīgs: tas pierāda, ka darbplūsma ir jāpārskata, nevis jātic aklai.

Kas var noiet greizi

Mākslīgais intelekts var padarīt cauruļvadu pilnīgāku, nekā tas patiesībā ir.

Bieži sastopamie neveiksmes punkti ir šādi:

• Izgudrojot ticamas kolonnas

• Atmaksas, atmaksas pieprasījumi un neveiksmīgi maksājumi tiek uzskatīti par vienu un to pašu lietu

• Dienas ieņēmumu trūkstošās laika joslas problēmas

• Ieteikt vispārīgus testus, kas neatklāj finanšu kļūdas

• Dokumentācijas rakstīšana, kas izklausās pārliecinoši, bet slēpj nenoteiktību

• Privātuma noteikumu aizmirstība, ja parauga datos ir ietverta klienta informācija

Labs noteikums: mākslīgais intelekts var izveidot modeli, bet cilvēkam ir jāparaksta definīcijas, naudas loģika, piekļuves kontrole un ražošanas laidiens.

Praktiska līdzņemšana

Vērtīgākā mākslīgā intelekta versija datu inženierijā nav “aizstāt datu inženieri”. Tā ir “noņemt tukšu lapu un pēc tam rūpīgi pārskatīt”.

Tas nozīmē ātrāku SQL, ātrākus testus un labāku pirmās kārtas dokumentāciju, savukārt inženierim joprojām pieder vissvarīgākā daļa: vai dati ir pareizi, uzticami, droši un izskaidrojami.

---

Bieži uzdotie jautājumi

Vai mākslīgais intelekts pilnībā aizstās datu inženierus?

Vairumā organizāciju mākslīgais intelekts (MI) drīzāk pārņems konkrētus uzdevumus, nevis pilnībā atcels lomu. Tas var paātrināt SQL izstrādi, cauruļvadu sastatņu veidošanu, dokumentācijas pirmās pārbaudes un pamata testu izveidi. Taču datu inženierija ietver arī atbildību un pārskatatbildību, kā arī nepievilcīgu darbu, lai haotiska biznesa realitāte darbotos kā uzticama sistēma. Šīm daļām joprojām ir nepieciešami cilvēki, lai izlemtu, kā izskatās “pareizi”, un uzņemtos atbildību, ja kaut kas neizdodas.

Kuras datu inženierijas daļas mākslīgais intelekts jau automatizē?

Mākslīgais intelekts vislabāk darbojas atkārtojamos darbos: SQL izstrādāšanā un pārveidošanā, datubāzes modeļu skeletu ģenerēšanā, izplatītu kļūdu skaidrošanā un dokumentācijas izklāsta izstrādē. Tas var arī veidot tādus testus kā nulles vai unikalitātes pārbaudes un ģenerēt veidnes “līmes” kodu orķestrēšanas rīkiem. Ieguvums ir impulss — jūs sākat tuvāk strādājošam risinājumam —, taču jums joprojām ir jāpārbauda pareizība un jānodrošina, ka tas atbilst jūsu videi.

Ja mākslīgais intelekts var rakstīt SQL un cauruļvadus, kas atliek datu inženieriem?

Daudz: datu līgumu definēšana, shēmu nobīdes apstrāde un cauruļvadu idempotentuma, novērojamības un atgūstamības nodrošināšana. Datu inženieri pavada laiku, izmeklējot metrikas izmaiņas, veidojot drošības barjeras pakārtotajiem lietotājiem un pārvaldot izmaksu un uzticamības kompromisus. Darbs bieži vien ir saistīts ar uzticības veidošanu un datu platformas “klusuma” uzturēšanu, kas nozīmē pietiekami stabilu, lai nevienam par to nebūtu jādomā katru dienu.

Kā mākslīgais intelekts maina datu inženiera ikdienas darbu?

Tas parasti samazina standarta tekstu un “meklēšanas laiku”, tāpēc jūs pavadāt mazāk laika rakstīšanai un vairāk laika pārskatīšanai, validēšanai un projektēšanai. Šī pāreja novirza lomu uz sagaidāmo rezultātu, kvalitātes standartu un atkārtoti izmantojamu modeļu definēšanu, nevis visu manuālu kodēšanu. Praksē jūs, visticamāk, vairāk sadarbosieties ar produktu, drošību un finansēm, jo ​​tehnisko rezultātu kļūst vieglāk izveidot, bet grūtāk pārvaldīt.

Kāpēc mākslīgajam intelektam ir grūtības ar neskaidrām biznesa definīcijām, piemēram, “aktīvs lietotājs”?

Tā kā biznesa loģika nav statiska vai precīza — tā mainās projekta gaitā un atšķiras atkarībā no ieinteresētās personas. Mākslīgais intelekts var izstrādāt interpretāciju, bet tas nevar pieņemt lēmumu, kad definīcijas attīstās vai rodas konflikti. Datu inženierija bieži vien prasa sarunas, pieņēmumu dokumentēšanu un neskaidru prasību pārvēršanu noturīgos līgumos. Šis "cilvēka saskaņošanas" darbs ir galvenais iemesls, kāpēc šī loma nepazūd pat tad, kad uzlabojas rīki.

Vai mākslīgais intelekts var droši pārvaldīt datu pārvaldību, privātumu un atbilstību prasībām?

Mākslīgais intelekts var palīdzēt izstrādāt politikas vai ieteikt pieejas, taču droša ieviešana joprojām prasa reālu inženieriju un rūpīgu uzraudzību. Pārvaldība ietver piekļuves kontroli, personas datu apstrādi, saglabāšanas noteikumus, audita takas un dažreiz arī rezidences ierobežojumus. Tās ir augsta riska jomas, kurās "gandrīz pareizi" nav pieņemami. Cilvēkiem ir jāizstrādā noteikumi, jāpārbauda to izpilde un jāuzņemas atbildība par atbilstības rezultātiem.

Kādas prasmes saglabā savu vērtību datu inženieriem, attīstoties mākslīgajam intelektam?

Prasmes, kas padara sistēmas noturīgas: sistēmu dizaina domāšana, datu kvalitātes inženierija un platformorientēta standartizācija. Līgumi, novērojamība, incidentu reaģēšanas paradumi un disciplinēta pamatcēloņu analīze kļūst vēl svarīgāka, ja vairāk cilvēku var ātri ģenerēt datu artefaktus. Arī komunikācija kļūst par diferenciācijas faktoru — definīciju saskaņošana, skaidru dokumentu rakstīšana un kompromisu izskaidrošana bez drāmas ir liela daļa no datu uzticamības saglabāšanas.

Kuras datu inženierijas lomas ir visvairāk pakļautas mākslīgā intelekta un pārvaldīto rīku riskam?

Lomas, kas šauri koncentrējas uz atkārtotu ievadīšanu vai standarta atskaišu sniegšanas kanāliem, ir vairāk pakļautas riskam, īpaši, ja pārvaldītie ELT savienotāji aptver lielāko daļu avotu. Darbs ar zemu īpašumtiesību līmeni, uz biļetēm balstīts darbs var sarukt, jo mākslīgais intelekts un abstrakcija samazina katra kanāla piepūli. Taču tas parasti izpaužas kā mazāk cilvēku, kas veic atkārtotus uzdevumus, nevis kā "nav datu inženieru". Lomas ar augstu īpašumtiesību līmeni, kas koncentrējas uz uzticamību, kvalitāti un paļāvību, saglabājas ilgtspējīgas.

Kā man vajadzētu izmantot tādus rīkus kā GitHub Copilot vai dbt ar mākslīgo intelektu, neradot haosu?

Uztveriet mākslīgā intelekta izvadi kā melnrakstu, nevis lēmumu. Izmantojiet to vaicājumu skeletu ģenerēšanai, lasāmības uzlabošanai vai DBT testu un dokumentu sagatavošanai, pēc tam validējiet to, salīdzinot ar reāliem datiem un perifērijas gadījumiem. Apvienojiet to ar stingrām konvencijām: līgumiem, nosaukumu piešķiršanas standartiem, novērojamības pārbaudēm un pārskatīšanas praksi. Mērķis ir ātrāka piegāde, neupurējot uzticamību, izmaksu kontroli vai pārvaldību.

Atsauces

1. Eiropas Komisija — Datu aizsardzības skaidrojums: GDPR principi — commission.europa.eu

2. Informācijas komisāra birojs (ICO) — glabāšanas ierobežojums — ico.org.uk

3. Eiropas Komisija — Cik ilgi datus var glabāt un vai tie ir jāatjaunina? — commission.europa.eu

4. Nacionālais standartu un tehnoloģiju institūts (NIST) — Privātuma ietvars — nist.gov

5. NIST Datoru drošības resursu centrs (CSRC) — SP 800-92: Datoru drošības žurnālu pārvaldības ceļvedis — csrc.nist.gov

6. Interneta drošības centrs (CIS) — Audita žurnālu pārvaldība (CIS vadīklas) — cisecurity.org

7. Snowflake dokumentācija — rindu piekļuves politikas — docs.snowflake.com

8. Google Cloud dokumentācija — BigQuery rindu līmeņa drošība — docs.cloud.google.com

9. BITOL — Atvērto datu līgumu standarts (ODCS) v3.1.0 — bitol-io.github.io

10. BITOL (GitHub) — Atvērto datu līguma standarts — github.com

11. Apache Airflow — dokumentācija (stabila) — airflow.apache.org

12. Apache Airflow — DAG (pamatkoncepcijas) — airflow.apache.org

13. dbt Labs dokumentācija — Kas ir dbt? — docs.getdbt.com

14. dbt Labs dokumentācija — Par dbt modeļiem — docs.getdbt.com

15. dbt Labs dokumentācija — Dokumentācija — docs.getdbt.com

16. dbt Labs dokumentācija — datu testi — docs.getdbt.com

17. dbt Labs dokumentācija — dbt semantiskais slānis — docs.getdbt.com

18. Fivetran dokumentācija — Darba sākšana — fivetran.com

19. Fivetran — Savienotāji — fivetran.com

20. AWS dokumentācija — AWS Lambda izstrādātāja rokasgrāmata — docs.aws.amazon.com

21. GitHub — GitHub līdzpilots — github.com

22. GitHub dokumentācija — koda ieteikumu iegūšana jūsu IDE, izmantojot GitHub Copilot — docs.github.com

23. Microsoft Learn — GitHub Copilot for SQL (VS Code paplašinājums) — learn.microsoft.com

24. Dynatrace dokumentācija — datu novērojamība — docs.dynatrace.com

25. DataGalaxy — Kas ir datu novērojamība? — datagalaxy.com

26. Lielo cerību dokumentācija — cerību pārskats — docs.greatexpectations.io

Atrodiet jaunāko mākslīgo intelektu oficiālajā mākslīgā intelekta palīgu veikalā

Par mums