Какова лучшая архитектура Airflow для кластеров AWS EMR?

Question

У меня есть кластер AWS EMR с 1 главным узлом, 30 базовыми узлами и некоторыми автоматически масштабируемыми узлами задач.теперь Oozie выполняет в кластере сотни заданий Hive и mysql.Я собираюсь сменить работу с Oozie на Airflow.Я гуглил, чтобы применить Airflow к моему кластеру.Я обнаружил, что все метки должны быть расположены на каждом узле, а Airflow Worker должен быть установлен на всех узлах.Но My Dag будет часто обновляться, и новые DAG будут добавляться часто, но количество узлов составляет около 100, и даже используются автоматически масштабируемые узлы.И, как вы знаете, только кластерный узел имеет приложение hive / mysql в кластере.Поэтому я очень смущен.Кто может подсказать мне архитектуру Airflow для применения в моем кластере EMR?

Answer 1

Рабочие узлы Airflow не совпадают с узлами EMR.

В типичной настройке рабочий из сельдерея («Рабочий узел Airflow») считывает из очереди заданий и выполняет их, используя соответствующий оператор (Inэтот случай, вероятно, SparkSubmitOperator или, возможно, SSHOperator).

Рабочие Celery не будут работать на ваших узлах EMR, поскольку они предназначены для выполнения заданий Hadoop.

Рабочие Celery, скорее всего, будут работать на EC2 вне вашего кластера EMR.

OneРаспространенное решение, заключающееся в том, чтобы иметь одинаковые группы доступности базы данных на каждом работнике сельдерея, - это поместить эти ярлыки в сетевое хранилище (например, EFS) и подключить сетевой диск к EC2s работника сельдерея.