Selectstar — Apache Flink SQL Sandbox
Интерактивная песочница для работы с Apache Flink SQL и Table API.
Инструмент позволяет экспериментировать с dynamic tables и changelog streams, запускать SQL-запросы поверх потоковых данных и в реальном времени видеть, как они транслируются между табличной и стриминговой моделью.
Это помогает лучше понять внутреннюю логику Flink и то, как SQL-операции преобразуются в потоковые вычисления.
Полезный ресурс для инженеров, работающих со streaming-пайплайнами и event-driven архитектурой.
@tldr_data
Интерактивная песочница для работы с Apache Flink SQL и Table API.
Инструмент позволяет экспериментировать с dynamic tables и changelog streams, запускать SQL-запросы поверх потоковых данных и в реальном времени видеть, как они транслируются между табличной и стриминговой моделью.
Это помогает лучше понять внутреннюю логику Flink и то, как SQL-операции преобразуются в потоковые вычисления.
Полезный ресурс для инженеров, работающих со streaming-пайплайнами и event-driven архитектурой.
@tldr_data
selectstar.stream
Flink SQL & Table API - Interactive Tutorial
Interactive demo for Apache Flink's table-stream duality - Learn Dynamic Tables and Changelog Streams
🔥1
Iceberg Lens
Iceberg Lens — это read-only desktop UI для инспекции структуры таблиц Apache Iceberg в локальной файловой системе.
Инструмент позволяет детально просматривать метаданные таблицы, snapshots, manifests, data files, delete files (equality и position), выборочные строки, а также changelog на каждом уровне, чтобы отслеживать изменения во времени.
Это удобно для понимания внутреннего устройства таблицы и отладки поведения пайплайнов.
Iceberg Lens работает в режиме read-only и не вносит изменений в таблицы или метаданные.
Приложение ориентировано на local-first сценарий: таблицы загружаются напрямую из директорий на вашей машине, что особенно полезно для локальной отладки.
Инструмент не требует внешних сервисов или каталогов и может работать полностью офлайн.
@tldr_data
Iceberg Lens — это read-only desktop UI для инспекции структуры таблиц Apache Iceberg в локальной файловой системе.
Инструмент позволяет детально просматривать метаданные таблицы, snapshots, manifests, data files, delete files (equality и position), выборочные строки, а также changelog на каждом уровне, чтобы отслеживать изменения во времени.
Это удобно для понимания внутреннего устройства таблицы и отладки поведения пайплайнов.
Iceberg Lens работает в режиме read-only и не вносит изменений в таблицы или метаданные.
Приложение ориентировано на local-first сценарий: таблицы загружаются напрямую из директорий на вашей машине, что особенно полезно для локальной отладки.
Инструмент не требует внешних сервисов или каталогов и может работать полностью офлайн.
@tldr_data
GitHub
GitHub - mmdemirbas/ice-lens: Visual inspector for Apache Iceberg tables
Visual inspector for Apache Iceberg tables. Contribute to mmdemirbas/ice-lens development by creating an account on GitHub.
👍1
Supermetal — альтернатива Debezium + Kafka
Supermetal — платформа репликации данных для batch, CDC и ELT-нагрузок.
Синхронизирует транзакционные БД с DWH и другими базами без классического multi-hop пайплайна.
Вместо схемы Source → Debezium → Kafka → Consumers → Target используется single-process архитектура.
Один бинарник на Rust с Apache Arrow внутри, без Kafka, JVM и сложной оркестрации. В роли durable-буфера — S3, Azure Blob или локальный NVMe.
Интересная модель монетизации: в trial доступно 1000 часов на синхронизацию данных, чего достаточно для тестирования и пилотных нагрузок.
Но если нужен self-hosted deployment, стоимость начинается примерно от $10 000 в год.
То есть вход в продакшен уже ориентирован на команды с бюджетом и серьёзными объёмами данных.
@tldr_data
Supermetal — платформа репликации данных для batch, CDC и ELT-нагрузок.
Синхронизирует транзакционные БД с DWH и другими базами без классического multi-hop пайплайна.
Вместо схемы Source → Debezium → Kafka → Consumers → Target используется single-process архитектура.
Один бинарник на Rust с Apache Arrow внутри, без Kafka, JVM и сложной оркестрации. В роли durable-буфера — S3, Azure Blob или локальный NVMe.
Интересная модель монетизации: в trial доступно 1000 часов на синхронизацию данных, чего достаточно для тестирования и пилотных нагрузок.
Но если нужен self-hosted deployment, стоимость начинается примерно от $10 000 в год.
То есть вход в продакшен уже ориентирован на команды с бюджетом и серьёзными объёмами данных.
@tldr_data
Supermetal
Supermetal - High Performance Data Replication Platform
Move terabytes of data with minimal resources using our Rust-based CDC platform.
👍1
Floe — это система обслуживания таблиц на основе политик для Apache Iceberg.
Floe автоматизирует compaction, snapshot expiration, orphan cleanup и оптимизацию манифестов с помощью декларативных политик.
Вместо написания кастомных скриптов или ручного запуска Spark job вы определяете политики, которые указывают, какое обслуживание выполнять, на каких таблицах, и при каких условиях запускать выполнение.
Floe берёт на себя остальное: планирование, выполнение через Spark или Trino, и отслеживание результатов.
@tldr_data
Floe автоматизирует compaction, snapshot expiration, orphan cleanup и оптимизацию манифестов с помощью декларативных политик.
Вместо написания кастомных скриптов или ручного запуска Spark job вы определяете политики, которые указывают, какое обслуживание выполнять, на каких таблицах, и при каких условиях запускать выполнение.
Floe берёт на себя остальное: планирование, выполнение через Spark или Trino, и отслеживание результатов.
@tldr_data
GitHub
GitHub - nssalian/floe: Floe: Policy-based table maintenance for Apache Iceberg
Floe: Policy-based table maintenance for Apache Iceberg - nssalian/floe
🔥2
Why Coinbase and Pinterest Chose StarRocks: Lakehouse-Native Design and Fast Joins at Terabyte Scale
StarRocks продолжает набирать популярность у команд, которым нужны быстрые аналитические запросы на больших объёмах данных.
Автор поста разобрался в том, как StarRocks используется в продакшене, взял интервью у инженеров и разобрал технические кейсы из таких компаний, как Coinbase, Pinterest, Fresha.
У всех компаний возникла похожая проблема: аналитика для пользователей, построенная на Snowflake, со временем стала слишком медленной.
Обновление данных раз в 15–20 минут уже не устраивало, а сервисам нужен был отклик быстрее секунды, без сложной предварительной денормализации во Flink или Spark.
В Coinbase почти вся аналитика работала на Snowflake, но для криптосервисов понадобился более быстрый Operational Data Store.
TiDB посчитали слишком радикальным изменением архитектуры.
В сравнении с ClickHouse, Pinot и Druid выбрали StarRocks, из-за сочетания быстрого приёма данных, нормальной работы JOIN’ов и возможности обслуживать запросы почти в реальном времени.
Плюс стоимость Snowflake и Databricks для такого сценария оказалась слишком высокой.
В Fresha ситуация была похожей: аналитика на dbt и Snowflake обновлялась каждые 20 минут и стала узким местом.
Они просто взяли существующие SQL-запросы с большим количеством CTE и JOIN’ов и запустили их в StarRocks.
Первый результат около четырёх секунд на сложных запросах, стал хорошей отправной точкой для дальнейшей оптимизации.
С ClickHouse добиться такого старта оказалось сложнее.
Pinterest использует StarRocks для инструмента Partner Insights - это аналитические дашборды для рекламодателей, которые отслеживают эффективность кампаний на аудитории более 500 миллионов активных пользователей в месяц.
Изначально система работала на Apache Druid, но со временем возникли ограничения по задержкам и эффективности инфраструктуры. После миграции на StarRocks компания добилась снижения p90 latency примерно на 50%.
При этом новая система использует около 32% от прежнего объёма инфраструктуры.
В пересчёте на соотношение цена/производительность это примерно трёхкратное улучшение.
Архитектура кластера включает 70 backend-узлов и 11 frontend-узлов.
Поддержка MySQL-совместимого протокола упростила интеграцию с существующими инструментами и сервисами.
Важным фактором стала и нативная загрузка данных в StarRocks - это позволило отказаться от тяжёлых MapReduce-задач в пайплайне, которые ранее использовались вместе с Druid.
В обсуждениях этой миграции на Reddit пользователи Druid и ClickHouse отмечали различия в подходах к архитектуре и работе с JOIN’ами, подчёркивая, что выбор движка во многом зависит от характера нагрузки и требований к задержке.
Главный технический аргумент в пользу StarRocks - производительность JOIN’ов.
Он использует распределение данных по хэш-ключам и colocation, чтобы минимизировать сетевые пересылки, а также кэширование и cost-based optimizer.
Кроме того, StarRocks может работать напрямую с данными в lakehouse (Iceberg, Delta Lake, Hudi, Hive), не требуя их переноса.
При этом у технологии есть ограничения: сообщество меньше, чем у ClickHouse, узнаваемость ниже, а экосистема менее зрелая.
В описанных кейсах StarRocks оказался инструментом, который лучше справился со сложной пользовательской аналитикой на больших объёмах данных, чем предыдущие решения.
@tldr_data
StarRocks продолжает набирать популярность у команд, которым нужны быстрые аналитические запросы на больших объёмах данных.
Автор поста разобрался в том, как StarRocks используется в продакшене, взял интервью у инженеров и разобрал технические кейсы из таких компаний, как Coinbase, Pinterest, Fresha.
У всех компаний возникла похожая проблема: аналитика для пользователей, построенная на Snowflake, со временем стала слишком медленной.
Обновление данных раз в 15–20 минут уже не устраивало, а сервисам нужен был отклик быстрее секунды, без сложной предварительной денормализации во Flink или Spark.
В Coinbase почти вся аналитика работала на Snowflake, но для криптосервисов понадобился более быстрый Operational Data Store.
TiDB посчитали слишком радикальным изменением архитектуры.
В сравнении с ClickHouse, Pinot и Druid выбрали StarRocks, из-за сочетания быстрого приёма данных, нормальной работы JOIN’ов и возможности обслуживать запросы почти в реальном времени.
Плюс стоимость Snowflake и Databricks для такого сценария оказалась слишком высокой.
В Fresha ситуация была похожей: аналитика на dbt и Snowflake обновлялась каждые 20 минут и стала узким местом.
Они просто взяли существующие SQL-запросы с большим количеством CTE и JOIN’ов и запустили их в StarRocks.
Первый результат около четырёх секунд на сложных запросах, стал хорошей отправной точкой для дальнейшей оптимизации.
С ClickHouse добиться такого старта оказалось сложнее.
Pinterest использует StarRocks для инструмента Partner Insights - это аналитические дашборды для рекламодателей, которые отслеживают эффективность кампаний на аудитории более 500 миллионов активных пользователей в месяц.
Изначально система работала на Apache Druid, но со временем возникли ограничения по задержкам и эффективности инфраструктуры. После миграции на StarRocks компания добилась снижения p90 latency примерно на 50%.
При этом новая система использует около 32% от прежнего объёма инфраструктуры.
В пересчёте на соотношение цена/производительность это примерно трёхкратное улучшение.
Архитектура кластера включает 70 backend-узлов и 11 frontend-узлов.
Поддержка MySQL-совместимого протокола упростила интеграцию с существующими инструментами и сервисами.
Важным фактором стала и нативная загрузка данных в StarRocks - это позволило отказаться от тяжёлых MapReduce-задач в пайплайне, которые ранее использовались вместе с Druid.
В обсуждениях этой миграции на Reddit пользователи Druid и ClickHouse отмечали различия в подходах к архитектуре и работе с JOIN’ами, подчёркивая, что выбор движка во многом зависит от характера нагрузки и требований к задержке.
Главный технический аргумент в пользу StarRocks - производительность JOIN’ов.
Он использует распределение данных по хэш-ключам и colocation, чтобы минимизировать сетевые пересылки, а также кэширование и cost-based optimizer.
Кроме того, StarRocks может работать напрямую с данными в lakehouse (Iceberg, Delta Lake, Hudi, Hive), не требуя их переноса.
При этом у технологии есть ограничения: сообщество меньше, чем у ClickHouse, узнаваемость ниже, а экосистема менее зрелая.
В описанных кейсах StarRocks оказался инструментом, который лучше справился со сложной пользовательской аналитикой на больших объёмах данных, чем предыдущие решения.
@tldr_data
Data Engineering Blog
Why Coinbase and Pinterest Chose StarRocks: Lakehouse-Native Design and Fast Joins at Terabyte Scale
Discover why Coinbase and Pinterest migrated to StarRocks for sub-second analytics. Learn how its lakehouse-native design and colocated joins handle terabyte-scale data on S3.
👍2❤1
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