Современный бизнес переживает очередную трансформацию под влиянием информационных технологий. Он движется от стадии слепого принятия концепций больших данных (Big data) и искусственного интеллекта к более осознанной работе с информацией. На этом фоне появляются новые профессии, такие как инженер по обеспечению качества данных — data quality assurance engineer, или просто инженер DQ, как часто указывают в вакансиях. Почему эта профессия на пике востребованности, где она нужна и кому легче освоить её прямо сейчас? На эти и другие вопросы отвечают эксперты российской ИТ-компании «Криптонит»: руководитель департамента тестирования Александр Гречин и ведущий инженер по тестированию качества данных Вероника Казакова.

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

Метаданные, или «данные о данных» — это их происхождение (источник), формат, время создания, правила обработки и контроля качества. Например, к нам загружаются таблицы с данными о компании (ИНН, названием компании, коды ОКВЭД и так далее). Здесь метаданные — это атрибуты таблицы (какие колонки мы загружаем, какой в них тип данных, обязательно ли их заполнение, какие правила мы накладываем на значения. 

Пайплайны (data pipelines): автоматизированные последовательности получения, преобразования и перемещения данных из источников в хранилища. Пайплайны работают как конвейеры, подготавливающие сырые данные для их дальнейшего анализа. 

Data driven — стратегия управления компанией на основе анализа данных.

Дата-контракты (data contracts) —
соглашения между поставщиком и потребителем данных. Это набор метрик и правил о предоставлении данных в определённом формате и с оговорённой частотой обновления. 

CI/CD (Continuous Integration/Continuous Delivery/Deployment) — это набор практик, автоматизирующих сборку, тестирование и доставку кода. Инженер по качеству данных использует их, чтобы автоматически проверять целостность данных и работоспособность пайплайнов. 

LLM (large language model, большая языковая модель) — это тип программы искусственного интеллекта, которая может распознавать и генерировать текст.

В чём отличие новой профессии от классического тестировщика?

Александр: Чтобы понять суть новой специализации, нужно чётко разделить сферы ответственности. Классический тестировщик и инженер качества данных смотрят на продукт под разными углами. Если тестировщик ищет баги в логике приложения, то инженер DQ ищет аномалии в данных, поступающих в это приложение. Я бы обозначил профессию как нечто промежуточное между инженером по функциональному тестированию и дата-аналитиком, который очень хорошо погружен в процессы. 

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

Как инженер DQ понимает, что данные качественные? Какими критериями измеряется качество данных?

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

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

То есть, как и у обычного тестировщика, здесь есть свои средства автоматизации?

Вероника: Для автоматизации проверок мы используем библиотеку Great Expectations. Правила, написанные в ней, запускаются по расписанию в Airflow, а результаты мониторинга выгружаются в дашборды. Мы планируем внедрение каталога OpenMetadata, который будет хранить метаданные, отчёты о качестве данных.

Кажется, что потребность контролировать качество данных была всегда. Почему же профессия инженера по обеспечению качества данных становится востребованной именно сейчас?

Александр: Объёмы и масштабы теперь другие. Понятие Big Data уже несколько лет как мейнстрим. Поначалу все стремились просто собирать как можно больше данных соответственно тезису «данные — новая нефть». Сейчас пришло понимание, что более конкурентоспособной становится не та компания, у которой данных больше, а та, у которой они достовернее, актуальнее. 

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

Кто делал работу по оценке качества данных до появления профильного специалиста?

Александр: До появления инженера DQ его функции выполняли либо дата-аналитик, либо разработчик, либо... сам заказчик. Заказчик на продакшене ловил проблемы с качеством данных, а «шишки» летели в аналитика. Конечно, так быть не должно. Сейчас ситуация меняется. Компании переходят к модели Data Driven не на словах, а на деле, понимая, что ошибки в данных ведут к прямым финансовым потерям. 

Вероника: Я бы выделила тренды, способствующие росту востребованности. Это использование дата-каталогов, внедрение дата-контрактов, а также встраивание мониторинга качества прямо в CI/CD-процессы. То есть, в современном бизнесе проверка данных становится обязательной частью поставки продукта.

К каким изменениям на рынке привела такая смена подходов к работе с данными?

Вероника: В 2025 отмечался общий спад на российском ИТ-рынке. При этом спрос на узкоспециализированные кадры в сфере ИТ достаточно высок. Также и DQ-специалисты остаются востребованными. Причём спрос, судя по тренду, будет расти. Кандидатов на вакансию инженера по обеспечению качества данных при этом гораздо меньше, чем на позицию обычного тестировщика. Многие просто не знают о таком направлении.

Как для вас выглядит профиль идеального кандидата и где искать таких специалистов?

Вероника: базовый набор компетенций такого соискателя для меня выглядит так: отличное знание SQL, понимание процессов ETL и архитектуры данных, опыт работы с инструментами Big Data (Airflow, kafka, Spark, хранилища данных). Python — опционально, но полезно для автоматизации. Знание специализированных DQ-инструментов (вроде Great Expectations, или Soda) — большой плюс, но на старте это редкость. 

Александр: По сути, ядро хард-скиллов инженера DQ сильно пересекается с навыками дата-аналитика. Однако ключевое отличие — в процессном мышлении. Я бы обозначил этого специалиста как нечто промежуточное между тестировщиком и дата-аналитиком. Тестировщик приносит понимание процессов обеспечения качества: как искать места, где система может «упасть». Аналитик приносит понимание бизнес-ценности данных. Однако аналитику часто не хватает процессности, а тестировщику — навыков работы с Big Data. Инженер DQ — это своеобразный симбиоз, «человек-мост».

Мнения наших спикеров о том, кого проще переучить на инженера по обеспечению качества данных, разделились. Вероника считает, что путь аналитика данных проще. Александр же делает ставку на процессное мышление тестировщиков, отмечая, что понимание цепочки движения данных нарабатывается дольше.

Какие социально-психологические компетенции, так называемые soft skills актуальны инженеру DQ?

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

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

Какие реальные истории помогают понять важность профессии инженера DQ?

Вероника: Отсутствие инженера DQ в крупных компаниях буквально приводит к потерям. Самый показательный пример — финансовая отчётность. Если в данных об объёмах продаж, ценах или кредитах будут ошибки, это приведёт к некорректным отчётам. Как следствие — будут приняты неверные управленческие решения и возникнут прямые финансовые потери. Именно инженер DQ обеспечивает доверие к отчётам. Кроме того, автоматизация его проверок ускоряет аналитику: бизнес гораздо быстрее получает доступ к проверенным данным. 

Александр: На сайте IBM описан интересный случай трансформации бизнес-процессов компании Autodesk. Если кратко, то разработчики и аналитики Autodesk последними узнавали о проблемах с данными (недоступность источников данных, ошибки в значениях, сбои в пайплайнах). Иногда с момента возникновения ошибки до её обнаружения проходило более месяца. Это вынуждало команду постоянно «тушить пожары», тратя ресурсы на перезапуски процессов и исправление решений, уже принятых на основе неверных или неполных данных. Речь идёт не только о прямых убытках, но и о потерянном времени команды, которое могло быть потрачено на развитие продукта.

Можно ли количественно оценить эффект работы инженера DQ?

Александр: Да, мне встречались такие оценки. По данным MIT Sloan, компании теряют от 15% до 25% своей выручки из-за низкого качества данных, что проявляется в неэффективном маркетинге, ошибках в логистике и принятии неверных стратегических решений. Более того, до 80% проектов AI/ML терпят неудачу из-за “потенциального отсутствия точности данных”. Как отмечается в исследовании Data Fortune, инженеры тратят около 60% своего времени на очистку данных вместо разработки инноваций.

Что ждёт профессию инженера DQ в будущем?

Вероника: Думаю, что в ближайшие три года мы увидим популяризацию профессии. Я надеюсь, что такой специалист станет обязательным участником любой команды разработки в сфере Big Data, наравне с дата-инженером и аналитиком. В более отдалённой перспективе, возможно, произойдёт слияние с дата-инжинирингом. Тогда появится специалист, отвечающий и за доставку данных, и за их качество. 

Александр: Пожалуй, взрывного роста не будет, но он и не нужен. Это постепенное, но неуклонное осознание рынком необходимости качества. Посмотрите на тренд с большими языковыми моделями. Сейчас все удивляются их возможностям, но следующим этапом станет отбраковка плохих моделей, которые слишком «галлюцинируют». И здесь снова понадобятся специалисты, способные оценить качество обучающих выборок. Data Quality — неотъемлемая часть любой современной системы, особенно в контексте больших данных.


По мере увеличения объёма и количества источников данных, компаниям потребовался новый специалист. Тот, кто следит не за работой кода, а за достоверностью загружаемых и обрабатываемых данных. Сейчас профессия инженера по обеспечению качества данных выглядит очень перспективной. В новой нише пока сложился «рынок соискателя»: число вакансий превышает число отправляемых на них резюме. Возможно, с течением времени профессия инженера DQ также трансформируется, но вряд ли она исчезнет. Всегда будет потребность в людях, способных отделить зёрна от плевел в бескрайнем информационном поле. Раньше говорили: «Кто владеет информацией, владеет миром!». Сейчас уже стали уточнять: кто владеет актуальной и качественной информацией.

Комментарии (10)


  1. ramil_trinion
    24.03.2026 13:14

    Для кого это написано? Это же чушь какая то. Любому дураку понятно что нужно проверить данные которые мы хотим обрабатывать. Для этого не нужно отдельного человека.


    1. MartianEngineer
      24.03.2026 13:14

      Для кого придумали ДПСников? Любому дураку понятно, что нужно соблюдать ПДД. Для этого не нужно отдельной профессии... или все-таки нужно?


      1. ramil_trinion
        24.03.2026 13:14

        Я вам открою тайну: проверка не обязательно должна производиться человеком. Можно проверять данные посредством скрипта.
        Скажу больше - обычно так и делают.


        1. I-AV
          24.03.2026 13:14

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


          1. ramil_trinion
            24.03.2026 13:14

            Вы не задумывались, кто пишет и проверяет эти скрипты?

            Кому скажут тот и будет.

            Достаточно ли однажды настроенной автоматической проверки, если меняются данные и методы их анализа, процессы в самой компании?

            Достаточно изменить скрипт (автоматическую проверку) при необходимости. Сути это не меняет.


    1. AI-SHA Автор
      24.03.2026 13:14

      Спасибо за комментарий! Цель статьи — подискутировать на тему, кто такой инженер по качеству данных. Мы обсуждаем, в чём специфика его работы и почему это направление востребовано сейчас. Что данные надо тестировать — очевидно, как вы выразились, любому дураку. Неочевидно другое: кто это делает в ИТ-командах? При современных объёмах данных и многообразии их источников на эту роль нужен именно отдельный человек с определённым набором компетенций. DQ — отдельная специализация среди всего многообразия в QA.


      1. ramil_trinion
        24.03.2026 13:14

        Неочевидно другое: кто это делает в ИТ-командах? При современных объёмах данных и многообразии их источников на эту роль нужен именно отдельный человек с определённым набором компетенций.

        Объем данных тут не причем. Многообразие источников тоже не играет роли.

        Мы пишем правила один раз и пользуемся. Это уже вопрос правильного проектирования.


  1. economist75
    24.03.2026 13:14

    В сфере охраны труда есть массовая практика (многолетняя культура) обобщений ЧП и ознакомления с ними всех - в отрасли, а то и во всей стране (СССР, Япония). Практика показала что это превентивно заставляет задумываться, чудесным образом “интуичить” и находить ранее неизвестные угрозы и купировать их задолго до первых корпоративных похорон.

    В сфере DQ на наших глахах появляются всякие GreateExpectation и т.п. Pander-ы, иногда это что-то попроще типа датаклассов, доктестов или шаблонов в Dagster/AirFlow. Но вот именно культуры обобщений ошибок так и не сложилось. Уж больно стыдно выносить на обозрение позорные упущения.

    Откуда берутся упущения и ошибки? В основном они лезут не из пользовательского ввода, а из-за безграмотного кода. Вот 1С-данные - это-ж эталон/стандарт учета. Так почему он позволяет дублировать то, что д.б. уникальным априори (ИНН/КПП, ед. измерения итп)? Вот вам источник ошибок. DA джойнит смело, а DQ полагается на порядочность и разум кодеров, но его нет, причем даже там, где без него нельзя. DA и DQ - оба бессильны перед разгильдяйством.


    1. infinum1
      24.03.2026 13:14

      Да, разгильдяйство есть всегда и степень его действительно влияет на итоговое качество продукта/данных. От багов в архитектуре и проектировании (как понимаю, речь о них) никто не застрахован и такие проблемы, как правило, самые дорогие. Но их тоже можно/нужно обнаруживать и лучше раньше, чем позже. Задача DQ совместно с DA и DE выработать такую схему мониторинга и тестирования данных, желательно автоматизированную, чтобы выявлять проблемы по факту их возникновения (например, когда данные по одному или группе объектов не согласованы). Универсальной защиты на все случаи жизни не придумали, но минимизировать риски - вполне посильная задача, кмк. В этом и ценность профессии, хороший инженер по тестированию (качеству даных) полагается не на доверие к разработчику, а действует по принципу доверяй, но проверяй. И доп. глаза (особенно опытный взгляд с насмотренностью на качество) всегда полезны.


  1. nikfr
    24.03.2026 13:14

    Отдельная роль для датакволити - довольно страннная практика, на мой взгляд. Родилась из посыла: данных много, мало кто их понимает, давайте закроем это "новым" тайтлом, чтобы не было как в компании XX, где потеряли YY из-за кривых данных. Интересно, кто-то измерял, сколько не потеряли, внедрив DQ? Несмотря на наличие подзаголовка, ответа на это я не вижу... Где в реальности DQ волшебники спасают 60% работы "тру" инженера и экономят 15% бизнеса, внедряя Great Expectations?

    А проблемы с качеством это же скорее про проектирование, контекст, владение. Тестировщики это не покроют, даже если захотят.

    На большинстве проектов, где реально был этот тайтл, датакволити инженер = тестировщик. Из-за размытия и непонимания этой роли другими участниками проекта, ещё и малоэффективный.