Привет! Меня зовут Николай Огоров, я 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? Делитесь мыслями в комментариях.
А если хотите вместе с нами адаптироваться в мире стремительно развивающихся технологий — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.