DataFrame API для фич

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 14, остальные разбираются в тренажёре.

1. #spark_dataframe_ops1 / 5
   Нужны сразу несколько агрегатов по группам (сумма, среднее, число). Как их посчитать за один проход?

   A)Отдельным groupBy на каждый агрегат с последующим join всех результатов по ключу группировки

   B)groupBy(ключ).agg(sum, avg, count) — несколько агрегатов считаются за один проход

   C)Собрать данные на драйвер и посчитать в цикле Python

   D)Агрегаты в Spark считаются только по одному за вызов

   показать ответ и разбор

   +B)groupBy(ключ).agg(sum, avg, count) — несколько агрегатов считаются за один проход

   // разбор: groupBy(...).agg(...) принимает сразу несколько агрегатных выражений (sum, avg, count, min/max, approx_count_distinct) — Spark посчитает их одним проходом с общим shuffle по ключу. Дробить на несколько groupBy и джойнить результаты дороже: лишние проходы и перемешивания. Для DS это стандартный способ собрать признаки по сущности (юзеру, товару) в одну строку.

2. #spark_dataframe_ops2 / 5
   К событиям нужно приклеить профиль пользователя, но сохранить события даже без совпавшего профиля. Какой join?

   A)Inner join — он сохранит все события, а профиль просто подставит там, где он есть в справочнике

   B)Cross join по ключу

   C)left outer join событий с профилями: события сохраняются, профиль где есть, иначе null

   D)Left anti join профилей

   показать ответ и разбор

   +C)left outer join событий с профилями: события сохраняются, профиль где есть, иначе null

   // разбор: Чтобы не потерять ни одного события, левой таблицей берут события и делают left outer join с профилями по ключу пользователя: все события остаются, а поля профиля заполняются, где нашлось совпадение, иначе null. inner отбросил бы события без профиля; anti — наоборот, оставил бы только без совпадения. Выбор типа join определяется тем, чьи строки обязаны сохраниться.

3. #spark_dataframe_ops3 / 5
   Для фичи нужно к каждому событию добавить «предыдущую покупку этого пользователя». Какой инструмент Spark?

   A)Обычный groupBy — он и даёт доступ к соседним строкам

   B)Оконная функция Window.partitionBy(user).orderBy(time) + lag даёт предыдущую строку

   C)Collect() и обход в Python-цикле по времени

   D)Джойном таблицы самой с собой по паре (user, time+1), чтобы подтянуть соседнюю по времени строку

   показать ответ и разбор

   +B)Оконная функция Window.partitionBy(user).orderBy(time) + lag даёт предыдущую строку

   // разбор: Оконные функции считают значения относительно упорядоченного окна, НЕ схлопывая строки (в отличие от groupBy). Определяют окно Window.partitionBy(user).orderBy(time), затем lag(col, 1) достаёт предыдущее значение, lead — следующее, rank/row_number — позицию, а rolling-суммы — по рамке (rowsBetween). Это рабочая лошадка фиче-инжиниринга по последовательностям (сессии, история покупок).

4. #spark_dataframe_ops4 / 5
   Нужна категориальная фича по правилу «если возраст < 18 → 'junior', иначе 'adult'». Как выразить это в Spark без UDF?

   A)when(col<18,'junior').otherwise('adult') внутри withColumn — встроенное условие

   B)Обычный питоновский if прямо в withColumn

   C)Только через пользовательскую функцию: встроенных условных выражений над колонками в Spark нет

   D)Через фильтр df.filter, он и создаст колонку

   показать ответ и разбор

   +A)when(col<18,'junior').otherwise('adult') внутри withColumn — встроенное условие

   // разбор: Условные фичи строят встроенным выражением when(...).otherwise(...) из pyspark.sql.functions — оно компилируется в план и выполняется движком на исполнителях, без выхода в Python. Питоновский if в withColumn выполнится один раз на драйвере при построении плана, а не по строкам. UDF решил бы задачу, но медленнее (сериализация Python↔JVM), поэтому для простых условий предпочитают when/otherwise.

5. #spark_dataframe_ops5 / 5
   Почему пользовательскую функцию (обычный Python UDF) в Spark стараются заменить встроенными функциями, когда это возможно?

   A)UDF в Spark вообще запрещены

   B)Python UDF гонит строки между JVM и Python и непрозрачен Catalyst; спасает pandas UDF

   C)UDF занимают слишком много места на диске

   D)UDF выполняются исключительно на драйвере, поэтому не задействуют исполнители и оттого медленны

   показать ответ и разбор

   +B)Python UDF гонит строки между JVM и Python и непрозрачен Catalyst; спасает pandas UDF

   // разбор: Обычный Python UDF для каждой строки сериализует данные из JVM в Python-процесс исполнителя и обратно, а для Catalyst остаётся непрозрачным — оптимизации (pushdown, перестановка) через него не проходят. Отсюда ощутимое замедление. Встроенные функции выполняются в JVM и оптимизируются. Если Python-логика необходима, берут pandas UDF (векторизованный, через Apache Arrow, обрабатывает батчи), который заметно быстрее построчного.