Заменит ли ИИ инженеров по обработке данных?

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

Основные выводы:

Ответственность: Приоритет отдается ответственности за результаты, а не просто за быстрое написание кода.

Качество: Разрабатывайте тесты, средства мониторинга и контракты, чтобы конвейеры обработки данных оставались надежными.

Управление: Обеспечение конфиденциальности, контроля доступа, хранения данных и журналов аудита должны осуществляться силами человека.

Сопротивление злоупотреблениям: рассматривайте результаты работы ИИ как черновики; проверяйте их, чтобы избежать самоуверенных ошибок.

Смена ролей: тратить меньше времени на набор шаблонного текста и больше времени на проектирование надежных систем.

Если вы провели в окружении команд, работающих с данными, больше пяти минут, вы наверняка слышали этот вопрос — иногда шепотом, иногда внезапно, словно неожиданный поворот сюжета, — иногда он звучит на совещании: Заменит ли ИИ инженеров по данным?

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

Но правда гораздо сложнее, чем кажется на первый взгляд. Искусственный интеллект кардинально меняет подход к обработке данных. Он автоматизирует скучные, повторяющиеся операции. Он ускоряет моменты, когда «я знаю, чего хочу, но не могу вспомнить синтаксис». А ещё он порождает совершенно новые виды хаоса.

Давайте изложим все как следует, без поверхностного оптимизма и паники, вызванной бесконечным пролистыванием ленты новостей.

Статьи, которые могут вас заинтересовать после этой:

🔗 Заменит ли ИИ врачей-радиологов?
Как искусственный интеллект в сфере обработки изображений меняет рабочие процессы, точность и будущие роли.

🔗 Заменит ли ИИ бухгалтеров?
Узнайте, какие бухгалтерские задачи автоматизирует ИИ, а какие остаются ручными.

🔗 Заменит ли искусственный интеллект инвестиционных банкиров?
Разберитесь в влиянии ИИ на сделки, исследования и отношения с клиентами.

🔗 Заменит ли искусственный интеллект страховых агентов?
Узнайте, как искусственный интеллект меняет подходы к андеррайтингу, продажам и поддержке клиентов.

---

Почему вопрос «Искусственный интеллект заменит инженеров данных» постоянно всплывает 😬

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

• Написание и рефакторинг SQL-запросов

• Создание скриптов для загрузки данных

• Сопоставление полей из одной схемы с другой

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

• Отладка сбоев в конвейере обработки данных, которые… в общем-то, предсказуемы

Искусственный интеллект необычайно хорошо справляется с повторяющимися шаблонами. И значительная часть инженерии данных как раз и представляет собой это — наложение шаблонов на шаблоны. Предложения по коду в GitHub Copilot

Кроме того, экосистема инструментов уже «скрывает» сложность:

• по управляемым ELT-коннекторам Документация Fivetran

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

• Обеспечение склада товарами в один клик

• по автоматическому масштабированию и оркестровке Документация

• Декларативные фреймворки преобразования. Что такое DBT?

Поэтому, когда появляется ИИ, это может ощущаться как последний недостающий элемент. Если стек уже абстрагирован, и ИИ может написать связующий код… что же остаётся? 🤷

Но вот что многие упускают из виду: разработка данных — это не в основном набор текста. Набор текста — это легко. Сложность заключается в том, чтобы заставить мутную, политизированную, изменчивую бизнес-реальность работать как надежная система.

И ИИ по-прежнему испытывает трудности с этой неопределенностью. Людям тоже сложно — просто они лучше импровизируют.

---

Чем на самом деле занимаются инженеры по обработке данных весь день (не самая привлекательная правда) 🧱

Давайте будем откровенны — название должности «Инженер данных» звучит так, будто вы строите ракетные двигатели из чистой математики. На практике же вы строите доверие.

Типичный рабочий день состоит не столько из «изобретения новых алгоритмов», сколько из:

• Ведение переговоров с вышестоящими командами по поводу определений данных (болезненно, но необходимо)

• Выяснение причин изменения показателя (и насколько эти изменения реальны)

• Обработка расхождений в схеме и неожиданностей, связанных с добавлением столбца «кто-то добавил его в полночь»

• Обеспечение идемпотентности, восстанавливаемости и наблюдаемости конвейеров обработки данных

• Создание механизмов защиты, чтобы аналитики, работающие с данными на последующих этапах, случайно не создавали бессмысленные панели мониторинга

• Управление затратами, чтобы ваш склад не превратился в настоящий финансовый пожар 🔥

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

• Создание продуктов на основе данных, которыми люди действительно смогут пользоваться, без необходимости задавать вам 20 вопросов в личных сообщениях

Значительная часть работы связана с социальными и оперативными аспектами:

• «Кому принадлежит этот стол?»

• «Сохраняет ли это определение свою актуальность?»

• «Почему CRM-система экспортирует дубликаты?»

• «Сможем ли мы без неловкости отправить этот показатель руководителям?» 😭

Искусственный интеллект, безусловно, может помочь в некоторых аспектах. Но полностью заменить его — это… слишком смелое предположение.

---

Что делает роль инженера данных по-настоящему сильной? ✅

Этот раздел важен, потому что в разговорах о замене обычно предполагается, что инженеры данных в основном занимаются «созданием конвейеров обработки данных». Это все равно что предполагать, что повара в основном «нарезают овощи». Это часть работы, но не вся работа целиком.

Высококвалифицированный инженер по обработке данных обычно умеет делать большинство из следующих вещей:

• Проектирование с учетом изменений
  . Данные меняются. Команды меняются. Инструменты меняются. Хороший инженер создает системы, которые не рушатся каждый раз, когда реальность чихает 🤧

• Определение контрактов и ожиданий.
  Что означает «клиент»? Что означает «активный»? Что происходит, когда строка поступает с опозданием? Контракты предотвращают хаос лучше, чем сложный код. Open Data Contract Standard (ODCS) ODCS (GitHub)

• Внедрите наблюдаемость во все процессы.
  Не просто «выполнилось ли это», а «выполнилось ли это правильно». Свежесть данных, аномалии объема, взрывы нулевых значений, сдвиги распределения. Наблюдаемость данных (Dynatrace). Что такое наблюдаемость данных?

• Принимайте компромиссы как взрослый человек:
  скорость против корректности, стоимость против задержки, гибкость против простоты. Идеального конвейера не существует, есть только те конвейеры, которые вас устраивают.

• Преобразуйте бизнес-потребности в надежные системы.
  Люди запрашивают метрики, но им нужен продукт, основанный на данных. Искусственный интеллект может написать код, но он не может волшебным образом распознать подводные камни бизнеса.

• Держите данные в секрете.
  Высшая похвала для платформы данных — это то, что о ней никто не говорит. Незначительные данные — это хорошие данные. Как сантехника. Вы замечаете их только тогда, когда они выходят из строя 🚽

Если вы занимаетесь подобными вещами, вопрос «Заменит ли ИИ инженеров данных?» начинает звучать… несколько неуместно. ИИ может заменить задачи, а не владение.

---

Искусственный интеллект уже помогает инженерам данных (и это действительно здорово) 🤖✨

Искусственный интеллект — это не просто маркетинг. При правильном использовании он может значительно повысить эффективность.

1) Более быстрая обработка SQL-запросов и преобразований

• Разработка сложных соединений

• Написание оконных функций, о которых лучше не думать

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

• Преобразование некрасивых запросов в читаемые CTE (CTE) GitHub Copilot for SQL

Это очень важно, потому что уменьшает эффект «чистого листа». Проверка по-прежнему необходима, но начинается она с 70%, а не с 0%.

2) Отладка и выявление первопричин проблемы

Искусственный интеллект неплохо справляется со следующими задачами:

• Объяснение сообщений об ошибках

• Подсказка, где искать

• Рекомендация использовать шаги типа «проверка несоответствия схемы» в GitHub Copilot.
  Это как иметь неутомимого младшего инженера, который никогда не спит и иногда уверенно лжет 😅

3) Обогащение документации и каталога данных

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

• Описание столбцов

• Сводные данные по моделям

• объяснения родословной

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

Это не идеальное решение, но оно разрушает проклятие незадокументированных трубопроводов.

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

Искусственный интеллект может предложить:

• Основные нулевые тесты

• Проверки на уникальность

• Идеи референтной целостности

• Утверждения в стиле «Этот показатель никогда не должен снижаться» Тесты данных DBT Большие надежды: Ожидания

Повторюсь, вы по-прежнему сами решаете, что важно, но это ускоряет рутинные этапы.

5) Код «связующего» интерфейса конвейера

Шаблоны конфигурации, YAML-шаблоны, черновики DAG-графов оркестровки. Всё это повторяется, а ИИ обожает повторяющееся 🥣 DAG-графы Apache Airflow

---

Где ИИ всё ещё испытывает трудности (и в этом вся суть) 🧠🧩

Это самая важная часть, потому что она отвечает на вопрос о замене, обеспечивая реальную текстуру.

1) Неоднозначность и изменчивость определений

Логика в бизнесе редко бывает четкой. Люди меняют свое мнение на середине предложения. «Активный пользователь» превращается в «активный платящий пользователь», а затем в «активный платящий пользователь, за исключением случаев возврата средств, кроме редких случаев»… вы понимаете, как это бывает.

Искусственный интеллект не может контролировать эту неопределенность. Он может лишь гадать.

2) Ответственность и риск

Когда конвейер обработки данных ломается, а на панели управления руководителя отображается полная ерунда, кто-то должен:

• сортировка

• сообщить о последствиях

• Исправьте это

• предотвратить рецидив

• написать посмертное заключение

• Решить, может ли компания по-прежнему доверять данным прошлой недели

Искусственный интеллект может помочь, но он не может обеспечить значимую подотчетность. Организации работают не на позитивных эмоциях, а на ответственности.

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

Платформы данных — это экосистемы: сбор, хранение, преобразование, оркестрация, управление, контроль затрат, соглашения об уровне обслуживания (SLA). Изменение на одном уровне вызывает цепную реакцию. Концепции Apache Airflow.

Искусственный интеллект может предлагать локальные оптимизации, которые создают глобальные проблемы. Это как починить скрипучую дверь, просто сняв её 😬

4) Безопасность, конфиденциальность, соответствие требованиям

Здесь умирают все фантазии о замене.

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

• Безопасность на уровне строк: политики доступа к строкам Snowflake, безопасность на уровне строк BigQuery.

• Обработка персональных данных в соответствии с Рамочной программой конфиденциальности NIST

• Правила хранения Ограничения на хранение (ICO) Руководство ЕС по хранению

• Журналы аудита NIST SP 800-92 (управление журналами) CIS Control 8 (управление журналами аудита)

• Ограничения на размещение данных

Искусственный интеллект может разрабатывать стратегии, но их безопасная реализация — это уже настоящая инженерная задача.

5) «Неизвестные неизвестные»

Инциденты, связанные с обработкой данных, часто непредсказуемы:

• API поставщика незаметно изменяет семантику

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

• Обратная загрузка дублирует раздел

• Механизм повторных попыток приводит к двойной записи

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

Искусственный интеллект работает слабее, когда ситуация не представляет собой известную закономерность.

---

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

Ниже представлен практический взгляд. Речь идёт не об «инструментах, заменяющих людей», а об инструментах и ​​подходах, которые упрощают выполнение определённых задач.

Инструмент / подход	Аудитория	Ценовой настрой	Почему это работает
Помощники по разработке кода с использованием ИИ (SQL + Python) GitHub Copilot	Инженеры, которые пишут много кода	От относительно бесплатного до платного	Отлично справляется с созданием каркаса кода, рефакторингом, синтаксисом… иногда бывает самодовольным в очень специфическом смысле
Управляемые ELT-коннекторы Fivetran	Команды устали от создания системы приема данных	Подписка	Избавляет от боли при приеме пищи, но ломается новыми, забавными способами
Платформы для мониторинга данных Наблюдаемость данных (Dynatrace)	Все, кто владеет соглашениями об уровне обслуживания (SLA)	Средний и крупный бизнес	Позволяет выявлять аномалии на ранней стадии — например, срабатывание датчиков дыма на трубопроводах 🔔
Трансформационные модели (декларативное моделирование) dbt	Гибриды аналитики и DE	Обычно инструмент + вычислительные ресурсы	Делает логику модульной и тестируемой, уменьшает количество «спагетти-кода»
Каталоги данных + семантические слои dbt Семантический слой	Организации, испытывающие путаницу с метрической системой	На практике всё зависит от обстоятельств	Дает определение «истины» один раз — сокращает бесконечные дебаты о метрической системе
Оркестрация с использованием шаблонов Apache Airflow	Команды, ориентированные на платформу	Открытие + операционные расходы	Стандартизирует рабочие процессы; уменьшает количество «снежинок» в DAG-графах
документации с помощью ИИ (dbt docs generation)	Команды, которые ненавидят писать документы	Недорого или средней ценовой категории	Создаёт «достаточно хорошие» документы, чтобы знания не исчезли бесследно
Автоматизированные политики управления. Рамочная программа NIST по обеспечению конфиденциальности.	Регулируемые среды	Предприятие-y	Помогает обеспечивать соблюдение правил, но для их разработки по-прежнему необходимы люди

Обратите внимание, чего не хватает: строки с надписью «нажмите кнопку, чтобы удалить инженеров данных». Да… такой строки не существует 🙃

---

Итак… заменит ли ИИ инженеров данных или просто изменит их роль? 🛠️

Вот простой и понятный ответ: ИИ заменит часть рабочего процесса, а не саму профессию.

Но это изменит роль. И если вы это проигнорируете, то почувствуете давление.

Какие изменения произойдут:

• Меньше времени на написание шаблонных фраз

• Меньше времени на поиск документов

• Больше времени на проверку, подтверждение и проектирование

• Больше времени на определение условий контрактов и требований к качеству. Стандарт контрактов открытых данных (ODCS).

• Больше времени на сотрудничество с отделами разработки продуктов, безопасности и финансов

В этом и заключается тонкий сдвиг: разработка данных все меньше сводится к «созданию конвейеров обработки данных» и все больше — к «построению надежной системы обработки данных»

И, как это ни парадоксально, это делает его более ценным, а не менее ценным.

Кроме того — и я скажу это, даже если это прозвучит драматично — ИИ увеличивает количество людей, способных создавать данные, что повышает потребность в ком-то, кто будет поддерживать весь процесс в рабочем состоянии. Больший объем данных означает больше потенциальной путаницы. GitHub Copilot

Это как раздать всем по дрели. Отлично! Теперь кто-то должен следить за соблюдением правила «пожалуйста, не сверлите водопроводную трубу» 🪠

---

Новый набор навыков, который остается ценным (даже при повсеместном использовании ИИ) 🧠⚙️

Если вам нужен практичный контрольный список, учитывающий перспективы на будущее, он выглядит примерно так:

Системный подход к проектированию

• Моделирование данных, устойчивое к изменениям

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

• Задержка, стоимость, надежность — все это имеет значение

инженерия качества данных

• Контракты, проверки, обнаружение аномалий. Стандарт контрактов открытых данных (ODCS). Наблюдаемость данных (Dynatrace).

• Соглашения об уровне обслуживания (SLA), соглашения об уровне обслуживания (SLO), методы реагирования на инциденты

• Анализ первопричин с соблюдением дисциплины (а не с подтекстом)

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

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

• Проверяемость в соответствии со стандартом NIST SP 800-92 (управление журналами)

• Принципы обеспечения конфиденциальности на этапе проектирования (NIST Privacy Framework)

• Управление жизненным циклом данных: рекомендации ЕС по хранению

платформенное мышление

• Многоразовые шаблоны, золотые пути

• Стандартизированные шаблоны для загрузки, преобразования и тестирования Fivetran данных

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

Коммуникация (да, действительно)

• Написание понятных документов

• Согласование определений

• Вежливо, но твердо сказать «нет»

• Объясняю компромиссы, не говоря при этом, что я робот 🤖

Если вы сможете это сделать, вопрос «Заменит ли ИИ инженеров по обработке данных?» станет менее пугающим. ИИ станет вашим экзоскелетом, а не заменой.

---

Реалистичные сценарии, в которых некоторые роли инженера данных сокращаются 📉

Ладно, давайте быстро взглянем правде в глаза, ведь не всё так радужно и наполнено смайликами 🎉

Некоторые должности более открыты для посторонних:

• Роли, предназначенные исключительно для приема данных, где все представляет собой стандартные коннекторы Fivetran.

• Команды, в основном занимающиеся повторяющимися процессами составления отчетов с минимальным вниманием к специфике предметной области

• Организации, где к инженерам данных относятся как к «SQL-обезьянам» (жестко, но правда)

• Должности с низкой степенью ответственности, где работа сводится к обработке заявок и копированию и вставке

Использование искусственного интеллекта в сочетании с управляемыми инструментами может сократить эти потребности.

Но даже в этом случае замена обычно выглядит так:

• Меньше людей выполняют одну и ту же монотонную работу

• Больше внимания уделяется праву собственности на платформу и ее надежности

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

Да, структура численности персонала может меняться. Роли развиваются. Должности меняются. Это правда.

Тем не менее, вариант этой роли, предполагающий высокую степень ответственности и доверия, по-прежнему сохраняется.

---

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

Заменит ли ИИ инженеров по обработке данных? Не в том смысле, в каком это обычно представляют.

Искусственный интеллект будет:

• автоматизация повторяющихся задач

• Ускорение кодирования, отладки и документирования. GitHub Copilot для SQL. Документация dbt.

• снизить стоимость производства трубопроводов

Но в основе инженерии данных лежит следующее:

• подотчетность

• проектирование системы

• Доверие, качество и управление. Стандарт контрактов открытых данных (ODCS). Рамки конфиденциальности NIST.

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

Искусственный интеллект может в этом помочь… но он не «владеет» этой территорией.

Если вы инженер по обработке данных, то переход прост (не то чтобы легок, но прост):
сосредоточьтесь на ответственности, качестве, платформенном мышлении и коммуникации. Пусть ИИ занимается рутинной работой, а вы — важными задачами.

Да, и иногда это означает быть тем самым взрослым человеком в комнате. Не очень привлекательно. Но зато тихо и уверенно 😄

Заменит ли ИИ инженеров по обработке данных?
Он заменит некоторые задачи, изменит структуру профессий и сделает лучших инженеров по обработке данных еще более ценными. Вот в чем реальная проблема.

Пример из реальной жизни: создание рабочего процесса проверки данных с помощью ИИ 🛠️

Сценарий

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

Команда не хочет, чтобы ИИ «владел» конвейером обработки данных. Это было бы рискованно. Вместо этого они используют ИИ в качестве помощника при создании черновых вариантов для рутинной, но важной работы: написании шаблонов моделей 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 — Open Data Contract Standard (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 for SQL (расширение для VS Code) - learn.microsoft.com

24. Документация Dynatrace — Наблюдаемость данных — docs.dynatrace.com

25. DataGalaxy — Что такое наблюдаемость данных? — datagalaxy.com

26. Документация по Great Expectations — Обзор Expectations — docs.greatexpectations.io

Найдите новейшие разработки в области ИИ в официальном магазине ИИ-помощников

О нас