Не поддавайтесь на «первый» и «последний» обман Apache Spark, это будет стоить вам денег!
Изучение «первого» и «последнего» методов Apache Spark: понимание их подводных камней и предложение более надежного подхода
1. Введение
В очередной раз столкнулся со знакомой всем ошибкой. Это было похоже на старого врага, который снова и снова всплывал на поверхность, заставая ничего не подозревающих программистов врасплох. Столкнувшись с этим несколько раз, я решил, что пришло время выдвинуть эту проблему на передний план и привлечь к ней внимание. Виновники? «Первый» и «последний» методы в Apache Spark.
2. Понимание «первого» и «последнего» в Spark
В Apache Spark «первый» и «последний» используются для извлечения первого и последнего элемента из группы в кадре данных. Это кажется простым, не так ли? Однако реальность далека от этого. Путаница заключается в том, как Spark обрабатывает данные, распределенные по разным разделам.
3. Проблема с «первым» и «последним»
Вот в чем загвоздка: «первый» и «последний» на самом деле не представляют первый и последний элементы группы. Вместо этого они указывают на первую и последнюю точки данных из произвольного раздела, который Spark выбирает для обработки. Именно эта непредсказуемость делает эти методы проблематичными. Они могут не обязательно каждый раз возвращать одни и те же результаты, особенно когда данные перемешиваются или секции обрабатываются в другом порядке. Названия в некотором роде вводят в заблуждение, потому что «первый» не всегда является истинным первым, а «последний» не всегда истинным последним.
4. В центре внимания сценарий
В одном случае «последнее» использовалось для отслеживания последнего действия, которое пользователь выполнил в приложении, с данными, сгруппированными по идентификатору пользователя. Вот пример того, как это было реализовано:
val df = spark.read.schema(schema).json(events)
val grouped = df.groupBy("userId")
val lastAction = grouped.agg(last("action"))
lastAction.show()
Однако возвращаемое действие не было истинным последним действием, что приводило к неправильному пониманию поведения пользователя. Произвольный характер «последнего» может вызвать значительную путаницу в понимании действий пользователя в приложении.
5. Предлагаемый подход: «любой» метод
Итак, какой подход лучше? Подумайте об использовании слова «любой». «Любой» — это метод, который, как и «первый» и «последний», возвращает элемент из группы. Тем не менее, это честно о своей случайности. В нем четко указано, что он вернет любое произвольное значение из группы, избегая ложных впечатлений.
«Любой» — более надежный выбор. Это не создает иллюзии детерминированности, как «первый» или «последний», что снижает вероятность ошибок.
6. Советы, как избежать «первой» и «последней» ловушки
Чтобы не попасть в ловушку «первого» и «последнего», очень важно знать об этой проблеме. Вам нужно перестать использовать «первый» и «последний» навсегда! Даже если вы понимаете их природу и считаете, что вас устраивает их недетерминированное поведение, все равно сопротивляйтесь их использованию. Потому что в один прекрасный день вы можете забыть об этом фрагменте кода или уйти из компании, оставив код для поддержки или модификации кем-то другим.
Добавление «первого» или «последнего» в картину может привести к множеству неопределенностей, особенно когда в ту же область добавляется новый код. Потенциально это может привести к многочисленным последствиям, некоторые из которых благоприятны, но многие вредны. Участие «первого» и «последнего» в коде может привести к созданию новых ошибок, усилению существующих или даже к пустой трате времени на разработку, как это было в нашем опыте.
Например, один из моих разработчиков думал, что нашел ошибку с «first». Учитывая нашу настороженность в отношении «первого», он потратил три дня на рефакторинг кода, чтобы сделать его «правильным», только для того, чтобы обнаружить, что исходный код на самом деле был разработан с учетом недетерминированного характера «первого». Сложность кода и паранойя, вызванная наличием «первого», привели к значительной потере времени на рефакторинг, который в итоге не потребовался.
В конце концов мы отказались от этого рефакторинга, поняв, что погоня за реальным «первым» элементом может иметь серьезные последствия для производительности. Вместо этого мы решили заменить «первый» на «любой», чтобы не наткнуться на эту ловушку в будущем.
Поэтому всегда будьте бдительны. Проверьте свой код и замените «первый» и «последний» на «любой», когда имеете дело с распределенными данными в Spark. Не забывайте всегда проверять результаты обработки ваших данных, чтобы обеспечить их точность.
7. Заключение
В заключение, хотя «первый» и «последний» могут показаться удобными методами для использования в Apache Spark, они могут привести к непредсказуемым и вводящим в заблуждение результатам из-за свойственного им поведения с распределенными данными. Пришло время пролить свет на этот вопрос и поощрять использование «любого», более честного и надежного метода. Давайте поделимся этими знаниями и улучшим наши методы кодирования для лучшей и более точной обработки данных в Apache Spark.
