Ці заменіць штучны інтэлект інжынераў дадзеных? [Відэа і віктарына]

Кароткі адказ: штучны інтэлект не заменіць інжынераў дадзеных цалкам; ён аўтаматызуе паўтаральную працу, такую ​​як чарчэнне SQL-запытаў, стварэнне канвеераў, тэставанне і дакументацыя. Калі ваша роля ў асноўным звязана з нізкім узроўнем уласнасці і працай па заяўках, яна больш рызыкоўная; калі вы адказваеце за надзейнасць, азначэнні, кіраванне і рэагаванне на інцыдэнты, штучны інтэлект у асноўным робіць вас хутчэйшымі.

Асноўныя высновы:

Адказнасць: Аддавайце прыярытэт адказнасці за вынікі, а не толькі за хуткае стварэнне кода.

Якасць: стварайце тэсты, назіральнасць і кантракты, каб канвееры заставаліся надзейнымі.

Кіраванне: Захоўвайце прыватнасць, кантроль доступу, захоўванне і журналы аўдыту ва ўласнасці чалавека.

Супраціў злоўжыванням: разглядайце вынікі штучнага інтэлекту як чарнавікі; праглядайце іх, каб пазбегнуць упэўненых памылак.

Змена роляў: менш часу прысвячайце набору шаблонаў і больш часу распрацоўцы трывалых сістэм.

Калі вы правялі больш за пяць хвілін з камандамі па апрацоўцы дадзеных, вы чулі прыпеў — часам яго шапталі, часам агучвалі на сустрэчы, як сюжэтны паварот: ці заменіць штучны інтэлект інжынераў дадзеных?

І… я разумею. Штучны інтэлект можа генераваць SQL, будаваць канвееры, тлумачыць трасіроўкі стэкаў, складаць мадэлі DBT і нават прапаноўваць схемы складоў з трывожнай упэўненасцю. GitHub Copilot для SQL Пра мадэлі DBT GitHub Copilot
Гэта адчуванне падобна на назіранне за аўтапагрузчыкам, які вучыцца жанглёрству. Уражвае, трохі трывожна, і вы не зусім упэўненыя, што гэта значыць для вашай працы 😅

Але праўда не такая акуратная, як паказана ў загалоўку. Штучны інтэлект цалкам змяняе інжынерыю дадзеных. Ён аўтаматызуе сумныя, паўтаральныя фрагменты. Ён паскарае моманты «я ведаю, чаго хачу, але не магу ўспомніць сінтаксіс». Ён таксама спараджае зусім новыя віды хаосу.

Дык давайце раскладзем усё як след, без аптымізму, які б ні хваляваў рукой, ці панікі, звязанай з чаканнямі.

Артыкулы, якія вам могуць спадабацца пасля гэтага:

🔗 Ці заменіць штучны інтэлект рэнтгенолагаў?
Як штучны інтэлект для стварэння візуалізацыі змяняе працоўны працэс, дакладнасць і будучыя ролі.

🔗 Ці заменіць штучны інтэлект бухгалтараў?
Паглядзіце, якія бухгалтарскія задачы аўтаматызуе штучны інтэлект, а якія застаюцца чалавечымі.

🔗 Ці заменіць штучны інтэлект інвестыцыйных банкіраў?
Зразумейце ўплыў штучнага інтэлекту на здзелкі, даследаванні і адносіны з кліентамі.

🔗 Ці заменіць штучны інтэлект страхавых агентаў?
Даведайцеся, як штучны інтэлект трансфармуе андэррайтынг, продажы і падтрымку кліентаў.

Чаму пытанне «штучны інтэлект замяняе інжынераў дадзеных» зноў і зноў узнікае 😬

Страх зыходзіць з вельмі канкрэтнага месца: інжынерыя дадзеных патрабуе шмат паўтаральнай працы.

• Напісанне і рэфактарынг SQL

• Стварэнне скрыптоў прыёму дадзеных

• Адлюстраванне палёў з адной схемы ў іншую

• Стварэнне тэстаў і базавай дакументацыі

• Адладка збояў канвеера, якія… збольшага прадказальныя

Штучны інтэлект незвычайна добра спраўляецца з паўтаральнымі шаблонамі. І частка інжынерыі дадзеных менавіта такая — шаблоны, якія складаюцца адзін з аднаго. Прапановы кода Copilot на GitHub

Акрамя таго, экасістэма інструментаў ужо «хавае» складанасць:

• Кіраваныя раздымы ELT Дакументацыя Fivetran

• Бессерверныя вылічэнні AWS Lambda (бессерверныя вылічэнні)

• Забеспячэнне сховішча адным пстрычкай мышы

• Аўтамаштабная аркестрацыя Apache Airflow дакументацыя

• Дэкларатыўныя фрэймворкі пераўтварэнняў Што такое DBT?

Такім чынам, калі з'яўляецца штучны інтэлект, ён можа адчувацца апошнім кавалачкам. Калі стэк ужо абстрагаваны, і штучны інтэлект можа напісаць злучальны код... што застаецца? 🤷

Але вось што людзі прапускаюць: інжынерыя дадзеных — гэта не толькі набор тэксту. Набор тэксту — гэта лёгкая частка. Цяжкая частка — прымусіць цьмяную, палітычную, зменлівую бізнес-рэальнасць паводзіць сябе як надзейная сістэма.

І штучны інтэлект усё яшчэ змагаецца з гэтай цемрай. Людзі таксама змагаюцца — яны проста лепш імправізуюць.

Чым насамрэч займаюцца інжынеры дадзеных цэлы дзень (непрывабная праўда) 🧱

Будзем шчырымі — пасада «інжынер дадзеных» гучыць так, быццам вы будуеце ракетныя рухавікі з чыстай матэматыкі. На практыцы вы будуеце давер.

Звычайны дзень — гэта менш «вынаходніцтва новых алгарытмаў» і больш:

• Перамовы з камандамі вышэйшага ўзроўню адносна вызначэнняў дадзеных (балюча, але неабходна)

• Даследаванне таго, чаму паказчык змяніўся (і ці гэта рэальна)

• Апрацоўка дрэйфу схемы і нечаканых памылак тыпу «хтосьці дадаў слупок апоўначы»

• Забеспячэнне ідэмпатэнтнасці, аднаўляльнасці і назіральнасці канвеераў

• Стварэнне ахоўных панэляў, каб аналітыкі ніжэй па плыні выпадкова не стваралі бессэнсоўныя панэлі кіравання

• Кіраванне выдаткамі, каб ваш склад не ператварыўся ў вогнішча грошай 🔥

• Палітыка забеспячэння доступу, аўдыту, адпаведнасці і захоўвання дадзеных Прынцыпы GDPR (Еўрапейская камісія) Абмежаванне захоўвання дадзеных (ICO)

• Стварэнне прадуктаў з дадзенымі, якімі людзі могуць карыстацца без асабістых паведамленняў. 20 пытанняў

Значная частка працы — гэта сацыяльны і аперацыйны аспект:

• «Каму належыць гэты стол?»

• «Ці гэтае вызначэнне ўсё яшчэ актуальнае?»

• «Чаму CRM экспартуе дублікаты?»

• «Ці можам мы без сораму перадаць гэты паказчык кіраўнікам?» 😭

Штучны інтэлект, вядома, можа дапамагчы з некаторымі гэтымі аспектамі. Але цалкам замяніць яго... складана.

Што робіць ролю інжынера дадзеных моцнай? ✅

Гэты раздзел важны, бо ў размовах пра замену звычайна мяркуецца, што інжынеры па апрацоўцы дадзеных — гэта ў асноўным «будаўнікі канвеераў». Гэта як меркаваць, што кухары ў асноўным «рэжуць гародніну». Гэта частка працы, але не сама праца.

Моцная версія інжынера дадзеных звычайна азначае, што ён можа рабіць большасць з наступных дзеянняў:

• Дызайн для змен
  . Змяняюцца дадзеныя. Змяняюцца каманды. Змяняюцца інструменты. Добры інжынер стварае сістэмы, якія не развальваюцца кожны раз, калі рэальнасць чхае 🤧

• Вызначэнне кантрактаў і чаканняў
  Што азначае «кліент»? Што азначае «актыўны»? Што адбываецца, калі радок прыходзіць са спазненнем? Кантракты прадухіляюць хаос лепш, чым мудрагелісты код. Стандарт кантрактаў адкрытых даных (ODCS) ODCS (GitHub)

• Убудуйце назіральнасць ва ўсё.
  Не проста «ці працавала гэта», а «ці працавала гэта правільна». Свежасць, анамаліі аб'ёму, нулявыя выбухі, зрухі размеркавання. Назіральнасць дадзеных (Dynatrace) Што такое назіральнасць дадзеных?

• Рабіце кампрамісы, як дарослы:
  хуткасць супраць карэктнасці, кошт супраць затрымкі, гнуткасць супраць прастаты. Ідэальнага канвеера не існуе, ёсць толькі канвееры, з якімі можна змірыцца.

• Пераўтварыце патрэбы бізнесу ў трывалыя сістэмы.
  Людзі просяць метрыкі, але ім патрэбны прадукт дадзеных. Штучны інтэлект можа напісаць код, але ён не можа чароўным чынам ведаць бізнес-мінныя перашкоды.

• Захоўвайце даныя ў цішыні
  Найвышэйшым кампліментам для платформы даных з'яўляецца тое, што пра яе ніхто не гаворыць. Нечаканыя даныя — гэта добрыя даныя. Як сантэхніка. Вы заўважаеце іх толькі тады, калі яны выходзяць з ладу 🚽

Калі вы робіце гэта, пытанне «Ці заменіць штучны інтэлект інжынераў апрацоўкі дадзеных?» пачынае гучаць… крыху дзіўна. Штучны інтэлект можа замяніць задачы, а не адказнасць.

Дзе штучны інтэлект ужо дапамагае інжынерам дадзеных (і гэта сапраўды выдатна) 🤖✨

Штучны інтэлект — гэта не проста маркетынг. Пры правільным выкарыстанні ён з'яўляецца сапраўдным памнажальнікам сілы.

1) Хутчэйшыя SQL-запыты і трансфармацыі

• Чарцёжныя складаныя злучэнні

• Напісанне аконных функцый, пра якія вы б лепш не думалі

• Ператварэнне логікі простай мовы ў шкілеты запытаў

• Рэфактарынг непрыгожых запытаў у чытэльныя CTE GitHub Copilot для SQL

Гэта вельмі важна, бо памяншае эфект «пустой старонкі». Вам усё роўна трэба будзе правяраць, але вы пачынаеце з 70% замест 0%.

2) Адладка і пошук першапрычын

Штучны інтэлект добра спраўляецца з:

• Тлумачэнне паведамленняў пра памылкі

• Падказваю, дзе шукаць

• Рэкамендацыя па этапах тыпу «праверка неадпаведнасці схемы» GitHub Copilot
  Гэта як нястомны малодшы інжынер, які ніколі не спіць і часам упэўнена хлусіць 😅

3) Папаўненне дакументацыі і каталога дадзеных

Аўтаматычна згенеравана:

• Апісанні слупкоў

• Кароткі змест мадэляў

• Тлумачэнні паходжання

• «Для чаго выкарыстоўваецца гэтая табліца?» — чарнавік дакументацыі па DBT.

Гэта не ідэальна, але гэта парушае праклён недакументаваных канвеераў.

4) Праверка і праверка будаўнічых рыштаванняў

Штучны інтэлект можа прапанаваць:

• Асноўныя нулявыя тэсты

• Праверкі на ўнікальнасць

• Ідэі спасылачнай цэласнасці

• Сцвярджэнні ў стылі «Гэты паказчык ніколі не павінен змяншацца», тэсты дадзеных DBT, Вялікія чаканні: Чаканні

Зноў жа — вы ўсё роўна вырашаеце, што важна, але гэта паскарае руцінныя часткі.

5) Код для «склейвання» трубаправода

Шаблоны канфігурацый, YAML-скафолды, аркестрацыйныя чарнавікі DAG. Усё гэта паўтараецца, і штучны інтэлект з'ядае паўтаральнае на сняданак 🥣 DAG Apache Airflow

Дзе штучны інтэлект усё яшчэ змагаецца (і ў гэтым яго аснова) 🧠🧩

Гэта самая важная частка, бо яна дае адказ на пытанне замены з рэальнай тэкстурай.

1) Неадназначнасць і змены ў азначэннях

Бізнес-логіка рэдка бывае выразнай. Людзі мяняюць сваё меркаванне на паўслове. «Актыўны карыстальнік» становіцца «актыўным плацежаздольным карыстальнікам», а потым — «актыўным плацежаздольным карыстальнікам без вяртання грошай, за выключэннем некаторых выпадкаў»... ну, вы ведаеце, як гэта бывае.

Штучны інтэлект не можа прызнаць гэтую двухсэнсоўнасць. Ён можа толькі здагадвацца.

2) Адказнасць і рызыка

Калі канвеер ламаецца, і панэль кіравання паказвае глупства, хтосьці павінен:

• трыяж

• паведамляць пра ўплыў

• выправіць гэта

• прадухіліць рэцыдыў

• напісаць пасмяротнае заключэнне

• вырашыць, ці можна давяраць бізнесу лічбам мінулага тыдня

Штучны інтэлект можа дапамагаць, але ён не можа несці значную адказнасць. Арганізацыі працуюць не на вібрацыях — яны працуюць на адказнасці.

3) Сістэмнае мысленне

Платформы дадзеных — гэта экасістэмы: прыём, захоўванне, пераўтварэнні, аркестрацыя, кіраванне, кантроль выдаткаў, пагадненні аб узроўні абслугоўвання. Змена ў адным узроўні — гэта хвалі. Канцэпцыі Apache Airflow.

Штучны інтэлект можа прапанаваць лакальныя аптымізацыі, якія ствараюць глабальны боль. Гэта як паправіць скрыпучыя дзверы, зняўшы іх 😬

4) Бяспека, прыватнасць, адпаведнасць патрабаванням

Вось тут і паміраюць фантазіі пра замену.

• Кантроль доступу

• Бяспека на ўзроўні радкоў Палітыкі доступу да радкоў Snowflake Бяспека на ўзроўні радкоў BigQuery

• Апрацоўка персанальна даных (PDA) NIST Privacy Framework

• Правілы захоўвання Абмежаванне захоўвання (ICO) Рэкамендацыі ЕС па захоўванні

• Аўдытарскія журналы NIST SP 800-92 (кіраванне журналамі) CIS Control 8 (кіраванне журналамі аўдыту)

• Абмежаванні на захоўванне дадзеных

Штучны інтэлект можа распрацоўваць палітыкі, але іх бяспечнае ўкараненне — гэта сапраўдная інжынерыя.

5) «Невядомыя невядомыя»

Інцыдэнты з данымі часта непрадказальныя:

• API пастаўшчыка ціха змяняе семантыку

• Меркаванне пра часавыя паясы мяняецца

• Запаўненне дублюе раздзел

• Механізм паўторнай спробы прыводзіць да падвойнага запісу

• Новая функцыя прадукту прадстаўляе новыя шаблоны падзей

Штучны інтэлект слабейшы, калі сітуацыя не з'яўляецца вядомай заканамернасцю.

Параўнальная табліца: што што зніжае на практыцы 🧾🤔

Ніжэй прыведзены практычны погляд. Не «інструменты, якія замяняюць людзей», а інструменты і падыходы, якія скарачаюць пэўныя задачы.

Звярніце ўвагу, чаго не хапае: радка з надпісам «націсніце кнопку, каб выдаліць інжынераў дадзеных». Так... гэтага радка не існуе 🙃

Дык… ці заменіць штучны інтэлект інжынераў дадзеных, ці проста зменіць іх ролю? 🛠️

Вось не драматызаваны адказ: штучны інтэлект заменіць часткі працоўнага працэсу, а не прафесію.

Але гэта перабудуе ролю. І калі вы праігнаруеце гэта, вы адчуеце ціск.

Што змяняецца:

• Менш часу трэба траціць на напісанне шаблонных тэкстаў

• Менш часу на пошук дакументаў

• Больш часу на праверку, праверку і праектаванне

• Больш часу на вызначэнне кантрактаў і чаканняў па якасці Стандарт адкрытых даных (ODCS)

• Больш часу на супрацоўніцтва ў галіне прадуктаў, бяспекі і фінансаў

Гэта тонкі зрух: інжынерыя дадзеных перастае быць арыентавана на «стварэнне канвеераў» і больш на «стварэнне надзейнай сістэмы прадуктаў дадзеных»

І, калі паверыць у ціхі паваротны момант, гэта больш каштоўна, а не менш.

Акрамя таго — і я скажу гэта, нават калі гэта прагучыць драматычна — штучны інтэлект павялічвае колькасць людзей, якія могуць ствараць артэфакты дадзеных, што павялічвае патрэбу ў тым, хто будзе падтрымліваць здаровы сэнс усяго гэтага. Большы вынік азначае большую патэнцыйную блытаніну. GitHub Copilot

Гэта як даць усім электрадрыль. Выдатна! Цяпер хтосьці павінен выконваць правіла «калі ласка, не свідруйце ў вадаправоднай трубе» 🪠

Новы набор навыкаў, які застаецца каштоўным (нават калі штучны інтэлект паўсюль) 🧠⚙️

Калі вам патрэбен практычны кантрольны спіс, гатовы да будучыні, ён выглядае наступным чынам:

Мысленне праектавання сістэм

• Мадэляванне дадзеных, якое выжывае змены

• Кампрамісы паміж пакетнай і струменевай перадачай

• Затрымка, кошт, надзейнасць

Інжынерыя якасці дадзеных

• Кантракты, праверкі, выяўленне анамалій. Стандарт адкрытых даных (ODCS). Назіральнасць даных (Dynatrace).

• SLA, SLO, звычкі рэагавання на інцыдэнты

• Аналіз першапрычын з дысцыплінай (не вібрацыямі)

Архітэктура кіравання і даверу

• Шаблоны доступу

• Аўдытабельнасць NIST SP 800-92 (кіраванне журналамі)

• Канфідэнцыяльнасць па дызайне NIST Privacy Framework

• Кіраванне жыццёвым цыклам дадзеных Рэкамендацыі ЕС па захоўванні

Платформеннае мысленне

• Шматразовыя шаблоны, залатыя сцежкі

• Стандартызаваныя шаблоны для прыёму, пераўтварэнняў, тэставання і тэставання дадзеных Fivetran DBT

• Інструменты самаабслугоўвання, якія не плавяцца

Зносіны (так, сапраўды)

• Напісанне зразумелых дакументаў

• Узгадненне азначэнняў

• Кажыце «не» ветліва, але цвёрда

• Тлумачу кампрамісы, не гучачы як робат 🤖

Калі вы можаце зрабіць гэта, пытанне «Ці заменіць штучны інтэлект інжынераў апрацоўкі дадзеных?» становіцца менш пагрозлівым. Штучны інтэлект становіцца вашым экзашкілетам, а не вашай заменай.

Рэалістычныя сцэнарыі, калі некаторыя пасады інжынера дадзеных скарачаюцца 📉

Добра, хуткая праверка рэальнасці, бо гэта не ўсё сонца і канфеці з эмодзі 🎉

Некаторыя ролі больш адкрытыя:

• Ролі толькі для прыёму дадзеных, дзе ўсё з'яўляецца стандартным злучальнікам. Злучальнікі Fivetran.

• Каманды ў асноўным выконваюць паўтаральныя справаздачныя працэсы з мінімальнымі нюансамі ў галіне

• Арганізацыі, дзе да інжынерыі дадзеных ставяцца як да «SQL-малпаў» (жорстка, але праўда)

• Пасады з нізкім узроўнем уласнасці, дзе праца складаецца толькі з квіткоў і капіявання

Штучны інтэлект разам з кіраванымі інструментамі могуць скараціць гэтыя патрэбы.

Але нават там замена звычайна выглядае наступным чынам:

• Менш людзей выконваюць адну і тую ж паўтаральную працу

• Большы акцэнт на ўласнасці платформы і яе надзейнасці

• Зрух у бок «адзін чалавек можа абслугоўваць больш трубаправодаў»

Так, колькасць персаналу можа змяняцца. Ролі развіваюцца. Пасады мяняюцца. Гэта рэальна.

Тым не менш, версія гэтай ролі, якая прадугледжвае высокую ступень уласнасці і высокі ўзровень даверу, застаецца.

Заключнае рэзюмэ 🧾✅

Ці заменіць штучны інтэлект інжынераў апрацоўкі дадзеных? Не ў тым чыстым, поўным выглядзе, як людзі сабе ўяўляюць.

Штучны інтэлект будзе:

• аўтаматызаваць паўтаральныя задачы

• паскорыць кадаванне, адладку і дакументацыю GitHub Copilot для SQL dbt дакументацыя

• знізіць выдаткі на вытворчасць трубаправодаў

Але інжынерыя дадзеных у аснове сваёй — гэта:

• падсправаздачнасць

• праектаванне сістэмы

• давер, якасць і кіраванне Стандарт кантрактаў па адкрытых дадзеных (ODCS) NIST Privacy Framework

• пераўтварэнне цьмянай бізнес-рэальнасці ў надзейныя прадукты дадзеных

Штучны інтэлект можа дапамагчы з гэтым... але ён не «валодае» гэтым.

Калі вы інжынер апрацоўкі дадзеных, крок просты (не лёгкі, але просты):
засяродзьцеся на адказнасці, якасці, платформенным мысленні і камунікацыі. Дазвольце штучнаму інтэлекту займацца шаблоннымі працэсамі, а вы — тым, што мае значэнне.

І так, часам гэта азначае быць дарослым у пакоі. Не гламурна. Але ціха і магутна 😄

Ці заменіць штучны інтэлект інжынераў апрацоўкі дадзеных?
Ён заменіць некаторыя задачы, перастануе кар'ерную лесвіцу і зробіць лепшых інжынераў апрацоўкі дадзеных яшчэ больш каштоўнымі. Вось у чым сапраўдная гісторыя.

Прыклад з рэальнага свету: стварэнне працоўнага працэсу агляду канвеера дадзеных з дапамогай штучнага інтэлекту 🛠️

Сцэнар

Уявіце сабе невялікую кампанію электроннай камерцыі з адным інжынерам па апрацоўцы дадзеных, двума аналітыкамі і вельмі знаёмай праблемай: фінансавая панэль кіравання пастаянна збочвае кожны раз, калі пастаўшчык плацяжоў змяняе назву поля.

Каманда не хоча, каб штучны інтэлект «валодаў» канвеерам. Гэта было б рызыкоўна. Замест гэтага яны выкарыстоўваюць штучны інтэлект як памочніка ў першым чарнавіку для руціннай, але важнай працы: напісанне шкілетаў мадэляў DBT, прапанова тэстаў, складанне дакументацыі і стварэнне кантрольнага спісу для праверкі кода.

Чалавек-інжынер па апрацоўцы дадзеных усё яшчэ адказвае за канчатковы дызайн, вызначэнні дадзеных, правілы доступу і разгортванне ў прадукцыйнай вытворчасці. Штучны інтэлект проста паскарае складаны прамежкавы этап.

Што патрабуецца для працоўнага працэсу

Перад выкарыстаннем штучнага інтэлекту каманда дае яму дастаткова кантэксту, каб ён быў карысным:

• Існуючая схема табліцы плацяжоў

• Вызначэнні мэтавых фінансавых паказчыкаў, такіх як «чысты даход», «сума вяртання сродкаў» і «ажыццёўлены плацёж»

• Правілы наймення для мадэляў DBT

• Прыклады зацверджаных тэстаў

• Кароткі кантракт на перадачу дадзеных для плацежнай стужкі

• Правілы апрацоўкі персанальнай інфармацыі, няўдалых плацяжоў, дублікатаў і запісаў, якія паступілі з затрымкай

• Прыклад мінулых інцыдэнтаў, у тым ліку што пайшло не так і як гэта было выпраўлена

Галоўнае не ў тым, каб «папрасіць штучны інтэлект пабудаваць канвеер». Гэта занадта расплывіста.

Больш моцны падыход: «Вось нашы правілы, вось схема, вось чаканая паводзіны. Напішыце нешта, што мы можам перагледзець»

Прыклад інструкцыі

Вы дапамагаеце распрацоўваць мадэль DBT для нашых плацежных дадзеных. Выкарыстоўвайце схему і правілы ніжэй, каб стварыць мадэль першага праходу, прапанаваныя DBT-тэсты і дакументацыю.

Мадэль павінна разлічваць штодзённы разліковы даход па order_id і payment_provider. Выключаць няўдалыя плацяжы, выключаць тэставыя транзакцыі і адымаць вяртанні сродкаў толькі тады, калі refund_status = «confirmed».

Не выдумляйце слупкі. Калі патрэбнага слупка няма, укажыце яго ў раздзеле «Пытанні для праверкі чалавекам», а не здагадвайцеся.

Таксама прапануйце тэсты на ўнікальнасць, нулявыя значэнні, прынятыя значэнні і разумнасць даходу. Пазначце любую логіку, якая можа паўплываць на фінансавую справаздачнасць.

Як гэта праверыць

Разумны тэст невялікі і наўмысна звычайны:

• Дайце штучнаму інтэлекту адну заведама добрую схему аплаты і праверце, ці пазбягае ён вынаходніцтва палёў.

• Дайце яму адну схему з адсутным слупком refund_status і паглядзіце, ці задасць ён пытанне, а не здагадку.

• Выканайце згенераваны SQL-запыт для прамежкавага набору даных, а не для прадукцыйнага.

• Параўнайце вынік з 20 запісамі плацяжоў, праверанымі ўручную.

• Папрасіце аналітыка і інжынера па апрацоўцы дадзеных праглядзець азначэнні перад аб'яднаннем.

• Дадайце прынятыя тэсты ў CI, каб канвеер працягваў правяраць сябе пасля разгортвання.

Важна праверыць штучны інтэлект на тых тыпах памылак, якія вас найбольш палохаюць: выдуманыя слупкі, няправільная логіка даходу, адсутнасць апрацоўкі вяртання сродкаў і маўклівыя дублікаты радкоў.

Вынік

Ілюстрацыйны вынік: заснаваны на хронаметры трох прыкладаў задач па змяненні канвеера да і пасля выкарыстання гэтага працоўнага працэсу.

Перад выкарыстаннем штучнага інтэлекту інжынер траціў каля 5 гадзін 30 хвілін на кожнае змяненне: прыкладна 2 гадзіны на напісанне SQL, 1 гадзіну на стварэнне тэстаў, 45 хвілін на напісанне дакументацыі, а астатняе — на праверку памежных выпадкаў з фінансавым аддзелам.

Калі штучны інтэлект выкарыстоўваўся толькі для першых чарнавікоў, аналагічны тып змяненняў заняў каля 2 гадзін 10 хвілін. Найбольшая эканомія была атрымана за кошт тэставых скафаў і чарнавікоў дакументацыі, якія скараціліся з 1 гадзіны 45 хвілін да прыкладна 25 хвілін.

Этап праверкі чалавекам усё яшчэ займаў каля 45 хвілін, і яго не варта выдаляць.

У тэсце з трох задач штучны інтэлект прапанаваў 18 праверак. Інжынер прыняў 11, адрэдагаваў 5 і адхіліў 2, таму што яны выказалі здагадку, што бізнес-правілы не адпавядаюць рэчаіснасці. Гэтая колькасць адхіленняў мае значэнне: яна даказвае, што працоўны працэс патрабуе перагляду, а не сляпога даверу.

Што можа пайсці не так

Штучны інтэлект можа зрабіць канвеер больш завершаным, чым ён ёсць на самой справе.

Сярод распаўсюджаных пунктаў паломкі:

• Вынаходніцтва калонак, якія гучаць праўдападобна

• Разгляд вяртання сродкаў, вяртання плацяжоў і няўдалых плацяжоў як адно і тое ж

• Праблемы з адсутнасцю гадзінных паясоў у штодзённым даходзе

• Прапанова агульных тэстаў, якія не выяўляюць фінансавых памылак

• Напісанне дакументацыі, якая гучыць упэўнена, але хавае няўпэўненасць

• Забыццё пра правілы прыватнасці, калі ўзоры дадзеных утрымліваюць звесткі пра кліента

Добрае правіла: штучны інтэлект можа распрацаваць чарнавік мадэлі, але чалавек павінен падпісаць азначэнні, грашовую логіку, кантроль доступу і выпуск у прадукцыю.

Практычны вывад

Каштоўная версія штучнага інтэлекту ў інжынерыі дадзеных — гэта не «замена інжынера дадзеных». Гэта «выдаліць пустую старонку, а потым старанна прагледзець».

Гэта азначае хутчэйшы SQL, хутчэйшыя тэсты і лепшую дакументацыю першага праходу, у той час як інжынер усё яшчэ валодае самай важнай часткай: ці з'яўляюцца дадзеныя правільнымі, надзейнымі, бяспечнымі і растлумачальнымі.

Часта задаваныя пытанні

Ці заменіць штучны інтэлект цалкам інжынераў апрацоўкі дадзеных?

У большасці арганізацый штучны інтэлект, хутчэй за ўсё, возьме на сябе пэўныя задачы, чым цалкам знішчыць гэтую ролю. Ён можа паскорыць распрацоўку SQL-запытаў, стварэнне канвеераў, першыя праходы дакументацыі і стварэнне базавых тэстаў. Але інжынерыя дадзеных таксама нясе адказнасць і адказнасць, а таксама непрывабную працу па прымушэнні бязладнай бізнес-рэальнасці паводзіць сябе як надзейная сістэма. Гэтыя часткі ўсё яшчэ патрабуюць ад людзей, каб вырашаць, што такое «правільнае», і браць на сябе адказнасць, калі нешта ламаецца.

Якія часткі інжынерыі дадзеных ужо аўтаматызуе штучны інтэлект?

Штучны інтэлект найлепш спраўляецца з паўтаральнай працай: чарчэннем і рэфактарынгам SQL, генерацыяй шкілетаў мадэляў DBT, тлумачэннем распаўсюджаных памылак і стварэннем планаў дакументацыі. Ён таксама можа ствараць тэсты, такія як праверкі на null або унікальнасць, і генераваць шаблонны «злучальны» код для інструментаў аркестрацыі. Перавага — гэта імпульс — вы пачынаеце бліжэй да працоўнага рашэння, але вам усё роўна трэба праверыць правільнасць і пераканацца, што яно адпавядае вашаму асяроддзю.

Калі штучны інтэлект можа пісаць SQL і канвееры, што застаецца інжынерам дадзеных?

Шмат чаго: вызначэнне кантрактаў дадзеных, апрацоўка дрэйфу схемы і забеспячэнне ідэмпатэнтнасці, назіральнасці і магчымасці аднаўлення канвеераў. Інжынеры дадзеных трацяць час на вывучэнне змяненняў метрык, стварэнне ахоўных парогаў для наступных карыстальнікаў і кіраванне кампрамісамі паміж коштам і надзейнасцю. Задача часта зводзіцца да стварэння даверу і падтрымання «цішыні» платформы дадзеных, гэта значыць дастатковай стабільнасці, каб нікому не даводзілася думаць пра яе штодня.

Як штучны інтэлект змяняе паўсядзённую працу інжынера дадзеных?

Звычайна гэта скарачае час на шаблонныя шаблоны і «пошук», таму вы марнуеце менш часу на ўвод тэксту і больш часу на праверку, праверку і праектаванне. Гэты зрух перамяшчае ролю ў бок вызначэння чаканняў, стандартаў якасці і шаблонаў паўторнага выкарыстання, а не на ручное кадаванне ўсяго. На практыцы вы, хутчэй за ўсё, будзеце больш працаваць у партнёрстве з прадуктам, бяспекай і фінансамі, таму што тэхнічны вынік становіцца лягчэй ствараць, але цяжэй кіраваць.

Чаму штучны інтэлект мае праблемы з неадназначнымі бізнес-вызначэннямі, такімі як «актыўны карыстальнік»?

Паколькі бізнес-логіка не з'яўляецца статычнай або дакладнай — яна змяняецца ў сярэдзіне праекта і залежыць ад зацікаўленых бакоў. Штучны інтэлект можа скласці інтэрпрэтацыю, але не можа адказваць за рашэнне, калі азначэнні змяняюцца або ўзнікаюць канфлікты. Інжынерыя дадзеных часта патрабуе перамоваў, дакументавання здагадак і ператварэння невыразных патрабаванняў у трывалыя кантракты. Гэтая праца па «ўзгадненні з чалавекам» з'яўляецца асноўнай прычынай таго, што гэтая роля не знікае, нават калі інструменты ўдасканальваюцца.

Ці можа штучны інтэлект бяспечна кіраваць дадзенымі, забяспечваць канфідэнцыяльнасць і выконваць патрабаванні?

Штучны інтэлект можа дапамагаць у распрацоўцы палітыкі або прапаноўваць падыходы, але бяспечная рэалізацыя ўсё яшчэ патрабуе сапраўднай інжынерыі і ўважлівага кантролю. Кіраванне ўключае ў сябе кантроль доступу, апрацоўку персанальнай інфармацыі, правілы захоўвання, журналы аўдыту і часам абмежаванні месца жыхарства. Гэта сферы высокай рызыкі, дзе «амаль правільна» непрымальна. Людзі павінны распрацоўваць правілы, правяраць іх выкананне і несці адказнасць за вынікі выканання.

Якія навыкі застаюцца каштоўнымі для інжынераў дадзеных па меры ўдасканалення штучнага інтэлекту?

Навыкі, якія робяць сістэмы ўстойлівымі: сістэмнае праектаванне, інжынерыя якасці дадзеных і стандартызацыя, арыентаваная на платформу. Кантракты, назіральнасць, звычкі рэагавання на інцыдэнты і дысцыплінаваны аналіз першапрычын становяцца яшчэ больш важнымі, калі больш людзей могуць хутка ствараць артэфакты дадзеных. Камунікацыя таксама становіцца адметнай рысай — узгадненне азначэнняў, напісанне зразумелай дакументацыі і тлумачэнне кампрамісаў без драматызму з'яўляюцца важнай часткай захавання даверу да дадзеных.

Якія пасады ў галіне інжынерыі дадзеных найбольш схільныя да рызыкі з-за штучнага інтэлекту і кіраваных інструментаў?

Ролі, вузка сканцэнтраваныя на паўтаральным прыёме дадзеных або стандартных канвеерах справаздачнасці, больш падвяргаюцца ўздзеянню, асабліва калі кіраваныя канектары ELT ахопліваюць большасць крыніц. Праца з нізкім узроўнем уласнасці, заснаваная на заяўках, можа скарачацца, таму што штучны інтэлект і абстракцыя зніжаюць намаганні на кожны канвеер. Але звычайна гэта выглядае як меншая колькасць людзей, якія выконваюць паўтаральныя задачы, а не «адсутнасць інжынераў дадзеных». Ролі з высокім узроўнем уласнасці, сканцэнтраваныя на надзейнасці, якасці і даверы, застаюцца трывалымі.

Як мне выкарыстоўваць такія інструменты, як GitHub Copilot або dbt з штучным інтэлектам, не ствараючы хаосу?

Разглядайце вынікі штучнага інтэлекту як чарнавік, а не як рашэнне. Выкарыстоўвайце яго для стварэння шаблонаў запытаў, паляпшэння чытальнасці або стварэння DBT-тэстаў і дакументацыі, а затым праверце на рэальных дадзеных і памежных выпадках. Спалучайце яго з строгімі пагадненнямі: кантрактамі, стандартамі наймення, праверкамі назіральнасці і практыкамі агляду. Мэта — хутчэйшая дастаўка без шкоды для надзейнасці, кантролю выдаткаў або кіравання.

Спасылкі

1. Еўрапейская камісія - Тлумачэнне абароны дадзеных: прынцыпы GDPR - commission.europa.eu

2. Офіс інфармацыйнага камісара (ICO) - Абмежаванне захоўвання - ico.org.uk

3. Еўрапейская камісія - Як доўга можна захоўваць дадзеныя і ці неабходна іх абнаўляць? - commission.europa.eu

4. Нацыянальны інстытут стандартаў і тэхналогій (NIST) - Структура прыватнасці - nist.gov

5. Цэнтр рэсурсаў камп'ютэрнай бяспекі NIST (CSRC) - SP 800-92: Кіраўніцтва па кіраванні журналамі камп'ютэрнай бяспекі - csrc.nist.gov

6. Цэнтр бяспекі Інтэрнэту (CIS) - Кіраванне журналамі аўдыту (сродкі кіравання CIS) - cisecurity.org

7. Дакументацыя Snowflake - Палітыка доступу да радкоў - docs.snowflake.com

8. Дакументацыя Google Cloud - Бяспека BigQuery на ўзроўні радкоў - docs.cloud.google.com

9. BITOL - Стандарт кантрактаў па адкрытых дадзеных (ODCS) версіі 3.1.0 - bitol-io.github.io

10. BITOL (GitHub) - Стандарт кантракту на адкрытыя даныя - github.com

11. Apache Airflow - Дакументацыя (стабільная версія) - airflow.apache.org

12. Apache Airflow - DAG (асноўныя канцэпцыі) - airflow.apache.org

13. Дакументацыя dbt Labs - Што такое dbt? - docs.getdbt.com

14. Дакументацыя dbt Labs - Пра мадэлі dbt - docs.getdbt.com

15. Дакументацыя dbt Labs - Дакументацыя - docs.getdbt.com

16. Дакументацыя dbt Labs - Тэсты дадзеных - docs.getdbt.com

17. Дакументацыя dbt Labs - Семантычны ўзровень dbt - docs.getdbt.com

18. Дакументацыя Fivetran - Пачатак працы - fivetran.com

19. Fivetran - Раздымы - fivetran.com

20. Дакументацыя AWS - Кіраўніцтва распрацоўшчыка AWS Lambda - docs.aws.amazon.com

21. GitHub - GitHub Copilot - github.com

22. Дакументацыя GitHub - Атрыманне прапаноў кода ў вашым IDE з дапамогай GitHub Copilot - docs.github.com

23. Microsoft Learn - GitHub Copilot для SQL (пашырэнне VS Code) - learn.microsoft.com

24. Дакументацыя Dynatrace - Назіральнасць дадзеных - docs.dynatrace.com

25. DataGalaxy - Што такое назіральнасць дадзеных? - datagalaxy.com

26. Дакументацыя па праграме "Вялікія чаканні" - Агляд праграм "Чаканні" - docs.greatexpectations.io

Знайдзіце найноўшы штучны інтэлект у афіцыйнай краме памочнікаў штучнага інтэлекту

Пра нас