Технический блог про ETL, Data Engineering, Big Data и OSINT: практические разборы, архитектурные заметки, инструменты и кейсы из реальной работы от компании ETLdata.ru
Вопрос о том, что лучше — Kimball или Data Vault, вызывает множество споров. Часто каждый стоит на своем и защищает метод, с которым работал. Но на самом деле, этот выбор не зависит от личных предпочтений. Все сводится к тому, какая задача стоит перед вами, какая команда работает над проектом и как часто меняются требования.
Внешние данные — это всегда нестабильность. Даже если сегодня всё работает, завтра может сломаться без предупреждения, потому что поведение внешних источников может измениться.
Есть три метрики качества, которые считаются базовыми. Если их не контролировать, аналитика рано или поздно начнёт вводить в заблуждение.
То, что ещё пару лет назад казалось фантастикой — когда искусственный интеллект выступает не просто помощником, а основной движущей силой создания кода, — сегодня становится повседневной реальностью для всё большего числа команд.
Текстовые внешние данные почти всегда “грязные” даже тогда, когда визуально всё выглядит нормально. Внутри могут быть лишние блоки, HTML, повторяющиеся вставки, разные кодировки и разные способы написания дат и чисел.
Внешние источники выглядят привлекательными, потому что данные вроде бы “лежат в открытом доступе”.
Инциденты в данных неизбежны, и главная проблема обычно не в самом инциденте, а в хаотичном разборе.
Платформа данных становится настоящей системой только тогда, когда её состояние видно. Если единственный сигнал — “DAG зелёный”, вы не защищены от ситуаций, когда данные приехали частично, в неправильном формате или с дублями.
