Привет! Меня зовут Николай Огоров, я Big Data-инженер в Авито. В этой статье я и мой коллега Айк Оганесян расскажем, как обеспечили пользователей инструментами, которые дают им возможность самим создавать витрины в хранилище Авито без привлечения специалистов. Эта история больше про подходы, решения и философию, которые позволяют жить в парадигме, когда потребностей на создание объектов DWH стало сильно больше, чем возможностей Data-инженеров.
Self-service – это концепция, в которой пользователь может сам решить свои задачи. Конкретно для пользователей DWH это возможность быстро и удобно создавать или изменять объекты хранилища, которые будут безопасно встроены в регламент, и пользователям не потребуется для этого привлекать Data-инженеров.
Содержание:
Задача
Авито – большая компания, ей требуется много различных отчётностей и данных, и разным сотрудникам нужны разные данные для разных целей и в разных форматах. Чтобы всё это подготовить нужно много людей. Инженеры могут с этим справиться, но жалко тратить их силы на рутину. Для этого процесс деплоя новых объектов нужно было автоматизировать.
Как мы её решили
Для этого мы придумали концепцию, в которой те сотрудники, которым нужны новые данные, могут сами задавать правила их поиска и подготовки. То есть создавать витрины, аплоадеры, словари и другие объекты хранилища.
Витрина (datamart) – это особая таблица базы данных, вся её структура и код описаны в виде SQL-файла. Такой файл лежит в нашем git-репозитории (Bitbucket). Витрина состоит из трёх частей:
шапка – это yaml-словарь с параметрами, необходимыми для запуска витрины;
DDL – это описание структуры витрины;
DML – её код, который запускается на регламенте и обновляет витрину.
Регламент – это ацикличный граф, узлами которого являются витрины. Он запускается раз в сутки и поочередно выполняет код всех витрин. Выполнение витрин происходит от корня к листьям, пока не выполнятся корневые витрины, листовые не запустятся.
Так мы придумали систему тестов, которая с помощью бота «за руку» проводит пользователя от идеи витрины до её появления на регламенте.
Я считаю, что это и есть главная фишка, потому что пройти весь этот путь без привлечения data-инженеров в большинстве других компаний не могут.
В итоге мы освободили инженеров для решения инженерных задач, а не написания витрин за пользователей. И даже пользователей, которые стали независимы в своей работе от инженеров.
Мы в цифрах
Нашему хранилищу DWH уже 11 лет. У него 4500 пользователей и более 4500 витрин, из которых более 900 – критичные, то есть это те витрины, к которым мы предъявляем самые высокие требования. Всего на регламенте за сутки обрабатывается более 30 тысяч тасок. У нас примерно 660 авторов витрин. И TTM деплоя минорной витрины составляет около 1 минуты. Для серьёзных объектов – до часа.
Витрин появилось так много, потому что мы даём пользователям создавать их и встраивать в регламент самостоятельно, не ограничивая.
Путь витрины пользователя от идеи до регламента
Пользователь придумывает свою витрину и несёт её к нам в Bitbucket . Там у нас настроены веб-хуки и бот, который общается с пользователем. Для него есть две команды: dwh test и dwh merge. Первая команда запускает проверки пользовательского кода. Вторая – мёржит pull request, если все проверки пройдены.
Этапы проверки
Опасный код – синтаксические ошибки, опасные drop-выражения, проверка правильного использования параметра шапки витрины.
Проверка перформанса – проверка того, что витрина написана без ошибок, выполняется и не съедает все ресурсы. Если в графе одна витрина работает слишком долго или съедает все ресурсы, то пострадают все витрины, которые зависят от неё или выполняются вместе с ней.
Проверка окружения – это проверка того, как изменения витрины повлияют на весь граф.
Мы проверяем, не заденет ли кого-то пользователь, меняя свою витрину, не удалились ли столбцы или сама витрина. Также проверяются циклические зависимости.
Ручные апрувы – это этап, на котором бот проверяет попытки пользователей изменить чужие витрины. Если пользователь всё же захочет изменить витри��у, которую создавал не он, ему нужно будет получить апрув от её владельца.
Мы не даём кому угодно менять что угодно.
Изменения DDL – проводим проверку попыток изменения структуры витрин. Если изменения затрагивают не только код обновления, но и DDL – саму структуру таблицы. Нам нужно будет поменять таблицу в хранилище в соответствие с тем, как это было сделано в файле. Здесь используются механизмы автогенерации и автопроверки миграции. Если пользователь поменял DDL, то бот определяет это автоматически и пытается сгенерировать миграции. В большинстве случаев он генерирует их правильно. Иногда, если пользователь сделал что-то очень сложное, необходимо вручную создать миграции через комментарии в Bitbucket.
Мы не можем просто так взять и смёржить любую правку, которую внёс пользователь, потому что это несёт риски.
После всех тестовых этапов пользователю приходит результат проверки в виде ссылки на отчёт. Если всё ок, то пользователь может написать боту команду dwh merge, и pull request автоматически смёржится. Только после всех этих пунктов витрина может попасть на регламент. Регламент сам ходит в Bitbucket и забирает актуальные витрины.
Сейчас мы закрываем все базовые потребности пользователей и наши собственные потребности безопасности, которые необходимы регламенту.
Планы на будущее
В будущем мы намерены дать ещё больше свободы пользователям, чтобы они сами выполняли ещё больше нужных им задач. Самообслуживание, так сказать.
Пользователи сами будут менять данные в витринах
Мы хотим позволить пользователям самостоятельно менять не только описание автоматического обновления витрины, но и точечно менять данные в ней.
Создадим админку для гибкой настройки системы тестирования
Сейчас строим админку, в которой администраторы self-service по запросу в пару кликов смогут редактировать проведение системы тестов. Тестов более сотни, много разных движков, разные виды объектов, пользователей – нужно редактировать сценарии. Сейчас добиваемся того, чтобы всё это работало бесшовно, чтобы не приходилось менять сам код проекта.
Создадим систему тестов as a platform
Сейчас у нас всё заточено под работу с Bitbucket, но изначально система тестов создавалась как независимый компонент, к которому можно обращаться не только через Bitbucket и систему мержей, а работать напрямую по API. Мы работаем над тем, чтобы таких пользователей становилось больше.
Интегрируем проверки в IDE
Есть глобальная инициатива по созданию IDE – единой точки входа в DWH, где пользователи смогут сами писать код, сразу его проверять и отправлять на регламент. Это будет альтернативой Bitbucket, который имеет специфичный интерфейс. Здесь всё будет заточено под написание кода. В эту систему мы встроили нашу систему автотестов, то есть IDE сможет проверять код, используя мощности нашего self-service решения.
Уже сейчас наша система автоматического тестирования позволяет обрабатывать более 90% пользовательских пулл-реквестов без привлечения Data-инженеров. Но мы постоянно совершенствуем её, стремясь добиться максимальной автономности каждого пользователя.
А что вы думаете о DWH? Делитесь мыслями в комментариях.
А если хотите вместе с нами адаптироваться в мире стремительно развивающихся технологий — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.