В последнем проекте для Surfalytics мы изучали SQLMesh.

Раньше я думал, что это имеет отношение к Data Mesh подходу. Оказывается, это конкурент dbt. То есть, решает такие же задачи, как dbt - трансформация с помощью SQL внутри хранилища данных. (T в ELT).

Инструмент тоже open source. Некоторые вещи реализованы по другому, например у них главная фишка - это виртуальные среды. Если в dbt мы сами выбираем физическое место (схему, базу), где dbt будет создавать таблицы и вьюхи, то в SQLMesh у нас этот процесс управляется виртуальными средами. (Тут больше про envs https://tobikodata.com/virtual-data-environments.html)

Есть и другие плюшки, например встроенный CRON (ставить модели на расписание), SQL клиент в UI, CI/CD бот, аналог SDF (SQL компилятор на базе SQLglot).

У них есть интеграция для dbt/dlt, то есть вы можете легко мигрировать ваши dbt проекты на SQLMesh.

Еще из интересного - они не пустили основателя на конференцию dbt.

Вот что пишут в статье про сравнение dbt и SQLMesh:

Стоит ли выбрать SQLMesh вместо dbt?
На мой взгляд, если вас заботят инженерные аспекты построения конвейеров данных (а это важно), или если дата-инженеры создают и управляют "T", то вам стоит выбрать SQLMesh.

Нужен ли вам широкий набор интеграций с различными платформами и инструментами для работы с данными и/или хотите использовать что-то с более крупным, зрелым сообществом? Тогда, возможно, стоит остановиться на dbt.

Если кратко, я бы сказал, что выбор между SQLMesh и dbt сводится к тому, стоит ли дополнительная сложность SQLMesh того для вас и вашей команды. Интеграции с другими инструментами и зрелость сообщества со временем подтянутся.

Следует отметить, что SQLMesh совместим с dbt, что означает возможность использования SQLMesh поверх существующего проекта dbt в качестве обёртки, используя функции SQLMesh, такие как виртуальные среды данных. Возможно, стоит попробовать и посмотреть, понравится ли вам SQLMesh?

Также не забывайте, что SQLMesh НЕ заставляет писать огромное количество yaml и Jinja. Некоторым нравится иметь всё в yaml, но я предпочитаю определять метаданные прямо в файлах моделей. Меньше переключений контекста - лучше для меня. Мне также никогда не нравился синтаксис Jinja. SQLMesh позволяет использовать чистый Python, что является большим плюсом.

Мое мнение: я бы не стал изучать SQLMesh, так как dbt очень популярный, работает отлично, большое сообщество, есть VC деньги на развитие продукта и есть спрос на такие скилы. SQLMesh это нишевой продукт, который больше подходит энтузиастам, которые любят плыть против течения и у них много свободного времени, чтобы внедрять такие решения. Главная цель пробовать такие нишевые продукты - быть в теме и такие insights порождают хороший диалог с нанимающим менеджером.

По плану дальше на проектах изучить:
- open source BI: Metabase, Superset, Evidence
- локальная оркестрация контейнеров (docker stack, kind, Minikube)
- GenAI функциональность Snowflake и Databricks

Из этих кубиков мы можем строить более большие проекты.

На январских праздниках я успел заехать в Питер, сходил на Щелкунчика в Мариинский театр (сравнил его с Щелкунчиком в Большом театре и в Ванкувере), посетил кафе Счастье и ресторан Joli. Покатался на льду по тротуарам (реально опасно передвигаться зимой).

Но самое прикольное, я встретился с 2мя дата профи, это Николай Валотти, автором Left Join и Сергей Громов, основатель компании BI Consult (самый аутентичный дизайн сайта, который я видел).

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

Так же познакомился в BI Consult с Жанной, руководителем направления обучения. Они рассказали, что хотели бы найти человека, кому интересно преподавать корпоративным клиентам. Я попросил поделится информацией, чтобы расшарить в канале, вдруг кому интересно и у кого-то есть желание диверсицировать свои доходы и подрабатывать преподавателем.

Учебный центр "BI Consult" успешно функционирует с 2018 года. В числе слушателей курсов сотрудники компаний нефтегазовой и финансовой отрасли, розничной торговли и производства.

Сейчас учебный центр в поиске эксперта в области DWH для прочтения курсов “Современная архитектура хранилища данных” и "Курс по DWH".

Что важно:
✔️Практический опыт сбора, хранения и обработки больших объемов данных с использованием OLTP, ETL, DWH и Data Lake, также работы с различными типами баз данных, включая традиционные SQL-базы данных и современные NoSQL-базы данных
✔️Понимание специфики столбцовой организации хранения данных
✔️Умение проектировать хранилища данных, используя методики Data Vault и Anchor Modeling
✔️Опыт работы с инструментами оркестрации и обработки данных в реальном времени
✔️Понимание принципа работы средств визуализации данных (BI)
✔️Понимание принципа работы машинного обучения в контексте инженерии данных и различий разновидностей машинного обучения в области анализа данных (Data Mining) и машинного обучения (Machine Learning)
✔️Желание рассказать и научить других строить архитектуру данных

Формат работы: Онлайн-курсы, несколько раз в год.

Своё резюме высылайте Жанне в личные сообщения: @Ghannaleto

Вы наверно уже видел и слышали про курс Анастасии Кузнецовой, автора канала Настенька укротительница диких графиков? Если нет, то я тоже поделюсь ссылкой.

Курс “Гибкий График” - 11 глав, куча домашек с обратной связью от графиков до дэшбордов 🤓

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

Почему я его рекомендую?

1. Мне нравится узкая специализация и экспертиза Анастасии про создание бизнес дашбордов (или дэшбордов).
2. Сам курс это агрегация многолетнего опыта в создание эффективных dashboards.
3. Я сам лично уже написал пару статей с Настей и мы пишем сейчас еще одну про подход Amazon - Weekly Business Review.
4. Я всегда рад поддержать экспертов, которые своими силами создают полезный контент, которые rise the bar в русско-язычном дата сообществе.

Вакансии по аналитике и системному анализу в Data Analytics Team компании Атом, создающей электромобиль-гаджет 🚙  и его версии для семьи, такси, каршеринга и службы доставки

Тут можно посмотреть ролик о проекте ▶️🎥

➕ Senior BI Analyst

Ищем биай аналитика, который будет заниматься визуализацией данных в дашбордах

Основные задачи:
Разрабатывать дашборды в Yandex DataLens 📊
Собирать и ставить требования на создание и доработку витрин данных
Анализировать данные для поиска инсайтов и презентовать результаты
Вести документацию по проектам

Нужны:
Опыт в аналогичной роли от 5 лет
Продвинутые навыки визуализации и знание UX/UI подходов 🎨
Уверенное владение Yandex DataLens или другими BI-инструментами
Глубокие знания SQL и понимание моделей и баз данных (PostgreSQL, ClickHouse)
Широкий кругозор в бизнес-доменах и понимание их специфики

Как откликнуться:
Отправить резюме в Telegram @FiestaTS, на почту Tatiana.Suslina@atom.team или оставить отклик на Hh.ru 📲📩

➕ Senior System Analyst

Ищем системного аналитика, который будет работать на стыке бизнеса и разработки

Основные задачи:
Анализ и формализация бизнес-требований
Проектирование процессов и интеграций
Участие в разработке технической документации
Взаимодействие с командами разработки, тестирования и бизнес-заказчиками 🤝

Нужны:
Опыт работы системным аналитиком от 4 лет в сфере DWH/Datalake
Работа с потоковыми и пакетными данными
Понимание различий между Datalake и DWH и их задач
Владение SQL на уровне сложных запросов (оконные функции, CTE и т.д.)
Уверенное знание Python 🐍
Опыт работы с базами данных: ClickHouse, PostgreSQL, Hive/Impala, Trino
Построение моделей данных: Data Vault, Inmon, Kimball
Опыт проектирования API (REST, GraphQL)

Как откликнуться:
Отправить резюме в Telegram @FiestaTS, на почту Tatiana.Suslina@atom.team или оставить отклик на Hh.ru 📲📩

Snowflake in Talks to Acquire Analytics Startup Redpanda By Kevin McLaughlin

Что такое Snowflake вы знаете. Snowflake это хранилище данных это аналитическая платформа, которая позволяет:
- создавать хранилище данных
- работать с данными в браузере (SnowSight) используя SQL или Python (SnowPark)
- возможность создавать веб-приложения на базе Streamlit (open source решение, которое Snowflake купил)
- создавать Stored Procedures прям как в PL/SQL в Oracle или T-SQL в SQL Server (можно на SQL, можно и на другом языке). Работает отлично - бесплатная замена dbt для трансформации данных
- ставить на расписание ваши запросы (jobs) с использованием Tasks
- интеграция с Apache Iceberg, свой Iceberg каталог Polaris
- поддержка стриминга через Pipes, Dynamic таблиц
- своя кривая LLM Arctic
- возможность хостить контейнеры (сам еще не проверял)
- создавать Data Apps на любой цвет и вкус (для монетизации своих данных)
- Data Sharing, большой маркетплейс различных приложений, вендоров, данных

Это первое, что пришло в голову про Snowflake. То есть это целая платформа. И стриминг - это не сильная сторона Snowflake.

А что такое RedPanda?

Redpanda – это высокопроизводительный потоковый движок, совместимый с Apache Kafka.

🔹 Ключевые особенности Redpanda:
1. Совместимость с Kafka API – поддерживает основные API Kafka (Producers, Consumers, Streams), что позволяет использовать Redpanda без изменения существующего кода Kafka-приложений.
2. Отказоустойчивость и высокая производительность – написан на C++ и использует локальную память и NVMe-диски для ускорения обработки событий.
3. Не требует Zookeeper – в отличие от Kafka, в Redpanda отказались от Zookeeper в пользу встроенной системы управления метаданными.
4. Меньше ресурсов, выше скорость – за счет оптимизированного использования процессора, памяти и хранения данных Redpanda показывает на 5-10 раз меньшую задержку, чем Kafka.
5. Поддержка WebAssembly (Wasm) – можно писать кастомные трансформации данных прямо в стриме, без внешних обработчиков.
6. Лучше работает в Kubernetes – Redpanda легче масштабируется и лучше интегрируется с облачными средами, чем Kafka.

Если Snowflake купит их, то они усилят свои позиции по стримингу, потому что у их главного конкурента Databricks все очень хорошо в этом плане с Apache Spark Structured Streaming.

Как-то я видел пост чувака, который нанял ассистента и посадил его за своей спиной и оплачивал фулл-тайм.

Главная задача ассистента - не давать чуваку отвлекаться от работы. Эффект был настолько крут по эффективности, что окупил все затраты.

Я даже сам проводил эксперимент, рядом сажал жену и она меня гоняла каждый раз как я пытался открыть телеграмм или LinkedIn.

Одно время я хотел снять коворкинг с товарищем, чтобы двоем там работать и подгонять друг друга.

А сегодня я узнал про термин для этого в посте у Кати - body doubling

На днях у меня произошла замечательная история про помощь AI (Claude, ChatGPT).

Задача:

На одном из проектов я использую Snowflake. Для повышения безопасности я решил обновить сервисных пользователей и перевести их с User/Password на User/Key-pair (private/public key).

Многие системы поддерживают этот метод из коробки, например dbt Labs, Sigma BI, Azure Data Factory. Однако некоторые не поддерживают его вовсе, что, конечно, не очень хорошо. Например, сервис блокнотов DeepNote.

Также, как и на нашем недавнем вебинаре по dbt core на Postgres, у меня есть CI (Continuous Integration) шаг, который запускает dbt.

Раньше я передавал пароль пользователя в GitHub Actions через GitHub Secrets.

Теперь же решил передать private key.

Вместо того чтобы просто скопировать ключ в GitHub Secret как есть, я решил спросить у чата, как сделать это быстро и правильно.

Чат не предложил просто вставить ключ (copy-paste), а начал чудить с декодированием, типа:

cat rsa_github_dbt_dev_user.p8 | base64

Base64 кодирует данные в этот формат, и я сохраняю результат в GitHub Secret.

Затем он предложил в YAML-файле GitHub Action обратно декодировать его с помощью:

base64 --decode

При этом вместо secret он предложил использовать переменную env, из-за чего мой ключ попадал в логи в открытом виде.

В итоге простая задачка неожиданно превратилась в небыструю.

Чат предлагал столько разных вариантов работы с ключами, вплоть до модификации логов, чтобы спрятать ключ от посторонних глаз.

В конце концов я просто сохранил ключ как есть – и всё заработало.

Кажется, у всех бывают такие истории. Хотел как лучше, а получилось как всегда. Уже даже мемы на эту тему есть – как бот пишет код за 5 минут, а мы потом часами его траблшутим. 😅