Apache Spark: RDD и DataFrame — бесплатный тест онлайн

Вопрос 1 из 30

В теме «Ленивая модель» проследите типы и порядок вычисления. Какой вывод выдерживает такую проверку?

val cleaned = spark.read.parquet("in").filter($"active" === true).select("id")
val count = cleaned.count()

Профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC. Трансформация DataFrame немедленно читает все данные и сохраняет результат до первого action. `Cache()` материализует данные сразу при вызове и поэтому не требует отдельного action. Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно. Action запускает вычисление и часто возвращает результат драйверу или записывает данные.

Вопрос 2 из 30

Какой риск остаётся после успешного запуска примера с «Ленивая модель»?

// Дополнительный контекст: Объём данных вырос, изменился план выполнения и часть вычислений прошла через `shuffle`.
val cleaned = spark.read.parquet("in").filter($"active" === true).select("id")
val count = cleaned.count()

Число разделов влияет только на оформление плана и не меняет размер задач, память исполнителей и сетевой обмен. Повторное использование DataFrame автоматически кеширует его после первого action. Побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. `Collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование.

Вопрос 3 из 30

Какой вариант чинит проблему на уровне «Ленивая модель»?

val cleaned = spark.read.parquet("in").filter($"active" === true).select("id")
val count = cleaned.count()
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью. Вызывать `collect()` для промежуточной проверки большого набора, а затем снова распределять данные. Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код. Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан. Начинать оптимизацию с увеличения `spark.sql.shuffle.partitions`, не изучая план и размеры стадий.

Вопрос 4 из 30

В контракте темы «Ленивая модель» какая формулировка учитывает и семантику конструкции, и реальный риск?

T=T_{compute}+T_{shuffle}+T_{spill}

В проектном решении сохранить утверждение «Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно» и риск «побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз». В проектном решении сохранить утверждение «action запускает вычисление и часто возвращает результат драйверу или записывает данные» и риск «простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование». В проектном решении сохранить утверждение «Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно» и риск «успешная обработка одного значения подтверждает совместимость всех вариантов модели». В проектном решении сохранить утверждение «Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно» и риск «`collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение». В проектном решении сохранить утверждение «профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC» и риск «побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз».

Вопрос 5 из 30

При проверке темы «Ленивая модель» какой итог ревью содержит и действие, и способ заметить возврат риска?

Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан. В проверке воспроизвести ситуацию: побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. В теме «Ленивая модель» исправить один показанный вызов по рекомендации «Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код». Общий контракт и прежнюю границу отдельно не воспроизводить. Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью. В проверке воспроизвести ситуацию: `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно. Ограничиться ручным запуском без автоматической регрессии. Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью. В проверке воспроизвести ситуацию: побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз.

Вопрос 6 из 30

В теме «Преобразования» какое утверждение не переносит в Scala правило из другого языка или другой конструкции?

val totals = df.groupBy("region").agg(sum("amount").as("total"))

DataFrame в Scala всегда сохраняет статический тип доменных объектов, как `Dataset[CaseClass]`. Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Action запускает вычисление и часто возвращает результат драйверу или записывает данные. Трансформация DataFrame немедленно читает все данные и сохраняет результат до первого action. Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle.

Вопрос 7 из 30

Задачу перезапустили после частичной записи результата. Какое ограничение темы «Преобразования» становится существенным?

// Дополнительный контекст: Объём данных вырос, изменился план выполнения и часть вычислений прошла через `shuffle`.
val totals = df.groupBy("region").agg(sum("amount").as("total"))

Проверка границы должна учитывать, что считать любой `map` дешёвым нельзя: пользовательская функция может сериализовать тяжёлый объект или разрушить оптимизацию DataFrame. Проверка границы должна учитывать, что `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Проверка границы должна учитывать, что побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. Проверка границы должна учитывать, что число разделов влияет только на оформление плана и не меняет размер задач, память исполнителей и сетевой обмен. Проверка границы должна учитывать, что повторное использование DataFrame автоматически кеширует его после первого action.

Вопрос 8 из 30

При исправлении темы «Преобразования» какое решение уменьшает вероятность повторения обнаруженного дефекта?

val totals = df.groupBy("region").agg(sum("amount").as("total"))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код. Начинать оптимизацию с увеличения `spark.sql.shuffle.partitions`, не изучая план и размеры стадий. Предпочитайте встроенные выражения Catalyst и проверяйте физический план перед переходом к UDF. Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью. Заменять выражения Spark SQL на UDF ради удобства, не проверяя потерю pushdown и code generation.

Вопрос 9 из 30

В контракте темы «Преобразования» новый сценарий не отменяет основное правило, но делает заметной его границу. Какой ответ это отражает?

p_i=|partition_i|

Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Пограничный сценарий: считать любой `map` дешёвым нельзя: пользовательская функция может сериализовать тяжёлый объект или разрушить оптимизацию DataFrame. Action запускает вычисление и часто возвращает результат драйверу или записывает данные. Пограничный сценарий: `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. Пограничный сценарий: побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. Пограничный сценарий: считать любой `map` дешёвым нельзя: пользовательская функция может сериализовать тяжёлый объект или разрушить оптимизацию DataFrame. Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. Пограничный сценарий: результат одного измерения можно считать устойчивой характеристикой производительности.

Вопрос 10 из 30

При проверке темы «Преобразования» что нужно оставить после исправления, кроме комментария в исходном файле?

Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. Проверить один объект и не рассматривать разделяемое состояние. Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью. В проверке воспроизвести ситуацию: считать любой `map` дешёвым нельзя: пользовательская функция может сериализовать тяжёлый объект или разрушить оптимизацию DataFrame. Предпочитайте встроенные выражения Catalyst и проверяйте физический план перед переходом к UDF. В проверке воспроизвести ситуацию: считать любой `map` дешёвым нельзя: пользовательская функция может сериализовать тяжёлый объект или разрушить оптимизацию DataFrame. Предпочитайте встроенные выражения Catalyst и проверяйте физический план перед переходом к UDF. В проверке воспроизвести ситуацию: побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. В теме «Преобразования» исправить один показанный вызов по рекомендации «Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код». Общий контракт и прежнюю границу отдельно не воспроизводить.

Вопрос 11 из 30

В теме «Действия» какой вывод о типах или выполнении прямо следует из кода?

val sample = df.orderBy(desc("amount")).limit(20).collect()

Action запускает вычисление и часто возвращает результат драйверу или записывает данные. Трансформация DataFrame немедленно читает все данные и сохраняет результат до первого action. Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно. Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. `Collect()` возвращает распределённый результат и не переносит строки в память драйвера.

Вопрос 12 из 30

Для темы «Действия» обычный пример прошёл, затем изменились условия использования. Какой риск нужно проверить первым?

// Дополнительный контекст: Небольшую таблицу перестали передавать широковещательно после обновления статистики.
val sample = df.orderBy(desc("amount")).limit(20).collect()

Побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. Простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование. `Collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Число разделов влияет только на оформление плана и не меняет размер задач, память исполнителей и сетевой обмен. UDF сохраняет все оптимизации выражения, потому что Catalyst анализирует её тело как обычные функции SQL.

Вопрос 13 из 30

При исправлении темы «Действия» команда сравнивает несколько правок. Какая из них делает допущение явным и проверяемым?

val sample = df.orderBy(desc("amount")).limit(20).collect()
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Начинать оптимизацию с увеличения `spark.sql.shuffle.partitions`, не изучая план и размеры стадий. Вызывать `collect()` для промежуточной проверки большого набора, а затем снова распределять данные. Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости. Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан. Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью.

Вопрос 14 из 30

В контракте темы «Действия» задачу перезапустили после частичной записи результата. Какой анализ пригоден для публичного API?

Оставить в контракте правило «Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно»; проверяемое ограничение — «простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование». Оставить в контракте правило «transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle»; проверяемое ограничение — «`collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение». Оставить в контракте правило «action запускает вычисление и часто возвращает результат драйверу или записывает данные»; проверяемое ограничение — «`collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение». Оставить в контракте правило «action запускает вычисление и часто возвращает результат драйверу или записывает данные»; проверяемое ограничение — «прохождение happy path исключает ошибки сериализации на старых и неполных данных». Оставить в контракте правило «action запускает вычисление и часто возвращает результат драйверу или записывает данные»; проверяемое ограничение — «побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз».

Вопрос 15 из 30

Какой критерий готовности по теме «Действия» действительно поймает повтор прежнего дефекта?

Action запускает вычисление и часто возвращает результат драйверу или записывает данные. Считать отсутствие исключения достаточным подтверждением контракта. Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан. В проверке воспроизвести ситуацию: побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан. В проверке воспроизвести ситуацию: `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. В теме «Действия» исправить один показанный вызов по рекомендации «Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости». Общий контракт и прежнюю границу отдельно не воспроизводить. Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью. В проверке воспроизвести ситуацию: `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение.

Вопрос 16 из 30

В теме «Разбиение данных» как сформулировать семантику примера так, чтобы она сохранилась после переименования переменных?

val keyed = rdd.keyBy(_.customerId)
val parts = keyed.getNumPartitions

Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC. Фильтр, записанный после пользовательской функции, гарантированно будет перенесён Catalyst внутрь любого источника. Разбиение данных определяет параллелизм и объём обмена; ключи с перекосом создают длинные straggler-задачи. Shuffle сохраняет исходное разбиение и лишь меняет порядок строк внутри каждого раздела.

Вопрос 17 из 30

Какой контрпример лучше всего проверяет обещание «Разбиение данных»?

// Дополнительный контекст: Объём данных вырос, изменился план выполнения и часть вычислений прошла через `shuffle`.
val keyed = rdd.keyBy(_.customerId)
val parts = keyed.getNumPartitions

UDF сохраняет все оптимизации выражения, потому что Catalyst анализирует её тело как обычные функции SQL. Простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование. Побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз. `Collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. `OrderBy(...).limit(n)` не требует глобальной координации и всегда выполняется локально в каждом разделе.

Вопрос 18 из 30

При исправлении темы «Разбиение данных» какой вариант не переносит проблему в вызывающий код?

val keyed = rdd.keyBy(_.customerId)
val parts = keyed.getNumPartitions
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Вызывать `collect()` для промежуточной проверки большого набора, а затем снова распределять данные. Начинать оптимизацию с увеличения `spark.sql.shuffle.partitions`, не изучая план и размеры стадий. Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition. Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код. Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости.

Вопрос 19 из 30

В контракте темы «Разбиение данных» какой вариант не теряет существенную часть технической картины?

Разбиение данных определяет параллелизм и объём обмена; ключи с перекосом создают длинные straggler-задачи. Отдельная граница — `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Разбиение данных определяет параллелизм и объём обмена; ключи с перекосом создают длинные straggler-задачи. Отдельная граница — простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование. Профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC. Отдельная граница — простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование. Разбиение данных определяет параллелизм и объём обмена; ключи с перекосом создают длинные straggler-задачи. Отдельная граница — если локальный вызов успешен, распределённые повторы и частичные отказы не меняют вывод. Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Отдельная граница — побочный эффект внутри transformation ненадёжен: задача может перезапускаться и выполнить его несколько раз.

Вопрос 20 из 30

При проверке темы «Разбиение данных» что команда должна проверять при каждом похожем изменении?

Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости. В проверке воспроизвести ситуацию: простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование. В теме «Разбиение данных» исправить один показанный вызов по рекомендации «Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан». Общий контракт и прежнюю границу отдельно не воспроизводить. Разбиение данных определяет параллелизм и объём обмена; ключи с перекосом создают длинные straggler-задачи. Проверить только маленький объём данных и не измерять рост затрат. Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition. В проверке воспроизвести ситуацию: `collect()` на большом наборе переносит все строки в память драйвера и может аварийно завершить приложение. Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition. В проверке воспроизвести ситуацию: простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование.

Вопрос 21 из 30

Во фрагменте проверяется тема «Профилирование решения». Какое правило точнее всего объясняет поведение кода?

df.explain("formatted")
println(spark.sparkContext.getConf.get("spark.sql.shuffle.partitions"))

Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно. DataFrame в Scala всегда сохраняет статический тип доменных объектов, как `Dataset[CaseClass]`. Shuffle сохраняет исходное разбиение и лишь меняет порядок строк внутри каждого раздела. Профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC.

Вопрос 22 из 30

Для темы «Профилирование решения» что остаётся обязанностью вызывающего кода или окружения?

// Дополнительный контекст: Объём данных вырос, изменился план выполнения и часть вычислений прошла через `shuffle`.
df.explain("formatted")
println(spark.sparkContext.getConf.get("spark.sql.shuffle.partitions"))

Сравнение только количества строк достаточно, чтобы доказать эквивалентность старого и нового запроса. Оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место. Переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Broadcast join безопасен при любом размере правой таблицы: Spark сам отменит передачу до нехватки памяти. Простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование.

Вопрос 23 из 30

При исправлении темы «Профилирование решения» что следует изменить, чтобы следующий рефакторинг не вернул тот же риск?

df.explain("formatted")
println(spark.sparkContext.getConf.get("spark.sql.shuffle.partitions"))
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости. Вызывать `collect()` для промежуточной проверки большого набора, а затем снова распределять данные. Начинать оптимизацию с увеличения `spark.sql.shuffle.partitions`, не изучая план и размеры стадий. Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код. Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition.

Вопрос 24 из 30

В контракте темы «Профилирование решения» что следует оставить в проектном решении после этого изменения контекста?

Оставить в контракте правило «профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC»; проверяемое ограничение — «оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место». Оставить в контракте правило «профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC»; проверяемое ограничение — «одного примера достаточно, чтобы подтвердить законы абстракции и отсутствие побочных эффектов». Оставить в контракте правило «профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC»; проверяемое ограничение — «переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана». Оставить в контракте правило «transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle»; проверяемое ограничение — «простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование». Оставить в контракте правило «Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно»; проверяемое ограничение — «оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место».

Вопрос 25 из 30

При проверке темы «Профилирование решения» какой итог можно проверить автоматически или воспроизводимым примером?

Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код. В проверке воспроизвести ситуацию: оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место. Сначала найдите самый дорогой stage и причину: skew, shuffle, сериализация, I/O или GC; только затем меняйте код. В проверке воспроизвести ситуацию: переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition. В проверке воспроизвести ситуацию: оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место. Профилирование Spark начинается с DAG, stage/task metrics, shuffle read/write, spill и времени GC. Оставить тест без старой версии данных и неизвестных полей. В теме «Профилирование решения» исправить один показанный вызов по рекомендации «Оставляйте transformations чистыми, а внешнюю запись делайте через поддерживаемый sink с идемпотентностью». Общий контракт и прежнюю границу отдельно не воспроизводить.

Вопрос 26 из 30

В теме «Архитектурные компромиссы» что в этом примере определяется семантикой Scala, а не соглашением автора?

val df2 = df.filter(col("year") >= 2025).select("id", "score")

Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Фильтр, записанный после пользовательской функции, гарантированно будет перенесён Catalyst внутрь любого источника. DataFrame в Scala всегда сохраняет статический тип доменных объектов, как `Dataset[CaseClass]`. Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно. Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle.

Вопрос 27 из 30

Для темы «Архитектурные компромиссы» после переноса кода в общий модуль проявилось скрытое допущение. Какое?

// Дополнительный контекст: Задачу перезапустили после частичной записи результата.
val df2 = df.filter(col("year") >= 2025).select("id", "score")

Переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место. Число разделов влияет только на оформление плана и не меняет размер задач, память исполнителей и сетевой обмен. UDF сохраняет все оптимизации выражения, потому что Catalyst анализирует её тело как обычные функции SQL. Простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование.

Вопрос 28 из 30

Какую правку по теме «Архитектурные компромиссы» разумно объединить?

val df2 = df.filter(col("year") >= 2025).select("id", "score")
// На ревью требуется устранить причину дефекта, не скрывая её приведением типа или значением по умолчанию.

Вызывать `collect()` для промежуточной проверки большого набора, а затем снова распределять данные. Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости. Кешировать каждый DataFrame сразу после создания и не вызывать `unpersist`. Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition. Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан.

Вопрос 29 из 30

В контракте темы «Архитектурные компромиссы» задачу перезапустили после частичной записи результата. Какой вывод одновременно сохраняет правило и учитывает его границу?

Transformation создаёт новый RDD/DataFrame, не возвращая данные драйверу; узкие и широкие преобразования различаются потребностью в shuffle. Пограничный сценарий: переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Spark строит ленивый план преобразований и выполняет его только при action; одна и та же ветка без cache может вычисляться повторно. Пограничный сценарий: простое увеличение числа partitions не устраняет skew и может добавить накладные расходы на планирование. Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Пограничный сценарий: переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Пограничный сценарий: успешная сборка гарантирует бинарную и исходную совместимость опубликованного API. Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Пограничный сценарий: оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место.

Вопрос 30 из 30

При проверке темы «Архитектурные компромиссы» как сформулировать защиту от регрессии без расплывчатого «работает как раньше»?

Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости. В проверке воспроизвести ситуацию: оптимизация по строкам исходного Scala-кода без просмотра Spark UI часто лечит не то узкое место. Используйте `limit`, агрегаты, распределённую запись или `take` для диагностики; объём перед collect должен быть доказан. В проверке воспроизвести ситуацию: переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Оставайтесь в DataFrame/Dataset, пока задача выражается декларативно; уходите в RDD только при измеренной необходимости. В проверке воспроизвести ситуацию: переход на RDD ради привычной функции может лишить систему predicate pushdown и оптимизации плана. Архитектурный компромисс между RDD и DataFrame: RDD даёт низкоуровневый контроль, DataFrame — схему и оптимизацию Catalyst. Проверить локальный успех, не моделируя частичный отказ внешнего сервиса. В теме «Архитектурные компромиссы» исправить один показанный вызов по рекомендации «Измерьте распределение ключей, примените salting или отдельную обработку горячих ключей и настройте размер partition». Общий контракт и прежнюю границу отдельно не воспроизводить.