сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · Spark и большие данные

Вопросы по Spark на собеседовании

Spark спрашивают у дата-инженеров и дата-сайентистов, работающих с большими объёмами. Ключевой вопрос почти всегда про шафл: откуда он берётся, сколько стоит и как его избежать.

109 вопросов в банке·9 подтем·ниже разбор 9

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

Примеры вопросов с разбором

  1. #file_formats_storage1 / 9
    Чем колоночный формат (Parquet) выгоднее строкового (CSV) для аналитики?
    A)Обычный текстовый CSV читается заметно быстрее Parquet при аналитике по нескольким колонкам
    B)Parquet и CSV — близкие форматы, отличаются лишь расширением файла
    C)Строковый формат позволяет читать одну колонку, не трогая остальные данные
    D)Parquet колоночный: читает нужные колонки и жмёт лучше, чем CSV
    показать ответ и разбор
    +D)Parquet колоночный: читает нужные колонки и жмёт лучше, чем CSV

    // разбор: Parquet хранит данные по колонкам: запрос читает только нужные столбцы, а не всю строку, и жмёт каждую колонку эффективнее (однотипные значения рядом). Плюс он несёт схему и статистику для предикат-пушдауна. CSV строковый — читать одну колонку без остальных нельзя, сжатие хуже, схемы нет.

  2. #hadoop_lakehouse2 / 9
    Что такое HDFS и как он хранит большой файл?
    A)HDFS хранит файл целиком на одном узле, копируя его на соседний как резервную копию
    B)HDFS — это реляционная СУБД, хранящая данные строками в таблицах с поддержкой SQL-запросов
    C)Распределённая ФС: файл режется на крупные блоки, разложенные по DataNode-узлам кластера, — так хранят объёмы больше одного диска
    D)HDFS оптимизирован под частые мелкие случайные обновления отдельных байтов внутри файлов
    показать ответ и разбор
    +C)Распределённая ФС: файл режется на крупные блоки, разложенные по DataNode-узлам кластера, — так хранят объёмы больше одного диска

    // разбор: HDFS (Hadoop Distributed File System) хранит файлы, которые не влезают на один сервер: файл делится на крупные блоки (обычно 128 МБ), и блоки распределяются по множеству узлов-DataNode. Метаданные (какой файл из каких блоков и где они лежат) держит NameNode. Так достигается и объём (суммарная ёмкость кластера), и параллелизм чтения (разные блоки читаются с разных узлов одновременно), и отказоустойчивость (каждый блок реплицирован). HDFS оптимизирован под большие последовательные чтения/записи, а не под мелкие случайные правки.

  3. #spark_core3 / 9
    Что такое RDD/DataFrame в Spark на концептуальном уровне?
    A)Распределённая коллекция данных, разбитая на партиции по узлам кластера
    B)Одна таблица, целиком помещающаяся в память одного драйвера
    C)Формат сжатия файлов на диске для колоночного хранения
    D)Специальный планировщик задач, распределяющий всю работу по воркерам кластера
    показать ответ и разбор
    +A)Распределённая коллекция данных, разбитая на партиции по узлам кластера

    // разбор: DataFrame/RDD — абстракция распределённого набора данных: он разбит на партиции, лежащие на разных узлах, и обрабатывается параллельно. Именно поэтому Spark тянет данные больше памяти одной машины. DataFrame поверх RDD добавляет схему и оптимизатор Catalyst, поэтому его предпочитают низкоуровневому RDD.

  4. #spark_optimization4 / 9
    Что такое партиция в Spark?
    A)Логический кусок данных — единица параллелизма, считается одной задачей
    B)Отдельный физический сервер или узел в распределённом вычислительном кластере Spark
    C)Копия всего датасета, продублированная для отказоустойчивости системы
    D)Индекс, ускоряющий точечный поиск строки по ключу в датасете
    показать ответ и разбор
    +A)Логический кусок данных — единица параллелизма, считается одной задачей

    // разбор: Партиция — логический фрагмент данных, обрабатываемый одной задачей на одном ядре; число партиций задаёт степень параллелизма. Слишком мало — кластер недозагружен и задачи огромны; слишком много — накладные расходы на планирование задач съедают выигрыш. Тюнинг числа партиций — базовый рычаг производительности.

  5. #spark_data_pull5 / 9
    Таблица событий партиционирована по дате и хранит 3 года. Тебе нужен один месяц. Как читать, чтобы Spark не поднимал все 3 года?
    A)Наложить фильтр по колонке-партиции (дате) прямо при чтении — сработает partition pruning, и лишние партиции не прочитаются
    B)Прочитать всё в DataFrame, а потом отфильтровать нужный месяц — Spark всё равно сам выкинет лишнее, и в объёме чтения не будет никакой разницы
    C)Считать все 3 года сразу в pandas и там взять срез по нужному месяцу привычным способом
    D)Никак: Spark читает таблицу целиком, партиции на объём чтения не влияют
    показать ответ и разбор
    +A)Наложить фильтр по колонке-партиции (дате) прямо при чтении — сработает partition pruning, и лишние партиции не прочитаются

    // разбор: Фильтр по колонке партиционирования во время чтения включает partition pruning — Spark физически пропускает каталоги/файлы других дат. Фильтр «после чтения» помогает меньше: часть данных уже прочитана с диска. Читай сразу с условием по партиции.

  6. #spark_dataframe_ops6 / 9
    Нужно добавить в DataFrame новую фичу как выражение от существующих колонок. Чем это делают в Spark?
    A)df.withColumn(имя, выражение) возвращает новый DataFrame с добавленной колонкой
    B)Прямым присваиванием df["имя"] =..., как в pandas, — оно меняет df на месте
    C)Только через сырой SQL, из DataFrame API колонки не добавить
    D)Через collect(), правку получившегося списка в Python и обратную сборку в DataFrame из строк
    показать ответ и разбор
    +A)df.withColumn(имя, выражение) возвращает новый DataFrame с добавленной колонкой

    // разбор: В Spark DataFrame неизменяем: withColumn(имя, выражение) не меняет исходный, а возвращает новый DataFrame с добавленной или переопределённой колонкой. Выражение строят из функций pyspark.sql.functions (col, when, арифметика) — оно ленивое и войдёт в общий план. Присваивание df["x"]=... в стиле pandas тут не работает: объект неизменяем, а операции возвращают новые DataFrame.

  7. #spark_lazy7 / 9
    Ты написал цепочку filter().select().join(), запустил ячейку — она вернулась мгновенно. Значит, данные уже обработаны?
    A)Да: раз ячейка отработала без единой ошибки, Spark уже материализовал результат, и дальнейшее обращение к нему будет мгновенным
    B)Нет: это ленивые трансформации, они лишь строят план; работа запустится только на действии (count/collect/write)
    C)Да, но только потому, что в цепочке был join — именно он заставляет Spark посчитать всё сразу
    D)Нет: цепочка вообще не сохранилась, её нужно переписать одной строкой без точек
    показать ответ и разбор
    +B)Нет: это ленивые трансформации, они лишь строят план; работа запустится только на действии (count/collect/write)

    // разбор: Трансформации (filter/select/join) ленивые — Spark лишь достраивает план вычислений. Реальное чтение и счёт запускаются только на действии: count, collect, show, write. Мгновенный возврат ячейки ≠ данные посчитаны.

  8. #spark_ml_features8 / 9
    MLlib-модель ждёт на входе один столбец-вектор признаков, а у тебя признаки в разных колонках. Чем их собрать?
    A)VectorAssembler собирает перечисленные колонки в один столбец-вектор features для MLlib
    B)Обычным concat строк по колонкам
    C)GroupBy по всем колонкам сразу
    D)MLlib-оценщики принимают исходные отдельные колонки, поэтому собирать их во что-то не требуется
    показать ответ и разбор
    +A)VectorAssembler собирает перечисленные колонки в один столбец-вектор features для MLlib

    // разбор: Оценщики Spark ML (LogisticRegression, RandomForest и т.д.) работают с одним векторным столбцом признаков. VectorAssembler(inputCols=[...], outputCol="features") склеивает числовые/индексированные колонки в единый вектор. Обычно это последний трансформер в Pipeline перед моделью. Категориальные колонки перед этим переводят в числа (StringIndexer/OneHotEncoder), иначе в вектор их не собрать.

  9. #spark_when9 / 9
    Датасет 200 МБ спокойно влезает в память ноутбука. Коллега советует «бери Spark, он же для данных». Что разумнее?
    A)Остаться на pandas: на данных, влезающих в RAM, оверхед планировщика и координации кластера Spark только замедлит работу
    B)Обязательно взять Spark: pandas не годится для серьёзной аналитики и уже на сотнях мегабайт начинает терять точность вычислений
    C)Взять Spark про запас — данные же вырастут, а переписывать пайплайн потом дороже, чем заложить кластер сразу
    D)Без разницы: на объёме данных оба инструмента дают примерно одинаковую скорость
    показать ответ и разбор
    +A)Остаться на pandas: на данных, влезающих в RAM, оверхед планировщика и координации кластера Spark только замедлит работу

    // разбор: Spark окупается, когда данные не влезают в память одной машины или уже лежат распределённо. На 200 МБ pandas проще, быстрее и без накладных расходов на кластер. «Про запас» — преждевременное усложнение: заведёшь Spark, когда реально упрёшься в память.

это 9 из 109

Ещё 100 вопросов по теме — в тренажёре, с движком повторения

Прочитать разбор и ответить самому — разные навыки. В Сеньорчике вопросы идут сессиями, а движок возвращает подтемы, где вы ошибаетесь, пока они не начнут отскакивать. Бесплатно, лимит по энергии.

Открыть тренажёрДругие темы

Частые вопросы

куда дальше