Англійська для Airflow Orchestration

Весь дизайн Airflow обертається навколо DAGs - спрямованих ациклічних графів завдань - і точний словник про те, як ці завдання пов’язані, повторюються і заповнюються, що робить обговорення конвеєра корисним замість нечіткого опису “роботи, яка виконується щоночі”

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

** DAG (Directed Acyclic Graph) ** — визначення конвеєра верхнього рівня: набір завдань і залежностей між ними, без дозволених циклів, запланованих до виконання за визначеним інтервалом.

• “Нічний ETL DAG має дванадцять завдань, з паралельним виконанням завдань видобування і завданням перетворення, яке чекає на завершення всіх завдань.” *

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

** Оператор ** — шаблон, який визначає, який тип роботи виконує завдання (запуск функції Python, виконання запиту SQL, запуск іншого DAG), створений з певними аргументами, щоб стати завданням. “Ми використовуємо PythonOperator для кроку перетворення і PostgresOperator для кінцевого навантаження — оператор визначає, який механізм фактично виконує роботу.”

** Sensor ** — особливий тип оператора, який очікує, поки умова стане справедливою (з’ явиться файл, закінчиться інший DAG, існуватиме рядок бази даних), перш ніж дозволити виконання наступних завдань. “DAG починається з датчика, який опитує прибуття файла-джерела — нічого іншого не виконується, поки цей файл не з’ явиться у контейнері.”

** Backfill ** — процес запуску DAG для минулих запланованих інтервалів, які було пропущено або потребують переобробки, відрізняється від його звичайних запланованих запусків.

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

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

• Чи це невдача на рівні DAG, чи просто одна задача зазнала невдачі?»
• Який оператор використовується в цьому завданні, і чи пояснює це тайм-аут?
• «Чи це сенсор, що чекає на зовнішній стан, чи фактичне завдання обробки?»
• Чи потрібно нам заповнювати це, або це добре, щоб просто дозволити новим запускам бути правильними в майбутньому?»
• Чи ці завдання виконуються паралельно, чи є залежність, що змушує їх виконуватися послідовно?»

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

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

Пояснення рішення щодо дизайну у перегляді:

• “Ми використовували датчик, щоб чекати на експорт команди розробників перед тим, як розпочати власну обробку — запит файла безпосередньо уникає потреби у крихкому фіксованому зсуві розкладу.” *

Запит на виправлення даних:

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

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

• Використовуйте DAG, коли мова йде про весь конвеєр, і task, коли мова йде про один крок — об’ єднання їх (« DAG не вдалося », коли не вдалося лише одне завдання) уповільнює сортування для тих, хто підбирає інцидент.
• Назва ** оператора **, який буде виконано, коли завдання поводитиметься несподівано — час очікування на завдання PythonOperator має інші ймовірні причини, ніж на завдання PostgresOperator.
• Відрізняти ** датчик ** від завдання обробки явно — датчик, який застряг у очікуванні, виглядає так само, як і застрягле завдання на панелі інструментів, але виправлення повністю відрізняється від нього.
• Завжди вказувати, чи виправлення потребує ** заповнення ** — виправлення вади без заповнення залишає історичні дані неправильними, про що легко забути, коли конвеєр знову стане зеленим.

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

1. Напишіть речення, яке відрізняє DAG від завдання.
2. Описати, що робить датчик, відрізняючись від звичайного завдання обробки.
3. Поясніть, коли вам потрібно буде заповнити DAG після виправлення вади.

Національний склад населення: Комунікаційні проблеми

Оскільки ви стаєте більш знайомими з технічними термінами Airflow — DAGs, завдання, оператори, датчики — важливо розуміти, як ці поняття * насправді * обговорюються в професійному середовищі. Не достатньо просто знати, що таке оператор; вам потрібно мати змогу сформулювати його мету, розв’ язати проблеми і ефективно співпрацювати з вашою командою. Тут і грають роль тонкощі англійської мови. Часто навіть досвідчені розробники борються з тим, щоб виразити складні ідеї чітко і точно, що призводить до непорозумінь під час перегляду коду, розмов Slack або при написанні описів запитів на витяг.

Однією з поширених перешкод для носіїв мови, яка не є рідною, є використання надмірно буквальних перекладів. Наприклад, сказати «Це завдання має бути * запущено *» може звучати ідеально спочатку, але в професійному контексті, «Це завдання має бути * розкладання *» або «Це завдання має бути * активація *» є набагато більш ідіоматичною і легко зрозумілою колегами, знайомими з робочим потоком Airflow. Аналогічно, опис комплексної залежності як «це завдання залежить від цього завдання» може бути замінено на «Це завдання залежить від виводу…» Цей невеликий зсув у фразування значно покращує ясність. Інша часта проблема виникає при спробі пояснити * чому * за операцією. Просто сказати « Я додав цей оператор » недостатньо; вам потрібно пояснити * обґрунтування *: « Я додав цей оператор, щоб перевірити дані перед завантаженням їх у кінцевий пункт призначення. »

Крім того, конструктивна критика під час перегляду коду часто покладається на конкретні фрази, які можуть відчуватися конфронтаційними, якщо не доставляються обережно. Замість того, щоб сказати «Це погана задача», більш дипломатичним підходом було б: «Я турбуюся про складність цієї задачі. Можливо, ми могли б розбити його на менші, більш керовані кроки, щоб поліпшити підтримку і зневадження.” Навчання формувати позитивний зворотній зв’язок - зосереджуючись на потенційних поліпшення, а не прямої критики - є важливим для сприяння співпраці середовища. Пам’ятайте, ефективне спілкування не просто про передачу інформації; це про будівництво довіри і забезпечення того, щоб кожен розумів загальну мету.

airflow tasks list --dag-id my_dag

Ця проста команда показує, як ви можете пояснити колегі: « Я запустив airflow tasks list --dag-id my_dag, щоб перевірити, чи всі заплановані завдання знаходяться у DAG ». Це конкретний приклад пояснення технічної дії і її результату — ключового елемента професійного спілкування.