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

Курс “Гибкий График” - 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 минут, а мы потом часами его траблшутим. 😅

Привет из LA!