Papalitan ba ng AI ang mga Data Engineer?

Papalitan ba ng AI ang mga Data Engineer?

Maikling sagot: Hindi direktang mapapalitan ng AI ang mga data engineer; awtomatiko nitong i-automate ang paulit-ulit na trabaho tulad ng SQL drafting, pipeline scaffolding, mga pagsubok, at dokumentasyon. Kung ang iyong tungkulin ay halos walang pagmamay-ari at nakabatay sa mga bayarin, mas lantad ito; kung mayroon kang reliability, mga kahulugan, pamamahala, at tugon sa insidente, higit kang pinapabilis ng AI.

Mga pangunahing punto:

Pagmamay-ari : Unahin ang pananagutan para sa mga resulta, hindi lamang ang mabilisang paggawa ng code.

Kalidad : Bumuo ng mga pagsubok, kakayahang maobserbahan, at mga kontrata upang manatiling mapagkakatiwalaan ang mga pipeline.

Pamamahala : Panatilihing pag-aari ng tao ang privacy, kontrol sa pag-access, pagpapanatili, at mga audit trail.

Paglaban sa Maling Paggamit : Ituring ang mga output ng AI bilang mga draft; suriin ang mga ito upang maiwasan ang kumpiyansang pagkakamali.

Pagbabago ng Tungkulin : Gumugol ng mas kaunting oras sa pag-type ng boilerplate at mas maraming oras sa pagdidisenyo ng mga matibay na sistema.

Papalitan ba ng AI ang mga Data Engineer? Infographic

Kung gumugol ka na ng mahigit limang minuto sa paligid ng mga data team, narinig mo na ang paulit-ulit na sinasabi—minsan ay bumubulong, minsan ay isinasadula sa isang pulong na parang isang plot twist: Papalitan ba ng AI ang mga Data Engineer?

At… naiintindihan ko. Kayang bumuo ng SQL ang AI, bumuo ng mga pipeline, magpaliwanag ng mga stack trace, mag-draft ng mga dbt model, at magmungkahi pa ng mga scheme ng warehouse nang may nakakabahalang kumpiyansa. GitHub Copilot para sa SQL Tungkol sa mga dbt model GitHub Copilot
Parang panonood ng isang forklift na natutong mag-juggle. Kahanga-hanga, medyo nakababahala, at hindi mo lubos na sigurado kung ano ang ibig sabihin nito para sa iyong trabaho 😅

Pero ang totoo ay hindi kasing-linaw ng headline. Lubos na binabago ng AI ang data engineering. Ina-automate nito ang mga nakakabagot at paulit-ulit na bahagi. Pinabibilis nito ang mga sandaling "Alam ko ang gusto ko pero hindi ko matandaan ang syntax". Nagdudulot din ito ng mga bagong uri ng kaguluhan.

Kaya't ilatag natin ito nang maayos, nang walang pabago-bagong optimismo o takot na mag-scroll pababa.

Mga artikulong maaaring gusto mong basahin pagkatapos nito:

🔗 Papalitan ba ng AI ang mga radiologist?
Paano binabago ng imaging AI ang daloy ng trabaho, katumpakan, at mga tungkulin sa hinaharap.

🔗 Papalitan ba ng AI ang mga accountant?
Tingnan kung aling mga gawain sa accounting ang awtomatiko na ina-automate ng AI at kung alin ang nananatiling tao.

🔗 Papalitan ba ng AI ang mga investment banker?
Unawain ang epekto ng AI sa mga deal, pananaliksik, at mga relasyon sa kliyente.

🔗 Papalitan ba ng AI ang mga ahente ng seguro?
Alamin kung paano binabago ng AI ang underwriting, sales, at customer support.

Bakit paulit-ulit na lumalabas ang tanong na “Pinapalitan ng AI ang mga Data Engineer” 😬

Ang takot ay nagmumula sa isang napaka-espesipikong lugar: ang data engineering ay may maraming paulit-ulit na trabaho .

  • Pagsulat at muling pag-factor ng SQL

  • Mga script sa pagbuo ng ingestion

  • Pagmamapa ng mga patlang mula sa isang schema patungo sa isa pa

  • Paggawa ng mga pagsubok at pangunahing dokumentasyon

  • Pag-debug ng mga pagkabigo sa pipeline na… medyo nahuhulaan na

Ang AI ay hindi pangkaraniwang mahusay sa mga paulit-ulit na pattern. At isang bahagi ng data engineering ang eksaktong ganoon - mga pattern na nakasalansan sa mga pattern. Mga mungkahi sa GitHub Copilot code

Gayundin, ang ecosystem ng mga tool ay "tinatago" na ang pagiging kumplikado:

Kaya kapag lumitaw ang AI, parang ito na ang huling piraso. Kung ang salansan ay abstracted na, at kayang isulat ng AI ang glue code… ano pa ang matitira? 🤷

Pero narito ang bagay na hindi napapansin ng mga tao: ang data engineering ay hindi lamang pagta-type . Ang pagta-type ang madaling bahagi. Ang mahirap na bahagi ay ang pagpapagana ng malabo, politikal, at pabago-bagong realidad ng negosyo na parang isang maaasahang sistema.

At nahihirapan pa rin ang AI sa dilim na iyon. Nahihirapan din ang mga tao - mas mahusay lang silang mag-improvise.

Ang talagang ginagawa ng mga data engineer buong araw (ang hindi kaakit-akit na katotohanan) 🧱

Maging prangka tayo - ang titulong "Data Engineer" ay parang gumagawa ka ng mga rocket engine gamit ang purong matematika. Sa pagsasagawa, bumubuo ka ng tiwala .

Ang isang karaniwang araw ay hindi gaanong "mag-imbento ng mga bagong algorithm" at higit pa:

  • Pakikipagnegosasyon sa mga upstream team tungkol sa mga kahulugan ng datos (masakit ngunit kinakailangan)

  • Pagsisiyasat kung bakit nagbago ang isang sukatan (at kung ito ba ay totoo)

  • Paghawak sa schema drift at mga sorpresang "may nagdagdag ng column sa hatinggabi"

  • Pagtiyak na ang mga pipeline ay idempotent, mababawi, at maobserbahan

  • Paggawa ng mga guardrail para hindi aksidenteng makagawa ng mga walang kwentang dashboard ang mga downstream analyst

  • Pamamahala ng mga gastos para hindi maging apoy sa pera ang iyong bodega 🔥

  • Pag-secure ng mga patakaran sa pag-access, pag-awdit, pagsunod, at pagpapanatili Mga prinsipyo ng GDPR (European Commission) Limitasyon sa imbakan (ICO)

  • Pagbuo ng mga produktong datos na magagamit ng mga tao nang hindi ka na kailangang mag-DM ng 20 tanong

Malaking bahagi ng trabaho ay panlipunan at operasyonal:

  • "Sino ang may-ari nitong mesa?"

  • "Mabisa pa ba ang kahulugang ito?"

  • "Bakit nag-e-export ng mga duplicate ang CRM?"

  • "Maaari ba nating ipadala ang sukatang ito sa mga ehekutibo nang walang kahihiyan?" 😭

Makakatulong ang AI sa ilang bahagi nito, oo. Pero ang pagpapalit nito nang buo ay... isang malaking hamon.

Ano ang bumubuo sa isang matibay na bersyon ng tungkulin ng isang data engineering? ✅

Mahalaga ang seksyong ito dahil karaniwang ipinapalagay ng usapang pampalit na ang mga data engineer ay pangunahing mga "tagagawa ng pipeline." Parang pag-aakalang ang mga chef ay pangunahing "nagtatadtad ng mga gulay." Bahagi iyon ng trabaho, ngunit hindi iyon ang trabaho.

Ang isang malakas na bersyon ng isang data engineer ay karaniwang nangangahulugan na kaya nilang gawin ang karamihan sa mga ito:

  • Disenyo para sa pagbabago
    . Nagbabago ang datos. Nagbabago ang mga koponan. Nagbabago ang mga kagamitan. Ang isang mahusay na inhinyero ay bumubuo ng mga sistemang hindi gumuguho sa tuwing bumabaliktad ang katotohanan 🤧

  • Tukuyin ang mga kontrata at inaasahan
    Ano ang ibig sabihin ng "customer"? Ano ang ibig sabihin ng "active"? Ano ang nangyayari kapag nahuli ang isang pagtatalo? Mas pinipigilan ng mga kontrata ang kaguluhan kaysa sa magarbong code. Open Data Contract Standard (ODCS) ODCS (GitHub)

  • Buuin ang obserbabilidad sa lahat ng bagay.
    Hindi lang "tumakbo ba ito" kundi "tumakbo ba ito nang tama." Pagkabago, mga anomalya sa volume, mga pagsabog ng null, mga pagbabago sa distribusyon. Pagmamasid ng datos (Dynatrace) Ano ang pagmasid ng datos?

  • Gumawa ng mga kompromiso tulad ng para sa isang nasa hustong gulang:
    Bilis laban sa kawastuhan, gastos laban sa latency, kakayahang umangkop laban sa pagiging simple. Walang perpektong pipeline, tanging mga pipeline lamang ang kaya mong tanggapin.

  • Isalin ang mga pangangailangan ng negosyo sa mga matibay na sistema.
    Humihingi ang mga tao ng mga sukatan, ngunit ang kailangan nila ay isang produkto ng datos. Kayang ibalangkas ng AI ang code, ngunit hindi nito mahiwagang malalaman ang mga panganib sa negosyo.

  • Panatilihing tahimik ang data.
    Ang pinakamataas na papuri para sa isang data platform ay walang nagsasalita tungkol dito. Ang mga hindi nagaganap na data ay mahusay na data. Tulad ng pagtutubero. Mapapansin mo lang ito kapag may sira na ito 🚽

Kung ginagawa mo ang mga bagay na ito, ang tanong na "Papalitan ba ng AI ang mga Data Engineer?" ay magsisimulang magmukhang... medyo kakaiba. Maaaring palitan ng AI ang mga gawain , hindi ang pagmamay-ari .

Kung saan nakakatulong na ang AI sa mga data engineer (at talagang mahusay ito) 🤖✨

Hindi lang marketing ang AI. Kapag ginamit nang maayos, isa itong lehitimong force multiplier.

1) Mas mabilis na SQL at gawaing transpormasyon

  • Pagbalangkas ng mga kumplikadong sanib

  • Pagsusulat ng mga function ng window na ayaw mong isipin

  • Paggawa ng mga balangkas ng query gamit ang simpleng lohika

  • Pag-refactor ng mga pangit na query sa mga nababasang CTE GitHub Copilot para sa SQL

Malaking bagay ito dahil binabawasan nito ang epekto ng "blank page". Kailangan mo pa ring mag-validate, pero magsisimula ka sa 70% sa halip na 0%.

2) Pag-debug at mga breadcrumb ng ugat ng sanhi

Mahusay ang AI sa:

  • Pagpapaliwanag ng mga mensahe ng error

  • Pagmumungkahi kung saan titingin

  • Pagrerekomenda ng mga hakbang sa uri ng "suriin ang schema mismatch" GitHub Copilot
    Parang may isang walang kapagurang junior engineer na hindi natutulog at kung minsan ay may kumpiyansang nagsisinungaling 😅

3) Pagpapayaman ng dokumentasyon at katalogo ng datos

Awtomatikong nabuo:

  • Mga paglalarawan ng kolum

  • Mga buod ng modelo

  • Mga paliwanag sa lahi

  • "Para saan ginagamit ang talahanayan na ito?" mga draft ng dokumentasyon ng dbt

Hindi ito perpekto, ngunit sinisira nito ang sumpa ng mga hindi dokumentadong pipeline.

4) Pagsubok sa scaffolding at mga pagsusuri

Maaaring imungkahi ng AI ang:

Muli - ikaw pa rin ang magpapasya kung ano ang mahalaga, ngunit pinapabilis nito ang mga nakagawiang bahagi.

5) Kodigo ng "pandikit" ng tubo

Mga template ng config, mga scaffold ng YAML, mga draft ng orchestration DAG. Paulit-ulit ang mga bagay na iyan at paulit-ulit ang kinakain ng AI para sa almusal 🥣 Mga Apache Airflow DAG

Kung saan nahihirapan pa rin ang AI (at ito ang pinakasentro nito) 🧠🧩

Ito ang pinakamahalaga, dahil sinasagot nito ang tanong tungkol sa pagpapalit gamit ang totoong tekstura.

1) Kalabuan at nagbabagong mga kahulugan

Bihirang maging malinaw ang lohika sa negosyo. Nagbabago ang isip ng mga tao sa kalagitnaan ng pangungusap. Ang "Aktibong gumagamit" ay nagiging "aktibong nagbabayad na gumagamit" ay nagiging "aktibong nagbabayad na gumagamit na hindi kasama ang mga refund maliban kung minsan"... alam mo na kung paano iyon.

Hindi kayang aminin ng AI ang kalabuang iyan. Tanging hula lang ang kaya nitong gawin.

2) Pananagutan at panganib

Kapag nasira ang isang pipeline at ang exec dashboard ay nagpapakita ng walang katuturang impormasyon, kailangang may isang taong:

  • triage

  • makipag-ugnayan sa epekto

  • ayusin ito

  • maiwasan ang pag-ulit

  • isulat ang postmortem

  • magdesisyon kung mapagkakatiwalaan pa rin ng negosyo ang mga numero noong nakaraang linggo

Makakatulong ang AI, ngunit hindi ito maaaring maging responsable sa makabuluhang paraan. Ang mga organisasyon ay hindi tumatakbo batay sa vibes - tumatakbo sila batay sa responsibilidad.

3) Sistematikong pag-iisip

Ang mga platform ng datos ay mga ecosystem: ingestion, storage, transformations, orchestration, governance, cost controls, SLAs. Ang pagbabago sa isang layer ay may epekto. Mga konsepto ng Apache Airflow

Kayang magmungkahi ng mga lokal na pag-optimize ang AI na lumilikha ng pandaigdigang problema. Parang pag-aayos ng isang lumalagutok na pinto sa pamamagitan ng pag-alis nito 😬

4) Seguridad, privacy, pagsunod

Dito namamatay ang mga pantasya tungkol sa kapalit.

Maaaring bumuo ng mga patakaran ang AI, ngunit ang ligtas na pagpapatupad ng mga ito ay isang tunay na inhinyeriya.

5) Ang "mga hindi kilalang bagay"

Kadalasang hindi mahuhulaan ang mga insidente ng datos:

  • Tahimik na binabago ng isang vendor API ang semantika

  • Binabaligtad ang isang palagay tungkol sa timezone

  • Dinoble ng backfill ang isang partisyon

  • Ang mekanismo ng muling pagsubok ay nagdudulot ng dobleng pagsusulat

  • Isang bagong tampok ng produkto ang nagpapakilala ng mga bagong pattern ng kaganapan

Mas mahina ang AI kapag ang sitwasyon ay hindi isang kilalang padron.

Talahanayan ng Paghahambing: ano ang nagbabawas sa ano, sa pagsasagawa 🧾🤔

Nasa ibaba ang isang praktikal na pananaw. Hindi "mga kagamitang pumapalit sa mga tao," kundi mga kagamitan at pamamaraang nagpapaliit sa ilang partikular na gawain.

Kasangkapan / pamamaraan Madla Presyo ng vibe Bakit ito gumagana
Mga copilot ng AI code (mga katulong sa SQL + Python) GitHub Copilot Mga inhinyero na nagsusulat ng maraming code Libre hanggang bayad Mahusay sa scaffolding, refactors, syntax… minsan ay mayabang sa isang napaka-espesipikong paraan
Mga pinamamahalaang konektor ng ELT na Fivetran Mga koponan na pagod na sa pagbuo ng ingestion Subscription-y Tinatanggal ang sakit sa paglunok gamit ang pasadyang paraan, ngunit nakakapagpawi nito sa masasayang bagong paraan
Mga plataporma ng pagmamasid sa datos Pagmamasid sa datos (Dynatrace) Sinumang may-ari ng mga SLA Katamtaman hanggang sa negosyo Maagang nakakakita ng mga anomalya - tulad ng mga smoke alarm para sa mga pipeline 🔔
Mga balangkas ng transpormasyon (deklaratibong pagmomodelo) dbt Mga hybrid ng Analytics + DE Karaniwang kagamitan + kalkulasyon Ginagawang modular at masusubukan ang lohika, mas kaunting spaghetti
Mga katalogo ng datos + mga semantikong patong dbt Semantikong Patong Mga organisasyong may kalituhan sa sukatan Depende, sa pagsasagawa Binibigyang-kahulugan ang "katotohanan" nang isang beses - binabawasan ang walang katapusang mga debate sa sukatan
Orkestrasyon gamit ang mga template na Apache Airflow Mga pangkat na nakatuon sa plataporma Gastos sa pagbubukas + operasyon Istandardisa ang mga daloy ng trabaho; mas kaunting snowflake DAG
Pagbuo ng mga dokumentong dbt na tinutulungan ng AI Mga pangkat na ayaw magsulat ng mga dokumento Mura hanggang katamtaman Gumagawa ng mga dokumentong "sapat na" para hindi maglaho ang kaalaman
Mga patakaran sa awtomatikong pamamahala Balangkas ng Pagkapribado ng NIST Mga kinokontrol na kapaligiran Enterprise-y Tumutulong sa pagpapatupad ng mga patakaran - ngunit nangangailangan pa rin ng mga tao upang magdisenyo ng mga patakaran

Pansinin kung ano ang kulang: isang hilera na nagsasabing “pindutin ang buton para alisin ang mga data engineer.” Oo… wala ang hilerang iyon 🙃

Kaya… papalitan ba ng AI ang mga Data Engineer, o ililipat na lang ang papel? 🛠️

Narito ang hindi dramatikong sagot: Papalitan ng AI ang mga bahagi ng daloy ng trabaho, hindi ang propesyon.

Pero babaguhin nito ang pagkakaayos ng tungkulin. At kung babalewalain mo iyon, mararamdaman mo ang pagpisil.

Ano ang mga pagbabago:

  • Mas kaunting oras sa pagsulat ng boilerplate

  • Mas kaunting oras sa paghahanap ng mga dokumento

  • Mas maraming oras sa pagsusuri, pagpapatunay, at pagdidisenyo

  • Mas maraming oras sa pagtukoy ng mga kontrata at mga inaasahan sa kalidad Open Data Contract Standard (ODCS)

  • Mas maraming oras sa pakikipagsosyo sa produkto, seguridad, at pananalapi

Ito ang banayad na pagbabago: ang data engineering ay nagiging hindi gaanong tungkol sa "pagbuo ng mga pipeline" at higit pa tungkol sa "pagbuo ng isang maaasahang sistema ng produkto ng data."

At sa isang tahimik na pag-ikot, iyon ay mas mahalaga, hindi mas kaunti.

Gayundin - at sasabihin ko ito kahit na parang dramatiko - pinapataas ng AI ang bilang ng mga taong maaaring gumawa ng mga artifact ng data , na nagpapataas ng pangangailangan para sa isang tao upang mapanatili ang buong katinuan. Ang mas maraming output ay nangangahulugan ng mas maraming potensyal na kalituhan. GitHub Copilot

Parang binibigyan mo ang lahat ng power drill. Ang galing! Kailangan nang ipatupad ang patakarang "huwag magbutas sa tubo ng tubig" 🪠

Ang bagong skill stack na nananatiling mahalaga (kahit na may AI kahit saan) 🧠⚙️

Kung gusto mo ng praktikal na checklist na "nakakasiguro sa hinaharap", ganito ang hitsura nito:

Pag-iisip sa disenyo ng sistema

  • Pagmomodelo ng datos na nakaligtas sa pagbabago

  • Mga kompromiso sa batch vs streaming

  • Pag-iisip ng latency, gastos, pagiging maaasahan

Inhinyeriya ng kalidad ng datos

Pamamahala at arkitektura ng tiwala

Pag-iisip sa plataporma

  • Mga template na magagamit muli, mga ginintuang landas

  • Mga pamantayang pattern para sa pag-ingest, pagbabago, pagsubok ng Fivetran dbt

  • Mga kagamitang self-service na hindi natutunaw

Komunikasyon (oo, talaga)

  • Pagsusulat ng malinaw na mga dokumento

  • Pag-align ng mga kahulugan

  • Magalang ngunit matatag na pagsasabi ng "hindi"

  • Pagpapaliwanag ng mga kompromiso nang hindi nagmumukhang robot 🤖

Kung magagawa mo ang mga ito, ang tanong na "Papalitan ba ng AI ang mga Data Engineer?" ay magiging hindi gaanong mapanganib. Ang AI ang magiging exoskeleton mo, hindi ang iyong kapalit.

Mga makatotohanang senaryo kung saan lumiliit ang ilang tungkulin sa data engineering 📉

Okay, mabilis na pag-unawa sa realidad, dahil hindi naman puro sikat ng araw at emoji confetti ang nangyayari 🎉

Ang ilang mga tungkulin ay mas nakalantad:

  • Mga tungkuling purong paglunok lamang kung saan ang lahat ay karaniwang mga konektor

  • Mga pangkat na gumagawa ng halos paulit-ulit na mga pipeline ng pag-uulat na may kaunting domain nuance

  • Mga organisasyon kung saan ang data engineering ay itinuturing na "mga SQL monkey" (mabagsik, ngunit totoo)

  • Mga tungkuling mababa ang pagmamay-ari kung saan ang trabaho ay mga tiket at kopya-paste lamang

Maaaring mabawasan ng AI kasama ang pinamamahalaang tooling ang mga pangangailangang iyon.

Ngunit kahit na doon, ang kapalit ay karaniwang ganito ang hitsura:

  • Mas kaunting mga taong gumagawa ng parehong paulit-ulit na gawain

  • Mas maraming diin sa pagmamay-ari at pagiging maaasahan ng platform

  • Isang pagbabago patungo sa "mas maraming pipeline ang kayang suportahan ng isang tao"

Kaya oo - maaaring magbago ang mga padron ng bilang ng mga tauhan. Nagbabago ang mga tungkulin. Nagbabago ang mga titulo. Totoo ang bahaging iyon.

Gayunpaman, nananatili pa rin ang bersyon ng tungkulin na may mataas na pagmamay-ari at mataas na tiwala.

Pangwakas na buod 🧾✅

Papalitan ba ng AI ang mga Data Engineer? Hindi sa malinis at ganap na paraan na iniisip ng mga tao.

Ang AI ay:

Ngunit ang data engineering ay pangunahing tungkol sa:

Makakatulong ang AI diyan... pero hindi nito "pagmamay-ari" ito.

Kung ikaw ay isang data engineer, ang hakbang ay simple (hindi madali, ngunit simple):
umasa sa pagmamay-ari, kalidad, platform thinking, at komunikasyon. Hayaan ang AI na humawak sa boilerplate habang ikaw ang humahawak sa mga mahahalagang bahagi.

At oo - minsan ang ibig sabihin niyan ay ang pagiging matanda sa silid. Hindi naman sa pagiging kaakit-akit. Pero tahimik na makapangyarihan 😄

Papalitan ba ng AI ang mga Data Engineer?
Papalitan nito ang ilang gawain, babaguhin ang ladder, at gagawing mas mahalaga ang pinakamahuhusay na data engineer. Iyan ang totoong kwento.

Mga Madalas Itanong

Papalitan ba nang tuluyan ng AI ang mga data engineer?

Sa karamihan ng mga organisasyon, mas malamang na ang AI ang humawak sa mga partikular na gawain kaysa tuluyang burahin ang papel. Maaari nitong mapabilis ang SQL drafting, pipeline scaffolding, dokumentasyon ng mga unang pagpasa, at paglikha ng mga pangunahing pagsubok. Ngunit ang data engineering ay mayroon ding pagmamay-ari at pananagutan, kasama ang hindi kaakit-akit na gawain ng paggawa ng magulong realidad ng negosyo na parang isang maaasahang sistema. Ang mga bahaging iyon ay nangangailangan pa rin ng mga tao upang magpasya kung ano ang hitsura ng "tama" at upang akuin ang responsibilidad kapag may mga bagay na nasira.

Anong mga bahagi ng data engineering ang awtomatiko nang ina-automate ng AI?

Pinakamahusay ang AI sa mga paulit-ulit na gawain: pagbalangkas at pag-refactor ng SQL, pagbuo ng mga skeleton ng dbt model, pagpapaliwanag ng mga karaniwang error, at paggawa ng mga balangkas ng dokumentasyon. Maaari rin itong mag-scaffold ng mga pagsubok tulad ng null o uniqueness check at bumuo ng template na "glue" code para sa mga tool sa orchestration. Ang panalo ay momentum - magsisimula ka nang mas malapit sa isang gumaganang solusyon - ngunit kailangan mo pa ring patunayan ang kawastuhan at tiyaking akma ito sa iyong kapaligiran.

Kung kayang magsulat ng SQL at pipelines ang AI, ano pa ang matitira para sa mga data engineer?

Marami: pagtukoy sa mga kontrata ng datos, paghawak sa schema drift, at pagtiyak na ang mga pipeline ay idempotent, naoobserbahan, at nababawi. Ang mga data engineer ay gumugugol ng oras sa pagsisiyasat ng mga pagbabago sa sukatan, pagbuo ng mga guardrail para sa mga downstream na gumagamit, at pamamahala ng mga tradeoff sa gastos at pagiging maaasahan. Ang trabaho ay kadalasang nakasalalay sa pagbuo ng tiwala at pagpapanatiling "tahimik" ng data platform, ibig sabihin ay sapat na matatag na walang kailangang mag-isip tungkol dito araw-araw.

Paano binabago ng AI ang pang-araw-araw na gawain ng isang data engineer?

Karaniwan nitong binabawasan ang boilerplate at "oras ng paghahanap," kaya mas kaunting oras ang ginugugol mo sa pagta-type at mas maraming oras sa pagrerepaso, pagpapatunay, at pagdidisenyo. Ang pagbabagong iyon ay nagtutulak sa papel patungo sa pagtukoy ng mga inaasahan, pamantayan ng kalidad, at mga magagamit muli na pattern sa halip na manu-manong i-code ang lahat. Sa pagsasagawa, malamang na mas marami kang gagawing pakikipagtulungan sa produkto, seguridad, at pananalapi - dahil ang teknikal na output ay nagiging mas madaling likhain, ngunit mas mahirap pamahalaan.

Bakit nahihirapan ang AI sa mga malabong kahulugan ng negosyo tulad ng "aktibong gumagamit"?

Dahil ang business logic ay hindi static o tumpak - nagbabago ito sa kalagitnaan ng proyekto at nag-iiba-iba depende sa stakeholder. Maaaring bumuo ng interpretasyon ang AI, ngunit hindi nito maaaring magdesisyon kapag nagbabago ang mga kahulugan o lumitaw ang mga hindi pagkakasundo. Ang data engineering ay kadalasang nangangailangan ng negosasyon, pagdodokumento ng mga pagpapalagay, at paggawa ng mga malabong kinakailangan tungo sa mga matibay na kontrata. Ang gawaing "human alignment" na iyon ang isang pangunahing dahilan kung bakit hindi nawawala ang papel kahit na bumubuti ang tooling.

Ligtas bang mapangasiwaan ng AI ang pamamahala, privacy, at pagsunod sa datos?

Makakatulong ang AI sa pagbuo ng mga patakaran o pagmumungkahi ng mga pamamaraan, ngunit ang ligtas na pagpapatupad ay nangangailangan pa rin ng tunay na inhinyeriya at maingat na pangangasiwa. Ang pamamahala ay kinabibilangan ng mga kontrol sa pag-access, paghawak ng PII, mga panuntunan sa pagpapanatili, mga audit trail, at kung minsan ay mga limitasyon sa paninirahan. Ito ay mga lugar na may mataas na peligro kung saan ang "halos tama" ay hindi katanggap-tanggap. Dapat idisenyo ng mga tao ang mga patakaran, beripikahin ang pagpapatupad, at manatiling may pananagutan para sa mga resulta ng pagsunod.

Anong mga kasanayan ang nananatiling mahalaga para sa mga data engineer habang umuunlad ang AI?

Mga kasanayang nagpapatatag sa mga sistema: pag-iisip sa disenyo ng sistema, inhinyeriya ng kalidad ng datos, at estandardisasyon na nakatuon sa plataporma. Ang mga kontrata, kakayahang maobserbahan, mga gawi sa pagtugon sa insidente, at disiplinadong pagsusuri ng ugat ng sanhi ay nagiging mas mahalaga kapag mas maraming tao ang mabilis na nakakabuo ng mga artifact ng datos. Ang komunikasyon ay nagiging isang pagkakaiba rin - ang pag-aayos ng mga kahulugan, pagsulat ng malinaw na mga dokumento, at pagpapaliwanag ng mga kompromiso nang walang drama ay isang malaking bahagi ng pagpapanatiling mapagkakatiwalaan ng datos.

Aling mga tungkulin sa data engineering ang pinakamapanganib mula sa AI at pinamamahalaang tooling?

Ang mga tungkuling nakatuon lamang sa paulit-ulit na paggamit o karaniwang mga pipeline ng pag-uulat ay mas nalalantad, lalo na kapag ang mga pinamamahalaang ELT connector ay sumasaklaw sa karamihan ng mga mapagkukunan. Ang mga gawaing mababa ang pagmamay-ari at nakabatay sa mga tiket ay maaaring lumiit dahil binabawasan ng AI at abstraction ang pagsisikap sa bawat pipeline. Ngunit kadalasan ay mukhang mas kaunting tao ang gumagawa ng mga paulit-ulit na gawain, hindi "walang mga data engineer." Ang mga tungkuling may mataas na pagmamay-ari na nakasentro sa pagiging maaasahan, kalidad, at tiwala ay nananatiling pangmatagalan.

Paano ko dapat gamitin ang mga tool tulad ng GitHub Copilot o dbt gamit ang AI nang hindi lumilikha ng kaguluhan?

Ituring ang output ng AI bilang isang draft, hindi isang desisyon. Gamitin ito upang bumuo ng mga query skeleton, mapabuti ang readability, o mag-scaffold ng mga dbt test at dokumento, pagkatapos ay i-validate laban sa totoong data at mga edge case. Ipares ito sa mga matibay na kombensiyon: mga kontrata, mga pamantayan sa pagpapangalan, mga observability check, at mga kasanayan sa pagsusuri. Ang layunin ay mas mabilis na paghahatid nang hindi isinasakripisyo ang pagiging maaasahan, pagkontrol sa gastos, o pamamahala.

Mga Sanggunian

  1. Komisyon sa Europa - Paliwanag sa proteksyon ng datos: Mga prinsipyo ng GDPR - commission.europa.eu

  2. Tanggapan ng Komisyoner ng Impormasyon (ICO) - Limitasyon sa imbakan - ico.org.uk

  3. Komisyon sa Europa - Gaano katagal maaaring itago ang datos at kinakailangan ba itong i-update? - commission.europa.eu

  4. Pambansang Instituto ng mga Pamantayan at Teknolohiya (NIST) - Balangkas ng Pagkapribado - nist.gov

  5. NIST Computer Security Resource Center (CSRC) - SP 800-92: Gabay sa Pamamahala ng Log ng Seguridad ng Computer - csrc.nist.gov

  6. Sentro para sa Seguridad sa Internet (CIS) - Pamamahala ng Log ng Audit (Mga Kontrol ng CIS) - cisecurity.org

  7. Dokumentasyon ng Snowflake - Mga patakaran sa pag-access sa hilera - docs.snowflake.com

  8. Dokumentasyon ng Google Cloud - Seguridad sa antas ng hilera ng BigQuery - docs.cloud.google.com

  9. BITOL - Pamantayan sa Kontrata ng Bukas na Datos (ODCS) v3.1.0 - bitol-io.github.io

  10. BITOL (GitHub) - Pamantayan sa Kontrata ng Bukas na Datos - github.com

  11. Apache Airflow - Dokumentasyon (matatag) - airflow.apache.org

  12. Apache Airflow - Mga DAG (mga pangunahing konsepto) - airflow.apache.org

  13. Dokumentasyon ng dbt Labs - Ano ang dbt? - docs.getdbt.com

  14. Dokumentasyon ng dbt Labs - Tungkol sa mga modelo ng dbt - docs.getdbt.com

  15. Dokumentasyon ng dbt Labs - Dokumentasyon - docs.getdbt.com

  16. Dokumentasyon ng dbt Labs - Mga pagsubok sa datos - docs.getdbt.com

  17. Dokumentasyon ng dbt Labs - dbt Semantic Layer - docs.getdbt.com

  18. Dokumentasyon ng Fivetran - Pagsisimula - fivetran.com

  19. Fivetran - Mga Konektor - fivetran.com

  20. Dokumentasyon ng AWS - Gabay sa Developer ng AWS Lambda - docs.aws.amazon.com

  21. GitHub - GitHub Copilot - github.com

  22. Mga Dokumento ng GitHub - Pagkuha ng mga mungkahi sa code sa iyong IDE gamit ang GitHub Copilot - docs.github.com

  23. Microsoft Learn - GitHub Copilot para sa SQL (ekstensyon ng VS Code) - learn.microsoft.com

  24. Dokumentasyon ng Dynatrace - Pagmamasid sa Datos - docs.dynatrace.com

  25. DataGalaxy - Ano ang data observability? - datagalaxy.com

  26. Dokumentasyon ng Mahusay na mga Inaasahan - Pangkalahatang-ideya ng mga Inaasahan - docs.greatexpectations.io

Hanapin ang Pinakabagong AI sa Opisyal na Tindahan ng AI Assistant

Tungkol sa Amin

Balik sa blog