5 minutes of data

Менторы и вкатуны Сегодня не совсем обычный пост. Просто хочу поделиться наблюдением. В последнее время всё чаще вижу в Telegram истории вроде: «Работал в крупной компании, выгорел, ушёл, теперь делаю свой канал или курс про системный дизайн». Звучит красиво. Опытный человек ушёл из корпорации и теперь делится знаниями. Но если честно — всё это выглядит немного странно. Средняя зарплата даже младшего инженера в большой компании — около 120К месяц. Если ты там был топ, то у тебя наверное от 500к зп была. И обычно внутри таких компаний можно спокойно сменить команду, стек или просто взять паузу. Никто не держит на «ночных созвонах по куберу». А потом человек уходит «в никуда» и начинает рассказывать, как устроена индустрия. Хотя сам уже давно в ней не работает. А технологии сегодня меняются слишком быстро, чтобы из «домашнего homelab» можно было кого-то учить. И ещё интересная тенденция — вчерашние джуны уже запускают свои каналы и менторские программы. Ко мне такие даже приходили с предложением рекламы. Я отказал. Было и так, что один из «менторов» когда-то приходил ко мне на собес — но я знал, что у него есть канал, где он учит крутить опыт. То есть он к нам на собес пошел , чтобы тупо слить ответы на вопросы. Конечно я ему отказал еще до собеседования. Я не против менторов вообще. Наоборот — хороший ментор может сильно сэкономить тебе время и силы. Но ментор — это не тот, кто продаёт курс, а тот, кто может показать тебе, как он сам работает. Если ищешь ментора — посмотри, что человек делает публично: выступает ли на конференциях, пишет ли статьи, делится ли опытом бесплатно(я делюсь видео на youtube). Это сразу многое скажет. И, пожалуйста, не ведитесь на обещания «300к после курса». Ни один нормальный инженер не обещает такого. За менторством в личку (шутка конечно) @five_minutes_of_data

Pipedash Десктопное приложение для управления CI/CD-пайплайнами от нескольких провайдеров Большинство команд разработчиков со временем используют несколько платформ CI/CD. Open source-проекты часто полагаются на GitHub Actions, внутренние сервисы могут работать на GitLab CI или Buildkite, нативные для Kubernetes — на Tekton, а обычно есть ещё какой-нибудь экземпляр Jenkins, который обслуживает legacy-системы. Чтобы всё проверить, приходится открывать кучу вкладок и вручную обновлять. Pipedash — собирает данные о пайплайнах из разных провайдеров и отображает их в одном месте. @five_minutes_of_data

pg_lake: Postgres for Iceberg and Data lakes Snowflake открыла исходники pg_lake — набора расширений, который превращает Postgres в настоящий lakehouse. Теперь Postgres может работать с Iceberg, транзакциями и данными прямо из S3 — и всё это через привычный SQL. Архитектура у pg_lake интересная. Он состоит из самого PostgreSQL с расширениями и отдельного процесса pgduck_server, где под капотом крутится DuckDB. Postgres отвечает за планирование и транзакции, а тяжёлые вычисления передаются DuckDB. Пользователь этого не замечает — всё работает прозрачно и быстро. История проекта тоже любопытная. Разработку pg_lake начали в Crunchy Data в 2024 году, чтобы добавить поддержку Iceberg в Postgres. Позже проект вырос в Crunchy Data Warehouse, а после покупки Crunchy компанией Snowflake был открыт под лицензией Apache. Первая публичная версия — 3.0, потому что две предыдущие существовали внутри Crunchy. Так что покупка open-source инструментов крупными вендорами не всегда означает, что проект закроют. Иногда, как в случае с pg_lake, это шанс дать технологии вторую жизнь и расширить её сообщество. @five_minutes_of_data

Прошлый пост Kafka is fast — I'll use Postgres вызвал неоднозначные реакции. И это хорошо — в инженерных обсуждениях всегда ценны разные точки зрения. На этот раз — взгляд с другой стороны. Почему идея просто используйте Postgres вместо Kafka на самом деле может быть вредной. Отличный разбор написал Gunnar Morling, разработчик Confluent и создатель Debezium. Он подробно объясняет, почему Postgres — не замена Kafka, и почему все советы в духе Kafka вам не нужен при вашем масштабе — скорее способ собрать лайки на Hacker News, чем реально полезная рекомендация. Postgres и Kafka решают совершенно разные задачи. Один — база данных, другой — платформа потоковой передачи событий. И выбор между ними всегда зависит не от моды, а от того, какую именно проблему вы решаете. Хорошая статья, особенно если вы задумывались, можно ли упростить архитектуру и обойтись без Kafka. @five_minutes_of_data

Прошлый пост Kafka is fast — I'll use Postgres вызвал неоднозначные реакции. И это хорошо — в инженерных обсуждениях всегда ценны разные точки зрения. На этот раз — взгляд с другой стороны. Почему идея просто используйте Postgres вместо Kafka на самом деле может быть вредной. Отличный разбор написал Gunnar Morling, разработчик Confluent и создатель Debezium. Он подробно объясняет, почему Postgres — не замена Kafka, и почему все советы в духе Kafka вам не нужен при вашем масштабе» — скорее способ собрать лайки на Hacker News, чем реально полезная рекомендация. Postgres и Kafka решают совершенно разные задачи. Один — база данных, другой — платформа потоковой передачи событий. И выбор между ними всегда зависит не от моды, а от того, какую именно проблему вы решаете. Хорошая статья, особенно если вы задумывались, можно ли упростить архитектуру и обойтись без Kafka. @five_minutes_of_data

Kafka is fast -- I'll use Postgres Кажется, за последние годы Kafka окончательно стала стандартом для потоковых систем. Её используют везде — от логов и аналитики до realtime-фичей и интеграций. Но недавно наткнулся на интересный разбор: действительно ли Kafka нужна всем? В статье “Kafka is fast — I’ll use Postgres” автор показывает, что для большинства задач pub/sub или очередей вполне хватает обычного Postgres. Он провёл серию бенчмарков и показал, что Postgres спокойно выдерживает десятки тысяч сообщений в секунду без лишней сложности — без брокеров, топиков и кластеров. Если нагрузка не огромная и вам не нужна распределённая стриминговая система, Kafka может быть избыточна. В таких случаях Postgres решает задачу проще, дешевле и надёжнее. Хорошее напоминание, что не всегда стоит выбирать “самую продвинутую” технологию — иногда достаточно просто выбрать подходящую. Оригинал @five_minutes_of_data

The 9 Ways to Move Data Kafka -> Iceberg Интересный пост, в котором рассказывают разные варианты доставки данных в iceberg из Kafka или других стриминговых систем. @five_minutes_of_data

Redpanda становится AI компанией Их видение — стать Agentic Data Plane. Агентский План Данных (ADP), насколько я понимаю, будет слоем данных вокруг ваших ИИ-агентов. Он состоит из: ⦁ шлюза ИИ, который позволяет агенту использовать LLM — локально размещённые (например, Llama) или публичные API (например, OpenAI, Claude) ⦁ шлюза MCP с серверами MCP для ваших сторонних систем (Google Drive, Github, таблицы Iceberg) ⦁ утилит для ИИ-агентов, таких как логирование событий аудита или действия, зависящие от человека ADP — это по сути middleware, который посредничает в взаимодействиях Agent<->System. Приобретение Benthos Год назад Redpanda приобрела Benthos и переименовала её в Redpanda Connect (RPC). Это что то, как смесь между Kafka Streams и Kafka Connect. У неё 300+ коннекторов к внешним системам и возможность применять трансформации к данным (обогащение, группировка, маппинг и т.д.). В новом "MCP Mode" RPC не перемещает данные в/из — вместо этого он создаёт сервер MCP из low-code YAML-определения. Поскольку RPC может общаться с 300+ системами, он может создать сервер MCP для любой из них с помощью нескольких строк кода. Поддерживает трансформации — вы можете трансформировать запросы MCP на лету (например, фильтровать данные) или добавить middleware (например, аудит-логгинг). Приобретение Oxla Redpanda только что приобрела Oxla — data warehouse, построенный на базе Postgres с разнесённой архитектурой compute/storage. Он оптимизирован для сложных запросов, включающих множественные джойны. Oxla будет выполнять роль предоставления агентам SQL-интерфейса для: ⦁ чтения из Iceberg и Kafka-данных (как в Streambased) ⦁ хранения/извлечения данных с низкой задержкой (generic DB, насколько я понимаю) @five_minutes_of_data

Как меняется архитектура data-инфраструктуры — по версии a16z Последние пару лет кажется, что рынок data-инфраструктуры застыл — те же хранилища, те же пайплайны. Но если посмотреть внимательнее, происходит куда более глубокая перестройка. Andreessen Horowitz выпустили обновлённый обзор Emerging Architectures for Modern Data Infrastructure — пожалуй, самый важный текст, если вы хотите понять, куда движется индустрия data-платформ. Главная мысль — ядро стека почти не меняется. Snowflake, Databricks, Kafka, dbt, Airflow — всё это остаётся фундаментом. Зато вокруг него растёт целая экосистема новых слоёв: observability, discovery, metrics layer, reverse ETL, feature stores, MLOps. Когда данные становятся более структурированными и доступны, поверх них естественно начинают появляться новые приложения — аналитические, ML и даже продуктовые. Интересно, как авторы формулируют идею data-платформенной гипотезы. Бэкенд постепенно консолидируется — ingestion, storage, compute, transform занимают несколько крупных игроков вроде Snowflake и Databricks, теперь и Fivetran. А на этой базе начинают жить все остальные уровни — BI, ML, аналитика, бизнес-приложения. И чем дальше, тем труднее выйти из такой платформы — слишком много завязано внутри. Из интересного: - растёт интерес к metrics layer (dbt, Transform, Supergrain) — стандартный слой метрик поверх warehouse; - усиливается adoption reverse ETL (Hightouch, Census), возвращающий данные в CRM и другие операционные системы; - укрепляется подход lakehouse — Iceberg, Delta, Hudi становятся стандартом; - стриминг переживает второе дыхание с Materialize, Upsolver и решениями от Databricks и Confluent. Кажется, мы постепенно переходим от набора инструментов к полноценным data-платформам, а дальше — к продуктам, где данные не просто хранятся, а реально работают. @five_minutes_of_data

A Great Day Out With... Apache Kafka Интерактивная карта всей экосистемы Kafka. В этой карте собрано все, что вам может понадобиться при работе с Kafka. Это: - Книги - Блоги - Учебные материалы - Инструменты и многое другое. Карту составил Gunnar Morling - разаработчик в Confluent, один из разработчиков Debezium и автор kcctl (open-source CLI тулза для работы с Kafka) @data_whisperer

Как DiDi выбрала StarRocks вместо ClickHouse для real-time риск-инжиниринга DiDi — крупнейший китайский сервис такси с 550 млн пользователей и огромными объёмами транзакций. Для таких систем real-time риск-инжиниринг — критичный компонент. Нужно быстро определять подозрительные операции, отклонять заявки по кредитам и анализировать поведение водителей и пассажиров — всё в реальном времени. Исторически такие задачи решают через Lambda- или Kappa-архитектуры. Lambda разделяет потоки и батчи, что создаёт дублирование логики и задержки. Kappa убирает batch-слой, но не справляется с историческими данными и хранением. DiDi пробовали унифицировать вычисления через Flink и Spark — но оказалось, что поддерживать и мигрировать всё это слишком дорого. Следующий шаг — поиск движка, который позволит объединить real-time и офлайн фичи. В списке кандидатов оказались ClickHouse и StarRocks. ClickHouse давно зарекомендовал себя как быстрый аналитический движок, но у него есть ограничения: - обновления и upsert’ы работают неэффективно. - при большом количестве параллельных запросов растёт латентность. - слабая интеграция с BI-инструментами без доп. прослоек. StarRocks, напротив, предложил то, что DiDi как раз искала: - MPP-архитектура и векторное исполнение, которые дают стабильную производительность при высоких нагрузках. - реальные апдейты и стриминг-инжест без необходимости пересчитывать всё хранилище. - умные materialized views и MySQL-протокол, что позволило бизнес-командам писать запросы привычным SQL’ем и использовать стандартные дашборды. - поддержка lake-форматов, что облегчает интеграцию с существующей инфраструктурой. В тестах на таблицах с миллиардами строк StarRocks показал более чем 80% сокращение задержек и позволил команде выпускать новые фичи не за 5 дней, как раньше, а за часы. Сейчас DiDi использует один StarRocks-кластер для risk features и планирует расширять архитектуру, добавляя отказоустойчивость и поддержку log-based источников. StarRocks для них стал не просто OLAP-движком, а основой новой stream-batch unified архитектуры — реальной альтернативой громоздким Lambda-пайплайнам. Читать полный пост тут @data_whisperer

RustFS — это высокопроизводительное программное обеспечение для распределенного хранения объектов, созданное с использованием Rust, одного из самых популярных языков программирования в мире. Наряду с MinIO, он обладает рядом преимуществ, таких как простота, совместимость с S3, открытый исходный код, поддержка data lakes, искусственного интеллекта и больших данных. Кроме того, он имеет более удобную и либеральную лицензию с открытым исходным кодом по сравнению с другими системами хранения, так как разработан под лицензией Apache. Поскольку Rust является его основой, RustFS обеспечивает более высокую скорость и безопасные распределенные функции для высокопроизводительного хранения объектов. @data_whisperer

ООП в Python на примере Кошмара перед Рождеством Обычно перед halloween появляются небольшие тематические курсы или квесты по программированию. На этот раз наткнулся на такой бесплатный курс на Stepik. Этот курс даст вам возможность изучить основы ООП на Python через мульт Тима Бёртона "Кошмар перед Рождеством". Вместо традиционных примеров, мы будем использовать историю Джека Повелителя Тыкв, чтобы глубже понять такие ключевые понятия ООП, как наследование, инкапсуляция, полиморфизм и композиция. @data_whisperer

AI Dev Tools Zoomcamp 2025 Уже скоро стартует новый бесплатный курс от Алексея Григорьева — автора легендарных ML Zoomcamp и Data Engineering Zoomcamp. На этот раз тема — ИИ в разработке. AI уже меняет привычный процесс создания софта: от генерации и тестирования кода до деплоя и CI/CD — умные инструменты помогают разработчикам работать быстрее, точнее и с меньшими усилиями. 18 ноября начинается AI Dev Tools Zoomcamp 2025 — курс, где вы не просто узнаете про AI-инструменты, а попробуете их в деле: как встроить ИИ в свой рабочий процесс и даже создать собственного AI-агента, который умеет генерировать реальные приложения. Если хотите разобраться, как использовать ИИ в инженерной практике — отличная возможность начать. Регистрация уже открыта и полностью бесплатна. @data_whisperer

Deploy dlt pipelines Узнайте, как интегрировать и развертывать пайплайны dlt с использованием популярных оркестраторов. Этот самостоятельный курс охватывает настройку, стратегии развертывания и реальные примеры для каждого инструмента. Первые 2 модуля по Airflow и Prefect уже доступны. @data_whisperer

Дайджест дата новостей за неделю Deep Dives: Pinterest и CDC: Перенос сотен ТБ данных из MySQL в аналитику через Kafka Connect + Debezium. Разделение конфига и логики позволяет безопасно обновлять коннекторы, перераспределять партиции и обеспечивать exactly-once семантику. Избегают дубликатов с метаданными и идемпотентными реплеями, плюс правила эволюции схем. Uber и Pinot: Переход от сложной Presto-архитектуры (Neutrino) к упрощённой без брокеров с Multi-Stage Engine (MSE) Lite. Улучшает надёжность, снижает задержки и масштабирует OLAP-запросы для миллионов ежедневных аналитик пользователей, поиска логов и трейсинга. Netflix: Рекомендации в реальном времени (Часть 3): Двухфазный подход для live-событий (типа NFL): prefetch через GraphQL в Domain Graph Service во время просмотра для баланса нагрузки, затем WebSocket-рассылка низко-кардинальных сообщений (ключи состояний + timestamps) на 100M+ устройств в критические моменты, чтобы не пропустить события. ⦁ RAG для enterprise: Модульная архитектура с аутентификацией, guardrails, переписыванием запросов, кастомными энкодерами, масштабируемым инжингом документов и выбором векторных БД. Добавьте reranking, hybrid search, chunking; мониторинг LLM, фидбек и кэш для надёжности и экономии. Opinions & Advice: Почему аналитические агенты ломаются иначе: В отличие от кодинговых, данные нельзя суммировать без потери смысла. Hex ввели структурированные контекст-карты, лимиты токенов и явную обрезку, чтобы агенты лучше ориентировались и анализировали сырые данные. Собери свою БД: Построение key-value БД с нуля показывает эволюцию от простых append-only файлов с компакцией (для durability) к индексации и сортировке (для скорости чтения, но медленнее записи). Основа LSM-trees, как в LevelDB и DynamoDB. RAG мёртв? Взлёт Context Engineering и семантических слоёв для Agentic AI: RAG — только старт; теперь контекст-инжиниринг включает запись, компрессию, изоляцию и селекцию с метаданными, policy-as-code и мультимодальностью. Графовые знания обеспечивают объяснимость и масштабируемость; новые метрики (релевантность, groundedness, provenance, recency) для enterprise. @data_whisperer

Тимлид — быть или не быть? Пока в тимлиды я не стремлюсь — мне комфортно в роли разработчика. Но однажды я уже пробовал. И это было… больно. Постоянные пожары, дедлайны, созвоны, код. Пытался писать и лидить одновременно, даже купил книгу по Канбану — но всё равно выгорел и уволился. Теперь решил подойти к этому с другой стороны: записался на курс по тимлидству от Школы Сильных Программистов. Почему именно курс по тимлидству? Потому что код сейчас может написать и AI а вот взаимодействие в команде — эта штука ему уже неподсильна. Курс по Developer Experience у них уже проходил — формат классный, подача практичная, инсайтов много. От нового жду не меньше. Пост не реклама — курс куплен за свои кровные, поэтому ссылки не оставляю😅 Буду делиться впечатлениями по ходу. @data_whisperer

OpenDbt Ну вот и начали появляться форки dbt-core. OpenDBT динамически расширяет dbt-core. Уже добавляются значительные функции, которых нет в оригинальном dbt-core. Например интеграция DLT и обновленный UI. Поддержка нескольких проектов с cross project ref models. Это путь к полноценному форку, управляемому сообществом. По мере развития проекта будут всплывать баги, поэтому команда форка приглашает разработчиков и более широкое сообщество данных к сотрудничеству. @data_whisperer

Jack Vanlightly: Why I’m not a fan of zero-copy Apache Kafka-Apache Iceberg Интеграция потоковых и аналитических систем часто соблазняет инженеров стремиться к архитектурам zero-copy, которые обещают эффективность за счёт объединения слоёв хранения. Автор утверждает, что дизайн Kafka–Iceberg с нулевым копированием вместо этого вводит серьёзные вычислительные накладные расходы, конфликты эволюции схем и тесную связанность, которая размывает чёткие границы систем. В блоге отстаивается традиционная материализация — поддержание отдельных, но скоординированных копий, — поскольку это сохраняет изоляцию производительности, гибкость схем и операционную ясность в системах Kafka и lakehouse. Вообщем расходимся, очередной buzzword @data_whisperer

MetricFlow dbt выложили в open-source семантический слой MetricFlow под лицензией Apache 2.0 MetricFlow — это семантический слой, который упрощает определение и управление метриками. Он компилирует эти определения в понятный и переиспользуемый SQL-код, обеспечивая согласованные и точные результаты при анализе данных по нужным атрибутам (измерениям). Название «MetricFlow» отражает подход: запросы метрик преобразуются в план запроса на основе потоков данных, который затем оптимизируется и переводится в SQL конкретного движка базы данных. @data_whisperer