Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).
Как юрист стала инженером данных: путь из права в пайплайны
Работая юристом, я втайне мечтала не о кодексах, а о коде. Из чистого любопытства брала в руки книги по базам данных и вечерами ныряла в онлайн-курсы. SQL на Stepik был первым — дался непросто, но увлёк. Следом пришёл Python, и всё завертелось. Мне хотелось понимать, как устроены данные — не на уровне отчётов, а вглубь, на уровне схем, таблиц, логики. Без карьерных целей, просто из жажды разобраться.
Когда я устроилась юристом в Сбер, это хобби сыграло в плюс: появилась возможность пройти внутренние курсы про архитектуру данных, жизненный цикл ПО, основы разработки. Тогда я впервые поняла, что «работа с данными» — это вполне реальная профессия, а не магия.
Погружение заняло около года. Свободное время исчезло: я штудировала всё подряд, чем делились коллеги, что было в открытом доступе, что рекомендовали на форумах. Учёба после работы стала частью жизни, а не дополнительной нагрузкой. Когда тебе реально интересно — учиться не тяжело.
К моменту перехода в банковскую сферу я уже закончила магистратуру по экономике. Хотелось глубже понять суть финансов, с которыми мы работаем. Позже, уже в блоке технологий, добавила третью магистратуру, на этот раз по информационным данным (ASoft). Сложно? Только по графику. А в остальном — сплошной кайф от процесса.
Так я пришла к новой роли — Data Quality Engineer. Сегодня я отвечаю за качество данных в одном из подразделений департамента управления благосостоянием: проверяю, что всё, что уходит в виджет в приложении Сбербанк Онлайн и в витрины данных, надёжно, актуально и логично. От брокерских счетов до накоплений в НПФ, от страховых полисов до инвестиционных продуктов — данные должны быть в порядке.
Вспоминая этот путь, сложнее всего было не выучить SQL, а дойти до собеседований. Почти полгода отказов, и на первом же реальном собеседовании я получила оффер. Так что не бойтесь. Если есть желание, то всё получится. Главное, не бояться начинать.
И да — три магистратуры, вечера с курсами, отказ за отказом... Зато теперь я точно знаю, где в данных болит.
Совет тем, кто идёт в инженерию данных: начинайте с SQL. Это ваша «латынь» в мире данных. Затем — понимание архитектуры БД, как они устроены, связаны, наполняются. Возможно, вам встретится Hadoop, Oracle или legacy-системы, а может — современный стек. Не страшно. Главное, уметь доставать нужное из хаоса, строить витрины, думать как инженер. Всё остальное придёт.
Редкая птица в джунглях данных
В эпоху, когда бизнесу нужны точные и своевременные данные, инженер по качеству данных становится не роскошью, а необходимостью. Но роль Data Quality-инженера — всё ещё как панда в джунглях эксплуатации. Встречается редко, живёт долго, а все вокруг спорят, кто за него должен отвечать: разработка, аналитика или тестировщики.
На деле роль эта — микс из тестировщика, аналитика и data-инженера. Не про кнопки, не про отчёты об ошибках и даже не про UI. Это про сами данные: как они живут, как передаются, где теряются, и почему одно и то же поле «дата» может быть 2025-04-01, "1 апреля 2025" или даже "1743451200". (Да, это реальный случай. И нет, это не шутка.)
Примечание: чем больше источников, тем веселее жизнь Data Quality-инженера. Особенно если у всех свои представления о прекрасном. Один пишет дату строкой, другой — timestamp, третий — просто числом. А у тебя одна цель: привести всё это к вменяемому виду, чтобы дальше по тракту всё текло как положено, единообразно. Как говорится, договорись с данными и с людьми.
Самое сложное — не SQL и не пайплайны, а коммуникация. Договориться с коллегами, с системами, с реальностью. И добиться, чтобы все данные из десятков источников, в итоге, сложились в правильную форму. Да, у нас всё получилось. Но это были переговоры в духе «как насчёт вот так, но по-человечески».
Актуальность важна. Но верность данных важнее. Потому что на «свежих, но кривых» отчётах можно так уехать, что не спасёт ни один BI-дашборд.
Тракт данных: от 30 секунд до суток
Скорость — понятие относительное. В Сбербанк Онлайн платёж проходит за несколько секунд, потому что за ним стоит мощнейший бэкенд и приоритет обработки. А вот отчёты, витрины или справочники обновляются по-другому графику — раз в день, раз в час, раз в год. Всё зависит от типа данных, длины тракта, расписания ETL и наличия ресурсов. Иногда нужна минута. Иногда — сутки.
Но, в любом случае, ресурсы бесконечно не масштабируются. Вычисления дорожают, железо хоть и стало компактнее (то, что раньше занимало стойку, теперь умещается в коробочку), но магии не существует. Поэтому — оптимизация. Скриптов, запросов, пайплайнов. И постоянная чистка хвостов.
Проверки идут по кругу. Ежедневно. Где-то — ежечасно. Стандартный минимум:
заполненность;
дубли;
актуальность;
проверка бизнес-логики (например, правильно ли считается доход).
И это важно. Потому что даже если поле не пустое, это не значит, что всё хорошо. Один банк считает проценты по календарному месяцу, другой — по усреднённому. Внешне всё, вроде бы, совпадает, а на деле — нет.
Особенно важно тестировать данные на каждом этапе, если с ними что-то произошло: пересчитались, сжались, переехали. Проверка нужна и тому, кто отдаёт, и тому, кто принимает. Но на практике проверяет чаще тот, кто потом будет крайним.
Так что да: Data Quality-инженер — не просто тестировщик, не просто аналитик, не просто инженер. Это человек, который понимает данные, умеет с ними разговаривать и знает, где у них болит. И да, таких пока немного. Но без них уже никак.
Мечты сбываются (и даже попадают в ПК)
Когда в чате HighLoad++ увидела сообщение от Олега Бунина о наборе в программный комитет новой конференции, у меня сердце, что называется, ёкнуло. Ну вот же оно — приглашение туда, где всё настоящее, большое и взрослое. Подала заявку в ПК Data Internals, не особо надеясь — и попала. Бинго.
Для меня это первый опыт в программном комитете серьёзного мероприятия. До этого был только «лайт»: внутренние митапы, рабочие обсуждения, помощь в выборе тем и докладчиков в Сбере. Но хотелось настоящей движухи. Хотелось посмотреть, как это устроено изнутри, что на самом деле делает ПК, как рождаются программы, как подбираются спикеры, как всё это, в итоге, превращается в конференцию.
«Может, я тоже могу что-то полезное привнести?» — подумала я. А вдруг моя тема — про качество данных, витрины, жизненный цикл и стандарты — кому-то действительно важна. Ведь это редкая область. Часто про неё забывают, хотя именно с неё всё начинается. Или, наоборот, разваливается.
И знаете, меня очень вдохновляет, что Data Internals — это не ноунейм, а конференция от Онтико. Крупное мероприятие, где всё по делу, без воды, без «а вот наш кейс про то, как мы написали wrapper». Это конференция про сами данные: как они рождаются, как передаются, как очищаются, как живут в эксплуатации. Можно смотреть на тему со всех сторон — от аналитики до DevOps. Это кайф.
Сообщество data-инженеров и инженеров данных огромное. В разных каналах по-разному, где-то 500 человек, где-то тысяча, где-то 10 тысяч. Все варятся в чатах, делятся болью, отвечают на вопросы, кто-то даже мемы шлёт. Но всё равно — личного контакта не хватает. А конференция — это переход в оффлайн: можно пожать руку, услышать живую обратную связь, позадавать вопросы. Можно найти команду. А можно просто вынести с собой список озарений — и ещё полгода работать эффективнее.
Заменит ли ИИ DQ
Проблемные вопросы индустрии сейчас связаны, в основном, с уходом части зарубежных компаний. Но есть вендор-замещение. А остальное, скорее, рабочая рутина. Из-за санкций нам, как и всем, пришлось от чего-то отказаться. Но поскольку Сбер большой, у нас есть свои наработки и замены. Да, индустрия изменилась. Но жизнь продолжается. Teradata ушла, но на её месте появилась новая база. Переехали. Всё живёт.
В контексте развития индустрии трудно забыть про ИИ, о нём все сейчас твердят. Но мне кажется, что от ручных операций всё равно не получится совсем уйти. В любом случае нужны люди, которые понимают, как всё работает изнутри под капотом. Как иначе взаимодействовать и делать именно тот продукт, который нужен? Важно, чтобы конечный пользователь данных, неважно, в БД или дашборде, мог видеть именно то, что хочет, без кучи лишних костылей и дополнительных настроек.
Про ИИ сейчас говорят все. И да, он действительно уже умеет многое: может составить запрос, выгрузить список таблиц, оценить структуру схемы. Иногда даже предложить вариант проверки.
Но вот нюанс: он не знает, почему вчера у нас в данных дыра, и нормально это или тревога. Он не может объяснить, что у клиента отключили продукт, потому что вышел новый. Не умеет считывать бизнес-контекст. А пока не умеет — верификация человека останется важной. Да и просто иногда нужен человек, который посмотрит на график и скажет: «Что-то тут не так. Пошли копать».
Что дальше
В будущем профессия Data Quality-инженера будет трансформироваться. Рутину — ИИ, контроль — человеку. Ручные проверки останутся, но будут точечными: запуск по чекпойнтам, подтверждение по дашборду или отбивке.
Главное — понимать, зачем ты это делаешь, где у данных слабые места и как сделать так, чтобы конечный пользователь получил именно то, что ждал. Без боли. Без костылей. С первого раза.
А конференции — это не про доклады и бейджи. Это про сообщество. Про то, что мечты действительно сбываются, если ты в теме, в ресурсе и готов учиться. Даже если тебе за тридцать, из провинции, с двумя непрофильными магистратурами и фонариком в джунглях SQL.
Если вы тоже увлечены данными и каждая задача для вас — интереснейший вызов, обязательно приходите на Data Internals. Вместе разберём, какие боли есть в индустрии и как выйти из сражения победителем.
Своими мыслями о Data Quality делюсь в канале, если интересно — заходите.
