Как Apache Nessie меняет работу с Data Lakehouse

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

В разработке эту проблему давно решает Git — ветки, коммиты, ревью и откат позволяют менять код, не затрагивая основную версию. На вебинаре покажем, как Apache Nessie переносит этот подход на данные: разберём работу с отдельными ветками, проверку изменений и публикацию в продакшен только проверенного результата.

Что вы узнаете:

• что такое транзакционный каталог таблиц и как Apache Nessie добавляет версионирование поверх Apache Iceberg — ветки, теги, история коммитов и Time Travel;
• как устроен паттерн Write-Audit-Publish: ETL пишет в изолированную ветку, DQ-тесты работают как гейт, а публикация в продакшен происходит после их прохождения;
• как проверять гипотезы и делать A/B-тестирование трансформаций без копирования данных и риска для продакшена;
• как организовать параллельную работу команд в отдельных ветках и разрешать конфликты при слиянии.

Практическая часть:

• создадим ветку Development от продакшена, изменим данные и покажем, что продакшен при этом не затронут, а данные в S3 не копируются;
• запустим ETL с намеренно некорректными данными и покажем, как DQ-проверки останавливают публикацию, оставляя данные на ветке для разбора;
• смоделируем конфликт слияния: изменим витрину в ветке разработки, а затем внесём изменения в ту же таблицу в продакшене — покажем, как Apache Nessie обнаруживает конфликт, и разберём варианты его разрешения;
• заглянем в историю изменений витрины: прочитаем данные по состоянию на любой прошлый коммит, сравним их с текущими и вернём продакшен к сохранённой точке одной командой.

Вебинар будет полезен data-инженерам и специалистам по данным, аналитикам данных, DevOps и SRE-инженерам, а также руководителям data-отделов и ИТ-директорам, которые хотят оптимизировать затраты и ускорить time-to-insight.