Видео Airflow Summit 2024

— Optimizing Airflow Performance: Strategies, Techniques, and Best Practices
— Airflow Datasets and Pub/Sub for Dynamic DAG Triggering
— Optimize Your DAGs: Embrace Dag Params for Efficiency and Simplicity
— Event-driven Data Pipelines with Apache Airflow
— LLMs for Software Development & Apache Airflow
— The road ahead: What’s coming in Airflow 3 and beyond?
— 10 years of Airflow: history, insights, and looking forward

Остальные доклады можно найти на официальном Ютуб-канале Apache Airflow
- https://www.youtube.com/@ApacheAirflow/videos

Из интересного:
- Видео про roadmap
- Performance tuning
- Event-driven DAGs

Не шибко густо и много, но в целом норм. Для поддержания актуальных знаний - хватит.

@ohmydataengineer - канал "🕯Труба Данных" который продолжает следить за Airflow

Операции записи и чтения по кворуму

Для n реплик
Операция записи должна быть подтверждена w реплик
Операция чтения должна опросить r реплик

Операции записи и чтения, удовлетворяющие соотношению
w + r > n
называются операциями по кворуму.

Можно рассматривать r и w как минимальные количества «голосов», необходимых для признания операции чтения или записи приемлемой.

Значения n,w и r обычно можно настраивать.
Чаще всего n делают нечетным (обычно 3 или 5),
а w = r = (n + 1) / 2 (с округлением в большую сторону).

Если у нас мало операций записи и много операций чтения, то можно увеличить w и уменьшить r.

Базы данных с кворумом могут выдержать отказы и замедление работы отдельных реплик, поскольку запросам не нужно ждать ответа от всех n реплик — достаточно, чтобы ответили w или r реплик.

Например, при n = 5, w = 3, r = 3 система может позволить себе 2 недоступных узла.

Поэтому БД с репликацией без лидера подходят для приложений:
🟣с высокой доступность
🟣с низкой задержкой
🟣допускающих иногда чтение устаревших данных

На мой взгляд эти характеристики подходят, например, соцсетям.

Нестрогий кворум и направленная передача

В кластере может быть много реплик, из которых мы выделяем n для кворума. Возможна ситуация, когда во время сбоя сети клиент может подключиться к каким-то репликам, но не к тем, которые выделены ему для кворума. Если в этом случае база все равно запишет значения, пусть и не в «родные» n реплик, то мы получим нестрогий кворум (sloppy quorum).

После исправления сбоя сети все операции записи, временно отправленные в какую-либо реплику вместо недоступной, отправляются в соответствующие «родные» реплики. Это называется направленной передачей (hinted handoff).

Нестрогие кворумы полезны для повышения доступности для записи: база может принимать операции записи до тех пор, пока доступны любые w реплик. Однако в случае нестрого кворума нельзя гарантировать чтение актуального значения даже из r реплик, поскольку актуальное значение может быть временно записано на какие-то реплики вне множества n.

Нестрогие кворумы — дополнительная возможность, могут быть по-умолчанию отключены.

#кабанчик #сисдиз #репликация