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!