Ī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 sanāksmes laikā kā 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
-
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.
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
-
Eiropas Komisija — Datu aizsardzības skaidrojums: GDPR principi — commission.europa.eu
-
Informācijas komisāra birojs (ICO) — glabāšanas ierobežojums — ico.org.uk
-
Eiropas Komisija — Cik ilgi datus var glabāt un vai tie ir jāatjaunina? — commission.europa.eu
-
Nacionālais standartu un tehnoloģiju institūts (NIST) — Privātuma ietvars — nist.gov
-
NIST Datoru drošības resursu centrs (CSRC) — SP 800-92: Datoru drošības žurnālu pārvaldības ceļvedis — csrc.nist.gov
-
Interneta drošības centrs (CIS) — Audita žurnālu pārvaldība (CIS vadīklas) — cisecurity.org
-
Snowflake dokumentācija — rindu piekļuves politikas — docs.snowflake.com
-
Google Cloud dokumentācija — BigQuery rindu līmeņa drošība — docs.cloud.google.com
-
BITOL — Atvērto datu līgumu standarts (ODCS) v3.1.0 — bitol-io.github.io
-
BITOL (GitHub) — Atvērto datu līguma standarts — github.com
-
Apache Airflow — dokumentācija (stabila) — airflow.apache.org
-
Apache Airflow — DAG (pamatkoncepcijas) — airflow.apache.org
-
dbt Labs dokumentācija — Kas ir dbt? — docs.getdbt.com
-
dbt Labs dokumentācija — Par dbt modeļiem — docs.getdbt.com
-
dbt Labs dokumentācija — Dokumentācija — docs.getdbt.com
-
dbt Labs dokumentācija — datu testi — docs.getdbt.com
-
dbt Labs dokumentācija — dbt semantiskais slānis — docs.getdbt.com
-
Fivetran dokumentācija — Darba sākšana — fivetran.com
-
Fivetran — Savienotāji — fivetran.com
-
AWS dokumentācija — AWS Lambda izstrādātāja rokasgrāmata — docs.aws.amazon.com
-
GitHub — GitHub līdzpilots — github.com
-
GitHub dokumentācija — koda ieteikumu iegūšana jūsu IDE, izmantojot GitHub Copilot — docs.github.com
-
Microsoft Learn — GitHub Copilot for SQL (VS Code paplašinājums) — learn.microsoft.com
-
Dynatrace dokumentācija — datu novērojamība — docs.dynatrace.com
-
DataGalaxy — Kas ir datu novērojamība? — datagalaxy.com
-
Lielo cerību dokumentācija — cerību pārskats — docs.greatexpectations.io