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