Англійська мова для Ray Distributed Compute

Обговорення Рей вимагають точного словника, щоб відрізнити безстатевий паралелізм від станових розподілених об’єктів — задачі проти акторів — і використання двох термінів взаємозамінно в розмові про дизайн закриває справжнє архітектурне рішення про те, де живе стан.

Ключовий словник

** Task ** — безстатева, віддалено виконувана функція Python, подана з @ray.remote і .remote(), яку Ray планує на будь- який доступний робочий процес без збереження пам’ яті попередніх викликів.

• “Зробіть це простим завданням, а не актором — кожен виклик є незалежним і не потрібно пам’ ятати нічого з попереднього.” *

** Актор ** — екземпляр класу Python, який виконується віддалено і має стан, який зберігається у багатьох викликах методів, що надає вам змогу підтримувати стан, подібний до завантаженої моделі або відкритого з’ єднання у розподіленому кластері.

• “Ми обгорнули модель у актор, щоб вона завантажувалася тільки один раз на кожного працівника, замість того, щоб кожне завдання перезавантажувало вагу з нуля.” *

** Об’ єктний магазин ** — склад загальної пам’ яті Ray для великих об’ єктів, що передаються між завданнями і акторами, що уникає дорогої серіалізації і копіювання, коли дані використовуються у багатьох викликах на одному вузлі.

• “Покласти цей великий масив у сховище об’ єктів один раз і передати посилання навколо, замість того, щоб серіалізувати і перенасилати його з кожним викликом завдання.” *

Ray reference ( ObjectRef ) — майбутній обробник, повернений негайно віддаленим викликом, що представляє результат, який, можливо, ще не був обчислений, розв’язаний пізніше з ray.get(). “Не викликайте ray.get() одразу після надсилання кожного завдання — спочатку зіберіть всі посилання на об’ єкти, а потім розв’ язайте їх разом, щоб завдання дійсно виконувалися паралельно.”

** Автомасштабування кластера ** — Механізм Ray для додавання або вилучення робочих вузлів на основі поточного попиту на ресурси, таким чином, завантаження може масштабуватися під час серії завдань і масштабуватися назад, коли не виконується жодної роботи.

• “Якщо увімкнено автоматичне масштабування, це пакетне завдання буде запускати додаткові обробники під час пікової напруги і звільняти їх після виснаження черги, замість того, щоб ми забезпечували фіксовану кількість кластерів.” *

Звичайні фрази

• Чи потрібно для цього бути актором, чи достатньо тут бездержавного завдання?»
• «Цей великий об’єкт проходить через об’єктний магазин, або він пересеріалізується при кожному виклику?»
• Чи викликаємо ми ray.get() занадто рано і випадково серіалізуємо ці завдання?»
• Чи кластер автомасштабування правильно, або він застряг на мінімальній потужності під навантаженням?»
• «Який вузол прикріплений до цього актора, і чи створює це вузьке місце?»

Приклади висловлювань

Пояснення вибору дизайну: “Ми використовували актора тут, тому що завантаження ваги моделі дороге — завдання перезавантажує їх при кожному виклику, чого актори уникають, зберігаючи стан резидента.”

Діагностика проблеми з швидкодією: “Ця петля випадково послідовна, тому що ми викликаємо ray.get() всередині неї відразу після кожного виклику .remote() — нам потрібно спочатку подати всі завдання і зібрати результати після цього.”

Перегляд інциденту масштабування: “Задача застопорилась, тому що автоматичне масштабування кластера не ввімкнулося достатньо швидко для піку трафіку — ми коригуємо поріг масштабування і попередньо нагріваємо невеликий буфер працівників.”

Професійні поради

• Розрізняти ** task ** від ** actor ** явно в обговореннях проекту — вибір визначає, чи перебуває стан у викликах, і об’ єднання їх призводить до заплутаного зневадження пізніше.
• Назвіть об’єктний магазин, коли обговорюється швидкість передачі даних — «це повільно, щоб передати цей масив навколо» неоднозначно, в той час як «це пересеріалізовано замість використання об’єктного магазину» вказує на виправлення.
• Прапор передчасних ray.get() викликів, зокрема, посилаючись на ** ObjectRef ** за назвою, при перегляді коду, який повинен бути паралельним, але не є - це один з найпоширеніших анти-патернів Ray.
• Згадайте про пороги автомасштабування кластерів явно, коли обговорюєте стрімкі навантаження — тихий недо-масштабування легко неправильно діагностувати як «Ray повільний», коли насправді це проблема масштабування-політики.

Практичні вправи

1. Поясніть різницю між завданням і актором у одному реченні.
2. Описати, чого об’ єктний сховище уникає, що вимагає простого серіалізації між викликами.
3. Напишіть речення, що пояснює, чому виклик ray.get() занадто рано може випадково серіалізувати інакше-паралельні роботи.

Національні мови: рідна мова для ненаціональних меншин

Будьмо чесними – навіть з чітким розумінням самих концепцій Ray — задач, акторів, об’єктного магазину, кластерного автомасштабування — ефективне спілкування англійською мовою як професійний розробник може відчувати себе як навігація в щільному лісі. Незначні відмінності у фразуваннях, наголос на точності та очікування технічного жаргону можуть представляти значні перешкоди для тих, чия перша мова не є англійською. Це не просто про те, щоб знати * що * щось є; це про передачу цього знання чітко, чітко, і з розумінням того, як інші інтерпретують ваші слова.

Часто виникає проблема під час обговорення зневадження або проблем у кластері Ray. Уявіть, що ви отримуєте повідомлення Slack: «Актор не може серіалізувати. Перевірити об’ єктний магазин. » Хоча це звучить просто, людина, для якої мова не є рідною, може не розуміти, що саме йдеться. « Серіалізувати » — це ключовий термін у цьому випадку, і хоча з технічної точки зору це правильний термін, його використання може здатися незграбним у розмові. Природнішою формулюванням було б: «Стан актора неправильно переданий до об’єктного магазину - нам потрібно дослідити потенційні проблеми серіалізації». Аналогічно, використання «не вдається» само по собі не передає невідкладності або специфічної природи проблеми. Додавши контекст, наприклад, «актор не може надійно виконати свою логіку», ви отримаєте багатший опис для когось, хто не знайомий з основними механізмами.

Іншою областю, де часто трапляються нерозуміння, є описи запитів на витяг (PR). Розгляньте цей уривок: « Цей PR вводить нове завдання, яке використовує можливості автоматичного масштабування Ray для обробки збільшеного навантаження. » Розробник, який не звик до технічної англійської, може перекласти це буквально, можливо, не врахувавши головну перевагу, яку воно дає — здатність системи * динамічно змінювати * ресурси за потребою. Краще було б описати це так: « Цей PR додає нове завдання, розроблене для автоматичного масштабування під час збільшення обробки завантаження, оптимізації використання ресурсів і забезпечення постійної продуктивності ». Додаток « оптимізація використання ресурсів » чітко вираховує позитивний результат.

Нарешті, пам’ятайте, що ясність і точність є найважливішими. Уникайте нечітких термінів, таких як « це не працює » або « щось не так ». Замість цього зосередьтеся на описі того, * що * ви спостерігали, * як * це проявилося, і * чому * ви вважаєте, що це може статися. Детальні спостереження, навіть якщо спочатку сприймаються як надто багатослівні, значно зменшують неоднозначність і прискорюють процес усунення несправностей.

# Example Ray CLI command to inspect object store usage
ray objectstore stats --cluster my_cluster

Ця команда демонструє практичний спосіб збору інформації, яку можна описати англійською мовою — « Команда ray objectstore stats показує, що об’ єктний сховище наближається до своєї ємності, що свідчить про те, що нам слід розглянути можливість збільшення об’ єкта або оптимізації стратегії збереження даних ». Використання таких інструментів і зосередження уваги на точних описах допомагає зменшити розрив у комунікації і сприяє співпраці у вашій команді.