Бэкенд-разработчик в Metric Store
Posted Updated 4
views
Summary
Backend developer for Yandex's Metric Store — a service that stores business metric definitions (formulas, data sources, dimensions). Day-to-day work centers on designing the metric model and API, SQL generation (joins, aggregations, window functions, virtual columns) and testing, using Python, SQL, and PostgreSQL.
Мы развиваем Metric Store — сервис, в котором хранятся определения бизнес-метрик: формулы, источники данных и доступные разрезы. Ищем разработчика бэкенда. Приходите, если знаете Python, SQL и PostgreSQL.Разрезы для сложных метрик
Иногда нужное измерение находится не в таблице, по которой считается метрика, а в связанной. Нужно описать такие связи в модели сервиса, сделать измерения доступными в фильтрах и группировках и проверить расчёт на существующих метриках. Несколько способов расчёта одной метрики
Для дашборда может подходить быстрая агрегированная таблица, а для исследования — подробные данные. Предстоит проработать модель и API, чтобы оба способа жили под одним именем метрики. При построении SQL пользователь должен явно выбирать способ расчёта; запросы без выбора должны работать как прежде. Оконные функции в виртуальных столбцах
Сейчас такие выражения попадают в запрос слишком поздно — на этапе расчёта метрики. Нужно изменить генерацию SQL, чтобы виртуальный столбец вычислялся до агрегации, и покрыть новые и существующие сценарии тестами. Также предстоит развивать проверки метрик и интеграции с Лабой и Атласом. Больше о бэкенде в Яндексе — в канале Yandex for Backend* Занимались бэкенд-разработкой на Python * Хорошо знаете SQL и PostgreSQL * Понимаете, как JOIN и агрегации влияют на результат * Умеете проектировать API и писать тесты* Работали с YT/YQL, ClickHouse или Spark
Иногда нужное измерение находится не в таблице, по которой считается метрика, а в связанной. Нужно описать такие связи в модели сервиса, сделать измерения доступными в фильтрах и группировках и проверить расчёт на существующих метриках. Несколько способов расчёта одной метрики
Для дашборда может подходить быстрая агрегированная таблица, а для исследования — подробные данные. Предстоит проработать модель и API, чтобы оба способа жили под одним именем метрики. При построении SQL пользователь должен явно выбирать способ расчёта; запросы без выбора должны работать как прежде. Оконные функции в виртуальных столбцах
Сейчас такие выражения попадают в запрос слишком поздно — на этапе расчёта метрики. Нужно изменить генерацию SQL, чтобы виртуальный столбец вычислялся до агрегации, и покрыть новые и существующие сценарии тестами. Также предстоит развивать проверки метрик и интеграции с Лабой и Атласом. Больше о бэкенде в Яндексе — в канале Yandex for Backend* Занимались бэкенд-разработкой на Python * Хорошо знаете SQL и PostgreSQL * Понимаете, как JOIN и агрегации влияют на результат * Умеете проектировать API и писать тесты* Работали с YT/YQL, ClickHouse или Spark