Распределенный и кластерный
- Кластерное и распределенное сравнение
кластер | распределенный |
---|---|
физическая форма | Способ работы |
Пока куча машин, его можно назвать кластером, о том, являются ли они совместной работой, которые этого не знают | Программу или систему можно назвать распределенной, если она работает на разных машинах (разумеется, архитектуру C/S также можно назвать распределенной). |
Как правило, это физически централизованное и единое управление. | Нет акцента на физическую централизацию и унифицированное управление |
- резюме
Кластер может запускать одну или несколько распределенных систем или вообще не иметь распределенных систем;
Распределенная система может работать в кластере или на нескольких (2 считается несколькими) машинах, которые не являются частью кластера.
2. Введение воздушного потока
Airflow — это инструмент планирования с открытым исходным кодом, написанный на Python компанией Airbnb.
2.1 Работа и задачи в Airflow
-
DAG
- Резюме: DAG (направленный ациклический граф) — это ориентированный ациклический граф, также известный как ориентированный ациклический граф. В Airflow DAG определяет полное задание. Все задачи в одной DAG имеют одинаковое время планирования.
- параметр:
- dag_id: Уникально идентифицирует DAG для будущего управления.
- default_args: параметры по умолчанию, если задание текущего экземпляра DAG не настроено с соответствующими параметрами, используются соответствующие параметры в default_args экземпляра DAG.
- schedule_interval: настроить период выполнения DAG, можно использовать синтаксис crontab.
-
Task
- Резюме: Задача — это конкретная задача-работа в DAG, которая зависит от DAG, то есть она должна существовать в определенной DAG. Задача может настраивать зависимости в DAG (Конечно, также можно настроить кросс-DAG-зависимости, но это не рекомендуется. Зависимости между DAG могут привести к менее интуитивным графам DAG и сложному управлению зависимостями.).
- параметр:
- dag: передать экземпляр DAG, чтобы текущее задание принадлежало соответствующему DAG.
- task_id: дать задаче идентификатор (имя) для будущего управления
- owner: Владелец задачи, что удобно для дальнейшего управления
- start_date: время начала задачи, то есть задача начнет планироваться после этого момента времени.
2.2 Время планирования воздушного потока
- start_date
В конфигурации это время планирования запуска задания. А когда речь идет о статусе выполнения, это время начала расписания.
- schedule_interval
Запланируйте цикл выполнения.
- execution_date
время исполнения. В Airflow это называется временем выполнения, но это не реальное время выполнения.
[стучит по доске, подчеркивая ключевые моменты]
Таким образом, первое время планирования: start_date, настроенное в задании, и момент времени, удовлетворяющий параметру schedule_interval. Записанная дата_выполнения — это первый раз, когда удовлетворяет параметру schedule_interval даты начала, настроенной в задании.
[Например]
Предположим, мы настроили задание с start_date как2 июня 2019 г., настроенный schedule_interval равен* 00 12 * * *
, то время первого исполнения будет3 июня 2019 г. 12:00. Таким образом, execute_date буквально не представляет время выполнения, как ожидалось.Реальное время выполнения — это следующая временная точка, которая удовлетворяет schedule_interval после времени, отображаемого с помощью параметра execute_date.
2.3 Метод планирования воздушного потока
- Метод планирования
- SequentialExecutor: последовательное планирование
- LocalExecutor: планирование нескольких процессов
- CeleryExecutor: распределенное планирование
Однако иногда только настройка зависимостей заданий и планирование циклов выполнения не может удовлетворить некоторые сложные требования.
- другие методы планирования задач
-
- Пропускать не самые последние запуски DAG (сбой в задании, восстановление через некоторое время)
-
- Когда выполняется выполнение DAG, пропустите текущий запуск DAG (время выполнения задания слишком велико, пока не начнется следующее задание).
- 3) Альтернатива датчику (в Airflow есть тип оператора, называемый датчиком. Датчик может определять, выполняются ли заданные условия. Когда условия выполняются, задание датчика становится успешным, чтобы можно было выполнять последующие задания.Недостатком является то, что если вышестоящее задание выполняется в течение 3 часов, оно займет работника на три часа и не освободит его, что приводит к трате ресурсов.)
-
2.4 Служебное здание воздушного потока
- webserver
Airflow предоставляет визуальный веб-интерфейс. После запуска веб-сервера вы можете просматривать определенные DAG, а также отслеживать и изменять статус работы в веб-интерфейсе. Некоторые переменные также можно настроить в веб-интерфейсе.
- worker
Вообще говоря, мы используем Celery Worker для выполнения определенных задач. Рабочие могут быть развернуты на нескольких машинах и могут устанавливать очереди получения индивидуально. Когда в полученной очереди есть задание, Worker получит задание и начнет его выполнение. Airflow автоматически развернет службу Serve Logs на каждой машине, где развернут Worker, чтобы мы могли легко просматривать журналы заданий, разбросанные по разным машинам, в веб-интерфейсе.
- scheduler
Планирование всего воздушного потока инициируется Планировщиком. Время от времени Планировщик проверяет все определенные DAG и определенные в них задания. Если есть задания, соответствующие условиям выполнения, Планировщик инициирует соответствующее задание. задания для работника, чтобы получить.
- flower
Flower предоставляет визуальный интерфейс для наблюдения за состоянием всех работников Celery. Эта услуга не нужна.
2.5 Оригинальная архитектура воздушного потока
3. Распределенная конструкция Airflow на основе Docker
3.1 Узел развертывания
-
Планировщик, веб-сервер, цветок: 10.21.0.192
-
Рабочий: 10.21.0.190, 10.21.0.191, 10.21.0.193
-
RabbitMQ(Celry broker ): 10.21.0.192
-
Mysql(backend): 10.21.0.235