NEW: Diskless Topics were just accepted into Kafka
В Apache Kafka приняли новый тип топиков - Diskless Topics.
Если коротко, это архитектура, в которой брокер Kafka пишет данные напрямую в Amazon S3 вместо локального диска.
Это довольно сильно меняет привычную модель Kafka.
За счёт отсутствия межзонной репликации стоимость может быть ниже до 90% по сравнению с классической Kafka.
При потоке около 1 GB/s это примерно $100k в год против $1M. Брокеры при этом становятся stateless, дисков больше нет, а значит нет состояния, которое нужно управлять.
По сути, их можно запускать так же просто, как Nginx.
Архитектура также становится leaderless: любой брокер может быть лидером.
Благодаря этому новые брокеры можно быстро поднимать и перераспределять трафик, что упрощает масштабирование и уменьшает проблему hot spots.
Появляется и гибкость в сетевой топологии- например, можно масштабировать брокеры по зонам доступности, подстраиваясь под архитектуру приложений.
У такого подхода есть и компромисс - более высокая задержка запросов, которая может доходить до ~2 секунд на p99.
История Diskless Topics во многом связана с компанией Aiven.
Они первыми сделали две важные вещи: открыли исходный код решения и пообещали внести его в основной open-source код Kafka, а также выпустили продукт, в котором в одном кластере можно использовать и классические (быстрые и дорогие) топики, и diskless (медленные, но дешёвые).
Благодаря этому open-source Apache Kafka становится гораздо более конкурентоспособным по сравнению с проприетарными решениями.
Пользователи действительно могут получить экономию более 90%, тогда как некоторые коммерческие продукты забирали значительную часть этой экономии в свою маржу, при этом рекламируя себя как в 10 раз дешевле. При этом не нужно выполнять рискованные миграции между кластерами или разделять стриминговую инфраструктуру на несколько кластеров только ради diskless-топиков. Фактически внедрение может свестись к апгрейду и установке параметра topic.type=diskless.
Интересно, что всего через два дня после анонса KIP в 2025 году компания AutoMQ изменила лицензию своего open-source проекта на Apache и начала передавать в open source некоторые ранее проприетарные функции.
Также ожидается, что Diskless Topics упростят интеграцию Kafka с data lake-экосистемой - например с форматами Apache Parquet и Apache Iceberg, поскольку теперь в Kafka появляется S3-first путь записи данных.
На фоне того, что происходит в экосистеме Kafka в последние годы, это одна из немногих действительно заметных новостей, особенно после того, как Confluent была приобретена IBM.
@tldr_data
В Apache Kafka приняли новый тип топиков - Diskless Topics.
Если коротко, это архитектура, в которой брокер Kafka пишет данные напрямую в Amazon S3 вместо локального диска.
Это довольно сильно меняет привычную модель Kafka.
За счёт отсутствия межзонной репликации стоимость может быть ниже до 90% по сравнению с классической Kafka.
При потоке около 1 GB/s это примерно $100k в год против $1M. Брокеры при этом становятся stateless, дисков больше нет, а значит нет состояния, которое нужно управлять.
По сути, их можно запускать так же просто, как Nginx.
Архитектура также становится leaderless: любой брокер может быть лидером.
Благодаря этому новые брокеры можно быстро поднимать и перераспределять трафик, что упрощает масштабирование и уменьшает проблему hot spots.
Появляется и гибкость в сетевой топологии- например, можно масштабировать брокеры по зонам доступности, подстраиваясь под архитектуру приложений.
У такого подхода есть и компромисс - более высокая задержка запросов, которая может доходить до ~2 секунд на p99.
История Diskless Topics во многом связана с компанией Aiven.
Они первыми сделали две важные вещи: открыли исходный код решения и пообещали внести его в основной open-source код Kafka, а также выпустили продукт, в котором в одном кластере можно использовать и классические (быстрые и дорогие) топики, и diskless (медленные, но дешёвые).
Благодаря этому open-source Apache Kafka становится гораздо более конкурентоспособным по сравнению с проприетарными решениями.
Пользователи действительно могут получить экономию более 90%, тогда как некоторые коммерческие продукты забирали значительную часть этой экономии в свою маржу, при этом рекламируя себя как в 10 раз дешевле. При этом не нужно выполнять рискованные миграции между кластерами или разделять стриминговую инфраструктуру на несколько кластеров только ради diskless-топиков. Фактически внедрение может свестись к апгрейду и установке параметра topic.type=diskless.
Интересно, что всего через два дня после анонса KIP в 2025 году компания AutoMQ изменила лицензию своего open-source проекта на Apache и начала передавать в open source некоторые ранее проприетарные функции.
Также ожидается, что Diskless Topics упростят интеграцию Kafka с data lake-экосистемой - например с форматами Apache Parquet и Apache Iceberg, поскольку теперь в Kafka появляется S3-first путь записи данных.
На фоне того, что происходит в экосистеме Kafka в последние годы, это одна из немногих действительно заметных новостей, особенно после того, как Confluent была приобретена IBM.
@tldr_data
👍1
OpenAI Analytics Engineer $234K – $335K + Offers Equity
В момент, когда многие переживают, что ИИ заменит их работу, в одной из ведущих AI-компаний открыта роль Analytics Engineer.
Технические навыки вроде SQL, Python и визуализации данных по-прежнему ожидаются, но главный акцент все же на другом:
тесная интеграция с бизнесом, формирование партнёрства со стейкхолдерами и умение объяснять данные через понятные истории.
Одна из ключевых идей Analytics Engineer должен встраиваться в бизнес-команду, а не просто поддерживать её.
Это означает более тесную работу между data и бизнесом: совместную разработку метрик, постоянную синхронизацию и участие стейкхолдеров в процессе создания моделей и дашбордов.
Вторая важная область это определение и стандартизация метрик.
На практике даже простой вопрос вроде что считать конверсией часто вызывает разные ответы у разных команд.
Согласование определения метрик, способов их расчёта и использования - сложная организационная работа, и именно здесь Analytics Engineer становятся ключевым звеном.
Причём основа стабильных метрик это корректные дата-модели, а не слой BI.
Третье направление - data storytelling.
Одних цифр недостаточно: важно объяснить, что они означают для бизнеса и какие решения из них следуют.
Руководителям нужно понимать, как метрики связаны между собой и что они говорят о продукте и стратегии.
Какой можно сделать вывод?
Технические навыки остаются важными, но будущее роли аналитического инженера всё больше связано с бизнес-контекстом.
Способность понимать процессы компании, формализовывать метрики и превращать бизнес-логику в масштабируемые дата-модели становится главным конкурентным преимуществом.
@tldr_data
В момент, когда многие переживают, что ИИ заменит их работу, в одной из ведущих AI-компаний открыта роль Analytics Engineer.
Технические навыки вроде SQL, Python и визуализации данных по-прежнему ожидаются, но главный акцент все же на другом:
тесная интеграция с бизнесом, формирование партнёрства со стейкхолдерами и умение объяснять данные через понятные истории.
Одна из ключевых идей Analytics Engineer должен встраиваться в бизнес-команду, а не просто поддерживать её.
Это означает более тесную работу между data и бизнесом: совместную разработку метрик, постоянную синхронизацию и участие стейкхолдеров в процессе создания моделей и дашбордов.
Вторая важная область это определение и стандартизация метрик.
На практике даже простой вопрос вроде что считать конверсией часто вызывает разные ответы у разных команд.
Согласование определения метрик, способов их расчёта и использования - сложная организационная работа, и именно здесь Analytics Engineer становятся ключевым звеном.
Причём основа стабильных метрик это корректные дата-модели, а не слой BI.
Третье направление - data storytelling.
Одних цифр недостаточно: важно объяснить, что они означают для бизнеса и какие решения из них следуют.
Руководителям нужно понимать, как метрики связаны между собой и что они говорят о продукте и стратегии.
Какой можно сделать вывод?
Технические навыки остаются важными, но будущее роли аналитического инженера всё больше связано с бизнес-контекстом.
Способность понимать процессы компании, формализовывать метрики и превращать бизнес-логику в масштабируемые дата-модели становится главным конкурентным преимуществом.
@tldr_data
Openai
Analytics Engineer
Data Science · San Francisco · FullTime
👍1🔥1
Inside OpenAI's in-house data agent
OpenAI опубликовала подробный разбор своего внутреннего AI data-агента инструмента, который помогает сотрудникам переходить от вопроса к аналитическому инсайту за минуты.
Причина появления такого инструмента, масштаб данных внутри компании.
Платформа OpenAI обслуживает более 3 500 сотрудников и содержит около 600 петабайт данных в 70 000 датасетов.
В таких условиях основная проблема аналитики даже не написание SQL, а поиск правильной таблицы и понимание её контекста.
Многие таблицы похожи друг на друга, отличаются нюансами (например, какие пользователи включены в данные), а ошибки вроде неправильных join’ов или фильтров могут незаметно исказить результат.
Чтобы решить эту проблему, OpenAI построила внутреннего агента, который понимает вопросы на естественном языке и выполняет весь аналитический цикл: находит данные, пишет SQL, запускает запросы и формирует выводы.
Он используется в разных командах, от инженерии и ресёрча до финансов и GTM, и позволяет задавать сложные аналитические вопросы без ручного исследования десятков таблиц.
Ключевая особенность системы - богатый контекст, на котором работает агент.
Он использует несколько слоёв информации:
• метаданные таблиц и lineage
• историю запросов
• аннотации от экспертов по данным
• анализ кода пайплайнов (через Codex), чтобы понимать, как именно формируются таблицы
• внутренние документы компании из Slack, Notion и Google Docs
• систему памяти, которая сохраняет исправления и знания для будущих запросов.
Агент также умеет рассуждать итеративно.
Если промежуточный результат выглядит подозрительно (например, из-за неправильного join’а получилось 0 строк), он пытается найти причину ошибки, меняет стратегию и повторяет анализ.
По сути, он работает как аналитик-коллега, с которым можно обсуждать задачу и уточнять направление исследования.
При этом особое внимание уделяется достоверности и безопасности.
Система наследует существующую модель доступа к данным: пользователь может работать только с теми таблицами, к которым у него есть права.
Каждый ответ сопровождается ссылками на выполненные запросы и исходные данные, чтобы результат можно было проверить.
По мере роста data-платформ узким местом становится не вычисление, а поиск нужных данных и понимание их контекста.
Именно поэтому внутренние AI-агенты, которые могут рассуждать поверх данных, кода и корпоративных знаний, становятся новым интерфейсом для аналитики.
@tldr_data
OpenAI опубликовала подробный разбор своего внутреннего AI data-агента инструмента, который помогает сотрудникам переходить от вопроса к аналитическому инсайту за минуты.
Причина появления такого инструмента, масштаб данных внутри компании.
Платформа OpenAI обслуживает более 3 500 сотрудников и содержит около 600 петабайт данных в 70 000 датасетов.
В таких условиях основная проблема аналитики даже не написание SQL, а поиск правильной таблицы и понимание её контекста.
Многие таблицы похожи друг на друга, отличаются нюансами (например, какие пользователи включены в данные), а ошибки вроде неправильных join’ов или фильтров могут незаметно исказить результат.
Чтобы решить эту проблему, OpenAI построила внутреннего агента, который понимает вопросы на естественном языке и выполняет весь аналитический цикл: находит данные, пишет SQL, запускает запросы и формирует выводы.
Он используется в разных командах, от инженерии и ресёрча до финансов и GTM, и позволяет задавать сложные аналитические вопросы без ручного исследования десятков таблиц.
Ключевая особенность системы - богатый контекст, на котором работает агент.
Он использует несколько слоёв информации:
• метаданные таблиц и lineage
• историю запросов
• аннотации от экспертов по данным
• анализ кода пайплайнов (через Codex), чтобы понимать, как именно формируются таблицы
• внутренние документы компании из Slack, Notion и Google Docs
• систему памяти, которая сохраняет исправления и знания для будущих запросов.
Агент также умеет рассуждать итеративно.
Если промежуточный результат выглядит подозрительно (например, из-за неправильного join’а получилось 0 строк), он пытается найти причину ошибки, меняет стратегию и повторяет анализ.
По сути, он работает как аналитик-коллега, с которым можно обсуждать задачу и уточнять направление исследования.
При этом особое внимание уделяется достоверности и безопасности.
Система наследует существующую модель доступа к данным: пользователь может работать только с теми таблицами, к которым у него есть права.
Каждый ответ сопровождается ссылками на выполненные запросы и исходные данные, чтобы результат можно было проверить.
По мере роста data-платформ узким местом становится не вычисление, а поиск нужных данных и понимание их контекста.
Именно поэтому внутренние AI-агенты, которые могут рассуждать поверх данных, кода и корпоративных знаний, становятся новым интерфейсом для аналитики.
@tldr_data
👍1
Если ваш процесс тестирования DAG’ов сводится к надежде, что вам не напишет руководитель в Slack со словами почему не работает дашборд, значит с тестированием что-то не так.
Компания Astronomer недавно опубликовала гайд с best practices по тестированию DAG’ов в Apache Airflow.
Слишком часто первым мониторингом для data-pipeline становится пользователь, который замечает, что дашборд не загрузился или данные выглядят странно.
Хорошие практики тестирования DAG’ов позволяют ловить такие проблемы раньше ещё на этапе разработки и CI, а не в момент, когда кто-то из бизнеса уже столкнулся с поломанной аналитикой.
Гайд бесплатный, рекомендую посмотреть
@tldr_data
Компания Astronomer недавно опубликовала гайд с best practices по тестированию DAG’ов в Apache Airflow.
Слишком часто первым мониторингом для data-pipeline становится пользователь, который замечает, что дашборд не загрузился или данные выглядят странно.
Хорошие практики тестирования DAG’ов позволяют ловить такие проблемы раньше ещё на этапе разработки и CI, а не в момент, когда кто-то из бизнеса уже столкнулся с поломанной аналитикой.
Гайд бесплатный, рекомендую посмотреть
@tldr_data
👍1
Как основатель DE Zoomcamp снес продовую базу
Основатель DataTalks.Club Alexey Grigorev рассказал довольно поучительную историю:
как он случайно снёс продовую базу данных, используя AI-агента.
Во время миграции инфраструктуры на Amazon Web Services он работал с Terraform и использовал AI-агента для помощи с командами и изменениями конфигурации.
В какой-то момент агент запустил terraform destroy, после чего была удалена практически вся продовая инфраструктура: VPC, ECS, load balancer и база данных в RDS.
В результате исчезли данные примерно за 2.5 года работы платформы - домашние задания, проекты и лидерборды студентов.
Причина оказалась в состоянии Terraform.
Агент распаковал старый state-файл, из-за чего Terraform решил, что текущая инфраструктура отсутствует, и команда удаления затронула реальные продовые ресурсы.
К счастью, ситуация закончилась не катастрофой. Команда поддержки AWS смогла найти внутренний snapshot и помогла восстановить базу данных.
На полное восстановление ушли примерно сутки.
Даже опытные вайбкодеры могут допускать такие ошибки, особенно когда начинают активно использовать AI-агентов для работы с инфраструктурой.
А в случае с Terraform и продом - одна ошибка и ты ошибся.
Хорошим правилом будет - не запускать локально команды и инструменты, которые могут менять вашу инфру.
Настройте CI, добавьте pre-commit и спите спокойно.
@tldr_data
Основатель DataTalks.Club Alexey Grigorev рассказал довольно поучительную историю:
как он случайно снёс продовую базу данных, используя AI-агента.
Во время миграции инфраструктуры на Amazon Web Services он работал с Terraform и использовал AI-агента для помощи с командами и изменениями конфигурации.
В какой-то момент агент запустил terraform destroy, после чего была удалена практически вся продовая инфраструктура: VPC, ECS, load balancer и база данных в RDS.
В результате исчезли данные примерно за 2.5 года работы платформы - домашние задания, проекты и лидерборды студентов.
Причина оказалась в состоянии Terraform.
Агент распаковал старый state-файл, из-за чего Terraform решил, что текущая инфраструктура отсутствует, и команда удаления затронула реальные продовые ресурсы.
К счастью, ситуация закончилась не катастрофой. Команда поддержки AWS смогла найти внутренний snapshot и помогла восстановить базу данных.
На полное восстановление ушли примерно сутки.
Даже опытные вайбкодеры могут допускать такие ошибки, особенно когда начинают активно использовать AI-агентов для работы с инфраструктурой.
А в случае с Terraform и продом - одна ошибка и ты ошибся.
Хорошим правилом будет - не запускать локально команды и инструменты, которые могут менять вашу инфру.
Настройте CI, добавьте pre-commit и спите спокойно.
@tldr_data
👍1🙈1
DB-AGENTS
Отец основатель дата инжиниринга Max Beauchemin - предложил соглашение DB-AGENTS в стиле AGENTS.md, которое встраивает понятную для агентов семантику и инструкции непосредственно в базы данных.
Этот документ описывает легковесное соглашение, а не платформу и не фреймворк.
DB-AGENTS позволяет AI-агентам эффективнее взаимодействовать с базами данных, предоставляя контекстные инструкции прямо внутри самой базы.
Для этого не требуется специализированных инструментов: внедрение можно начать с одной таблицы метаданных и небольшого набора инструкций, добавленных в system prompt.
@tldr_data
Отец основатель дата инжиниринга Max Beauchemin - предложил соглашение DB-AGENTS в стиле AGENTS.md, которое встраивает понятную для агентов семантику и инструкции непосредственно в базы данных.
Этот документ описывает легковесное соглашение, а не платформу и не фреймворк.
DB-AGENTS позволяет AI-агентам эффективнее взаимодействовать с базами данных, предоставляя контекстные инструкции прямо внутри самой базы.
Для этого не требуется специализированных инструментов: внедрение можно начать с одной таблицы метаданных и небольшого набора инструкций, добавленных в system prompt.
@tldr_data
Preset on Notion
DB-AGENTS | Notion
DB-AGENTS is a proposal for an AGENTS.md-style convention that embeds agent-readable semantics and guidance directly inside databases.
👍1🔥1
MCP is dead. Long live the CLI
Достаточно хайповый пост от разработчика.
Он говорит, что LLM отлично работают с командной строкой.
Они обучены на огромном количестве man-страниц, GitHub-репозиториев и shell-скриптов, поэтому команды вроде gh, kubectl или terraform для них естественная среда.
При этом CLI удобен не только для агента, но и для человека: если модель сделала что-то неожиданное, можно просто выполнить ту же команду вручную и увидеть тот же результат.
Командная строка также идеально подходит для композиции инструментов.
Pipes, jq, grep, редиректы — вся Unix-философия уже позволяет обрабатывать данные и соединять инструменты между собой без дополнительной инфраструктуры.
А вот тут уже интереснее, почему пост все же хайпует на том, что MCP мертв.
MCP может быть полезен, если у сервиса нет CLI.
Например - это могут быть:
• Документ-ориентированные SaaS (Notion)
• Issue tracking / project tools
• Knowledge bases (Confluence)
• CRM-системы
Если хотите разабраться в том, как работают MCP, то можно посмотреть курс Андрея Созыкина по Протоколу MCP(курс в процессе разработки).
Андрей прежде всего известен очень хорошими курсами по Компьютерным Сетям.
А в конце, закрепить это все бесплатным курсом от Anthropic - Introduction to Model Context Protocol.
@tldr_data
Достаточно хайповый пост от разработчика.
Он говорит, что LLM отлично работают с командной строкой.
Они обучены на огромном количестве man-страниц, GitHub-репозиториев и shell-скриптов, поэтому команды вроде gh, kubectl или terraform для них естественная среда.
При этом CLI удобен не только для агента, но и для человека: если модель сделала что-то неожиданное, можно просто выполнить ту же команду вручную и увидеть тот же результат.
Командная строка также идеально подходит для композиции инструментов.
Pipes, jq, grep, редиректы — вся Unix-философия уже позволяет обрабатывать данные и соединять инструменты между собой без дополнительной инфраструктуры.
А вот тут уже интереснее, почему пост все же хайпует на том, что MCP мертв.
MCP может быть полезен, если у сервиса нет CLI.
Например - это могут быть:
• Документ-ориентированные SaaS (Notion)
• Issue tracking / project tools
• Knowledge bases (Confluence)
• CRM-системы
Если хотите разабраться в том, как работают MCP, то можно посмотреть курс Андрея Созыкина по Протоколу MCP(курс в процессе разработки).
Андрей прежде всего известен очень хорошими курсами по Компьютерным Сетям.
А в конце, закрепить это все бесплатным курсом от Anthropic - Introduction to Model Context Protocol.
@tldr_data
Anthropic Courses
Learn to build with Claude AI through Anthropic's comprehensive courses and training programs.
🔥1
dbt + Flink для batch и streaming одновременно
Вышел коннектор dbt для Flink.
Теперь можно писать трансформации один раз и запускать их и в batch, и в streaming режиме.
Раньше для batch и streaming нужны были разные инструменты и разные модели.
Что работает для batch, не работает для streaming без переписывания.
Теперь просто пишешь трансформацию один раз, и она работает и для batch, и для streaming.
Плюс все ваши модели остаются версионированными и протестированными.
Так же интересно посмотреть на CLAUDE.md, который используют в адаптере.
Думаю, что то можно взять и в свой проект.
@tldr_data
Вышел коннектор dbt для Flink.
Теперь можно писать трансформации один раз и запускать их и в batch, и в streaming режиме.
Раньше для batch и streaming нужны были разные инструменты и разные модели.
Что работает для batch, не работает для streaming без переписывания.
Теперь просто пишешь трансформацию один раз, и она работает и для batch, и для streaming.
Плюс все ваши модели остаются версионированными и протестированными.
Так же интересно посмотреть на CLAUDE.md, который используют в адаптере.
Думаю, что то можно взять и в свой проект.
@tldr_data
❤3🔥1
SQL Crack
Новое расширение для VS Code под названием SQL Crack преобразует SQL-запросы в интерактивные визуальные диаграммы потоков, позволяя разработчикам отслеживать data lineage, находить возможности для оптимизации и анализировать зависимости между файлами в более чем 14 диалектах баз данных, включая PostgreSQL, MySQL и Snowflake.
Этот open-source инструмент использует цветовое кодирование для разных типов узлов (таблицы, join’ы и фильтры) и операций (READ, WRITE, INSERT).
Он поддерживает навигацию с клавиатуры и screen readers, автоматически индексирует SQL-файлы в рабочем пространстве и пропускает build-директории.
@tldr_data
Новое расширение для VS Code под названием SQL Crack преобразует SQL-запросы в интерактивные визуальные диаграммы потоков, позволяя разработчикам отслеживать data lineage, находить возможности для оптимизации и анализировать зависимости между файлами в более чем 14 диалектах баз данных, включая PostgreSQL, MySQL и Snowflake.
Этот open-source инструмент использует цветовое кодирование для разных типов узлов (таблицы, join’ы и фильтры) и операций (READ, WRITE, INSERT).
Он поддерживает навигацию с клавиатуры и screen readers, автоматически индексирует SQL-файлы в рабочем пространстве и пропускает build-директории.
@tldr_data
GitHub
GitHub - buva7687/sql-crack
Contribute to buva7687/sql-crack development by creating an account on GitHub.
👍1
Video Conferencing with Postgres
SpacetimeDB сделали первый в мире видеозвонок через базу данных и в своём стиле предложили всем желающим попробовать повторить это.
Идея действительно интересная и очень необычная.
Они сделали фронтенд, который захватывает аудио и видео из браузерных media API, кодирует их в компактные кадры (PCM16LE для аудио и JPEG для видео), отправляет эти кадры в базу данных, которая выступает в роли брокера сообщений в реальном времени, а затем стримит их обратно в браузер другого участника для воспроизведения.
Реализация выложена в open-source, поэтому автор поста решил разобраться, как это все работает.
@tldr_data
SpacetimeDB сделали первый в мире видеозвонок через базу данных и в своём стиле предложили всем желающим попробовать повторить это.
Идея действительно интересная и очень необычная.
Они сделали фронтенд, который захватывает аудио и видео из браузерных media API, кодирует их в компактные кадры (PCM16LE для аудио и JPEG для видео), отправляет эти кадры в базу данных, которая выступает в роли брокера сообщений в реальном времени, а затем стримит их обратно в браузер другого участника для воспроизведения.
Реализация выложена в open-source, поэтому автор поста решил разобраться, как это все работает.
@tldr_data
GitHub
GitHub - Lethalchip/SpaceChatDB
Contribute to Lethalchip/SpaceChatDB development by creating an account on GitHub.
👍1💯1
AI Engineering Field Guide
Алекс Григорьев собрал интересный репозиторий с материалами, которые могут помочь подготовиться к позиции AI Engineer.
Алекс проанализировал 1700+ реальных описаний вакансий, опыт прохождения собеседований и истории практиков, чтобы понять, какие навыки и темы чаще всего встречаются в требованиях.
Репозиторий пока находится в процессе наполнения, но уже сейчас там есть полезный ориентир: небольшой roadmap того, на что стоит обратить внимание, если вы, например, хотите перейти из Data Engineer в AI Engineer.
Внутри планируются:
- анализ ролей
- данные по рынку вакансий
- вопросы с собеседований
- learning paths
Выглядит как потенциально хороший справочник для тех, кто пытается понять, какие навыки сейчас реально ожидают от AI-инженеров и в каком направлении двигаться.
@tldr_data
Алекс Григорьев собрал интересный репозиторий с материалами, которые могут помочь подготовиться к позиции AI Engineer.
Алекс проанализировал 1700+ реальных описаний вакансий, опыт прохождения собеседований и истории практиков, чтобы понять, какие навыки и темы чаще всего встречаются в требованиях.
Репозиторий пока находится в процессе наполнения, но уже сейчас там есть полезный ориентир: небольшой roadmap того, на что стоит обратить внимание, если вы, например, хотите перейти из Data Engineer в AI Engineer.
Внутри планируются:
- анализ ролей
- данные по рынку вакансий
- вопросы с собеседований
- learning paths
Выглядит как потенциально хороший справочник для тех, кто пытается понять, какие навыки сейчас реально ожидают от AI-инженеров и в каком направлении двигаться.
@tldr_data
GitHub
GitHub - alexeygrigorev/ai-engineering-field-guide: Research into AI engineering interview assignments, take-home challenges, and…
Research into AI engineering interview assignments, take-home challenges, and hiring practices from Q4 2025 / Q1 2026 - alexeygrigorev/ai-engineering-field-guide
👍2
SlowQL
SlowQL - это статический анализатор SQL.
Указываете ему ваши SQL-файлы, и он находит паттерны, которые часто приводят к продакшн-инцидентам, до того как код попадёт в прод.
Инструмент работает полностью офлайн и не имеет зависимостей.
В нём реализовано 171 правило в 6 категориях, которые помогают находить:
• анти-паттерны производительности
• уязвимости безопасности
• нарушения комплаенса
• потенциальные ловушки по стоимости
У SlowQL приятный терминальный интерфейс, который делает использование инструмента довольно удобным для разработчиков.
@tldr_data
SlowQL - это статический анализатор SQL.
Указываете ему ваши SQL-файлы, и он находит паттерны, которые часто приводят к продакшн-инцидентам, до того как код попадёт в прод.
Инструмент работает полностью офлайн и не имеет зависимостей.
В нём реализовано 171 правило в 6 категориях, которые помогают находить:
• анти-паттерны производительности
• уязвимости безопасности
• нарушения комплаенса
• потенциальные ловушки по стоимости
У SlowQL приятный терминальный интерфейс, который делает использование инструмента довольно удобным для разработчиков.
@tldr_data
GitHub
GitHub - slowql/slowql: SQL static analyzer for performance, security, compliance and cost. 272 rules. Completely offline. Works…
SQL static analyzer for performance, security, compliance and cost. 272 rules. Completely offline. Works in CI pipelines. - slowql/slowql
👍2
OpenAI Data Engineer
$230K – $385K + Offers Equity
Недавно был пост про позицию Analytics Engineer в OpenAI, теперь в компании открыта вакансия Data Engineer.
По стэку все достаточно консервативно - Hadoop, Flink, Airflow, Spark.
Никаких смузи инструментов в виде DuckDB/DLT, только хардкор.
Компания релоцирует новых сотрудников.
В целом хорошая мотивация, чтобы было к чему стремиться. Представьте, что вы работаете в компании, которая меняет облик всего человечества.
@tldr_data
$230K – $385K + Offers Equity
Недавно был пост про позицию Analytics Engineer в OpenAI, теперь в компании открыта вакансия Data Engineer.
По стэку все достаточно консервативно - Hadoop, Flink, Airflow, Spark.
Никаких смузи инструментов в виде DuckDB/DLT, только хардкор.
Компания релоцирует новых сотрудников.
В целом хорошая мотивация, чтобы было к чему стремиться. Представьте, что вы работаете в компании, которая меняет облик всего человечества.
@tldr_data
👍1
Dolt - это open-source база данных, совместимая с MySQL, со встроенным контролем версий в стиле Git.
Она позволяет создавать ветки, смотреть diff, делать merge, commit и clone для таблиц и схем так же, как это делается с кодом в Git, при этом оставаясь совместимой со стандартными SQL-инструментами.
Это полезно для совместной работы с данными, воспроизводимости, аудита и отладки.
Можно просматривать исторические состояния датасетов и даже разрешать конфликты слияния на уровне строк прямо в SQL.
@tldr_data
Она позволяет создавать ветки, смотреть diff, делать merge, commit и clone для таблиц и схем так же, как это делается с кодом в Git, при этом оставаясь совместимой со стандартными SQL-инструментами.
Это полезно для совместной работы с данными, воспроизводимости, аудита и отладки.
Можно просматривать исторические состояния датасетов и даже разрешать конфликты слияния на уровне строк прямо в SQL.
@tldr_data
GitHub
GitHub - dolthub/dolt: Dolt – Git for Data
Dolt – Git for Data. Contribute to dolthub/dolt development by creating an account on GitHub.
👍1
Breaking the Microbatch Barrier: The Architecture of Apache Spark Real-Time Mode
В Spark наконец-то начали нормально решать старую проблему: либо у тебя высокопроизводительный ETL, либо стриминг с низкой задержкой. Real-Time Mode - это попытка убрать этот компромисс.
Раньше Structured Streaming строился вокруг microbatch-модели: данные собираются в маленькие батчи, обрабатываются, потом следующий батч. Это удобно, но даёт задержку. Даже если батчи маленькие это всё равно batch.
В Real-Time Mode модель меняется. Вместо дискретных микробатчей появляется более гибридный подход: данные идут непрерывно, а обработка не останавливается между итерациями.
При этом полностью от дискретности не отказываются. Появляется понятие epoch - это не батч, а скорее логический интервал выполнения, который нужен для координации обработки и согласованности. Ключевая идея в том, что эти epochs становятся длиннее, но внутри них данные текут непрерывно.
За счёт этого снижается overhead на планирование, уменьшается latency и исчезают постоянные stop-the-world паузы. Стадии могут выполняться параллельно, а операторы больше не блокируют пайплайн.
В итоге получается что-то между классическим streaming и batch, но с задержками уже ближе к миллисекундам. По сути, Spark уходит от batch disguised as streaming к более честной стриминговой модели.
@tldr_data
В Spark наконец-то начали нормально решать старую проблему: либо у тебя высокопроизводительный ETL, либо стриминг с низкой задержкой. Real-Time Mode - это попытка убрать этот компромисс.
Раньше Structured Streaming строился вокруг microbatch-модели: данные собираются в маленькие батчи, обрабатываются, потом следующий батч. Это удобно, но даёт задержку. Даже если батчи маленькие это всё равно batch.
В Real-Time Mode модель меняется. Вместо дискретных микробатчей появляется более гибридный подход: данные идут непрерывно, а обработка не останавливается между итерациями.
При этом полностью от дискретности не отказываются. Появляется понятие epoch - это не батч, а скорее логический интервал выполнения, который нужен для координации обработки и согласованности. Ключевая идея в том, что эти epochs становятся длиннее, но внутри них данные текут непрерывно.
За счёт этого снижается overhead на планирование, уменьшается latency и исчезают постоянные stop-the-world паузы. Стадии могут выполняться параллельно, а операторы больше не блокируют пайплайн.
В итоге получается что-то между классическим streaming и batch, но с задержками уже ближе к миллисекундам. По сути, Spark уходит от batch disguised as streaming к более честной стриминговой модели.
@tldr_data
❤2
Are AI agents actually slowing us down?
По мере того как всё больше инженеров ежедневно используют AI-агентов, растёт и количество проблем: более грязный код, инциденты, падение качества и даже снижение скорости разработки. Что происходит и как это исправить?
Также появляются признаки общего ухудшения качества продуктов.
• Anthropic: деградация флагманского сайта. Раздражающая UX-проблема затронула платящих пользователей Claude - и никто в компании этого не заметил. При этом Anthropic двигается очень быстро и генерирует 80%+ продакшен-кода с помощью Claude, но качество и пользовательский опыт, похоже, отходят на второй план.
• Amazon: зависимость от AI-агентов приводит к SEV-инцидентам. В retail-направлении Amazon выросло число сбоев, вызванных собственными AI-агентами. В результате теперь требуется одобрение более сеньорных инженеров для изменений, сделанных с помощью AI.
• Big Tech: используешь AI или ты неэффективен. Компании вроде Uber отслеживают использование AI (например, токены) в performance review, усиливая давление на инженеров - независимо от влияния на качество.
• OpenCode: больше времени на исправления. Создатель OpenCode, Dax Reed, отмечает, что AI-агенты понижают планку качества, демотивируют рефакторинг и не ускоряют команды.
• Стартапы: LLM замедляют долгосрочную скорость. CTO Sentry и другие отмечают, что AI снижает порог входа, но приводит к раздутому и плохо поддерживаемому коду, что замедляет развитие в долгосрочной перспективе.
• Исследования: результаты хуже ожиданий. Некоторые исследования показывают, что AI-инструменты дают краткосрочный прирост скорости, за которым следует рост технического долга.
Как это исправить?
Инженеры с сильным архитектурным мышлением становятся критически важными. Среди предлагаемых решений - формальные методы валидации и, возможно, возвращение к некоторым “олдскульным” практикам QA.
полный пост тут
@tldr_data
По мере того как всё больше инженеров ежедневно используют AI-агентов, растёт и количество проблем: более грязный код, инциденты, падение качества и даже снижение скорости разработки. Что происходит и как это исправить?
Также появляются признаки общего ухудшения качества продуктов.
• Anthropic: деградация флагманского сайта. Раздражающая UX-проблема затронула платящих пользователей Claude - и никто в компании этого не заметил. При этом Anthropic двигается очень быстро и генерирует 80%+ продакшен-кода с помощью Claude, но качество и пользовательский опыт, похоже, отходят на второй план.
• Amazon: зависимость от AI-агентов приводит к SEV-инцидентам. В retail-направлении Amazon выросло число сбоев, вызванных собственными AI-агентами. В результате теперь требуется одобрение более сеньорных инженеров для изменений, сделанных с помощью AI.
• Big Tech: используешь AI или ты неэффективен. Компании вроде Uber отслеживают использование AI (например, токены) в performance review, усиливая давление на инженеров - независимо от влияния на качество.
• OpenCode: больше времени на исправления. Создатель OpenCode, Dax Reed, отмечает, что AI-агенты понижают планку качества, демотивируют рефакторинг и не ускоряют команды.
• Стартапы: LLM замедляют долгосрочную скорость. CTO Sentry и другие отмечают, что AI снижает порог входа, но приводит к раздутому и плохо поддерживаемому коду, что замедляет развитие в долгосрочной перспективе.
• Исследования: результаты хуже ожиданий. Некоторые исследования показывают, что AI-инструменты дают краткосрочный прирост скорости, за которым следует рост технического долга.
Как это исправить?
Инженеры с сильным архитектурным мышлением становятся критически важными. Среди предлагаемых решений - формальные методы валидации и, возможно, возвращение к некоторым “олдскульным” практикам QA.
полный пост тут
@tldr_data
Pragmaticengineer
Are AI agents actually slowing us down?
As more software engineers use AI agents daily, there’s also more sloppy software, outages, quality issues, and even a slowdown in shipping velocity. What’s happening, and how do we solve it?
🔥1
Data Engineering After AI
По мере того как AI автоматизирует задачи дата-инжиниринга - генерацию пайплайнов, трансформации и вывод схем, сама роль инженера смещается от перемещения данных к определению и управлению их смыслом.
Традиционные ETL-архитектуры были сфокусированы именно на движении данных и часто зашивали бизнес-логику прямо в пайплайны, из-за чего интерпретационный контекст постепенно размывался по мере прохождения данных через цепочку преобразований.
В качестве альтернативы можно рассматривать подход ECL (Extract, Contextualize, Link), который закрывает этот разрыв за счёт трёх этапов: извлечение надёжных данных из источников, обогащение их контекстом и бизнес-определениями, а затем связывание сущностей между системами, чтобы сохранить целостность и согласованность.
@tldr_data
По мере того как AI автоматизирует задачи дата-инжиниринга - генерацию пайплайнов, трансформации и вывод схем, сама роль инженера смещается от перемещения данных к определению и управлению их смыслом.
Традиционные ETL-архитектуры были сфокусированы именно на движении данных и часто зашивали бизнес-логику прямо в пайплайны, из-за чего интерпретационный контекст постепенно размывался по мере прохождения данных через цепочку преобразований.
В качестве альтернативы можно рассматривать подход ECL (Extract, Contextualize, Link), который закрывает этот разрыв за счёт трёх этапов: извлечение надёжных данных из источников, обогащение их контекстом и бизнес-определениями, а затем связывание сущностей между системами, чтобы сохранить целостность и согласованность.
@tldr_data
🔥1
OpenViking: The Context Database for AI Agents
OpenViking - новый open-source контекстный стор для AI-агентов, который использует файловую парадигму. Он организует память агента, ресурсы и навыки как локальную файловую систему через протокол viking://.
Внутри - трёхуровневая обработка контекста: skeleton, medium и full, что позволяет балансировать между скоростью и полнотой. Для повышения точности используется рекурсивный обход директорий при извлечении контекста.
Отдельно стоит self-iteration loop: агент может автоматически обновлять свою память на основе результатов задач и пользовательского фидбека.
@tldr_data
OpenViking - новый open-source контекстный стор для AI-агентов, который использует файловую парадигму. Он организует память агента, ресурсы и навыки как локальную файловую систему через протокол viking://.
Внутри - трёхуровневая обработка контекста: skeleton, medium и full, что позволяет балансировать между скоростью и полнотой. Для повышения точности используется рекурсивный обход директорий при извлечении контекста.
Отдельно стоит self-iteration loop: агент может автоматически обновлять свою память на основе результатов задач и пользовательского фидбека.
@tldr_data
GitHub
GitHub - volcengine/OpenViking: OpenViking is an open-source context database designed specifically for AI Agents(such as openclaw).…
OpenViking is an open-source context database designed specifically for AI Agents(such as openclaw). OpenViking unifies the management of context (memory, resources, and skills) that Agents need th...
👍1
Anthropic Data Engineer (Safeguards)
£170K – £220K + (возможен equity)
Еще одна открытая позиция в AI гигант.
Data Engineer в Anthropic в команде Safeguards, которая отвечает за безопасность моделей и контроль их поведения.
Роль не совсем про классический data engineering. Это инфраструктура, на которой держится detection абьюза, мониторинг моделей и все safety-механизмы.
По стэку всё довольно стандартно:
SQL, Python, dbt, Airflow, Spark, BigQuery / Snowflake / Redshift, BI-инструменты типа Looker или Tableau.
Все из проверенного data stack.
Из интересного, много работы с real-world сигналами: model outputs, user reports, automated classifiers.
Всё это нужно собрать в единый слой и сделать пригодным для анализа и принятия решений.
Компания спонсирует визы и работает в гибридном формате.
В целом уже прослеживается трансформация роли data engineer, не просто пайплайны и витрины, а система, от которой напрямую зависит, как ведёт себя модель в проде.
@tldr_data
£170K – £220K + (возможен equity)
Еще одна открытая позиция в AI гигант.
Data Engineer в Anthropic в команде Safeguards, которая отвечает за безопасность моделей и контроль их поведения.
Роль не совсем про классический data engineering. Это инфраструктура, на которой держится detection абьюза, мониторинг моделей и все safety-механизмы.
По стэку всё довольно стандартно:
SQL, Python, dbt, Airflow, Spark, BigQuery / Snowflake / Redshift, BI-инструменты типа Looker или Tableau.
Все из проверенного data stack.
Из интересного, много работы с real-world сигналами: model outputs, user reports, automated classifiers.
Всё это нужно собрать в единый слой и сделать пригодным для анализа и принятия решений.
Компания спонсирует визы и работает в гибридном формате.
В целом уже прослеживается трансформация роли data engineer, не просто пайплайны и витрины, а система, от которой напрямую зависит, как ведёт себя модель в проде.
@tldr_data
job-boards.greenhouse.io
Data Engineer, Safeguards
London, UK
❤1👍1
🚨 Breaking: OpenAI to acquire Astral
OpenAI объявили о покупке Astral - команды, которая делает uv, Ruff и ty.
Это уже не какие-то нишевые тулзы.
Ruff - де-факто стандарт линтинга в Python, uv быстро становится заменой pip + venv, ty - попытка переосмыслить type checking.
Все это open-source и уже используется миллионами разработчиков.
Сделка логично укладывается в стратегию OpenAI вокруг Codex, они усиливают слой developer tooling, чтобы закрыть весь lifecycle разработки, а не только генерацию кода.
При этом open-source обещают оставить и развивать.
По сути, они покупают не просто инструменты, а точку входа в developer workflow.
@tldr_data
OpenAI объявили о покупке Astral - команды, которая делает uv, Ruff и ty.
Это уже не какие-то нишевые тулзы.
Ruff - де-факто стандарт линтинга в Python, uv быстро становится заменой pip + venv, ty - попытка переосмыслить type checking.
Все это open-source и уже используется миллионами разработчиков.
Сделка логично укладывается в стратегию OpenAI вокруг Codex, они усиливают слой developer tooling, чтобы закрыть весь lifecycle разработки, а не только генерацию кода.
При этом open-source обещают оставить и развивать.
По сути, они покупают не просто инструменты, а точку входа в developer workflow.
@tldr_data
OpenAI
OpenAI to acquire Astral
Accelerates Codex growth to power the next generation of Python developer tools
👍1
Your Data Agents Need Context
a16z на этой неделе выпустили материал с довольно жёстким тезисом: первая волна enterprise AI-агентов по сути провалилась из-за отсутствия контекста.
Пример у них почти карикатурный: агенту задают вопрос какой был рост выручки за прошлый квартал? и он ломается.
Ломается, потому что ему никто не объяснил, как в компании считается revenue, какой используется fiscal calendar, что semantic layer давно не обновлялся и какая из трёх таблиц на самом деле source of truth.
В качестве решения предлагается отдельный context layer между данными и агентом - слой, который хранит бизнес-определения, фиксирует tribal knowledge, описывает source mappings и задаёт governance правила, а затем отдаёт всё это через API или MCP, чтобы агент работал не вслепую, а с реальным контекстом.
В целом это звучит логично и давно напрашивалось как отдельная категория.
Но интереснее другое, откуда этот контекст берётся.
В статье почти весь фокус на структурированных системах: data warehouse, BI-слой, dbt, LookML.
Это важная часть, но огромный кусок контекста туда вообще никогда не попадает. Ключевые решения принимаются в других местах: обсуждения что считать revenue происходят в почте, исключения согласуются в пересланных цепочках, часть договорённостей уходит в Slack или остаётся в созвонах.
И это нигде нормально не фиксируется.
В итоге есть две параллельные проблемы.
Первая - построить context layer поверх структурированных данных, и это как раз хорошо разобрано у a16z.
Вторая - вытащить контекст из неструктурированной коммуникации до того, как он вообще станет данными. Про это почти не говорят, хотя именно там живёт значительная часть реального знания компании. Если этот слой не закрыт, любой агент всё равно будет работать с неполной картиной и по сути гадать.
@tldr_data
a16z на этой неделе выпустили материал с довольно жёстким тезисом: первая волна enterprise AI-агентов по сути провалилась из-за отсутствия контекста.
Пример у них почти карикатурный: агенту задают вопрос какой был рост выручки за прошлый квартал? и он ломается.
Ломается, потому что ему никто не объяснил, как в компании считается revenue, какой используется fiscal calendar, что semantic layer давно не обновлялся и какая из трёх таблиц на самом деле source of truth.
В качестве решения предлагается отдельный context layer между данными и агентом - слой, который хранит бизнес-определения, фиксирует tribal knowledge, описывает source mappings и задаёт governance правила, а затем отдаёт всё это через API или MCP, чтобы агент работал не вслепую, а с реальным контекстом.
В целом это звучит логично и давно напрашивалось как отдельная категория.
Но интереснее другое, откуда этот контекст берётся.
В статье почти весь фокус на структурированных системах: data warehouse, BI-слой, dbt, LookML.
Это важная часть, но огромный кусок контекста туда вообще никогда не попадает. Ключевые решения принимаются в других местах: обсуждения что считать revenue происходят в почте, исключения согласуются в пересланных цепочках, часть договорённостей уходит в Slack или остаётся в созвонах.
И это нигде нормально не фиксируется.
В итоге есть две параллельные проблемы.
Первая - построить context layer поверх структурированных данных, и это как раз хорошо разобрано у a16z.
Вторая - вытащить контекст из неструктурированной коммуникации до того, как он вообще станет данными. Про это почти не говорят, хотя именно там живёт значительная часть реального знания компании. Если этот слой не закрыт, любой агент всё равно будет работать с неполной картиной и по сути гадать.
@tldr_data
Andreessen Horowitz
Your Data Agents Need Context | Andreessen Horowitz
Enterprise AI data agents are failing without a robust context layer, driving demand for modern data ontologies that unify business definitions, messy data systems, and tribal knowledge to power accurate, autonomous analytics.
👍1