Тестирование искры: стоит ли? (Лучшие практики) - PullRequest
0 голосов
/ 29 августа 2018

Используя Apache Spark, мне стало интересно, действительно ли это ценный производственный тест и на каком уровне.

Чтение Искра: полное руководство они предлагают:

Бизнес-логика в ваших конвейерах, скорее всего, изменится, так же как и входные данные. Что еще более важно, вы хотите быть уверены, что то, что вы выводите из необработанных данных, - это то, что вы на самом деле думаете, что выводите. Это означает, что вам необходимо провести надежное логическое тестирование с реалистичными данными, чтобы убедиться, что вы действительно получаете то, что хотите от него.

Что предлагает ввести какое-то тестирование.

Но что меня впечатляет:

Здесь следует с осторожностью написать несколько «модульных тестов Spark», которые просто проверяют функциональность Spark. Вы не хотите этим заниматься; вместо этого вы хотите проверить свою бизнес-логику и убедиться, что созданный вами сложный бизнес-конвейер действительно выполняет то, что, по вашему мнению, должно быть.

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

Вероятно, стоит проверить логику преобразования данных, примененного через Spark.

Снова из книги:

Во-первых, вы можете сохранить пустое место, например, интерактивный блокнот или какой-то аналог, а затем, когда вы создаете ключевые компоненты и алгоритмы, вы перемещаете их в более постоянное место, например, в библиотеку или пакет. Опыт работы с ноутбуком мы часто рекомендуем (и используем для написания этой книги) из-за его простоты в экспериментах

Что предлагает проверить вашу логику преобразования данных в интерактивной среде, такой как ноутбуки (например, Jupyter Notebooks для Pyspark). По сути, вы непосредственно видите, что производят преобразования.

Итак, я спрашиваю людей с большим опытом, чем я, согласны ли вы с цитируемыми пунктами из книги? (или я неправильно истолковываю) Могут ли они использоваться в качестве своего рода Best Practices в этой области? (например, избегать юнит-тестов, вместо этого предлагая более высокоуровневые тесты, такие как логические / интеграционные тесты)

1 Ответ

0 голосов
/ 29 августа 2018

В заявлении не сказано, чтобы избежать модульных тестов. Это говорит о том, что следует избегать тестовых данных, которые не представляют никакой ценности для бизнеса, в противном случае вы в конечном итоге будете тестировать API-интерфейс spark, а не свой бизнес-компонент. Например, вы написали функцию в spark UDF для выполнения агрегации, поэтому при написании модульных тестов убедитесь, что ваша функция передает реальные данные, которые будут имитировать производственную среду.

С ноутбуком вроде Zeepline вы можете иметь все этапы в одном месте, такие как прием данных, визуализация. Это действительно интерактивно с конвейерами данных

...