Твики для Git, которые стоит попробовать прямо сейчас!

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

1. Точно улучшат жизнь

автоматически связывает локальные и удалённые ветки.

 git config --global push.autoSetupRemote true

красивый и точный diff.

git config --global diff.algorithm histogram

чтобы ветка по умолчанию называлась main, а не master.

git config --global init.defaultBranch main

2. Почему бы и нет?

Git сам исправит опечатку в команде (и подождёт 2 сек перед выполнением).

git config --global help.autocorrect 20 

показывать diff при коммите.

git config --global commit.verbose true 

запоминает, как вы разрешали конфликты, чтобы не делать это снова.

git config --global rerere.enabled true

3. На любителя

умный rebase для связанных веток.

git config --global rebase.updateRefs true

красивые таблицы в git branch и git tag.

git config --global column.ui auto 

автоматически удаляет "мёртвые" ссылки при fetch.

git config --global fetch.prune true 

Не бойтесь экспериментировать! Все настройки можно применить одной командой, а потом откатить.
Оригинальная статья

Что такое Data Mesh?

Архитектура Data Mesh - это революционная парадигма в мире аналитики данных в реальном времени.
Концепция была впервые определена Zhamak Dehghani в 2019 году как подход к проектированию архитектуры платформы данных, ориентированной на работу с данными в движении.
По сути, Data Mesh - это набор принципов для создания современной архитектуры данных.
С появлением архитектур потоковой обработки событий и требований к данным в реальном времени стали очевидны ограничения старой аналитической парадигмы, используемой десятилетиями.
Data Mesh - это новый подход, который позволяет компаниям отказаться от монолитных архитектур данных и эффективно масштабировать работу с информацией.

В этом курсе Тим Берглунд (старший директор по работе с разработчиками в Confluent) подробно разбирает четыре принципа Data Mesh:

1. Владение данными по доменам - данные управляются командами, которые их создают (например, маркетинг, финансы).
2. Данные как продукт - данные рассматриваются как ценность, которую нужно улучшать и «упаковывать».
3. Доступность везде и самообслуживание - данные доступны всем командам без посредников.
4. Управление данными в любой точке - безопасность и согласованность даже в распределенных системах.

Тим также объясняет, как Data Mesh решает проблемы современной аналитики, на примере реального кейса, и шаг за шагом разбирает процесс внедрения этой архитектуры.

Так же на платформе Confluent доступны другие курсы по все экосистеме Kafka.

@data_whisperer

Smallpond

Deepseek выкатили фрэймворк для дата-процессинга построенный на базе DuckDB и распределенной файловой системы 3FS.

🚀 Скорость на уровне космоса: Обработка PB-масштабных данных с рекордной пропускной способностью.
🌍 Масштабируемость без границ: Работает на кластерах любого размера — от стартапов до корпоративных гигантов.
🛠️ Простота вместо сложности: Никаких долгих настроек и запущенных сервисов. Инструмент готов к работе «из коробки».

📊 Производительность, которая впечатляет:

На тесте GraySort (тест для сортировки больших данных):

- 110,5 TiB данных отсортировано за 30 минут 14 секунд!
- Средняя пропускная способность — 3,66 TiB/мин (это как перегнать 20 фильмов в 4K каждую секунду).
- Тест проведен на кластере из 50 вычислительных узлов + 25 узлов хранения 3FS.

Подробности можно найти в 3FS - Grey Sort.

@data_whisperer

Пугающая Data

Курцвейл писал, что технологическая сингулярность наступит в 2045 году. Нам с вами осталось ещё 20 лет!
Однако пока хочется поговорить о «сингулярности ануса», в которую катится вся дата-индустрия последние пару лет.

Поясню, о чём я. Заметили, как дата-домены в большинстве компаний страдают от вечного технического долга и от смены технологий буквально раз в год?

Давайте откатимся назад, лет на пять. У меня самого немного опыта — сейчас только пятый год. Когда я в 2020–2021 годах был джуниор-специалистом, у моих старших коллег в индустрии было по 5 и более лет стажа. Менеджерами дата-команд часто становились сеньор-специалисты, которые отлично разбирались в архитектуре и дата-технологиях, строили стратегии развития и понимали инфраструктуру. Мидл-аналитики умели писать хороший код, хорошо знали статистику и экономику, владели Data Science.
Полноценный продукт или даже целое направление бизнеса тогда могла обеспечивать аналитикой команда из пяти-восьми человек.

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

Что мы видим теперь?
В среднестатистической компании на 500–1000 сотрудников:
• 24-30 человек в дата-домене и ещё по 3–5 открытых вакансий;
• Средний Head of Data / CDO — выходец из бизнес-анализа или системного анализа, то есть с данными «руками» работал немного;
• В иерархии дата команды «Head of» на «Head of» на «Head of» на «Lead» на «Team Lead» руками работают 5 человек;
• Обязательно открыт поиск Data Partners и специалистов по Data Governance… Возможно, кто-то сочтёт меня глупым, но до сих пор не понимаю, чем именно они занимаются;
• Среднестатистический дата-аналитик не может адекватно собрать требования с заказчика, чтобы проанализировать именно процесс, а не перечень хотелок;
• Фундаментальные принципы программирования, чистый код, оптимальные SQL-запросы и архитектура в сфере данных практически отсутствуют;
• Средний митап похож на презентацию инструмента или рассказ дата-менеджеров о том, чего они сами никогда не делали руками.

И вопрос не в дата-сфере какой-либо страны, я вот в 4-х разных странах поработал. Но проблемы одни и те же.

В общем, мне кажется, что дата-сфера глобально сильно угасает. Увы, не могу сформулировать понятного вывода.

Поделитесь, если вы чувствуете то же самое — или, наоборот, видите расцвет «весеннего тюльпана» дата-отрасли :)

Оригинальный пост в LinkedIn

И еще немного про Git

Вы уверены, что используете Git на 100%? Даже опытные программисты часто не знают о скрытых фишках, которые экономят часы работы. Подборка лайфхаков, которые прокачают ваш workflow!

🔄 1. git checkout - — Магия переключения веток
Как это работает:
- Переключайтесь на предыдущую ветку одной командой: git checkout -.
- Пример: вместо git checkout main → просто git checkout -.
- Бонус: git merge - сливает текущую ветку с предыдущей.
Алиас в помощь:

alias gco='git checkout'  # Теперь просто gco -  

🔎 2. git bisect — Детектив для поиска багов
Нашли баг? Запустите бинарный поиск по коммитам:

git bisect start  
git bisect bad <commit>   # Текущий коммит с ошибкой  
git bisect good <commit>   # Коммит, где всё работало  

Git сам найдет проблемный коммит за log₂(n) шагов!
Лайфхак: Вернитесь на неделю назад:

git checkout HEAD@{1.week.ago}  

🕵️ 3. git log -G "regex" — Поиск изменений по шаблону
Ищете, где добавили/удалили код?

-G "регекс" → ищет строки в истории.
-S "строка" → ищет изменения количества вхождений.

Пример для package.json:

glp -G '"next"' -- package.json  # Все коммиты с "next"  

Алиас для красивого вывода:

alias glp='git log --pretty=format:"%C(yellow)%h%Creset - %C(green)%an%Creset, %ar : %s"'  

⚔️ 4. git merge -X theirs/ours — Война веток без боли
Конфликты при слиянии? Решайте их автоматически:

-X theirs → берет изменения из сливаемой ветки.
-X ours → оставляет ваши изменения.

Пример:

git merge branch-A -X theirs  # Пусть победит branch-A  

⚡ 5. Настройки Git, которые ускорят ваш workflow

Добавьте в конфиг:

git config core.fsmonitor true          # Ускоряет git status  
git config push.autosetupremote true    # git push без -u  
git config --global branch.sort committerdate  # Сортировка веток по дате  

Источник: Unspoken Git Secrets

Modern Data Stack: Где баланс между мощью и простотой?

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

Более 70% респондентов вынуждены использовать более 5-7 различных инструментов или работать с 3-5 поставщиками для различных задач. Около 10% используют более 10 инструментов, что показывает растущую сложность ландшафта данных.

Проблемы текущих data-стеков:
1. Фрагментация инфраструктуры
Раньше хватало SQL-базы и BI-инструмента. Сейчас компании используют десятки узкоспециализированных решений, которые слабо интегрируются друг с другом. Результат — «лоскутное» решение, где данные теряются на стыке систем.

2. Экономические и временные затраты:
Каждый новый инструмент - это:
• Лицензии,
• Обучение сотрудников,
• Настройка интеграций,
• Постоянные доработки под меняющиеся требования.
Команды тратят 60% времени на поддержку инфраструктуры вместо анализа.

3. Зависимость от экспертов:
Сложные стеки требуют узких специалистов, которых не хватает на рынке. Уход такого сотрудника может парализовать процессы.

4. Снижение гибкости:
Добавление новых источников данных или изменение ETL-процессов превращается в многонедельный проект из-за нагромождения технологий.

Что предлагает автор?
• Консолидация вместо фрагментации
Платформы, которые объединяют сбор, трансформацию, хранение и визуализацию данных (например, Databricks или Google BigQuery). Чем меньше «точек соприкосновения» между инструментами, тем ниже риски ошибок.
• Стандартизация процессов
Унификация форматов данных, API и протоколов (как в случае с Apache Arrow или Parquet). Это снижает порог входа для новых сотрудников и упрощает масштабирование.
• End-to-end решения
«Бесшовные» платформы, где данные перемещаются между этапами без ручных преобразований. Например, Snowflake с поддержку ML-моделей или Looker.


Сложность - не всегда признак продвинутости.

@data_whisperer

The DuckDB local UI

DuckDB выпустили новый локальный веб-интерфейс, представляющий собой простую в использовании альтернативу CLI для запросов, исследования и управления базами данных DuckDB.

Для каких задач вы используете DuckDB?

Pre-Commit Хуки: Твой код скажет тебе спасибо!
Или как не отправить в прод кривой SQL и забытые импорты

Программируете ли вы профессионально или в качестве хобби - умение писать качественный код стоит оттачивать.
Все мы, люди, совершаем ошибки, и это нормально.
Совершенство не цель, но постоянное улучшение - да.
В профессиональной среде после завершения проекта ваш код обычно проверяет коллега.
Но что, если такого человека рядом нет, чтобы помочь исправить недочёты?
Тут в игру вступают pre-commit хуки.

По сути, pre-commit hook - это программа, которая автоматически запускается в вашем репозитории при выполнении команды git commit в терминале.
В зависимости от типа хука, он проверяет ваш код на ошибки или нарушения правил, которые он запрограммирован находить.
Эти хуки работают через Python-пакет pre-commit.
Подробнее о нём можно узнать на официальном сайте pre-commit.
Настроить хуки очень просто. В вашем репозитории:

📦 Ставим пакет: pre-commit.
📄 Создаём файлик .pre-commit-config.yaml в корне проекта.
✨ Копипастим туда магию (пример ниже ↓).
🚀 Запускаем: pre-commit install - готово!

Теперь при каждом коммите хуки будут автоматически проверять и исправлять код.

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.3.0
    hooks:
    -   id: check-yaml
    -   id: end-of-file-fixer
    -   id: trailing-whitespace

🛠 Топ-5 Хуков, Без Которых Ты Не Выживешь

1. isort
Что делает: Раскладывает твои import ... по полочкам:

• Стандартные библиотеки →
• Сторонние →
• Твои модули.

До: import sys, pandas, my_module (хаос!)
После: Все по PEP.

2. black
Что делает: форматирует код автоматически. Не спорит, не спрашивает - просто делает код красивым и читаемым.
Пример: превращает мешанину с кривыми отступами в аккуратные блоки с правильными пробелами.

3. ruff
Что ловит:

• Неиспользуемые переменные (типа x = 10, который ты так и не вызвал),
• Нарушения PEP8 (да, он знает, где поставить пробел).

4. sqlfluff
Что делает: Форматирует SQL-запросы, проверяет синтаксис и стиль.

5. mypy
Что проверяет: Проверяет типы данных. Если функция должна возвращать str, а вы пишете int - он вас остановит.

Зачем это надо?
• Меньше конфликтов в Git (код в одном стиле у всей команды),
• Спасает от я потом исправлю — исправляет сразу,

А какие хуки используете вы? Делитесь в комментариях!

@data_whisperer

Прямые эфиры: задавайте вопросы о бесплатных курсах MLOps и LLM Zoomcamp!

Очень скор стартуют два бесплатных курса — MLOps Zoomcamp и LLM Zoomcamp!
Перед началом обучения команда курса приглашает вас на живые Q&A-сессии, где авторы ответят на все ваши вопросы.

🔧 MLOps Zoomcamp
Погрузитесь в практику: как развернуть ML-сервисы в продакшене.

💬 LLM Zoomcamp
Научитесь применять большие языковые модели (LLM) для реальных задач: от чат-ботов до анализа данных.

Даты эфиров:

📅 21 апреля (понедельник) — Q&A по MLOps
📅 23 мая (пятница) — Q&A по LLM

Успеете спросить обо всём: от программы курсов до нюансов обучения.
Присоединяйтесь, чтобы не пропустить старт и прокачаться в ML-инженерии и работе с языковыми моделями.
Участие бесплатное!

DBT MEETUP

Совсем скоро состоится митап по dbt - инструменту, который перевернул мир data engineering и аналитики!
Если ты хочешь прокачать навыки работы с данными, узнать лучшие практики и пообщаться с единомышленниками - это событие для тебя.

Что будет?
- Полезные доклады от экспертов индустрии.
- Реальные кейсы внедрения dbt в проектах.
- Нетворкинг с теми, кто говорит на языке данных.

🔗 Регистрация и детали: inzhenerka.tech/dbt_meetup

The Python Paradox

В 2004 году Пол Грэм заявил, что Python-программисты в среднем сообразительнее Java-разработчиков.
Не потому что Java - плохой язык, а потому что Python тогда был нишевым инструментом, который учили не ради работы, а из любви к кодингу.
И эта идея до сих пор взрывает мозг: если компания пишет софт на непрактичном языке, она ловит самых увлеченных.

Rust/Elixir vs Java/PHP - первые чаще привлекают тех, кто готов гореть проектом, а не просто трекать часы.

Go - идеальный пример, как простота и популярность убивают среднюю температуру по больнице. Синтаксис - легче некуда, зарплаты - выше крыши. Итог?
Толпы новичков, тонны шаблонного кода, а энтузиасты уже смотрят в сторону Zig.

Что делать?

Компаниям - ищите в резюме проекты на бесполезных языках. Человек пишет на Erlang в 2025? Это как татуировка программист-фанатик.
Даже если у вас legacy на Java, дайте таким людям модуль на Kotlin - они его оживят.

Разработчикам - учите то, от чего горят глаза. Не Go потому что модно, а Elixir потому что офигенно.
Google до сих пор в Java-вакансиях спрашивает про Python. Потому что знает: это маркёр любви к коду.

Python из хобби стал мейнстримом. С Go та же история. Эзотерика сегодня - завтра хайп.
Даже среди Java-программистов есть гики - их видно по опенсорсу и странным хобби вроде сборки своих IDE.

Личное мнение:
Парадокс Грэма - не про языки. Это про выбор людей, которые не ищут лёгких путей. Такие есть везде.
Просто в нишевых языках их концентрация выше.

А вы как думаете?
Вот если бы вам пришлось нанимать команду - взяли бы Java-спеца с 10 годами опыта или того парня с кучей проектов на Haskell?

@data_whisperer

ETL/ELT Patterns with Apache Airflow®: 7 Practical DAG Code Examples

Использование Airflow для организации ETL и ELT позволяет вам интегрировать несколько источников данных и использовать современные инструменты трансформации, сохраняя при этом контроль над вашей инфраструктурой данных.

Эта электронная книга содержит 7 примеров DAG для различных сценариев ETL и ETL, включая:

- Шаблон DAG с использованием Dynamic Task Mapping.

- Шаблон DAG с использованием явного внешнего хранилища.

- Шаблон DAG с использованием XCom.

Плюс ко всему, вы получите доступ к сопутствующему репозиторию GitHub, содержащему полностью функциональный проект Airflow со всеми 7 DAG, настроенными для запуска из коробки с использованием Astro CLI без необходимости настройки каких-либо подключений или дополнительных инструментов.

F*ck Leetcode

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

Разработчик по имени Ли запустил Interview Coder - инструмент на базе ИИ, который позволяет кандидатам обманывать работодателей во время технических интервью. За $60 в месяц пользователи получают доступ к "невидимому" помощнику для решения задач на кодинг.
По словам Ли, его стартап был на пути к годовому доходу в $2 млн... до того, как его отстранили от учебы. Причиной стало видео на YouTube, где он демонстрировал использование своего инструмента во время собеседования в Amazon.

А вот видео с разбором ситуации.

Писать промпты? Это что то из прошлого.

Встречайте QUACK-TO-SQL
первую в мире модель искусственного интеллекта, которая позволяет вам делать запросы к вашей базе данных с помощью кряканья. Да, буквально кряканья. Работая на основе усовершенствованного распознавания утиных звуков, она работает локально в вашем браузере - как и DuckDB.

Никакой настройки. Никакого набора текста. Только чистая, гудящая производительность.

Хотите 10 лучших клиентов по доходу? Просто крякайте.

dbt-column-lineage

Понимание происхождения данных на уровне столбцов в проектах dbt может быть сложным.
Инструмент dbt-column-lineage решает эту проблему, предоставляя визуализации отношений столбцов с использованием артефактов dbt, таких как manifest.json и catalog.json.
Он поддерживает несколько форматов вывода, включая интерактивные представления HTML, файлы GraphViz DOT и простые текстовые выводы.

Пакет тестировался на:
- Snowflake
- SQLite
- DuckDB

Синдром самозванца и программирование: как жить без диплома Computer Science

Я никогда не проходил формальный курс по Computer Science. Моё образование - это программная инженерия, и долгие годы я даже не задумывался, что между ними есть разница. Но потом дошло: инженерия - это про практику, про управление проектами, тестирование, профилирование, бесконечные итерации и доставку рабочего кода в срок. А Computer Science - это уже совсем другая история: теория структур данных, нотация O(n), математические выкладки и прочие штуки, от которых голова идет кругом, если ты не в теме. Именно так начинается книга The Imposter’s Handbook - и это как будто про меня.

Вообще, многие разработчики обходятся без корочки CS и прекрасно справляются со своей работой. Но вот этот проклятый синдром самозванца. Он никуда не девается. Знакомо? Сидишь на встрече с командой, кто-то небрежно бросает: «О, это же похоже на цепь Маркова?» - а ты такой: «Ага, ну да, это… эм… совершенно точно так!» И улыбаешься, а внутри паника: «Что за цепь такая, почему я этого не знаю?»

Синдром самозванца не вылечить навсегда.
Это как тень, которая то отступает, то снова накрывает. Можно, конечно, пойти учиться на полноценное CS-образование - но это годы, деньги и куча усилий. А можно выбрать другой путь: самообразование. Закрывать пробелы в знаниях шаг за шагом, своими силами.
The Imposter’s Handbook как раз про это - книга, которая помогает разобраться в базовых концепциях CS без лишнего пафоса. Жаль только, перевода на русский нет.

Если хочется чего-то на русском, вот пара годных вариантов:

- Код. Тайный язык информатики Чарльза Петцольда - про основы основ, доступно и без занудства.

- Теоретический минимум по Computer Science. Все, что нужно программисту и разработчику - чуть посерьезнее, но тоже по делу.

В общем, если синдром самозванца тебя тоже иногда душит - не паникуй. Это нормально. Главное, двигаться вперед, учиться и не бояться спрашивать. Даже если про цепь Маркова пока только гуглить и остается.

@data_whisperer

Паттерны проектирования для Data Engineer: необходимость или излишество?

Паттерны проектирования - тема, которая вызывает споры среди разработчиков не меньше, чем отсутствие CS-образования. На заре Data Engineering большинство специалистов приходили из Backend-разработки, где знание паттернов считалось обязательным навыком. Но с ростом популярности профессии в неё хлынули люди из смежных областей - аналитики данных, BI-разработчики, специалисты без опыта применения паттернов. Так нужны ли они Data Engineer?

Ответ зависит от задач. Если вы пишете Spark-джобы, собираете витрины или работаете с моделированием данных - паттерны, скорее всего, останутся на полке. Но если вы в платформенной команде и создаёте Self Service платформу, которую нужно поддерживать и развивать, паттерны становятся незаменимыми. Они помогают строить масштабируемый и понятный код, избегая хаоса.

Как изучать паттерны и с чего начать?

Гугл первым выдаёт «Банду четырёх» - книга культовая и глубокая, но для новичка может быть тяжёлой. Есть серия Head First - подача проще, но их стиль лично мне не подошёл. Я выбрал свой путь: комбинацию теории и практики из нескольких источников.

Что рекомендую:
- «Погружение в паттерны проектирования» от Refactoring guru - фундаментально и доступно (книга платная).
- Курс «Шаблоны проектирования на Python» на Stepik/Udemy - хорошая основа, хоть примеры не всегда идеальны.
- Mastering Python Design Patterns - отличные примеры на Python, моём ключевом языке.

Как я учу:
1. Изучаю теорию паттерна в Refactoring guru.
2. Смотрю разбор на Stepik/Udemy.
3. Читаю реализацию в Mastering Python Design Patterns.
4. Закрепляю практикой (на Stepik есть ДЗ).

Это не самый быстрый метод, но он работает: каждый источник дополняет другой, закрывая пробелы. Паттерны не универсальны, но в нужных сценариях спасают. А что думаете вы - помогают ли они в Data Engineering?

p.s. в книге из прошлого поста, так же разбираются паттерны.

@data_whisperer

Всем привет 👋
Решил провести такое необычное мероприятие, провести розыгрыш книги.
Начинаем с легенды

Fundamentals of Data engineerings в бумажном варианте.
Просто нажмите участвую и результаты узнаем через неделю 🎉

Моделирование данных для Data Engineer: как выбрать и не пожалеть?

Data Engineering - это поле, где споры не утихают: кто-то за Trino до последнего, кто-то Greenplum расхваливает. Но как только разговор заходит о моделировании данных, все резко притихли. И неудивительно - тема сложная, и далеко не каждый в ней как рыба в воде.

Знакомая картина?

Сказали делать Data Vault - ок, давайте попробуем.

А зачем? Ну… потом разберёмся.

На деле моделирование данных - это не просто «выбрал и забыл». Данные - штука капризная: сегодня всё гладко, а завтра бизнес поменял планы, данные растут как на дрожжах, и твоя модель тянет проект вниз. Плюс этот вопрос, который всех мучает: «А если выберем Data Vault, а через год появится что-то круче? Опять всё переделывать?»

Как сделать выбор, который не аукнется через полгода? Давайте разберёмся.

Моделирование данных:

По моделированию материалов полно - от книг до блогов, так что я не буду советовать что-то одно. Вместо этого вот несколько практичных идей, чтобы не запутаться:

- Не гонись за модой.
Data Vault, Delta Lake - это инструменты, а не таблетка от всех бед.

Выбирай то, что решает твою задачу, а не то, что у всех на слуху.

- Оставляй себе свободу. Иногда чистый подход вроде Kimball или Data Vault не тянет - тогда пробуй гибриды. Например, Data Vault + Kimball часто спасает, когда всё меняется.

- Читай кейсы больших компаний. Netflix, Uber, Airbnb - это не только про успехи. Они делятся своими ошибками, а это шанс не наступить на те же грабли.

Итог
Моделирование данных- это не магия, просто нужна нассмотренность и чуть-чуть опыта.

@data_whisperer

Discord разогнал dbt в 5 раз: как укротить петабайты данных без хаоса

Проблема:
Представьте: 100+ разработчиков, 2500+ моделей данных и петабайты информации. Стандартный dbt начал задыхаться - долгие компиляции, конфликты в тестовых средах и бесконечные бэкфиллы ломали процессы.

Решение Discord
Команда кастомизировала dbt, добавив:
- Персональные алиасы таблиц - каждый разработчик работает в своей песочнице, конфликты ушли в прошлое.
- Инкрементная обработка по времени - только свежие данные, без перегрузки кластера.
- Автоматические версии бэкфиллов - откаты и проверки теперь чёткие и предсказуемые.

Результат:
- Время компиляции сократилось в 5 раз.
- 100+ разработчиков работают без сбоев и трений.
- Тестирование и коллаборация стали проще и быстрее.
- Экономия на инфраструктуре - приятный бонус.

Вывод:
Масштаб требует нестандартных решений. Discord показал, как кастомизация dbt может прокачать весь дата-стек.
А как вы оптимизируете свои ETL-процессы? Делитесь в комментах!