Grace Goheen

Сегодня мы опубликовали первую альфа-версию dbt Core 2.0, подняв планку того, чего пользователи dbt могут ожидать от своего инструмента трансформации данных. Как и прежде, исходный код dbt Core полностью открыт под лицензией Apache 2.0. Этот выпуск особенно важен потому, что dbt Core 2.0 теперь построен на той же основе, что и движок dbt Fusion: мы впервые открыли исходный код значительной части Fusion.

Выпуск dbt Core 2.0 включает ряд важных функциональных улучшений:

• Значительное сокращение времени разбора, особенно для самых крупных проектов dbt
• Строго определённая спецификация языка, которая не позволит случайно задать desciptin вместо description и предоставляет всем, кто создаёт интеграции с экосистемой dbt (включая собственную команду разработки dbt!), стабильный интерфейс для разработки.
• Новые артефакты в формате Parquet как высокопроизводительная альтернатива большим JSON-файлам, к которым можно напрямую обращаться с запросами через DuckDB или агента на ваш выбор
• Полностью переработанная локальная документация, которая использует новые артефакты и масштабируется для проектов любого размера.
• Более простой способ создания новых адаптеров на базе ADBC и экосистемы Arrow
• Упрощённый процесс установки, избавляющий от необходимости бороться с виртуальными окружениями Python

Почему мы это создали: Краткая история команды профессиональных услуг dbt Labs​

Если вы посетили Coalesce 2022, вы знаете, что секрет раскрыт — команда профессиональных услуг dbt Labs — это не просто группа опытных консультантов по данным; мы также межгалактическая группа инопланетян, путешествующих по Млечному Пути с миссией помочь аналитическим инженерам успешно внедрять и управлять dbt по всей галактике.

Почему люди используют cherry pick для верхних веток?​

Самая простая стратегия ветвления для внесения изменений в код вашего репозитория dbt проекта — это иметь единственную основную ветку с кодом уровня продакшн. Чтобы обновить ветку main, разработчик должен:

1. Создать новую ветку для функции непосредственно от ветки main
2. Внести изменения в эту ветку для функции
3. Протестировать локально
4. Когда будет готово, открыть pull request для слияния изменений обратно в ветку main

Базовый рабочий процесс Git

Если вы только начинаете работать с dbt и решаете, какую стратегию ветвления использовать, этот подход — часто называемый "непрерывным развертыванием" или "прямым продвижением" — является оптимальным. Он предоставляет множество преимуществ, включая:

• Быстрый процесс продвижения для внесения новых изменений в продакшн
• Простая стратегия ветвления для управления

Основной риск, однако, заключается в том, что ваша ветка main может стать уязвимой для багов, которые могут проскользнуть через процесс утверждения pull request. Чтобы провести более интенсивное тестирование и контроль качества перед слиянием изменений в коде в продакшн, некоторые организации могут решить создать одну или несколько веток между ветками для функций и main.

Существует множество причин, по которым вы, как инженер по аналитике, можете захотеть зафиксировать полную историю версий данных:

• Вы работаете в отрасли с очень высокими стандартами управления данными
• Вам нужно отслеживать крупные OKR с течением времени, чтобы отчитываться перед заинтересованными сторонами
• Вы хотите создать окно для просмотра истории с прямой и обратной совместимостью

Это часто ситуации с высокими ставками! Поэтому точность в отслеживании изменений в ваших данных имеет ключевое значение.