Переигрываемость как ключевой принцип ingestion-архитектуры
В данных неизбежны ситуации, когда нужно «переиграть» обработку: исправили баг в нормализации, поменяли правило дедупа, добавили справочник или обнаружили, что источник тихо изменил формат.
Лента
Технический блог про ETL, Data Engineering, Big Data и OSINT: практические разборы, архитектурные заметки, инструменты и кейсы из реальной работы от компании ETLdata.ru
Зачем разделять landing, raw и normalized
Когда источников становится больше пары, попытка загрузить всё сразу в «финальную таблицу» начинает ломать систему. Внешние данные меняют форматы, внутренние системы обновляются, появляются пропуски и дубли, а команда вынуждена чинить это прямо в витрине, рискуя аналитикой.
Ретраи, таймауты и конкуррентность как единый механизм
Ретраи в Airflow полезны только тогда, когда они встроены в нормальную модель отказов. Если повторять запросы без пауз и ограничений, вы создаёте лавину: источник не успевает восстановиться, растёт очередь, и вместо одного сбоя вы получаете каскад ошибок.
Airflow не делает пайплайн надежным сам по себе
Airflow часто воспринимают как «установили оркестратор — стало надёжно». На деле Airflow всего лишь управляет запуском задач, но не гарантирует корректность данных и не спасает от архитектурных ошибок.
Идемпотентность как страховка от дорогих ошибок
Идемпотентность в данных — это способность повторного запуска не менять итоговый смысл результата.
Почему «просто загрузить данные» недостаточно для продакшена
В проде ETL — это не про перенос строк из точки А в точку Б, а про управление риском. Любой источник может начать отвечать медленнее, менять формат полей или отдавать данные частично, и это происходит без предупреждения.
ETL ≠ просто выгрузка: 5 признаков продового пайплайна
Многие думают, что ETL — это “забрать данные и положить в таблицу”. В тестовой среде так и бывает. Но в проде всё упирается не в саму загрузку, а в то, насколько система переживает ошибки, изменения и рост.