DSPROGLIB Telegram 6266
🔄 Изменения в схеме данных: как избежать проблем для дата-команд

Мы рассмотрим четыре стратегии адаптации к изменениям и их возможные комбинации.

1. Встречи — самый простой подход

📌 Только коммуникация: команды источника данных и аналитики заранее обсуждают изменения, согласовывают сроки и схему данных перед внесением изменений в исходные наборы данных.

▪️ Плюсы:
— Самый простой подход
— Документирование в Confluence, Google Docs и т. д.
— Договоренность между командами

▪️ Минусы:
— Подвержен ошибкам
— Встречи замедляют процесс разработки
— Невозможно учесть все нюансы данных

🎯 Как реализовать:
— Фиксируйте договоренности в Confluence или Google Docs
— Включайте конкретные задачи и шаги для реализации изменений

2. Источник просто сбрасывает данные, а дата-команда разбирается

📌 Dump & Forget: команда источника просто выгружает данные, а дата-команда работает с тем, что получает. Этот метод наиболее распространен в индустрии.

▪️Плюсы:
— Самый удобный способ для команды источника
— Позволяет источнику работать быстро
— Достаточно для большинства бизнес-кейсов

▪️Минусы:
— Дата-команда постоянно догоняет изменения
— Плохие данные, сбои конвейеров и технический долг
— Дата-команда теряет концептуальное понимание данных

🎯 Как реализовать:
— Используйте Apache Iceberg и Spark’s mergeSchema
— Для инструментов типа dbt включайте on_schema_change

3. Дата-команда участвует в ревью изменений схемы данных

📌 Upstream Review: дата-команда участвует в моделировании данных источником. Как правило, дата-команды более внимательно относятся к проработке моделей данных.

▪️Плюсы:
— Предотвращает появление плохих данных
— Обеспечивает качественную схему данных
— Улучшает понимание данных между командами

▪️Минусы:
— Замедляет работу команды источника
— Не позволяет предотвратить агрегированные ошибки (например, несоответствие средней выручки за разные дни)

🎯 Как реализовать:
— Ускорьте процесс с помощью data contracts
— Используйте CODEOWNERS в GitHub, чтобы дата-команды участвовали в ревью

4. Валидация входных данных перед обработкой

📌 Input Validation: дата-команда проверяет входные данные перед их использованием. Если обнаруживается проблема, необходимо взаимодействовать с командой источника, чтобы исправить данные и повторно их обработать.

▪️ Плюсы:
— Быстрое обнаружение проблем
— Автоматизация отладки ошибок и уведомление команды источника

▪️ Минусы:
— Необходимо согласовывать проверки данных между командами
— Множественные проверки увеличивают время обработки данных

🎯 Как реализовать:
— Используйте любой инструмент контроля качества данных
— В потоковых системах применяйте DLQ (Dead Letter Queue) и реконсиляционные паттерны

Библиотека дата-сайентиста #буст
👍31



tgoop.com/dsproglib/6266
Create:
Last Update:

🔄 Изменения в схеме данных: как избежать проблем для дата-команд

Мы рассмотрим четыре стратегии адаптации к изменениям и их возможные комбинации.

1. Встречи — самый простой подход

📌 Только коммуникация: команды источника данных и аналитики заранее обсуждают изменения, согласовывают сроки и схему данных перед внесением изменений в исходные наборы данных.

▪️ Плюсы:
— Самый простой подход
— Документирование в Confluence, Google Docs и т. д.
— Договоренность между командами

▪️ Минусы:
— Подвержен ошибкам
— Встречи замедляют процесс разработки
— Невозможно учесть все нюансы данных

🎯 Как реализовать:
— Фиксируйте договоренности в Confluence или Google Docs
— Включайте конкретные задачи и шаги для реализации изменений

2. Источник просто сбрасывает данные, а дата-команда разбирается

📌 Dump & Forget: команда источника просто выгружает данные, а дата-команда работает с тем, что получает. Этот метод наиболее распространен в индустрии.

▪️Плюсы:
— Самый удобный способ для команды источника
— Позволяет источнику работать быстро
— Достаточно для большинства бизнес-кейсов

▪️Минусы:
— Дата-команда постоянно догоняет изменения
— Плохие данные, сбои конвейеров и технический долг
— Дата-команда теряет концептуальное понимание данных

🎯 Как реализовать:
— Используйте Apache Iceberg и Spark’s mergeSchema
— Для инструментов типа dbt включайте on_schema_change

3. Дата-команда участвует в ревью изменений схемы данных

📌 Upstream Review: дата-команда участвует в моделировании данных источником. Как правило, дата-команды более внимательно относятся к проработке моделей данных.

▪️Плюсы:
— Предотвращает появление плохих данных
— Обеспечивает качественную схему данных
— Улучшает понимание данных между командами

▪️Минусы:
— Замедляет работу команды источника
— Не позволяет предотвратить агрегированные ошибки (например, несоответствие средней выручки за разные дни)

🎯 Как реализовать:
— Ускорьте процесс с помощью data contracts
— Используйте CODEOWNERS в GitHub, чтобы дата-команды участвовали в ревью

4. Валидация входных данных перед обработкой

📌 Input Validation: дата-команда проверяет входные данные перед их использованием. Если обнаруживается проблема, необходимо взаимодействовать с командой источника, чтобы исправить данные и повторно их обработать.

▪️ Плюсы:
— Быстрое обнаружение проблем
— Автоматизация отладки ошибок и уведомление команды источника

▪️ Минусы:
— Необходимо согласовывать проверки данных между командами
— Множественные проверки увеличивают время обработки данных

🎯 Как реализовать:
— Используйте любой инструмент контроля качества данных
— В потоковых системах применяйте DLQ (Dead Letter Queue) и реконсиляционные паттерны

Библиотека дата-сайентиста #буст

BY Библиотека дата-сайентиста | Data Science, Machine learning, анализ данных, машинное обучение








Share with your friend now:
tgoop.com/dsproglib/6266

View MORE
Open in Telegram


Telegram News

Date: |

Judge Hui described Ng as inciting others to “commit a massacre” with three posts teaching people to make “toxic chlorine gas bombs,” target police stations, police quarters and the city’s metro stations. This offence was “rather serious,” the court said. As the broader market downturn continues, yelling online has become the crypto trader’s latest coping mechanism after the rise of Goblintown Ethereum NFTs at the end of May and beginning of June, where holders made incoherent groaning sounds and role-played as urine-loving goblin creatures in late-night Twitter Spaces. With the sharp downturn in the crypto market, yelling has become a coping mechanism for many crypto traders. This screaming therapy became popular after the surge of Goblintown Ethereum NFTs at the end of May or early June. Here, holders made incoherent groaning sounds in late-night Twitter spaces. They also role-played as urine-loving Goblin creatures. Members can post their voice notes of themselves screaming. Interestingly, the group doesn’t allow to post anything else which might lead to an instant ban. As of now, there are more than 330 members in the group. Write your hashtags in the language of your target audience.
from us


Telegram Библиотека дата-сайентиста | Data Science, Machine learning, анализ данных, машинное обучение
FROM American