[Перевод] AI и Data engineering: Что реально происходит с профессией?

Сразу успокоим читателя: AI не вытеснил data-инженера из рабочего процесса. Наоборот, он сделал эту роль еще более значимой. И в этой статье объясняется, что именно это означает для вас и вашей профессии. Не с точки зрения технологий и инструментов, а с точки зрения изменения зоны ответственности.

Каждый год роль data-инженера (или любого другого ИТ-специалиста) объявляется ненужной. Считалось, что или управляемые сервисы (managed Hadoop например) снимут операционные сложности, или облачные хранилища избавят от забот об инфраструктуре, или ETL-инструменты кратно упростят создание пайплайнов. И теперь ожидается, что AI-копилоты завершат начатое и попросту сделают профессию ненужной.

Но не смотрят на смену инструментов и платформ, те базовые ограничения как были, так и остались. А именно: данным по-прежнему нужна инфраструктура, нужна валидация, данные должны быть доступны, должна быть поддержка множества пользователей и тому подобное. Хайп быстро проходит, а этот фундамент остается.

AI, как и везде, конечно классно справляется с некоторыми задачами, но всю ответственность по-прежнему несет человек. Весь контекст не передашь через промпт, и AI не делает компромиссных решений. Большинство систем не выходят из строя, потому что было сложно написать код. Выходят, потому что решения по разработке были приняты поспешно, и без четкого понимания, кто и как этими системами будет пользоваться. И AI еще быстрее за нас принимает решения, но все те же риски «непонимания контекста» остаются.

Эти ограничения и проблемы существовали и ранее, до появления современных инструментов. И будут существовать и дальше. AI лишь меняет темп работы, ускоряет ее, но не исправляет эти «узкие» места в разработке.

И вопрос для data -инженеров сегодня заключается не в том, изменит ли ИИ их работу. Потому что он уже это сделал. Главный вопрос – какие аспекты работы сводились не к простому написанию кода?

AI может вам предлагать схему данных, но никогда не скажет, что данные реально означают

В современных платформах задача создания схем (моделей данных) стала достаточно тривиальной. Таблицы генерируются автоматически, состав колонок также автоматически определяются, и даже угадываются связи между таблицами.

Со временем и подходы к моделированию стали менее строгими. Теперь используются снимки данных (snapshots) заместо стандартных SCD, а секционированные таблицы факты и стратегии перезаписи (overwrite) упрощают работу с историческими данными. Эти подходы стали популярными, потому что сложность их реализации меньше, а аналитическая польза та же.

AI также сильно упрощает работу. Рекомендация по схемам генерируется автоматически, различные ошибки или несоответствия паттернам проектирования выявляются тут же. Но само понимание данных от этого не становится лучше. То есть AI не сможет вам выдать ничего разумного, если у него не будет семантического слоя. Нужно знать, как считать те или иные метрики. Человек сам также определяет, какие данные какой гранулярности должны быть. ИИ этого не сможет сделать. Он, конечно, может предлагать варианты, но не способен за вас решить, что конкретно нужно вам. И он не умеет выбирать, когда нужен компромисс. Что важнее: точность или гибкость? Производительность или много данных? На все эти вопросы только вы сможете ответить.

Мы часто забываем, что выбор между методологиями: звезда или снежинка, или data vault – вторичен. Ключевым фактором остаётся цель, ради которой создаётся модель данных.

Настоящий риск для data-инженера – некачественные данные

Современные платформы данных или даже экосистемы данных усугубляют мелкие ошибки. Вы подключаете все больше источников данных, все больше делаете ETL-пайплайнов. И все это время постепенно распространяются по вашей системе проблемы с качеством данных. При этом проблемы с качеством это не явные проблемы, которые сразу все видят. Они накапливаются постепенно, потому что растет взаимозависимость объектов.

ИИ, конечно, может в какой-то степени помочь с этим. Будет автоматически генерировать проверки качества данных. Сможет даже автоматически находить аномалии в данных и подсвечивать их. Однако, он снова не будет понимать смысла ваших данных и всего контекста.

Строки могут быть формально корректными, но при этом абсолютно бесполезными. К примеру, транзакции без метки времени или клиент без региона, или продукт без категории. Формально проверка на дубли или на NULL происходит успешно, но данные в целом бесполезны. И вот именно здесь роль data-инженера становится незаменимой. Качество данных невозможно закладывать во время потребления, а нужно закладывать на этапе проектирования.

Примечание переводчика: в российских компаниях в 90% случаев за качество данных отвечает не data-инженер, а аналитик данных или бизнес/системный аналитик. Никогда не встречал, чтобы data-инженер знал бизнес-контекст и мог предлагать более-менее серьезные проверки качества в рамках бизнес-контекста. С этим к ним приходят аналитики.

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

AI пишет запросы, но не будет поддерживать скорость ваших дашбордов

Дашборды редко сразу работают медленно. Обычно их производительность падает постепенно и незаметно. По мере использования и доработок добавляются новые фильтры, усложняются расчеты, добавляется детализация. Запросы, которые когда-то выполнялись за секунды, теперь выполняются минуты.

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

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

AI не сможет вам помочь с постепенной деградацией, а возможно сделает даже хуже.

AI ускоряет разработку ошибок!

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

То есть, сильно обманчив тот тезис, что работа data-инженера стала простой. Мол, просто указывай ИИ, что разработать и он даст результат. Действительно, разработка стала быстрее, но также увеличилась цена неверных решений. Вы попросту быстрее накапливаете баги, которые потом могут ой как больно выстрелить.

Заменит ли AI data-инженеров?

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

И самое важное – если реально уволить data-инженеров, кто возьмет на себя ответственность? Аналитики, бизнес или кто-то другой? Особенно, когда все сломается при внедрении очередного кода, сгенерированного AI.

Да, ИИ ускоряет работу. И это видоизменяет работу самого data-инженера, а не отменяет его самого. Теперь он стал ближе к бизнес-задачам, должен больше понимать бизнес-контекст. Он принимает компромиссные решения. Нужно теперь не только развивать технические навыки, но и разбираться в процессах компании.

Больше материалов про AI и данные в Телеграм канале.