Ще замени ли изкуственият интелект инженерите по данни?

Ще замени ли изкуственият интелект инженерите по данни?

Кратък отговор: Изкуственият интелект няма да замени изцяло инженерите по данни; той ще автоматизира повтаряща се работа, като например SQL чертки, изграждане на скелета на конвейери, тестове и документация. Ако вашата роля е предимно работа с ниска степен на собственост и въз основа на заявки, тя е по-изложена; ако отговаряте за надеждността, дефинициите, управлението и реакцията при инциденти, изкуственият интелект основно ви прави по-бързи.

Ключови изводи:

Отговорност : Приоритизирайте отговорността за резултатите, а не само за бързото създаване на код.

Качество : Изграждайте тестове, наблюдаемост и договори, така че тръбопроводите да останат надеждни.

Управление : Поддържайте поверителността, контрола на достъпа, съхранението и одитните следи собственост на хора.

Устойчивост на злоупотреба : Третирайте резултатите от ИИ като чернови; преглеждайте ги, за да избегнете уверени грешки.

Смяна на ролите : Прекарвайте по-малко време в писане на шаблони и повече време в проектиране на издръжливи системи.

Ще замени ли изкуственият интелект инженерите по данни? Инфографика

Ако сте прекарали повече от пет минути около екипи за данни, сигурно сте чували рефрена - понякога прошепнат, понякога изричан по време на среща като обрат в сюжета: Ще замени ли изкуственият интелект инженерите по данни?

И… разбирам. Изкуственият интелект може да генерира SQL, да изгражда конвейери, да обяснява стекови трасирания, да изготвя DBT модели, дори да предлага складови схеми с обезпокоителна увереност. GitHub Copilot за SQL Относно DBT моделите GitHub Copilot
Усещането е като да гледаш как мотокар се учи да жонглира. Впечатляващо, леко тревожно, и не си напълно сигурен какво означава това за работата ти 😅

Но истината е по-малко подредена от заглавието. Изкуственият интелект напълно променя инженерството на данни. Автоматизира скучните, повтарящи се части. Ускорява моментите „Знам какво искам, но не мога да си спомня синтаксиса“. Също така поражда съвсем нови видове хаос.

Така че нека го подредим както трябва, без оптимизъм, движещ се с ръце, или паника от предсказания на съдбата.

Статии, които може да ви харесат след тази:

🔗 Ще замести ли изкуственият интелект рентгенолозите?
Как изкуственият интелект за обработка на изображения променя работния процес, точността и бъдещите роли.

🔗 Ще замести ли изкуственият интелект счетоводителите?
Вижте кои счетоводни задачи се автоматизират от изкуствения интелект и кои остават човешки.

🔗 Ще замени ли изкуственият интелект инвестиционните банкери?
Разберете влиянието на изкуствения интелект върху сделките, проучванията и взаимоотношенията с клиентите.

🔗 Ще замести ли изкуственият интелект застрахователните агенти?
Научете как изкуственият интелект трансформира застрахователното стратегическо развитие, продажбите и обслужването на клиенти.

Защо въпросът „ИИ замества инженерите по данни“ продължава да се появява отново и отново 😬

Страхът идва от много специфично място: инженерството на данни изисква много повтаряща се работа .

  • Писане и рефакторинг на SQL

  • Изграждане на скриптове за приемане

  • Съпоставяне на полета от една схема към друга

  • Създаване на тестове и основна документация

  • Отстраняване на грешки в конвейера, които са... някак предвидими

Изкуственият интелект е необичайно добър в повтарящите се модели. И част от инженерството на данни е точно това - модели, подредени върху модели. Предложения за код на GitHub Copilot

Също така, екосистемата от инструменти вече „крие“ сложността си:

Така че, когато се появи изкуствен интелект, може да се почувства като последното парче. Ако стекът вече е абстрахиран и изкуственият интелект може да напише свързващия код... какво остава? 🤷

Но ето нещо, което хората пропускат: инженерството на данни не е основно писане . Писането е лесната част. Трудната част е да накараме мътната, политическа, променяща се бизнес реалност да се държи като надеждна система.

И изкуственият интелект все още се бори с тази мъгла. Хората също се борят - просто импровизират по-добре.

Какво всъщност правят инженерите по данни по цял ден (небляскавата истина) 🧱

Нека бъдем откровени - длъжността „Инженер по данни“ звучи сякаш строите ракетни двигатели от чиста математика. На практика вие изграждате доверие .

Типичният ден е по-малко „изобретяване на нови алгоритми“ и повече:

  • Преговори с екипите по нагоре по веригата относно дефинициите на данни (болезнено, но необходимо)

  • Проучване защо дадена метрика се е променила (и дали това е реално)

  • Обработка на дрейф на схемата и изненади от типа „някой добави колона в полунощ“

  • Осигуряване на идемпотентност, възстановимост и наблюдаемост на тръбопроводите

  • Създаване на предпазни мерки, така че анализаторите надолу по веригата да не създават случайно безсмислени табла за управление

  • Управление на разходите, така че складът ви да не се превърне в паричен огън 🔥

  • Осигуряване на достъп, одит, съответствие, политики за съхранение Принципи на GDPR (Европейска комисия) Ограничение на съхранението (ICO)

  • Създаване на продукти с данни, които хората могат реално да използват, без да ви пишат в директни съобщения. 20 въпроса

Голяма част от работата е социална и оперативна:

  • „Чий е собственикът на тази маса?“

  • „Валидно ли е все още това определение?“

  • „Защо CRM експортира дубликати?“

  • „Можем ли да изпратим този показател на ръководителите без да се срамуваме?“ 😭

Изкуственият интелект може да помогне с части от това, разбира се. Но пълното му заместване е... прекалено.

Какво прави една роля в областта на инженерството на данни силна? ✅

Този раздел е важен, защото разговорите за заместване обикновено предполагат, че инженерите по данни са предимно „строители на тръбопроводи“. Това е все едно да предположим, че готвачите основно „режат зеленчуци“. Това е част от работата, но не е самата работа.

Силната версия на инженер по данни обикновено означава, че той може да прави повечето от следните неща:

  • Проектиране за промяна
    Данните се променят. Екипите се променят. Инструментите се променят. Добрият инженер изгражда системи, които не се сриват всеки път, когато реалността кихне 🤧

  • Дефиниране на договори и очаквания
    Какво означава „клиент“? Какво означава „активен“? Какво се случва, когато даден ред пристигне със закъснение? Договорите предотвратяват хаоса повече от сложния код. Стандарт за договори за отворени данни (ODCS) ODCS (GitHub)

  • Вградете наблюдаемост във всичко.
    Не само „работи ли“, а „работи ли правилно“. Актуалност, аномалии в обема, нулеви експлозии, промени в разпределението. Наблюдаемост на данните (Dynatrace). Какво е наблюдаемост на данните?

  • Правете компромиси като възрастен:
    Скорост срещу коректност, цена срещу латентност, гъвкавост срещу простота. Няма перфектен процес на разработка, има само процеси, с които можете да живеете.

  • Превърнете бизнес нуждите в устойчиви системи.
    Хората искат показатели, но това, от което се нуждаят, е продукт с данни. Изкуственият интелект може да пише код, но не може магически да разпознае бизнес мини.

  • Пазете данните в тайна
    Най-големият комплимент за една платформа за данни е, че никой не говори за нея. Нестандартните данни са добри данни. Като водопроводната инсталация. Забелязвате ги само когато се повреди 🚽

Ако правите тези неща, въпросът „Ще замести ли изкуственият интелект инженерите по данни?“ започва да звучи... малко странно. Изкуственият интелект може да замести задачите , а не отговорността .

Където изкуственият интелект вече помага на инженерите по данни (и това е наистина страхотно) 🤖✨

Изкуственият интелект не е просто маркетинг. Използван правилно, той е легитимен умножител на силата.

1) По-бърза работа със SQL и трансформации

  • Изчертаване на сложни съединения

  • Писане на прозоречни функции, за които предпочитате да не мислите

  • Превръщане на логиката на обикновен език в скелети на заявки

  • Рефакториране на грозни заявки в четливи CTEs GitHub Copilot за SQL

Това е от огромно значение, защото намалява ефекта на „празна страница“. Все още е необходимо да се валидира, но започвате от 70% вместо от 0%.

2) Отстраняване на грешки и навигационни трохи за отстраняване на първопричини

Изкуственият интелект е добър в:

  • Обяснение на съобщенията за грешки

  • Предложение къде да се търси

  • Препоръчвам стъпки от типа „проверка на несъответствието на схемата“ в GitHub Copilot.
    Все едно имаш неуморен младши инженер, който никога не спи и понякога уверено лъже 😅

3) Обогатяване на документация и каталог с данни

Автоматично генерирано:

  • Описания на колоните

  • Резюмета на модели

  • Обяснения за родословието

  • „За какво се използва тази таблица?“ изготвя документация за DBT

Не е перфектно, но разбива проклятието на недокументираните тръбопроводи.

4) Тестване на скелето и проверки

Изкуственият интелект може да предложи:

Отново - вие все още решавате кое е важно, но това ускорява рутинните части.

5) Код за „лепило“ на тръбопровода

Шаблони за конфигурация, YAML скелета, оркестрационни DAG чернови. Тези неща са повтарящи се, а изкуственият интелект ги изяжда за закуска 🥣 Apache Airflow DAG-ове

Където ИИ все още се затруднява (и това е същността му) 🧠🧩

Това е най-важната част, защото отговаря на въпроса за подмяната с истинска текстура.

1) Неяснота и променящи се дефиниции

Бизнес логиката рядко е ясна. Хората си променят мнението по средата на изречението. „Активен потребител“ става „активен плащащ потребител“, става „активен плащащ потребител, без да се възстановяват суми, освен понякога“... знаете как е.

Изкуственият интелект не може да приеме тази неяснота. Той може само да гадае.

2) Отговорност и риск

Когато даден конвейер се повреди и таблото за управление на изпълнителните директории показва глупости, някой трябва:

  • триаж

  • комуникиране на въздействието

  • поправи го

  • предотвратяване на рецидив

  • напишете аутопсията

  • да реши дали бизнесът все още може да се довери на данните от миналата седмица

Изкуственият интелект може да помага, но не може да бъде отчетен по смислен начин. Организациите не функционират на базата на вибрации - те функционират на базата на отговорност.

3) Системно мислене

Платформите за данни са екосистеми: прием, съхранение, трансформации, оркестрация, управление, контрол на разходите, SLA. Промяна в един слой е вълничка. Концепции на Apache Airflow.

Изкуственият интелект може да предлага локални оптимизации, които създават глобална болка. Все едно да поправиш скърцаща врата, като я махнеш 😬

4) Сигурност, поверителност, съответствие

Тук умират фантазиите за заместване.

Изкуственият интелект може да изготвя политики, но безопасното им прилагане е истинско инженерство.

5) „Неизвестните неизвестни“

Инцидентите с данни често са непредсказуеми:

  • API на доставчик тихомълком променя семантиката

  • Предположението за часова зона се променя

  • Запълването дублира дял

  • Механизмът за повторен опит причинява двойни записи

  • Нова продуктова функция въвежда нови модели на събития

Изкуственият интелект е по-слаб, когато ситуацията не е познат модел.

Сравнителна таблица: какво намалява какво на практика 🧾🤔

По-долу е даден практичен поглед. Не „инструменти, които заместват хората“, а инструменти и подходи, които намаляват определени задачи.

Инструмент / подход Аудитория Ценова атмосфера Защо работи
Копилоти за AI код (SQL + Python помощници) GitHub Copilot Инженери, които пишат много код От безплатно до платено Страхотен в скелето, рефакторирането, синтаксиса… понякога самодоволен по много специфичен начин
Управлявани ELT конектори Fivetran Екипите са уморени от изграждането на прием Абонамент-y Премахва неудобството при персонализирано поглъщане, но прекъсва по забавни нови начини
Платформи за наблюдение на данни Наблюдаемост на данни (Dynatrace) Всеки, който притежава SLA Средно до корпоративно ниво Открива аномалии рано - като димни аларми за тръбопроводи 🔔
Трансформационни рамки (декларативно моделиране) dbt Хибриди за анализ + DE Обикновено инструмент + изчисление Прави логиката модулна и тестваема, по-малко „спагети“
Каталози с данни + семантични слоеве dbt Семантичен слой Организации с объркване с показателите Зависи, на практика Дефинира „истина“ веднъж - намалява безкрайните дебати за показателите
Оркестрация с шаблони Apache Airflow Екипи, ориентирани към платформата Разходи за отваряне + операции Стандартизира работните процеси; по-малко DAG-ове тип „снежинка“
Генериране на DBT документи с помощта на изкуствен интелект Екипи, които мразят да пишат документи Евтино до умерено Създава „достатъчно добри“ документи, така че знанията да не изчезнат
Политики за автоматизирано управление NIST Privacy Framework Регулирана среда Enterprise-y Помага за прилагането на правилата - но все пак се нуждае от хора, които да ги проектират

Обърнете внимание какво липсва: ред, който гласи „натиснете бутон, за да премахнете инженерите по данни“. Да… този ред не съществува 🙃

И така... ще замени ли ИИ инженерите по данни или просто ще промени ролята им? 🛠️

Ето недраматичния отговор: Изкуственият интелект ще замени части от работния процес, а не професията.

Но това ще преконфигурира ролята. И ако игнорирате това, ще усетите напрежението.

Какво се променя:

  • По-малко време за писане на шаблонни текстове

  • По-малко време за търсене на документи

  • Повече време за преглед, валидиране, проектиране

  • Повече време за дефиниране на договори и очаквания за качество Стандарт за договори с отворени данни (ODCS)

  • Повече време за партньорство с продукти, сигурност, финанси

Това е фината промяна: инженерството на данни става по-малко свързано с „изграждане на тръбопроводи“ и повече с „изграждане на надеждна система от продукти от данни“

И в един тих обрат, това е по-ценно, не по-малко.

Също така - и ще го кажа, дори и да звучи драматично - изкуственият интелект увеличава броя на хората, които могат да създават артефакти от данни , което увеличава нуждата от някой, който да поддържа цялото нещо здраво. Повече продукция означава повече потенциално объркване. GitHub Copilot

Все едно да дадеш на всички електрическа бормашина. Чудесно! Сега някой трябва да наложи правилото „моля, не пробивайте във водопроводната тръба“ 🪠

Новият набор от умения, който остава ценен (дори с изкуствен интелект навсякъде) 🧠⚙️

Ако искате практичен „готов за бъдещето“ контролен списък, той изглежда така:

Начин на мислене за системен дизайн

  • Моделиране на данни, което оцелява при промяна

  • Компромиси между пакетно и стрийминг

  • Мислене за латентност, цена, надеждност

Инженеринг на качеството на данните

Архитектура на управление и доверие

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

  • Шаблони за многократна употреба, златни пътеки

  • Стандартизирани модели за приемане, трансформации, тестване на Fivetran dbt тестове на данни

  • Инструменти за самообслужване, които не се разпадат

Комуникация (да, наистина)

  • Писане на ясни документи

  • Подравняване на дефинициите

  • Казване на „не“ учтиво, но твърдо

  • Обясняване на компромиси, без да звуча като робот 🤖

Ако можете да направите това, въпросът „Ще замести ли ИИ инженерите по данни?“ става по-малко заплашителен. ИИ се превръща във вашия екзоскелет, а не във ваш заместник.

Реалистични сценарии, при които някои роли в инженерството на данни се свиват 📉

Добре, бърза проверка на реалността, защото не е само слънце и конфети от емоджита 🎉

Някои роли са по-изложени на показ:

  • Чисто роли само за прием, където всичко е стандартно. Конектори : Fivetran конектори

  • Екипи, работещи предимно с повтарящи се отчетни процеси с минимални нюанси в домейна

  • Организации, където инженерството на данни се третира като „SQL маймуни“ (сурово, но вярно)

  • Роли с ниско ниво на собственост, където работата е само с тикети и копиране/поставяне

Изкуственият интелект плюс управляваните инструменти могат да намалят тези нужди.

Но дори и там, подмяната обикновено изглежда така:

  • По-малко хора, които извършват една и съща повтаряща се работа

  • По-голям акцент върху собствеността на платформата и надеждността ѝ

  • Преход към „един човек може да поддържа повече тръбопроводи“

Така че да - моделите на численост на персонала могат да се променят. Ролите еволюират. Длъжностите се изместват. Тази част е реална.

Въпреки това, версията на ролята, изискваща висока степен на собственост и високо доверие, се запазва.

Заключително резюме 🧾✅

Ще замести ли изкуственият интелект инженерите по данни? Не по чистия, тотален начин, по който хората си го представят.

Изкуственият интелект ще:

  • автоматизиране на повтарящи се задачи

  • ускоряване на кодирането, отстраняването на грешки и документирането GitHub Copilot за SQL dbt документация

  • намаляване на разходите за производство на тръбопроводи

Но инженерството на данни е основно свързано със:

Изкуственият интелект може да помогне с това... но не го „притежава“.

Ако сте инженер по данни, промяната е проста (не лесна, но проста):
насочете се към отговорност, качество, платформено мислене и комуникация. Оставете изкуствения интелект да се справи с шаблона, докато вие се занимавате с важните части.

И да - понякога това означава да си възрастният в стаята. Не е бляскав. Въпреки това е тихо и мощен 😄

Ще замени ли изкуственият интелект инженерите по данни?
Той ще замени някои задачи, ще пренареди стълбицата и ще направи най-добрите инженери по данни още по-ценни. Това е истинската история.

ЧЗВ

Ще замени ли изкуственият интелект напълно инженерите по данни?

В повечето организации е по-вероятно изкуственият интелект да поеме конкретни задачи, отколкото да заличи ролята им напълно. Той може да ускори изготвянето на 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) v3.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

Намерете най-новия изкуствен интелект в официалния магазин за асистенти с изкуствен интелект

За нас

Обратно към блога