Обеспечиваем качество данных в компании. Подборка open-source-инструментов для Data Quality

Привет, Хабр! Я Алексей Чумагин, Data Quality Team Lead Островка. В компании мы работаем с десятками источников данных: авиакомпании, отели, агрегаторы, платёжные сервисы. При этом источники постоянно обновляются: добавляются партнёры, меняются API и форматы. В таких условиях Data Quality становится непрерывным процессом, встроенным в ежедневную работу, а вовсе не стереотипным «набором тестов, которые раз в сутки что-то проверяют». 

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

Архитектура нашей платформы организована вокруг следующих задач:

• автоматизация создания и выполнения тестов;

• их централизованное хранение;

• визуализация результатов;

• мгновенное оповещение команд об инцидентах.

Вся эта экосистема работает в едином ритме с основными data-процессами компании.

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

Какие инструменты мы используем в Data Quality

1. Ядро и автоматизация

• В качестве ядра системы мы выбрали Soda Core — движок, который позволяет формализовать правила качества: целостность, уникальность, диапазоны значений. Тесты описываются декларативно, что упрощает поддержку и масштабирование.

• После того как тесты написаны, их запуск и оркестрацию мы доверяем Apache Airflow. Он автоматически запускает проверку после ETL-процессов, управляет зависимостями и расписанием, что критично для стабильной работы пайплайнов.

• Чтобы не тратить время на рутинное написание DAG’ов для новых тестов, мы используем DAG Factory — генератор DAG’ов, позволяющий держать код тестов и их запусков в едином месте, легко масштабировать количество проверок.

2. Интеграция и доступ

• Важной частью платформы стала интеграция с другими системами. Для этого мы подняли сервисный слой на FastAPI: через API можно запускать тесты, получать результаты, интегрировать платформу с внешними инструментами.

• Для визуализации выбрали Streamlit — он позволяет быстро собирать дашборды и интерактивные отчёты, которые особенно удобны инженерам для экспресс-проверок и разбора логов ошибок.

• Но не все участники процесса хотят разбираться в технических деталях. Менеджеры и аналитики зачастую предпочитают DataHub — каталог метаданных, где хранятся все проверки, их результаты, а также информация о таблицах, lineage и пайплайнах. Это позволяет сделать качество данных частью общего ландшафта данных компании.

3. Оперативность и реакция

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

• Вся DQP-платформа развернута в Kubernetes, — это обеспечивает масштабируемость, отказоустойчивость и централизованное управление компонентами.

И почётное упоминание ещё одной неизбежно важной технологии: для ручных ad-hoc-проверок мы, конечно же, используем старый добрый SQL. Без него ни одна оперативная сверка или исследование гипотез не обходится.

Итого: наш Data-Quality-стек — это комбинация проверенных open-source-инструментов, которые удобны на практике: легко автоматизируем тесты, быстро видим результаты, интегрируемся с чем угодно и не особо беспокоимся о лицензиях. Всё масштабируется, поддерживается инженерами, а не только админами и даёт нам уверенность в качестве данных, даже когда вокруг всё меняется.

А какие инструменты используете вы для контроля качества данных? Что бы вы добавили или изменили в нашем подходе? Будем рады обсудить в комментах!

***

ТГ-канал Ostrovok! Tech

Роадмап для начинающих питонщиков

Изучение Python может показаться сложным, но с правильным подходом и пониманием ключевых аспектов процесс станет понятным и увлекательным. Привет, я Иван Чернов, senior system architect, кратко расскажу, как начать вкатываться в Python, с какими проблемами сталкиваются новички и как их преодолеть.

Первые шаги

Определяемся с направлением, в котором вы хотите развиваться. Это может быть веб-разработка, машинное обучение, DevOps и т. д. Каждое направление требует своих знаний и навыков. Поэтому важно понять, что конкретно вам интересно и на какой позиции не будет скучно или слишком сложно.

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

Когда определились с направлением и изучили теорию — проходите курсы с практическим обучением или начинайте работать с кодом сами. Всегда лучше писать, чем читать. Как только вывели “Hello, World!”, переходите к обучающим программам, где первые задачки применимы к жизни. Например, на некоторых курсах учат разрабатывать Telegram-бота под ваши нужды. Это отличная практика для понимания процессов.

Также можете прочитать базу «Питона» — книгу “Automated Boring Stuff with Python”. В ней много практических задач, которые помогут вам освоить язык. А ещё есть полезный курс “Learning How to Learn”, который учит, как правильно учиться, опираясь на достижения нейронауки.

Этап, на котором новички отваливаются

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

Чтобы облегчить старт, можно для начала научиться использовать онлайн-среду разработки, например Replit. Можно просто зайти на сайт, выбрать язык Python и сразу приступать к написанию кода. 

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

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

Концептуальные вопросы

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

Например, в Python переменная может принимать разные значения, что противоречит математическим представлениям. Это может привести к путанице и неправильному пониманию основ программирования. 

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

Советы начинающим питонщикам

• Постоянная практика. Пишите код каждый день, хотя бы немного. Работайте над проектами, которые вас интересуют, и решайте проблемы, которые вас раздражают. Я в 2010-м хотел, чтобы дома лампочка включалась по голосу. С помощью Python удалось сделать это.

• Изучайте чужой код. Чтение и понимание чужого кода поможет вам увидеть, как другие решают задачи и какие подходы используют. Однако не стоит изучать рандомный код. Лучше ищите тот, что поможет улучшить ваши проекты. 

• Go sport, go team. Физическая активность способствует лучшему усвоению информации. Поэтому не забывайте делать перерывы и заниматься спортом.

Заключение

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

Улучшаем опыт бронирования отелей на О! Хакатоне

Кто-то предпочитает отели, кто-то — апартаменты и квартиры, но точно все бы хотели, чтобы искать временное жильё и заселяться в него можно было просто и быстро. Мы в Островке хотим того же, поэтому посвятим этому целый хакатон. А вы своим участием поможете нам.

Если вы Middle- или Senior-разработчик на Python или Go, приходите на «О! Хакатон», решайте интересные задачи и выигрывайте призы. Вам предстоит разработать инструменты для улучшения опыта бронирований и оценки отелей.

Как будет проходить «О! Хакатон»? Вас ждут два трека. На одном предстоит разработать инструмент «Секретный гость». На другом нужно персонализировать подбор отелей, используя данные о пользователе, чтобы предоставить лучшие рекомендации.

Призовой фонд каждого трека — 500 000 рублей, которые разделят между собой три команды победителей. Кроме того, все участники получат шанс выиграть промокоды на бронирование отелей.

Регистрируйтесь до 18 сентября 2025 года включительно, «О! Хакатон» стартует 26 сентября. У вас будет 8 дней на решение задач. 

Следите за обновлениями в канале «О! Хакатона» в Телеграме!

Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести

Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.

В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться. 

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

Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.

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

На этих циклах фокусируемся на доске в Miro во время встречи. 

В ивент-шторминге 3 этапа: 

1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.

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

3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации. 

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

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

Поделюсь советами, как круто провести ивент-шторминг.

Онлайн-формат

● Для проведения онлайн достаточно доски в Miro.

● Разбивайте встречу на три части, каждая встреча — один этап.

● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.

● Максимум людей для успешной фасилитации онлайн — 8–10 человек.

Подбор людей и подготовка

● Соотношение участников: 70% бизнеса, 30% разработки.

● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».

● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.

● Берите людей из разных направлений домена. 

● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.

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

● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.

Фасилитация

● На старте не бойтесь повторить все вводные.

● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.

● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали. 

● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.

● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.

● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.

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

Внешние интеграции

Поставщики отелей, бронирования билетов, трансферов, автомобилей… для пользователя все они должны взаимодействовать бесшовно.

Внутренние интеграции

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

Реалистичные данные для тестов

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

НО!

...самые интересные истории могут родиться даже не из-за обилия сервисов. Есть у нас услуга: автоотмена бронирования отелей до истечения срока бесплатной отмены в отеле. Как-то осенью в одном американском отеле эта отмена стала срабатывать на час раньше. Мы сверили часовые пояса: все было в порядке, проверили еще кучу мелочей. Но нашли ответ именно в согласовании времени. Хотя большинство штатов США переходят на летнее и зимнее время как остальной мир, отдельные штаты это игнорируют — и проблемный отель находился как раз в одном из них.

Хотите узнать больше о работе QA-инженеров в Островке? Пишите в комментариях и эта тема получит шанс заиметь свою статью в блоге :) И на наш Телеграм-канал подписывайтесь!

А если вы или ваши друзья хотите скать частью QA-команды Островка, то обратите внимание на эти открытые позиции в нашей компании:

• QA Engineer в команду CheckOut

• QA Engineer в команду Маркетинга

Исследуй неизведанные пути на О! Хакатоне

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

На О! Хакатоне, который пройдёт с 28 сентября по 5 октября, участников ждут испытания на оригинальных маршрутах по миру тревел-теха и встречи с экспертами. А победители получат призы.

Мы зовём в путь прежде всего Middle-разработчиков на Python и Go, разработчиков на других языках, девопсов, аналитиков, продактов. В путь можно отправиться как в одиночку, так и командой до пяти человек. А если у вас нет команды, но вы хотите сотрудничать на хакатоне с другими специалистами, мы поможем подобрать единомышленников после регистрации.

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

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

Хотите почувствовать себя первопроходцами? Регистрируйтесь на О! Хакатон до 19 сентября.

Чем занимаются Go-специалисты в Островке?

У нас 10 команд, использующих Go, как основной язык. Для примера возьмём команду интеграций с поставщиками отелей. Вот что делают разработчики в этой команде:

• Адаптируют API различных поставщиков к внутреннему API сервиса. Внешние поставщики отелей используют разные технологии: GraphQL, XML, SOAP, WTF. В каждом API своё время ответа, свои коды ошибок и ещё много кастомного. 

• Поддерживают и правят существующие интеграции. Протокол сменился, или (куда реже) коды ошибок стали другие — всё надо держать в актуальном состоянии и при необходимости править.

• Уменьшают технический долг. Это задачи, связанные с библиотеками и рефакторингом. Есть правило — на одну итерацию должно приходиться 75% продуктовых задач и 25% техдолговых.

• Дежурят в общем чате. В нём разработчики отвечают на вопросы менеджеров. Раньше дежурств не было, на вопрос отвечал тот, кто увидел его первым. Когда поток обращений вырос, решили назначать дежурного.

• Обмениваются знаниями внутри компании. В Островке есть активности, напрямую не связанные с работой. Например, канал в слаке #dev-golang и еженедельный книжный клуб.

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

Что почитать начинающим разработчикам на Go

Привет, Хабр! Меня зовут Алексей Артамонов, я лид команды интеграции в «Островке». Сделал подборку, что можно почитать для старта работы с Go:

• «The Go programming language» — азы для старта. Хотя синтаксис в Go простой, важно уметь из этих простых вещей собирать сложные конструкции. 

• Effective Go — практическое пособие для создания тех самых сложных конструкций.

• «Сто ошибок в Go» — ещё одна хорошая книга. Заход со стороны «как делать не надо».

• В различных обучающих программах очень много внимания уделяют монолитам, микросервисам и в принципе архитектуре. Но правда в том, что джун или мидл вряд ли столкнётся со столь глобальными задачами. Ему важнее уметь разбить свою логику по классам, пакетам, модулям. Важно писать качественный код. Для этого обязательно рекомендую книгу «Good code, bad code».

• Много полезного в книге «Принципы юнит-тестирования». Хорошие юнит-тесты неразрывно связаны с тем, как приложение разбито на модули, какие есть связи и зависимости.

• Два блога-рассылки: GoLang Blog и Awesome Go Weekly.

• Подкасты довольно сложны для восприятия в фоновом режиме. Особенно для новичков. Но если очень хочется: GoTime, GoPodcast и GoGetPodcast.

Обучение пройдёт легче, если уже знать какой-нибудь язык программирования. К примеру, в «Островке» два главных языка — Python и, собственно, Go. Главный секрет — желание и практика. Если хочешь стать программистом — надо сесть и начать кодить. Ни одна книга без практики не поможет стать программистом.

Привет! Меня зовут Ильдар Ломов. Расскажу, чем занимаются ML-инженеры в Островке. Знаю об этом всё, я сам руководитель команды Data Science.

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

Состав команды стандартный: ML-инженер, бизнес-аналитик, проджект, продакт. Опционально тимлиды и разработчики.

Работа ML-инженера в Островке — посередине между стартапом с его моделью в jupyter-ноутбуке и корпорацией, где работа с сотнями моделей упорядочена, стандартизирована, вшита в интерфейсы. Можно поработать над серьезным проектом гибко с разнообразием инструментов.

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

Нужно уметь покрывать метриками, следить за проектом на проде, чтобы тот не потерял смысл из-за нестыковок в ТЗ. И работал так, как задумано. 

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

Работа оценивается с точки зрения влияния на бизнес, инженер видит, как проекты прямо и понятно воздействуют на бизнес-метрики. 

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

Привет, я Иван Елфимов, Developer Advocate в Островке. Расскажу про самые полезные open source решения, которые использую я сам и Команда партнерских интеграций.

• Вообще, трудно назвать не open source решение, которое бы использовал Островок в своей разработке. Используем большей частью опенсорс с подходящими лицензиями.

• Один из самых малоизвестных и узкопрофильных компонентов, который мы используем: django-chronograph. Это приложение, позволяющее запускать management-команды из админки. Эта библиотека давно не поддерживается, поэтому мы форкнули её к себе доработали. Возможно когда-нибудь выложим в Open Source.

• Компания Astral создает (точнее пересоздает) отдельные инструменты для питона на языке Rust, заставляя их работать в разы быстрее. Мы уже начали пользоваться и ruff и uv.

• Личная рекомендация от меня: pre-commit. Инструмент очень мощный и полезный, хотя даже там встречается юмор от разработчиков. К примеру, скрипт проверки кода на случайно оставленный print называется «oops, I print it again!»

• Островок готовит к выпуску свой техрадар. Пока он работает в закрытом режиме только для сотрудников, но в планах вынести его наружу. В техрадаре будет информация о библиотеках, прошедших через тесты команды Островка. Они будут сгруппированы по направлениям (frontend, backend, ios/android, аналитика, QA, devops) и каждая из библиотек будет иметь свою стадию: adopt, trial, assess и hold.

Привет, я Иван Елфимов, Developer Advocate в Ostrovok.ru. Расскажу про наш переход на Django 5.0.

4 марта вышел третий security release, когда мы обычно переходим на новые версии библиотек. Мы были готовы к переходу: проверили на декабрьском 5.0.0. что могло сломаться. Из-за некоторых обновлений нам пришлось менять код:

• Раньше мы использовали nulls_last=False. Теперь nulls_first и nulls_last могут быть True или None, поэтому в некоторых местах вместо значений по умолчанию теперь nulls_last = None:

  - nulls_last = False
  + nulls_last = None
    if ordering_by == OrderingField.FIELD_START_AT:
        nulls_last = True

• В сигналах появился новый тип асинхронных ресиверов  (async_receivers), мы добавили его во вспомогательный класс SignalBlocker, которым временно выключаем сигналы.

• Теперь надо явно указывать USE_TZ = False, но это не проблема, мы не используем таймзоны в нашем сервисе.

• Если после refresh_from_db надо дальше по коду использовать закешированные значения из базы данных, появился такой хак:

my_model_obj._meta.private_fields = []
my_model_obj.refresh_from_db()

Новинка, которой воспользуемся в будущем, — расчетные поля по умолчанию (default) в БД. Есть сценарии, где нужно, чтобы поле по умолчанию было не скаляром, а содержало расчётное значение на основе других полей.