Подготовка к собеседованию — Дата-инженер

Короткий ответ: SELECT извлекает строки из таблиц. Логический порядок выполнения НЕ совпадает с порядком написания: сначала FROM, затем WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, LIMIT.

Подробно:

Порядок написания (синтаксический):

SELECT   DISTINCT col1, agg(col2)
FROM     t
WHERE    cond
GROUP BY col1
HAVING   agg_cond
ORDER BY col1
LIMIT    10 OFFSET 20;

Логический порядок исполнения:

1. FROM / JOIN      -- какие таблицы, как соединить
2. WHERE            -- фильтр строк ДО группировки
3. GROUP BY         -- группировка
4. HAVING           -- фильтр групп ПОСЛЕ агрегации
5. SELECT           -- вычисление выражений, алиасов
6. DISTINCT         -- удаление дублей
7. ORDER BY         -- сортировка
8. LIMIT / OFFSET   -- срез

⚠️ Ловушка: алиас из SELECT нельзя использовать в WHERE (т.к. WHERE выполняется раньше SELECT), но можно в ORDER BY и часто в GROUP BY (зависит от СУБД). Пример ошибки:

SELECT salary * 12 AS annual FROM emp WHERE annual > 100000; -- ОШИБКА
SELECT salary * 12 AS annual FROM emp ORDER BY annual;        -- ОК

Короткий ответ: OLTP обслуживает короткие транзакции — вставку и обновление отдельных строк с низкой задержкой, а OLAP отвечает на аналитические запросы, сканирующие миллионы строк. Построчное хранение типично для OLTP, колоночное — для OLAP; это категории нагрузки, а не обязательные форматы хранения. Тяжёлую аналитику не гоняют на боевой OLTP-базе, потому что она конкурирует за ресурсы с транзакциями и роняет latency продакшена.

Подробно:

1. Профиль нагрузки — OLTP: много мелких операций (INSERT/UPDATE по первичному ключу); OLAP: мало тяжёлых запросов с GROUP BY и агрегациями.
2. Модель хранения — построчное хранение читает всю строку целиком (удобно для транзакций), колоночное читает только нужные столбцы и лучше сжимается (удобно для аналитики).
3. Нормализация — OLTP часто использует нормализацию для целостности записи, OLAP — размерные или денормализованные модели для анализа. Бывают гибридные решения.
4. Изоляция ресурсов — аналитический скан забивает буферный кэш и диск, из-за чего транзакции начинают ждать.

Критерий	OLTP	OLAP
Задача	транзакции	аналитика
Операции	чтение/запись строк	агрегации по колонкам
Типичное хранение	построчное	колоночное
Частая модель	нормализованная	размерная/звезда
Метрика	latency, TPS	throughput скана

⚠️ Частая ошибка: гонять отчётность прямо по продакшен-базе. Данные выгружают в отдельное хранилище (ETL/ELT), чтобы аналитика не мешала транзакциям.

Короткий ответ: ETL трансформирует данные до загрузки (на отдельном движке), ELT сначала грузит сырые данные в хранилище, а трансформации выполняет уже внутри него на SQL. ELT стал стандартом, потому что облачные MPP-хранилища (Snowflake, BigQuery, Redshift) дёшево масштабируют вычисления и разделяют storage/compute.

Подробно:

1. ETL — трансформация на промежуточном движке (раньше — дорогие ETL-серверы). В хранилище попадают только готовые, «чистые» данные. Минус: логика заперта в инструменте, а сырьё теряется.
2. ELT — грузим сырой слой как есть, трансформируем через dbt/SQL. Плюс: сырьё сохраняется, трансформации версионируются в Git, масштабирование берёт на себя хранилище.
3. Почему ELT победил — разделение storage/compute сделало вычисления в хранилище дешёвыми и эластичными; аналитику стало удобнее держать в SQL.

Критерий	ETL	ELT
Где трансформация	На отдельном движке	Внутри хранилища
Сырой слой	Обычно теряется	Сохраняется
Масштабирование	Ограничено движком	Эластичное (MPP)
Типичный стек	Informatica, SSIS	Fivetran + dbt + Snowflake

Когда ETL всё ещё нужен: тяжёлые преобразования до попадания в хранилище, маскирование PII/комплаенс (нельзя грузить сырьё), или источник, который проще привести к схеме на лету.

⚠️ Частая ошибка: думать, что ELT — это «без трансформаций». Трансформации никуда не делись, они просто переехали в хранилище и выполняются после загрузки.

Короткий ответ: В строковом формате значения одной записи лежат рядом, в колоночном — рядом лежат все значения одной колонки. Для аналитических запросов (агрегаты по нескольким колонкам из десятков) колоночный формат читает только нужные колонки, лучше сжимается и поддерживает предикатный пушдаун — отсюда меньше I/O и ниже стоимость.

Подробно:

1. Проекция колонок (projection pushdown) — запросу нужны 3 колонки из 50, и колоночный движок читает с диска только эти три. Строковый формат вынужден прочитать строку целиком.
2. Сжатие — в колонке лежат однотипные значения (один тип, похожие данные), поэтому dictionary-, run-length- и delta-кодирование дают степень сжатия в разы выше, чем на разнородной строке.
3. Предикатный пушдаун (predicate pushdown) — по хранимым min/max статистикам блока фильтр WHERE date = ... пропускает целые блоки, не читая их.
4. Строковый формат выигрывает при точечных операциях: прочитать/записать запись целиком (OLTP, стриминг по одной записи).

Строковый (row):   [id=1,name=A,ts=..][id=2,name=B,ts=..][id=3,...]
                    └── запись 1 ──┘└── запись 2 ──┘

Колоночный (columnar):
  id:   [1, 2, 3, ...]        ← читаем только нужные
  name: [A, B, C, ...]           колонки, каждая
  ts:   [.., .., .., ...]        сжата отдельно

⚠️ Частая ошибка: считать колоночный формат universally лучшим. Для построчной записи и чтения записи целиком (стриминг, транзакционные апдейты) строковый формат (Avro) эффективнее.

Короткий ответ: Драйвер строит план и координирует выполнение, cluster manager (YARN, Kubernetes, Standalone) выделяет ресурсы, а экзекьюторы на воркерах выполняют задачи и хранят данные в памяти. Каждый экшен запускает job, который планировщик режет на стадии по границам шафла, а стадию — на задачи по числу партиций.

Подробно:

1. Драйвер — процесс с вашим кодом и SparkSession. Строит логический и физический план, DAG стадий, планирует задачи и собирает результаты. Падение драйвера убивает всё приложение.
2. Cluster manager — договаривается о ресурсах: сколько экзекьюторов, сколько ядер и памяти на каждый. Сам вычислениями не занимается.
3. Экзекьюторы — JVM-процессы на воркерах. Выполняют задачи, кэшируют партиции, отдают данные через shuffle. Живут всё время работы приложения.
4. Иерархия работы — Job (на каждый экшен) → Stage (границы по шафлу) → Task (одна задача на одну партицию, минимальная единица параллелизма).

            ┌──────────────┐
            │   Драйвер    │  план + DAG + планировщик
            │ SparkSession │
            └──────┬───────┘
                   │ запрос ресурсов
            ┌──────▼───────┐
            │Cluster Manager│  YARN / K8s / Standalone
            └──────┬───────┘
        ┌──────────┼──────────┐
   ┌────▼────┐ ┌───▼────┐ ┌───▼────┐
   │Экзекьютор│ │Экзекьютор│ │Экзекьютор│  задачи + кэш
   └─────────┘ └────────┘ └────────┘

⚠️ Частая ошибка: путать ядра экзекьютора с задачами — параллелизм ограничен число экзекьюторов × ядер, и если партиций меньше, чем слотов, часть ядер простаивает.