Англійська для розробників Apache Spark
Словник для розробників, які працюють з Apache Spark — RDDs, DataFrames, executors, shuffles і lazy evaluation — для команд, які обговорюють розподілену обробку даних англійською мовою.
Apache Spark розподіляє обробку даних між кластером машин, і більшість нерозумінь у розмовах Spark виникають через помилкове поєднання логічного плану (те, що ви запитали) з фізичним виконанням (що насправді виконується і наскільки повільно). Правильне вивчення словника дозволяє вам діагностувати « чому ця робота повільна », замість того, щоб просто перезапускати її і сподіватися.
Основні абстракції
** RDD (Resilient Distributed Dataset) ** — оригінальна низькорівнева абстракція Spark: незмінна, розділена на розділи збірка даних, розкиданих по кластеру, з графіком послідовності, який дозволяє Spark перерахувати втрачені розділи після аварії.
- “Ми перейшли до RDD API, оскільки оптимізатор DataFrame постійно сплющував перетворення, яке нам потрібно було контролювати вручну.” *
DataFrame — абстракція вищого рівня, що відчуває схему, побудована на вершині RDD, схожа на таблицю, яка дозволяє оптимізатору Spark розглядати стовпці і типи замість непрозорих об’єктів.
- “Переключити цей параметр з RDD на DataFrames — оптимізатор Catalyst може насправді знизити рівень фільтра перед з’ єднанням, якщо він знає схему.” *
** Розділ ** — частина набору даних, яка знаходиться на одному виконавчому пристрої і обробляється незалежно; одиниця паралельності у Spark.
“У нас 200 розділів, але лише 20 ядер, тому більшість паралельності витрачається на очікування в черзі.”
Модель виконання
** Ліньова оцінка ** — Spark створює ланцюг перетворень без запуску чого- небудь, доки дія (наприклад, collect або write ) не викликає виконання, що дозволяє йому оптимізувати весь план перед його запуском.
“Ніщо не виконується доки ви не викликаєте
.write()— все до цього просто будує логічний план.”
** Перестановка ** — дорога операція перерозподілу даних між розділами (і по всій мережі) так, щоб записи з однаковим ключем опинилися на одному і тому ж виконавчому пристрої, необхідна для з’ єднань, групових переходів і перерозподілів.
“Це з’ єднання викликає повне перетасовування — 40 ГБ пересуваються по мережі, тому цей етап займає десять хвилин.”
** Драйвер проти виконавця ** — драйвер — це єдиний процес, який координує виконання завдання і веде логічний план; виконавці — це робочі процеси, які фактично виконують завдання на розділах даних.
“OOM знаходиться на драйвері, а не на виконавцях — ми викликаємо
.collect()і витягуємо весь набір даних назад в один процес.”
** Етап ** — набір завдань, які можна виконувати без межі перетасовування; Spark розбиває завдання на етапи, коли потрібне перетасовування.
- “Це завдання має три етапи — перетасування після групування розділяє його на другий і третій етапи.” *
Виконання і зневадження
** Скос (скос даних) ** — нерівномірний розподіл даних між розділами, зазвичай спричинений ключем з непропорційно великою кількістю записів, що залишає одному виконавцю набагато більше роботи, ніж іншим.
“Один ідентифікатор клієнта має десять мільйонів рядків, а всі інші мають тисячі — це похилення, яке робить це об’єднання тривати вічно.”
** Broadcast join ** — стратегія з’ єднання, за якої невелику таблицю повністю копіюється до кожного виконавця, уникаючи перетасування (набагато більшої) іншої таблиці.
- “Ця таблиця пошуку має лише 50 МБ — примусово встановити зв’ язок широкомовлення замість того, щоб Spark перетасовував обидві сторони.” *
** Спіл (на диск) ** — коли виконавець не має достатньої пам’ яті для зберігання проміжних даних і записує їх на диск, що є правильним, але набагато повільнішим.
“Сцена не зупиняється, вона просто розливається - вдаріть по пам’яті виконавця і це повинно повернутись за хвилину.”
Поширені помилки
- Сказати « це повільно » без вказівки, чи є вузької місця перестановка, похилий розділ, або збір драйвера — кожен потребує абсолютно іншого виправлення.
- Назва кожного широкого перетворення «запитом на приєднання», коли group-bys, distinct і repartitions також викликають перетасування.
- Забувши, що лінь оцінки означає, що стековий слід часто вказує на дію (
.write(),.count()), а не на фактичну лінію, де було визначено погане перетворення.
Практичні вправи
- Поясніть у двох реченнях, чому завдання з 200 розділами все ще може бути повільним на кластері з 20 ядрами.
- Написати коротке повідомлення Slack, у якому буде вказано, що повільне з’ єднання є результатом перекосу даних, а не загальної скарги на те, що з’ єднання відбувається повільно.
- Створити коментар перегляду коду, у якому буде рекомендовано широкомовне приєднання для невеликої пошукової таблиці.
Зв’язані ресурси
- Англійська для розробників Python
- Англійська для розробників Kafka Streaming
- Англійська для розробників Apache Beam
Навігація та зв’язок
Для не-рідних носіїв, отримання і надання зворотнього зв’язку - особливо в технічному середовищі, як Spark розробки - може бути значною перешкодою. Нітками професійної англійської часто виходять за рамки буквального перекладу, вимагаючи розуміння неявного значення і прийнятих розмовних шаблонів в рамках спільноти розробників програмного забезпечення. Просте «це не працює» рідко достатньо; це потребує контексту, логіки і запропонованого рішення. Розглянемо такий сценарій: ви надіслали запит на звантаження, у якому міститься нове перетворення DataFrame, і ваш колега відповідає: « Цей запит повільний ». Хоча це технічно вірно, у цьому повідомленні відсутні дійові відомості, які б допомогли вам вирішити проблему. Це можна інтерпретувати як критику або просто спостереження без намірів.
Ключ тут полягає в тому, щоб обдумано сформулювати свої відповіді. Замість оборони, націлюйся на ясність і співпрацю. Конструктивнішою відповіддю може бути: «Дякую за те, що звернули на це увагу! Я зосередився на оптимізації цього конкретного перетворення за допомогою broadcast join, щоб зменшити перемикування даних. Однак, я розумію вашу думку — початкова продуктивність повільніша, ніж очікувалося. Чи можете ви розібратися, що ви бачите у використанні ресурсів (ЦП/ пам’ яті) під час виконання цього запиту? Можливо, є проблема з самими даними, яку ми можемо дослідити. ” Зауважте зміну тону: визнання зворотнього зв’ язку, надання контексту для вашого підходу і запитання конкретної інформації, щоб допомогти діагностувати проблему. Це демонструє готовність навчатися і співпрацювати, що є ключовим при роботі в різних командах. Аналогічно, якщо ви пояснюєте складну концепцію, наприклад, лінь оцінки під час перегляду коду, уникайте жаргону, якщо це не абсолютно необхідно, і завжди пояснюйте * чому * його використовують.
Крім того, розмови Slack часто вимагають такого ж рівня ретельної фразування. Швидке « виправлення », надіслане без контексту, може бути неправильно інтерпретовано як недбалість. Замість цього, щось на зразок: «Щойно реалізовано зміну для оптимізації фільтра RDD — повинна поліпшити продуктивність, зменшивши небажані перестановки. Я моніторю метрику виконавця і даю вам знати, якщо я бачу будь-які регресії.” забезпечує прозорість і демонструє, що ви активно управляєте впливом ваших змін. Проактивне спілкування є ключовим; це запобігає непорозумінням і сприяє більш продуктивному середовищу, особливо при роботі з потенційно складними концепціями розподілених обчислень.
// Example: Scala code demonstrating DataFrame broadcast join (for illustrative purposes)
// This isn't meant to be a complete solution but shows the concept.
val dataFrame1 = spark.createDataFrame(Seq(("A", 1)), ["id", "value"])
val dataFrame2 = spark.createDataFrame(Seq(("X", 10), ("Y", 20)), ["id", "multiplier"])
// Broadcast the smaller DataFrame for efficiency
val broadcastedDataframe2 = dataFrame2.sparkSession.broadcast()
dataFrame1.join(broadcastedDataframe2, "id").select("id", "value", "multiplier")