Nik в мире данных

Привет, чатик! 👋
Мы готовим возвращение наших онлайн митапов и планируем первый из них уже в феврале (предварительно).

Ищем спикеров с темами из нашего modern (а иногда уже и не modern) дата-стека!

Особенно будем рады докладам о:
Новинках и трендах в индустрии.
Опыт с SQLMesh, DLT и др в проде.
Инсайтах и практиках в области DataOps, DQ
.
Если у вас есть, чем поделиться, и вы хотите выступить — напишите мне! @nikbeesti

Ищем спикеров на наш февральский онлайн митап от modern data stack чатика @dbt_users

Если есть чем поделиться, напишите мне

Обнаружил интересный пост - https://javisantana.com/2024/11/30/learnings-after-4-years-data-eng.html

90% утверждений резонируют с моим опытом

People focus on learning the tools, which is good, but they forget about principles.

Перейти с одного решения на другое для 99% задач потребует неделю знакомства с инструментом и изучения архитектуры нового решения 😎. Есть небольшое число задач, требуемое максимальной оптимизации и знания кишков, но такая оптимизация является внутренним решением с структурой данных, придуманной под него и разрабатывается итерационно

Ingestion is 80% of the job but usually it’s not even monitored.

Загрузка данных в базу данных / файловую систему - то место, которое часто можно ускорить за небольшие усилия. Особенно, если у вас какое-то самописное решение по вставке данных. ✨

Data quality is like unit testing but in production.

Как фанат WAP паттерна, полностью поддерживаю такое. У меня были разговоры с принципал инженерами, почему у нас нет покрытия юнит тестами, и зачем нам runtime проверки. Считаю, что технические проверки должны быть у каждого ETL при загрузке (а в идеале и бизнес-проверки в том числе). На паре проектов у меня было, что косты dq были почти такие же, как косты ETL загрузок.

Most companies just need basic bash / make knowledge, a single instance SQL processing engine (DuckDB, CHDB or a few python scripts), a distributed file system, git and a developer workflow (CI/CD).

Ну это прямо база. Один раз я решал задачу переписывания загрузки сотен мегабайт в неделю (!!!) через Apache Spark и Hadoop. Задача оптимизации заключалась сделать так, чтобы нетворк и shuffle был минимален и все считалось на одной ноде 😂 А выбрать другую архитектуру нельзя было, так как архитекторы банка решили, что все витрины должны считаться в хадупе 👋

There is always a schema. You decide on it when you write the data or later when you read it, but at some point, you need to decide attributes and data types for your data

В экстремальном случае уже на уровне дата продукта / витрины появляется схема и разбор полустуктурированных данных произойдет на этапе подготовки данных. Так что парсинг JSON потребуется все равно =)

15 ноября старт DE буткемпа от американского инфлюенсера Zach Wilson

https://www.youtube.com/watch?v=myhe0LXpCeo

Будет интересно сравнить с DE Zoomcamp

Запись прошедшего разговора - https://www.youtube.com/watch?v=sqLCAjc9DYQ

Получилось по ощущениям интересно, но микрофон немного подкачал (Я зафейлил с настройкого основного)

Слайды - https://link.excalidraw.com/p/readonly/JZ3p956Nz1zqNdJ0hmFg ( В Safari у меня почему-то не ренедерятся, в Google Chrome норм)

Во вторник, 12 марта в 19:00 GMT+0 разбираем как устроены интервью для Дата инженеров

В гостях - Ник, автор канала @analytics_engineer

Кликайте Notify me чтобы не пропустить 😎 и приходите задавать вопросы в комменты!

Ссылка на стрим
https://youtube.com/live/vWYbsbnJphI?feature=share

Залетел на подкаст / разговоры в FAANGTalk кекспертом эскпертом по DE 😂 на выпуск про дата инженерию.

Главным спикером был Vladimir Elfimov и видео стоит послушать ради него и презентации.
Я врывался пару раз с крайне важными вопросами, по типу мертв ли Hadoop 👋 и является ли Excel Reverse-ETL или ML системой 🤯

Обсудили такие темы:
- История развития Data Engineering
- «Большие данные» и его отличие от «средних данных».
- Инструменты Data Engineering, и отличия от Data Science и Data Analytics
- C-level в сфере Data Engineering (CDO, CIO, CAO).

Немного затронули:
- Обработка данных. Отличия между pull и push системами, batch и streaming обработкой данных
- Data Warehouse, Data Marts, Data Lake, Data Platform, Data Mesh и Data LakeHouse
- Планирование дата-архитектуры и сложности, связанные с этим процессом

Само видео: https://www.youtube.com/watch?v=VyUqrYfj_yY

#datadesign
WAP Pattern

Знаете ли вы, что такое WAP (Write - Audit - Publish. ) паттерн в дата инженерии? Скорее всего, многие из вас им уже пользуются! 🤔
Я объясню это на коленке, желающим детальных кишочек -> в ссылки снизу. 📌

Представим, я инженер в компании Colt 👍, и мы занимаемся доставкой еды. Моя зона ответственности - end-to-end решение для ежедневной отчетности в разрезе городов (прибыль, количество доставок, средний чек, среднее время доставки, ...).

У меня есть проблема с источником данных по возвратам денег (допустим кому-то что-то не доставили, и вам возвращают денег на счет). Он обновляется непостоянно, так еще и иногда там часто бывают ошибки в данных. 🆗

Когда менеджеры смотрят мой отчет, они недовольны тем, что цифры, которые они видели вчера резко меняются после обновлений. Они не верят нашим данным, поэтому продолжают использовать свои проверенные эксели. А я не получаю свой заслуженный promotion.😂

Что же делать? Мы можем добавить тесты! 👍 Но возникает дилемма - скорость доставки vs качество. Если взять dbt как инструмент, то базовая имплементация тестов выглядит следующим образом -> прогнали модель, запустили тест над моделью, если тест упал, анализируем. Но если это уже презентационный слой, то конечные пользователи уже увидят эти данные. Мы можем настроить алертинг, но кто будет в него смотреть.👨‍🦳

Поэтому в случае критичных отчетов / дата продуктов, можно применить подход WAP.

- Write. Записываем данные в stage таблицу / объект
- Audit. Проверяем качество и полноту данных на уровне stage таблицы. Есть проблема -> автоматический алерт команде и on-call инженер с радостью разбирается 😮 (можно еще больше автоматизировать в случае повторяемых случаев, например сразу с ноги выбивать дверь к коллегам с источника писать письмо / заводить инцидент ).
- Publish. Если все тесты успешно прошли, кладем в Publish слой. Это можно делать как логически (синонимы, линки на файловой системы, переопределение view, alter/modify partition, ...) или физически (ETL).

Есть еще один use-case применения WAP паттерна. Далеко не все системы поддерживают ACID транзакции, а те, которые поддерживают, не всегда готовы часами ждать тяжелых расчетов. Для организации консистентности (ну или чаще уменьшения неконсистентного промежутка по времени) вы можете подготовить свои 20+ таблиц в стейдже, а потом переключить их одновременно в презентационном слое. 🍷

Недостатки? Данные будут устаревшие, поэтому нам надо быстро сообщить об этом пользователям, чтобы они не сообщили об этом нам!🙂

Кроме этого, далеко не всегда причина может быть устранена быстро, но что с этим делать, обсудим в следующих постах.😵




Cсылочки 💻
- Верхнеуровневое обсуждение - https://lakefs.io/blog/data-engineering-patterns-write-audit-publish/
- Пример имплементации - https://lakefs.io/blog/write-audit-publish-with-lakefs/ , продолжение - https://lakefs.io/blog/write-audit-publish-with-lakefs/ и https://dagster.io/blog/python-write-audit-publish
- Видео - https://www.youtube.com/watch?v=fXHdeBnpXrg (в целом хорошее видео, сам WAP pattern с 16 минуты)
- Презентация для Iceberg - https://www.dremio.com/wp-content/uploads/2022/05/Sam-Redai-The-Write-Audit-Publish-Pattern-via-Apache-Iceberg.pdf

#никчитает
Обзор на Analytics Engineering with SQL and dbt

Сегодня узнал о выходе книги Analytics Engineering в O'Reilly with SQL and dbt - https://www.oreilly.com/library/view/analytics-engineering-with/9781098142377/

Автор был бы не автором, если бы ее уже не прочитал =)

Пройдемся по главам

1. Analytics Engineering. Обзорная глава про историю, появление и кто такие эти analytics engineers. Корни AE, откуда взялся BI, как в Cloud Era появились решения, демократизирующие инструментарий. Рассказ про жизненный цикл дата аналитики (-> Определение проблемы -> Моделирование данных -> Внедрение данных и трансформация -> Хранение данных и структурирование -> Визуализация данных -> DQ, мониторинг, тестированик и документировние ).
Обсуждают роль и ответственность AE, базовое обсуждение Data mesh и Data product, переход от легаси BI/ETL систем (с visual-coding etl и процедурными расширениями) в modern data stack (с visual-coding etl и процедурными расширениями, прим. Nik 🙂)

2. Data Modeling. Глава про моделирование данных. КМД, ЛМД и ФМД, нормализацию (да-да, нормальные формы в 2к24 😂), базовое ведение в схему звезда/снежинка с упоминанием Кимбала и Инмона, и невнятный параграф про Data Vault 😡. Обсуждается переход от монолитного дата моделирования к модульному дата моделировани. В конце вводят Medallion Architecture Pattern. Последнее, это просто Bronze-Silver-Gold layers - https://www.databricks.com/glossary/medallion-architecture

3. SQL For Analytics. 🔥 Рассказывают про основы SQL с оконками, join как обычно через диграммы Венна 😺. Вторая часть - про SQL for Distributed Data Processing, используя DuckDB, Polaris, и FugueSQL 🤯 (новое для меня).

4. Data Transformation with dbt.😃 Основы dbt, причем показывают как запускать только для dbt cloud (никакой core настройки не описано).

5. Dbt Advanced Topics😃. Кратко обсуждают такие понятия, как материализация, jinja шаблоны, макросы, пакеты и semantic layer.

6. Building An End-to-End Analytics Engineering Use Case 👍. Показывают полноценное "end-to-end" решение от заливки сырых данных в BigQuery из MySQL до финальной витрины данных и ad-hoc аналитики. 😎Треть главы уделена тому, как делать архитектуру дата решения (как определяем бизнес-процесс, понимаем, какие данные нужны, моделируем). Сначала проектируем - потом кодим. 🔥

⚡️Книга оставила смешанное впечатление. В плюс занесу 1 и 6 главу. В главе 2 про дата моделирование получилась какая-то каша терминов, и я не увидел какой-то раскрытости. 3 глава представляет собой базовое введение в SQL, и добавление про DuckDB, которое дальше вообще никак не используется 4 и 5 главы про dbt, уступают dbt мануалам.
Из минусов таже отмечу отсутствие Further Reading или доп материалов.
Читая книгу, я словил дежавю, как будто это мини-курс Analytics Engineer (Аналитик DWH) на ОТУС времен 2022 годов. Разрозненный материал, с разными доменными примерами и технологиями от главы к главе, который надо собрать как-то у себя в голове.


🙆Оценка 3/5. Подойдет, как доп. материал к dbt курсам, если у вас есть подписка O'Reilly.

Database in 2023 A Year in Review

Обзор 2023 от Andy Pavlo. https://ottertune.com/blog/2023-databases-retrospective

- Векторные базы данных (ну или векторные поисковые движки) сильно в тренде в DS кругах. Я лично о них услышал в декабре, но в 2024 потрачу время на изучение. В статье сравнивают vector database и relational databases - https://www.youtube.com/watch?v=jDhVEjgCHGk&t=3s
- Обзор SQL: 2023 стандарта и SQL/PGQ. Property Graph Queries (SQL/PGQ): выглядят офигенно. Надо бы сделать еще 1 попытку прочитать современный стандарт 🙂
- Проблемы MariaDB. Мы только недавно добавили интеграцию с MariaDB на проекте, но до корпоратов это докатится года через 3-4, если будет поворо обратно к MySQL
- Рынок VS-финансирования СУБД проектов уменьшился, но есть интересные проекты в списке. Также Andy написал, что большему числу студентов потребовалась помощь в поиске internship.
- В конце обсуждается американская специфика о Larry Ellison, Elon Musk, и их взаимотношения. Рад, что Oracle снова на коне. Oracle как СУБД для меня точно в топ-3 по удобству и широты использования.

​​Hello wonderful people!
I’m thrilled to announce that my new book, “Grokking Concurrency,” has officially hit the shelves!
This book dives deep into the concept of concurrency, making it accessible and practical for software engineers, computer science enthusiasts and data engineers, I believe this book can be valuable to many. It's packed with insights, real-world examples, and practical tips. And, most importantly, with cool visualizations. You can find it here: https://www.manning.com/books/grokking-concurrency
I could really use your support in spreading the word! You can support me by:
1. spreading the news on social media
2. writing reviews (on amazon, goodreads or whatever people use nowadays)
3. mentioning to your colleagues, neighbors, and pets
Thank you so much for your support!

Вышла книга Grokking Concurrency.
Автор книги - Senior Data Engineer в Spotify и ведет https://luminousmen.com (думаю, многие видели этот блог)

Я просмотрел содержание книги (благо есть manning подписочка) и однозначно добавлю ее в reading list на этот год, так как планирую подтянуть свой теорикрафт по concurrency и distributed системам.

Книга кажется неплохим введением для этого, чтобы потом вернуться к зубодробительным томам по CS. Примеры на питоне, и покрываются такие темы как процессы, треды, тред пулы, multitasking, semaphores, non-blocking i/o, coroutines, ...
Для суровых дата инженеров может быть повторением того, что знают, а нам, склщикам головного мозга, будет введением в тематику.

SQL  и CASE WHEN

CASE - знакомое многим выражение SQL для условий. Я хотел бы показать варианты использования CASE WHEN, о которых может быть не известно

Все примеры из public datasets в Bigquery. В основном будем использовать таблицу заказов для примеров. То, что можно так сделать с точки зрения синтаксиса не значит, что так стоит делать, всегда думайте о поддерживаемости и читабельности

CASE в агрегатной функции
Нужно вывести для каждого пользователя последние даты отмененного, возвращенного и завершенного заказов.

SELECT user_id,
MAX(case when status = 'Cancelled' THEN created_at END)
  AS last_cancelled_dt,
MAX(case when status = 'Returned' THEN returned_at END) 
  AS last_returned_dt,
MAX(case when status = 'Complete' THEN delivered_at END) 
  AS last_complted_at
FROM bigquery-public-data.thelook_ecommerce.orders
GROUP BY user_id

CASE в Order by оконной функции

Для каждого пользователя вывести последнюю дату отменненого заказа, а если у него не было отменненых заказов, последнюю дату возвращенного заказа

SELECT distinct user_id,
LAST_VALUE(CASE WHEN status = 'Cancelled' THEN created_at
                WHEN Status = 'Returned' THEN returned_at END)
  OVER
  (PARTITION BY user_id
  ORDER BY
   CASE WHEN status = 'Cancelled' THEN 2 
        WHEN status = 'Returned' THEN 1 
        ELSE 0 END,
    CASE WHEN status = 'Cancelled' THEN created_at
            WHEN Status = 'Returned' THEN returned_at 
        END
  ROWS BETWEEN UNBOUNDED PRECEDING
   AND UNBOUNDED FOLLOWING )
FROM bigquery-public-data.thelook_ecommerce.orders

CASE в джоинах

Убедиться что дата активности заказа не произошла на выходной день

SELECT ord.user_id, count(distinct ord.order_id)
FROM `bigquery-public-data.thelook_ecommerce.orders` ord
LEFT JOIN `bigquery-public-data.ml_datasets.holidays_and_events_for_forecasting` h
ON h.region = 'DE'
AND CASE WHEN status = 'Cancelled' THEN DATE(created_at)
         WHEN status = 'Returned' THEN DATE(returned_at)
         WHEN status = 'Complete' THEN DATE(delivered_at)
    END = h.primary_date
WHERE h.primary_date IS NOT NULL
GROUP by ord.user_i

CASE в QUALIFY
Последний пример более искусственный, но показывает пример применения в QUALIFY

SELECT distinct user_id
FROM `bigquery-public-data.thelook_ecommerce.orders` 
QUALIFY 
  CASE WHEN user_id > 100 
    THEN 
    SUM(num_of_item * 
                CASE WHEN status = 'Complete' THEN 1 
                           WHEN status = 'Returned' THEN -1 
                           ELSE 0 
                END) 
         OVER (PARTITION BY user_id 
                     ORDER BY created_at 
                     ROWS BETWEEN UNBOUNDED PRECEDING 
                                 AND UNBOUNDED FOLLOWING)
    ELSE  
    SUM(num_of_item * 
                 CASE WHEN status = 'Complete' THEN 2 
                           WHEN status = 'Returned' THEN -0.5 
                            ELSE 0 
                  END) 
        OVER (PARTITION BY user_id 
                    ORDER BY created_at 
                    ROWS BETWEEN UNBOUNDED PRECEDING 
                               AND UNBOUNDED FOLLOWING)
  END > 2

Опыт собеседования на позицию Senior Staff Data Engineer 🤔

Недавно я принял участие в собеседовании на должность Senior Staff Data Engineer (Data Architecture) в компанию из сферы foodtech. Хотя я и не ищу совсем работу, мне было интересно пощупать немецкий рынок и попробовать себя в интервью на позицию Staff DE и роль была связана с дата моделированием.

Первоначальный контакт с рекрутером ☎️

Рекрутер нашёл меня в LinkedIn был краткий 10-15 минутный звонок. Обсуждали вакансию, мои ожидания, текущее состояние компании, мои интересы к роли и следующие шаги.

Собеседование с hiring manager 😃

Следующим этапом было интервью с непосредственным менеджером, которое было смесью проектного и подходящего интервью. Обсуждали весь скоуп по дата инженерии, особое внимание уделили end-to-end и CI/CD процессам, где у меня меньше опыта и я часто работаю с нестандартными решениями. На Q&A довольно откровенно отвечали о текущих болячках и что нужно улучшать.

Coding 👩‍💻

Техническое интервью по программированию было нестандартным и ориентированным на Data Engineering. За 90 минут предполагалось решить 2-3 задачи (batch, SQL, streaming). Собесил Staff DE.
Batch-задача - написать ETL на псевдо-Spark, включая базовые вопросы о partition pruning, partitioning и обработке dataframe.
SQL-задача - классика около-FAANG – создание модели данных и написание инкрементного заполнения. Как SQL-гик я постоянно докидывал corner case :D.
Streaming решили не делать поскольку оставалось 25 минут, и была расширенная Q&A сессия, где я поспрашивал про работу стаффом, организацию внутри команды, компании, и процессам.

СисДиз 😵

Интервью по системному дизайну было довольно стандартным. Было 2 интервьюера - Senior Staff DE и Staff SWE (или наоборот :D). Задача была связана с данными, но не требовала серьёзного масштабирования после анализа входных параметров.
На детальной части обсуждали Kafka, топики и схемы. А затем мы похоливарили с интервьюерам, так как они вели к одному решению, но оно мне не нравилось :D. Q&A было 5 минутным, так что просто спросил про работу стаффом в компании.

Обратная связь №1 👍

Рекрутер сделал фидбек по интервью.
По кодингу был strong go 😂, но был сделан акцент на то, что я усложнил SQL-часть, постоянно увеличивая сложность задачи.
По системному дизайну дали фидбек как улучшить процесс в целом.
По менеджерскому интервью было отмечено отсутствие глубины знаний CI/CD, частично из-за использования DBT Cloud, а не DBT Core.

Поведенческое интервью 👋

Финальный этап - интервью с VP of Data. Сначала он 20 минут рассказывал о компании, затем задавал поведенческие вопросы и обсуждал мои вопросы о работе в компании, практиках и сочетании data vault и data mesh. Почти не было bullshit, а были довольно четкие ответы с неплохой глубиной, но послевкусие было как будто бы не случилось фита.

Обратная связь №2 🚩

Перед второй сессией обратной связи мне уже сообщили об отказе, так что я был готов 👨‍🦳

В качестве фидбека  сказали, что решение принято уже на совместном обсуждении
Как плюсы - сильная ориентация на данные и аналитический подход, ориентация на клиента, предпочтение долгосрочного и стратегического подхода.
Отказ был обусловлен рядом факторов: неясные цели в отношении роли IC, не показал Learning never stops принцип, сомнения в том что буду адаптировн к быстроизменчивым средам.

Выводы ⚡️

Оценка рекрутеру - 5, компании и процессу интервью - 4, себе - 3+.
Что надо улучшить: начать уже готовиться к behaivoral interview, улучшить знания по сис дизу и английский с точки зрения коммуникации

А что по деньгам 💰
Компания была тир2 и была ожидаемой для вилки стаффа. Сам вилка, по моим ощущениям, это 105-130k  EUR base + 10-50k EUR bonus/RSU.

Channel photo updated

Data System Design Interview

Что это за зверь 🤔

Data system design - это подмножество сисдиз интервью, но с упором на data-driven задачу, где кандидат показывает способность построения систем в области хранения, управления и обработки данных.

Пример задачи 💁‍♂️
(Пример подробный, часто кандидат сам формулирует требования через диалог)

Мы компания Х, новая платформа для авторов. У каждого автора есть свое пространство и люди могут подписываться или отписываться от них. Запрос отписки может приходит либо от пользователя из UI интерфейса, отдельного запроса от департамента Customer Success или Legal (может содержать в себе большое число пользователей за один раз)

Нам необходимо разработать решение, у которого будет:
1. Возможность отправлять near real-time событие в уже разработанный UnsubMe сервис для отписки
2. Финальный отчет для сеньор менеджмента для анализа воронки отписок (с возможностью работы на разных уровнях агрегаций и времени)
3. Возможность для аналитиков осуществлять ad-hoc аналитику

Как проходит интервью 😅

Формат интервью обычно соответствует тем же временным рамкам, что и сис дизайн интервью (пример для интервью в 90 минут):

1. Интро (5 минут)
• Вы представляетесь друг другу и пара слов о бекграунде каждого. Для больших компаний обычно присутствуют 2 интервьюера.
2. Понимание проблемы и сбор требований (10-15 минут)
• Интервьюер описывает вам проблему и предлагает задавать вопросы
• Ваша задача проговорить функциональные и нефункциональные требования и те ограничения, которые будут приняты в виду ограничения по времени (например, если у вас задача по имплементации GDPR, то вы обсуждаете только часть удаления пользовательских данных)
• Также вы обсуждаете текущую нагрузку на систему и как это изменится в краткосрочной и среднесрочной перспективе
• В какой среде будет задача (клауд/гибрид/on-prem)? Есть ли доп ограничения вида Cloud Agnostic?
3. Высокоуровневый дизайн (15-20 минут)
• Вы совместно рисуете и обсуждает общую схему решения на уровне компонетов / сервисов / технологий. Тут часто бывают общие обсуждения уровня нужен ли нам дополнительной слой DWH, выбора синхронного или асинхронного метода передачи сообщения, необходимости какой-то шины данных и т.п.
4. Детальное обсуждения какого-то компонента (20-35 минут)
• Идет углубленное обсуждение какого-то компонента. В виду дата ориентированности, обычно это завязано на какой-то компонент стриминга, етл, дата модели и т.п.
5. (Опционально) Обсуждение оптимизаций, масштабирования или каких-то адаптаций для решения (10-15 минут)
• Такие обсуждения часто бывают в процессе предыдущих этапов или кандидат инициирует их
• Интервьюер может предложить изменение требований и спросить, какие адаптации надо сделать под них (например, подключение 3rd party vendor в примере компании X, который может работать с отписками)
6. Q&A и Вопросы Кандидата
• Обычная Q&A сессия, которая позволяет кандидату спросить про работу в компании

Примеры детальных обсуждений 👨‍🦳

Неполный список тем, который может быть в детальном обсуждении

• CDC. Как организовать, зачем, какой тип выбрать
• Message Broker, какой выбрать, какой критерий выбор, формат сообщений, какая модель обработки
• DWH. Нужен? Какая модель данных? Какие основные сущности будут?
• Качество данных. на каком этапе, какие тулзы, что покрыть
• Мониторинг. Что мониторить, как мониторить?
• Batch Processing. Как будет организована загрузка? Как выглядит инициализирующая / инкрементальная загрузка? Как ускорить загрузку?
• Оркестрация, как организовать, на каком этапе?

Как готовиться 😺
Курс/книги по системному дизайну (educative / карпов / System Design Interview от Alex Xu), общие книги по дата инженерии (Fundamentals of Data Engineering / DDIA) и более глубокое погружение в конкретные темы, которые могут всплыть.

Если времени не много, попробовать поделать мок интервью и по фидбеку пытаться что-то доизучить, но мок-интервьюеры смотрят на то, что интересно им, и могут упустить часть вещей. Я также провожу их в рамках моих менторинг сессий =)

Любой дата проект в одной картинке

Вторая неделя dbt meetup - https://space307.team/dbt-meetup

Расскажут про dbt и DataVault, как мигрировать 40+ DS/PA на dbt и не грустить и что такое экпозиция в dbt!

Мои слайды с dbt meetup #3