timlid.ru | блог про Data Engineering Заметки, инструменты и кейсы из реальной работы

Лента

Технический блог про ETL, Data Engineering, Big Data и OSINT: практические разборы, архитектурные заметки, инструменты и кейсы из реальной работы от компании ETLdata.ru

Data Vault как «устойчивое ядро» платформы данных

Data Vault хорошо работает там, где источников много и они меняются чаще, чем успевает обновляться документация. Его ценность не в том, что он “красивее” других подходов, а в том, что он снижает стоимость изменений.

Почему стабильные определения важнее «самой красивой схемы»

В DWH можно бесконечно спорить о структуре и стиле моделирования, но на практике доверие держится на стабильных определениях.

Витрина как продукт, а не как «правильная таблица»

Витрина редко проваливается потому, что она “не по учебнику”. Чаще она проваливается потому, что ей неудобно пользоваться.

Drift форматов и аномалии: почему «всё зелёное» не значит «всё правильно»

Одна из самых неприятных категорий проблем — это тихие изменения форматов и распределений, которые не ломают пайплайн технически, но ломают смысл данных.

Почему BI «врёт», даже если дашборды сделаны правильно

Проблема доверия к BI почти всегда начинается не с визуализации, а с качества входных данных. Дашборд может быть идеально собран, но если данные не обновились вовремя, пришли не в полном объёме или задублировались, цифры будут выглядеть правдоподобно и при этом вводить в заблуждение.

Переигрываемость как ключевой принцип ingestion-архитектуры

В данных неизбежны ситуации, когда нужно «переиграть» обработку: исправили баг в нормализации, поменяли правило дедупа, добавили справочник или обнаружили, что источник тихо изменил формат.

Зачем разделять landing, raw и normalized

Когда источников становится больше пары, попытка загрузить всё сразу в «финальную таблицу» начинает ломать систему. Внешние данные меняют форматы, внутренние системы обновляются, появляются пропуски и дубли, а команда вынуждена чинить это прямо в витрине, рискуя аналитикой.

Ретраи, таймауты и конкуррентность как единый механизм

Ретраи в Airflow полезны только тогда, когда они встроены в нормальную модель отказов. Если повторять запросы без пауз и ограничений, вы создаёте лавину: источник не успевает восстановиться, растёт очередь, и вместо одного сбоя вы получаете каскад ошибок.

Airflow не делает пайплайн надежным сам по себе

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

Идемпотентность как страховка от дорогих ошибок

Идемпотентность в данных — это способность повторного запуска не менять итоговый смысл результата.

← Назад Страница 3 / 4 Вперёд →