Data Engineer
Схему самой базы данных ты как правил — прям руками в базе или скрипты где-то хранил, или вообще в Liquibase сидел, какой процесс был?
Что такое GIL (Global Interpreter Lock)?
Разбор dbt-модели с инкрементальной стратегией: что делает модель, есть ли проблемы?
Когда ты строил пайплайны на Airflow, как ты решал проблему junk data (мусорных/невалидных данных)?
Как передавать данные между задачами в Airflow?
Юнит-тесты писали? Есть ли у вас такой опыт?
Какие индексы знаете в PostgreSQL?
Что такое CTE (Common Table Expression)?
Что такое индекс? Чем отличается кластеризованный индекс от некластеризованного?
Чем отличаются типы данных int и uint в ClickHouse?
Строил ли ты дашборды и работал ли с инструментами визуализации данных (BI-инструменты)?
Можешь рассказать, что здесь в итоге у нас получится? Нужно прокомментировать каждый шаг, как это работает.
Какое выражение на месте пропуска [...] автоматически приведет к созданию индекса? На мобильной платформе присутствует горизонтальный скролл кода create table some_table( col_name [...] ); unique references other_table(col_name) not null serial integer check (col_name > 0)
Как часто рассчитывались витрины? Был ли это инкрементальный или полный расчёт?
Тебе пришла задача с номером ABC. Каков твой порядок действий в Git при начале работы?
Как будет решаться работа с рисками расхождения данных и ответственность за данные?
Ветка feature содержит несколько коммитов с неудачно закоммиченным файлом config.yaml, который позже был исправлен. В результате команда решила полностью удалить все изменения файла из истории, чтобы избежать раскрытия конфиденциальных настроек. Исходное состояние ветки (вывод git log --oneline): 1 a4b5c67 (HEAD -> feature) Refactored service logic 2 d9f0a11 Fixed config.yaml typo 3 7c1d3f2 Added temporary config.yaml 4 e3a98cd Initial commit 5 После переписывания истории, чтобы удалить файл config.yaml, вывод git log --oneline стал т 6 b9e7d42 (HEAD -> feature) Refactored service logic 7 41f3b60 Initial commit Какую операцию выполнила команда? - Выполнила git revert на коммит с config.yaml - Выполнила git filter-branch --index-filter "git rm --cached config.yaml" -- --all - Выполнила git rebase -i с удалением коммитов, содержащих изменения файла - Выполнила git commit --amend и git push --force - Выполнила git cherry-pick для создания новой ветки без config.yaml
Что для вас важно при проектировании пайплайна?
По каким полям ты дистрибьютировал данные в Greenplum?
Анализ продаж по категориям товаров в розничном магазине Вы работаете аналитиком в розничном магазине. Ваша задача — сформировать отчет о продажах по категориям товаров с расчетами: • общее количество проданных единиц в категории (total_units_sold); • суммарная выручка по категории, учитывая скидки, где скидка применяется как unit_price × units_sold × (1 − discount/100). Если скидка отсутствует (NULL), считать скидку равной 0%. Округлить до двух знаков после запятой; • среднее количество проданных единиц на одну продажу (avg_units_per_sale), округленное до двух знаков после запятой; • долю продаж без скидки (no_discount_share) — количество продаж с NULL или 0% скидкой, деленное на общее количество продаж в категории, округленную до трех знаков после запятой. Результат сначала отсортируйте по убыванию total_revenue, затем по возрастанию среднего количества единиц в продаже (avg_units_per_sale), в конце — по названию категории в алфавитном порядке. Формат ввода Таблица sales: • sale_id (int) — уникальный идентификатор продажи • product_id (int) — идентификатор товара • category (text) — категория товара • sale_date (timestamp) — дата и время продажи • units_sold (int) — количество проданных единиц • unit_price (numeric) — цена за единицу товара • discount (numeric) — скидка на товар в процентах, может быть NULL Колонка discount может содержать пропуски. Формат вывода Запрос должен вернуть таблицу с полями в таком порядке: • category (text) — категория товара • total_units_sold (int) — общее количество проданных единиц товаров в данной категории • total_revenue (numeric) — общая выручка по категории с учетом скидок, округленная до двух знаков после запятой • avg_units_per_sale (numeric) — среднее количество единиц товара в одном заказе, округленное до двух знаков после запятой • no_discount_share (numeric) — доля продаж без скидок в категории (значение от 0 до 1), округленная до трех знаков после запятой Результат сортируется сначала по убыванию total_revenue, затем по возрастанию среднего количества единиц в продаже (avg_units_per_sale), в конце — по названию категории в алфавитном порядке.