Stop rebuilding what production already built. Change-aware SQL pipelines with all state in the warehouse.
SQLBuild предлагает довольно простой подход: не пересобирать модели, которые не изменились. Инструмент отслеживает изменения, повторно использует уже готовые таблицы из продакшена и хранит всё состояние прямо в хранилище данных — без отдельной базы для метаданных и дополнительных сервисов.
Из интересного: работает поверх существующего dbt-проекта и не требует миграции или изменений в моделях.
Идея выглядит особенно актуальной для крупных проектов, где время сборки и затраты на вычисления становятся заметной проблемой.
@tldr_data
SQLBuild предлагает довольно простой подход: не пересобирать модели, которые не изменились. Инструмент отслеживает изменения, повторно использует уже готовые таблицы из продакшена и хранит всё состояние прямо в хранилище данных — без отдельной базы для метаданных и дополнительных сервисов.
Из интересного: работает поверх существующего dbt-проекта и не требует миграции или изменений в моделях.
Идея выглядит особенно актуальной для крупных проектов, где время сборки и затраты на вычисления становятся заметной проблемой.
@tldr_data
GitHub
GitHub - chio-labs/sqlbuild
Contribute to chio-labs/sqlbuild development by creating an account on GitHub.
🔥1
AI может написать код за секунды. Понять и поддерживать этот код — уже ваша задача.
Именно поэтому всё больше внимания уделяется не только генерации кода, но и его единообразию.
В новом материале Bartosz Konieczny(тот самый автор Data Engineering Design Patterns) рассказывает, как использовать Ruff в проектах на Databricks и почему этот инструмент стал стандартом даже для Apache Spark.
Основные мысли:
• Ruff объединяет линтер и форматтер в одном инструменте, упрощая разработческий стек.
• Сообщество Apache Spark использует Ruff для проверки качества и форматирования Python-кода.
• Не стоит бездумно копировать чужие наборы правил — конфигурация должна отражать потребности конкретного проекта.
• Для Databricks Declarative Automation Bundles полезно запускать Ruff через pre-commit, чтобы находить проблемы ещё до отправки изменений в репозиторий.
Такой подход автор уже демонстрировал на примере автоматической валидации DAB через Git hooks.
• Строгие проверки лучше выполнять в CI/CD для основных веток, а не блокировать разработку в sandbox-окружениях.
В эпоху AI-агентов стиль кода становится не вопросом эстетики, а способом сохранить контроль над кодовой базой. Чем больше кода генерируется автоматически, тем важнее единые правила его оформления и проверки.
Статья автора:
Ruff and Declarative Automation Bundles
@tldr_data
Именно поэтому всё больше внимания уделяется не только генерации кода, но и его единообразию.
В новом материале Bartosz Konieczny(тот самый автор Data Engineering Design Patterns) рассказывает, как использовать Ruff в проектах на Databricks и почему этот инструмент стал стандартом даже для Apache Spark.
Основные мысли:
• Ruff объединяет линтер и форматтер в одном инструменте, упрощая разработческий стек.
• Сообщество Apache Spark использует Ruff для проверки качества и форматирования Python-кода.
• Не стоит бездумно копировать чужие наборы правил — конфигурация должна отражать потребности конкретного проекта.
• Для Databricks Declarative Automation Bundles полезно запускать Ruff через pre-commit, чтобы находить проблемы ещё до отправки изменений в репозиторий.
Такой подход автор уже демонстрировал на примере автоматической валидации DAB через Git hooks.
• Строгие проверки лучше выполнять в CI/CD для основных веток, а не блокировать разработку в sandbox-окружениях.
В эпоху AI-агентов стиль кода становится не вопросом эстетики, а способом сохранить контроль над кодовой базой. Чем больше кода генерируется автоматически, тем важнее единые правила его оформления и проверки.
Статья автора:
Ruff and Declarative Automation Bundles
@tldr_data
GitHub
databricks-playground/ruff-dab at main · bartosz25/databricks-playground
Contribute to bartosz25/databricks-playground development by creating an account on GitHub.
🔥1
Вышел Flink 2.3.0
На мой взгляд, самое важное изменение — обновление SinkUpsertMaterializer.
SinkUpsertMaterializer может автоматически добавляться планировщиком Flink Table API, когда возникает несоответствие между upsert-операциями и первичным ключом (а такое происходит очень часто).
Теперь в Flink наконец появилась оптимизация, которая позволяет очищать состояние (state) на основе watermarks. Раньше состояние SinkUpsertMaterializer только росло и никогда не освобождалось.
https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/
@tldr_data
На мой взгляд, самое важное изменение — обновление SinkUpsertMaterializer.
SinkUpsertMaterializer может автоматически добавляться планировщиком Flink Table API, когда возникает несоответствие между upsert-операциями и первичным ключом (а такое происходит очень часто).
Теперь в Flink наконец появилась оптимизация, которая позволяет очищать состояние (state) на основе watermarks. Раньше состояние SinkUpsertMaterializer только росло и никогда не освобождалось.
https://flink.apache.org/2026/06/25/apache-flink-2.3.0-release-announcement/
@tldr_data
flink.apache.org
Apache Flink 2.3.0 Release Announcement
The Apache Flink PMC is pleased to announce the release of Apache Flink 2.3.0.
This release significantly expands SQL capabilities with changelog conversion operators, enhances materialized table flexibility, introduces an experimental, high-performance native…
This release significantly expands SQL capabilities with changelog conversion operators, enhances materialized table flexibility, introduces an experimental, high-performance native…
🔥1
Point-in-time recovery for MySQL — no locks, no schema changes, no waiting for a restore.
dbtrail добавляет для MySQL возможность восстановления данных на любой момент времени (point-in-time recovery). Для этого он непрерывно считывает binlog, индексирует изменения строк и сохраняет их состояние до и после каждой операции.
В результате команды могут:
- просматривать историю изменений;
- автоматически генерировать SQL для отката изменений;
- выполнять запросы к данным «как они выглядели» в определённый момент времени (time-travel queries);
- использовать MCP для восстановления данных с помощью AI.
@tldr_data
dbtrail добавляет для MySQL возможность восстановления данных на любой момент времени (point-in-time recovery). Для этого он непрерывно считывает binlog, индексирует изменения строк и сохраняет их состояние до и после каждой операции.
В результате команды могут:
- просматривать историю изменений;
- автоматически генерировать SQL для отката изменений;
- выполнять запросы к данным «как они выглядели» в определённый момент времени (time-travel queries);
- использовать MCP для восстановления данных с помощью AI.
@tldr_data
GitHub
GitHub - dbtrail/dbtrail: Data recovery for your MySQL and PostgreSQL. DB Trail remembers every row change: searchable, reversible…
Data recovery for your MySQL and PostgreSQL. DB Trail remembers every row change: searchable, reversible, yours. The wrong UPDATE becomes a two-minute fix. - dbtrail/dbtrail
🔥1
From Airflow to AI Agents: Maxime Beauchemin on the Future of Software Development
Maxime Beauchemin — создатель Apache Airflow и Apache Superset — стал гостем подкаста и рассказал о том, как его путь привел от data engineering к разработке AI-инструментов.
Он вспоминает, как в Airbnb появился Airflow: команде просто не хватало хорошего инструмента для оркестрации data-пайплайнов, поэтому они сделали его сами. Позже появился Superset, а затем и компания Preset.
Но самая интересная часть — разговор о том, куда движется разработка сегодня. Максим рассказывает о своем «моменте Claude Code» и новом проекте Agor — платформе для работы с AI-агентами.
По его словам, такие агенты уже помогают автоматизировать самые разные процессы: проверяют договоры, участвуют в согласовании сделок, ищут баги и даже выполняют часть QA-тестирования.
Под конец разговор становится немного философским: что будет, если разработка станет почти полностью автоматизированной? И чем тогда будут заниматься люди? Максим считает, что времени на любимые увлечения — вроде горного велосипеда или e-foiling — станет только больше.
@tldr_data
Maxime Beauchemin — создатель Apache Airflow и Apache Superset — стал гостем подкаста и рассказал о том, как его путь привел от data engineering к разработке AI-инструментов.
Он вспоминает, как в Airbnb появился Airflow: команде просто не хватало хорошего инструмента для оркестрации data-пайплайнов, поэтому они сделали его сами. Позже появился Superset, а затем и компания Preset.
Но самая интересная часть — разговор о том, куда движется разработка сегодня. Максим рассказывает о своем «моменте Claude Code» и новом проекте Agor — платформе для работы с AI-агентами.
По его словам, такие агенты уже помогают автоматизировать самые разные процессы: проверяют договоры, участвуют в согласовании сделок, ищут баги и даже выполняют часть QA-тестирования.
Под конец разговор становится немного философским: что будет, если разработка станет почти полностью автоматизированной? И чем тогда будут заниматься люди? Максим считает, что времени на любимые увлечения — вроде горного велосипеда или e-foiling — станет только больше.
@tldr_data
YouTube
Airflow's Creator on His 'Claude Code' Moment
Maxime Beauchemin, the creator of Apache Airflow and Apache Superset, joins the show to discuss his transition from data engineering to the frontier of AI. Max shares the origin stories of his massive open-source projects, detailing how Airflow was born at…
🔥1
5 Signs Your Codebase Is Punishing Your Team
Представьте: команде понадобилась неделя, чтобы добавить экспорт CSV в админку. Два разработчика, все требования описаны, а самой работы — максимум на день. Остальное время ушло на попытки понять существующий код и безопасно внести изменения.
Автор статьи называет это явление Codebase Drag — сопротивление кодовой базы, которое замедляет любую задачу.
1. The Apology Estimate
Фича выглядит как задача на 2–3 дня, а разработчики называют две недели.
Просто они знают, что изменение кода в одном месте может затронуть всю систему и привести к неожиданным последствиям. Поэтому закладывают дополнительное время на фичу.
2. Deploy Fear
Это классика, про которую слышали все.
Команда избегает выкатывать изменения по пятницам или вообще после среды.
Каждый релиз воспринимается как потенциальный инцидент.
По метрикам DORA лучшие команды деплоят по требованию и удерживают долю неудачных изменений ниже 5%. В примере из статьи команда делала один деплой в неделю и каждый раз затаивала дыхание.
3. The “Don’t Touch That” File
В каждом проекте есть тот самый модуль, про который говорят: «Лучше туда не лезть».
Со временем вокруг него начинает разрастаться новый код, а проблема только усугубляется.
4. The Coverage Lie
Покрытие может показывать 80%, но критически важные части системы остаются без проверок.
Тесты проходят, а прод продолжает ломаться.
Прогон CI занимает 40 минут, а новые тесты делают его ещё медленнее.
В какой-то момент разработчики перестают запускать тесты локально.
В итоге метрика покрытия врёт дважды: тесты не проверяют самое важное, а часть из них вообще никто не запускает.
5. Time to First Commit
Если новому разработчику нужны недели, чтобы поднять проект и внести первое изменение, то это уже звоночек о накопившейся сложности системы.
В здоровой кодовой базе на это уходит день-два. README актуален, окружение поднимается без танцев с бубном, тесты запускаются локально. В проблемных проектах этот процесс может занимать недели.
Главная мысль статьи:
технический долг — это не только баги и плохой код, это ещё и постоянный налог на скорость команды.
Чем выше этот налог, тем больше времени уходит не на создание нового, а на борьбу со сложностью существующей системы.
Именно поэтому добавление новых процессов, митингов или даже AI-инструментов часто не даёт ожидаемого эффекта.
Если фундамент проекта мешает работать, сначала нужно инвестировать в его оздоровление.
В конце автор предлагает провести простой Codebase Drag Audit.
Для каждого из пяти признаков выставляется оценка от 0 до 2 баллов.
Если суммарно получается 4 балла и больше, то кодовая база уже требует целенаправленных инвестиций.
По мнению автора, до этого момента любые попытки ускорить команду будут давать ограниченный эффект.
Неплохое упражнение для любого техлида или EM — чтобы оценить свою систему и понять, где вы находитесь сейчас.
@tldr_data
Представьте: команде понадобилась неделя, чтобы добавить экспорт CSV в админку. Два разработчика, все требования описаны, а самой работы — максимум на день. Остальное время ушло на попытки понять существующий код и безопасно внести изменения.
Автор статьи называет это явление Codebase Drag — сопротивление кодовой базы, которое замедляет любую задачу.
1. The Apology Estimate
Фича выглядит как задача на 2–3 дня, а разработчики называют две недели.
Просто они знают, что изменение кода в одном месте может затронуть всю систему и привести к неожиданным последствиям. Поэтому закладывают дополнительное время на фичу.
2. Deploy Fear
Это классика, про которую слышали все.
Команда избегает выкатывать изменения по пятницам или вообще после среды.
Каждый релиз воспринимается как потенциальный инцидент.
По метрикам DORA лучшие команды деплоят по требованию и удерживают долю неудачных изменений ниже 5%. В примере из статьи команда делала один деплой в неделю и каждый раз затаивала дыхание.
3. The “Don’t Touch That” File
В каждом проекте есть тот самый модуль, про который говорят: «Лучше туда не лезть».
Со временем вокруг него начинает разрастаться новый код, а проблема только усугубляется.
4. The Coverage Lie
Покрытие может показывать 80%, но критически важные части системы остаются без проверок.
Тесты проходят, а прод продолжает ломаться.
Прогон CI занимает 40 минут, а новые тесты делают его ещё медленнее.
В какой-то момент разработчики перестают запускать тесты локально.
В итоге метрика покрытия врёт дважды: тесты не проверяют самое важное, а часть из них вообще никто не запускает.
5. Time to First Commit
Если новому разработчику нужны недели, чтобы поднять проект и внести первое изменение, то это уже звоночек о накопившейся сложности системы.
В здоровой кодовой базе на это уходит день-два. README актуален, окружение поднимается без танцев с бубном, тесты запускаются локально. В проблемных проектах этот процесс может занимать недели.
Главная мысль статьи:
технический долг — это не только баги и плохой код, это ещё и постоянный налог на скорость команды.
Чем выше этот налог, тем больше времени уходит не на создание нового, а на борьбу со сложностью существующей системы.
Именно поэтому добавление новых процессов, митингов или даже AI-инструментов часто не даёт ожидаемого эффекта.
Если фундамент проекта мешает работать, сначала нужно инвестировать в его оздоровление.
В конце автор предлагает провести простой Codebase Drag Audit.
Для каждого из пяти признаков выставляется оценка от 0 до 2 баллов.
Если суммарно получается 4 балла и больше, то кодовая база уже требует целенаправленных инвестиций.
По мнению автора, до этого момента любые попытки ускорить команду будут давать ограниченный эффект.
Неплохое упражнение для любого техлида или EM — чтобы оценить свою систему и понять, где вы находитесь сейчас.
@tldr_data
piechowski.io
Why Your Engineering Team Is Slow (It's the Codebase, Not the People)
A two-minute interactive audit to score whether technical debt is dragging your engineering team. Five signals that separate people problems from code problems.
🔥1
Как Airtable сократил стоимость хранения архивных данных в 100 раз и сэкономил миллионы долларов
В 2024 году команда Airtable столкнулась с проблемой, знакомой многим крупным компаниям: объем данных в MySQL рос настолько быстро, что некоторые базы уже приближались к лимиту AWS RDS в 64 ТБ.
Основную часть занимали журналы изменений и история действий пользователей — данные, которые редко читаются, но по требованиям клиентов должны храниться до 10 лет.
Хранить петабайты такой информации в MySQL оказалось слишком дорого.
При этом отказаться от нее было нельзя: пользователи ожидают, что история изменений открывается мгновенно, а инженеры регулярно используют эти данные для расследования инцидентов и отладки.
Решение оказалось довольно элегантным.
Свежие данные остались в MySQL, а архивные перенесли в AWS S3, сохранив их в формате Apache Parquet.
Для выполнения запросов команда протестировала несколько движков, включая Athena, DuckDB и StarRocks, но в итоге остановилась на DataFusion — SQL-движке на Rust, который лучше остальных использовал возможности Parquet и позволял встроить движок прямо в существующие сервисы без запуска отдельного кластера.
Сама миграция была нетривиальной.
Снимки огромных MySQL-таблиц выгружались из RDS в Parquet, после чего Apache Flink перераспределял данные по отдельным базам. Затем специальные процессы объединяли файлы, удаляли дубликаты и формировали оптимизированные Parquet-файлы для дальнейшего хранения и обслуживания запросов.
Перед запуском новую систему долго проверяли.
Помимо сверки данных между MySQL и Parquet, команда включила shadow-режим на реальном трафике, когда каждый запрос параллельно выполнялся и через старую, и через новую систему.
Такой подход помог обнаружить множество неожиданных проблем: различия в обработке чисел между JavaScript и Rust, ошибки сортировки в DataFusion и даже проблемы во взаимодействии Rust-кода с Node.js.
После запуска основная работа сосредоточилась вокруг производительности.
Поскольку запросы выполнялись поверх файлов в S3, инженеры построили многоуровневую систему кэширования и добились более 99% попаданий в кэш для метаданных.
Для сложных фильтров появились собственные вторичные индексы на базе Parquet, а для некоторых типов запросов начали использовать Bloom Filters, чтобы не сканировать лишние данные.
Итог проекта:
Airtable вынес петабайты данных из MySQL, снизил стоимость хранения примерно в 100 раз и начал экономить миллионы долларов ежегодно.
При этом для пользователей практически ничего не изменилось — история изменений по-прежнему открывается с интерактивной скоростью.
Это отличный пример того, как современные форматы хранения данных, объектные хранилища и open-source инструменты вроде DataFusion позволяют строить решения, которые раньше ассоциировались только с полноценными СУБД.
♾️ Оригинальный пост♾️
@tldr_data
В 2024 году команда Airtable столкнулась с проблемой, знакомой многим крупным компаниям: объем данных в MySQL рос настолько быстро, что некоторые базы уже приближались к лимиту AWS RDS в 64 ТБ.
Основную часть занимали журналы изменений и история действий пользователей — данные, которые редко читаются, но по требованиям клиентов должны храниться до 10 лет.
Хранить петабайты такой информации в MySQL оказалось слишком дорого.
При этом отказаться от нее было нельзя: пользователи ожидают, что история изменений открывается мгновенно, а инженеры регулярно используют эти данные для расследования инцидентов и отладки.
Решение оказалось довольно элегантным.
Свежие данные остались в MySQL, а архивные перенесли в AWS S3, сохранив их в формате Apache Parquet.
Для выполнения запросов команда протестировала несколько движков, включая Athena, DuckDB и StarRocks, но в итоге остановилась на DataFusion — SQL-движке на Rust, который лучше остальных использовал возможности Parquet и позволял встроить движок прямо в существующие сервисы без запуска отдельного кластера.
Сама миграция была нетривиальной.
Снимки огромных MySQL-таблиц выгружались из RDS в Parquet, после чего Apache Flink перераспределял данные по отдельным базам. Затем специальные процессы объединяли файлы, удаляли дубликаты и формировали оптимизированные Parquet-файлы для дальнейшего хранения и обслуживания запросов.
Перед запуском новую систему долго проверяли.
Помимо сверки данных между MySQL и Parquet, команда включила shadow-режим на реальном трафике, когда каждый запрос параллельно выполнялся и через старую, и через новую систему.
Такой подход помог обнаружить множество неожиданных проблем: различия в обработке чисел между JavaScript и Rust, ошибки сортировки в DataFusion и даже проблемы во взаимодействии Rust-кода с Node.js.
После запуска основная работа сосредоточилась вокруг производительности.
Поскольку запросы выполнялись поверх файлов в S3, инженеры построили многоуровневую систему кэширования и добились более 99% попаданий в кэш для метаданных.
Для сложных фильтров появились собственные вторичные индексы на базе Parquet, а для некоторых типов запросов начали использовать Bloom Filters, чтобы не сканировать лишние данные.
Итог проекта:
Airtable вынес петабайты данных из MySQL, снизил стоимость хранения примерно в 100 раз и начал экономить миллионы долларов ежегодно.
При этом для пользователей практически ничего не изменилось — история изменений по-прежнему открывается с интерактивной скоростью.
Это отличный пример того, как современные форматы хранения данных, объектные хранилища и open-source инструменты вроде DataFusion позволяют строить решения, которые раньше ассоциировались только с полноценными СУБД.
@tldr_data
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
How we reduced archive storage costs by 100x and saved millions
In this post, we introduce a new storage system that we built in order to cost-efficiently store log data while providing interactive query…
❤2
🤖 RisingWave 3.0: взгляд на AI-инфраструктуру со стороны данных
Последние пару лет вокруг AI много говорят про модели, RAG и векторные базы.
Но когда компании начинают запускать AI-агентов в продакшене, быстро выясняется, что одна из главных проблем находится совсем в другой плоскости — как дать модели доступ к актуальным данным.
Представьте агента поддержки клиентов.
Он сообщает, что товар есть в наличии, хотя его уже раскупили.
Показывает старый статус заказа или предлагает промокод, который больше не действует. Во многих случаях причина таких ошибок довольно простая: модель получает устаревшую информацию.
Именно на эту проблему нацелена новая версия RisingWave.
Вместо того чтобы при каждом запросе собирать данные из множества систем, платформа предлагает заранее формировать актуальное состояние бизнеса в виде непрерывно обновляемых materialized views.
Изменения поступают через CDC из PostgreSQL, MySQL, Kafka и других источников, обрабатываются потоковым SQL и становятся доступны через привычный PostgreSQL-интерфейс или MCP.
В RisingWave предлагают смотреть на data lake не просто как на место хранения данных.
Для аналитики это хранилище таблиц и исторических данных.
Для AI-приложений — место, где хранится весь накопленный контекст, который может понадобиться модели.
Поэтому в версии 3.0 поддержка Apache Iceberg превратилась из обычного sink'а в полноценный табличный движок.
Появилась поддержка Iceberg V2 и V3, автоматическая эволюция схем, встроенная компакция файлов, очистка старых снапшотов и собственный query engine на базе Apache DataFusion.
При этом данные остаются в открытом формате.
Один и тот же Iceberg-слой может использоваться RisingWave, Spark, Trino, DuckDB и любыми другими совместимыми инструментами.
Получается интересная картина: потоковые данные обновляют представления практически в реальном времени, аналитика работает поверх тех же данных, а AI-приложения получают доступ к актуальному контексту из того же самого хранилища.
Без отдельных копий данных и без привязки к одному вендору.
Мне кажется, это одна из самых интересных идей в релизе. Не очередная попытка построить новую AI-платформу, а попытка решить вполне практическую задачу: как поддерживать данные в таком состоянии, чтобы ими одновременно могли пользоваться и аналитические системы, и AI-приложения.
@tldr_data
Последние пару лет вокруг AI много говорят про модели, RAG и векторные базы.
Но когда компании начинают запускать AI-агентов в продакшене, быстро выясняется, что одна из главных проблем находится совсем в другой плоскости — как дать модели доступ к актуальным данным.
Представьте агента поддержки клиентов.
Он сообщает, что товар есть в наличии, хотя его уже раскупили.
Показывает старый статус заказа или предлагает промокод, который больше не действует. Во многих случаях причина таких ошибок довольно простая: модель получает устаревшую информацию.
Именно на эту проблему нацелена новая версия RisingWave.
Вместо того чтобы при каждом запросе собирать данные из множества систем, платформа предлагает заранее формировать актуальное состояние бизнеса в виде непрерывно обновляемых materialized views.
Изменения поступают через CDC из PostgreSQL, MySQL, Kafka и других источников, обрабатываются потоковым SQL и становятся доступны через привычный PostgreSQL-интерфейс или MCP.
В RisingWave предлагают смотреть на data lake не просто как на место хранения данных.
Для аналитики это хранилище таблиц и исторических данных.
Для AI-приложений — место, где хранится весь накопленный контекст, который может понадобиться модели.
Поэтому в версии 3.0 поддержка Apache Iceberg превратилась из обычного sink'а в полноценный табличный движок.
Появилась поддержка Iceberg V2 и V3, автоматическая эволюция схем, встроенная компакция файлов, очистка старых снапшотов и собственный query engine на базе Apache DataFusion.
При этом данные остаются в открытом формате.
Один и тот же Iceberg-слой может использоваться RisingWave, Spark, Trino, DuckDB и любыми другими совместимыми инструментами.
Получается интересная картина: потоковые данные обновляют представления практически в реальном времени, аналитика работает поверх тех же данных, а AI-приложения получают доступ к актуальному контексту из того же самого хранилища.
Без отдельных копий данных и без привязки к одному вендору.
Мне кажется, это одна из самых интересных идей в релизе. Не очередная попытка построить новую AI-платформу, а попытка решить вполне практическую задачу: как поддерживать данные в таком состоянии, чтобы ими одновременно могли пользоваться и аналитические системы, и AI-приложения.
@tldr_data
RisingWave
RisingWave 3.0:
The real-time context layer for interactive AI
The real-time context layer for interactive AI
Discover RisingWave 3.0, featuring Apache Iceberg V3, native vector search, DataFusion, SQL operational workflows, and a real-time context layer for AI.
❤1
Kafka is easier to understand when you can break it
Kafka легко объяснить как набор понятий: топики, партиции, брокеры, реплики, лидеры, оффсеты.
В начале это работает, но потом падает первый брокер, ISR сжимается, продюсер с acks=all перестаёт получать подтверждения — и статичная схема превращается в последовательность решений во времени.
Самое важное в Kafka скрыто именно в этих переходах: до и после сбоя, до и после выборов лидера.
Monedula сделали Kafka Simulator — браузерную детерминированную модель, которую можно безопасно сломать и разобрать по шагам.
Ставишь replication factor=3, min.insync.replicas=2, acks=all, убираешь один брокер — кластер деградировал, но пишет.
Убираешь второй — лидер жив, данные на месте, а запись уже отклоняется с NotEnoughReplicas.
Гарантию надёжности больше не выполнить.
Очень круто что команда сделала большой туториал по работе с Kafka.
@tldr_data
Kafka легко объяснить как набор понятий: топики, партиции, брокеры, реплики, лидеры, оффсеты.
В начале это работает, но потом падает первый брокер, ISR сжимается, продюсер с acks=all перестаёт получать подтверждения — и статичная схема превращается в последовательность решений во времени.
Самое важное в Kafka скрыто именно в этих переходах: до и после сбоя, до и после выборов лидера.
Monedula сделали Kafka Simulator — браузерную детерминированную модель, которую можно безопасно сломать и разобрать по шагам.
Ставишь replication factor=3, min.insync.replicas=2, acks=all, убираешь один брокер — кластер деградировал, но пишет.
Убираешь второй — лидер жив, данные на месте, а запись уже отклоняется с NotEnoughReplicas.
Гарантию надёжности больше не выполнить.
Очень круто что команда сделала большой туториал по работе с Kafka.
@tldr_data
Monedula
Monedula Kafka Simulator
An interactive simulator for Apache Kafka. Modeled baseline: Kafka 4.3. Deterministic, seeded, replayable. Browser-only.
👍2
Apache Arrow ecosystem
Экосистема Apache Arrow давно вышла за рамки просто формата колоночного хранения данных в памяти.
Сегодня это слой обмена данными, который лежит в основе современных аналитических движков, lakehouse-решений и файловых форматов (например, Apache Iceberg, Parquet), а также AI-систем.
В своей основе Arrow определяет, как данные представлены в памяти. Но экосистема вокруг него решает более широкие задачи: как эффективно перемещать данные и как выполнять запросы между различными системами.
Каждый подпроект отвечает за свою часть этой задачи.
Разберём основные компоненты:
Arrow — определяет независимый от языка программирования колоночный формат данных в памяти, который позволяет разным системам обмениваться данными без сериализации и десериализации (без дорогостоящих преобразований в JSON, CSV и другие форматы).
Arrow Flight — высокопроизводительный RPC-фреймворк, построенный на gRPC, который передаёт данные в формате Arrow между клиентом и сервером практически на максимальной скорости сети.
Flight SQL — протокол, расширяющий Flight и позволяющий передавать SQL-запросы и выполнять их удалённо.
ADBC (Arrow Database Connectivity) — стандартизированный API для взаимодействия с базами данных. Он упрощает выполнение запросов и работу с БД, используя данные в нативном формате Arrow (как через Flight SQL, так и без него).
Как эти компоненты работают вместе?
✅ Клиент использует драйвер ADBC для отправки SQL-запроса.
✅ ADBC передаёт запрос в библиотеку клиента Flight SQL.
✅ Библиотека упаковывает запрос и отправляет его через Arrow Flight RPC.
✅ Серверный endpoint Flight SQL выполняет запрос.
✅ Результаты возвращаются в виде потоков колоночных батчей Arrow, готовых для непосредственной обработки в памяти.
Что даёт такой подход
Сквозное колоночное перемещение данных: от представления в памяти до транспорта и выполнения запросов.
Минимизацию копирования и преобразования данных.
Более высокую производительность по сравнению с традиционными JDBC/ODBC-подходами.
Удобную интеграцию аналитических систем, движков обработки данных и AI-приложений.
Если упростить до одной фразы:
@tldr_data
Экосистема Apache Arrow давно вышла за рамки просто формата колоночного хранения данных в памяти.
Сегодня это слой обмена данными, который лежит в основе современных аналитических движков, lakehouse-решений и файловых форматов (например, Apache Iceberg, Parquet), а также AI-систем.
В своей основе Arrow определяет, как данные представлены в памяти. Но экосистема вокруг него решает более широкие задачи: как эффективно перемещать данные и как выполнять запросы между различными системами.
Каждый подпроект отвечает за свою часть этой задачи.
Разберём основные компоненты:
Arrow — определяет независимый от языка программирования колоночный формат данных в памяти, который позволяет разным системам обмениваться данными без сериализации и десериализации (без дорогостоящих преобразований в JSON, CSV и другие форматы).
Arrow Flight — высокопроизводительный RPC-фреймворк, построенный на gRPC, который передаёт данные в формате Arrow между клиентом и сервером практически на максимальной скорости сети.
Flight SQL — протокол, расширяющий Flight и позволяющий передавать SQL-запросы и выполнять их удалённо.
ADBC (Arrow Database Connectivity) — стандартизированный API для взаимодействия с базами данных. Он упрощает выполнение запросов и работу с БД, используя данные в нативном формате Arrow (как через Flight SQL, так и без него).
Как эти компоненты работают вместе?
✅ Клиент использует драйвер ADBC для отправки SQL-запроса.
✅ ADBC передаёт запрос в библиотеку клиента Flight SQL.
✅ Библиотека упаковывает запрос и отправляет его через Arrow Flight RPC.
✅ Серверный endpoint Flight SQL выполняет запрос.
✅ Результаты возвращаются в виде потоков колоночных батчей Arrow, готовых для непосредственной обработки в памяти.
Что даёт такой подход
Сквозное колоночное перемещение данных: от представления в памяти до транспорта и выполнения запросов.
Минимизацию копирования и преобразования данных.
Более высокую производительность по сравнению с традиционными JDBC/ODBC-подходами.
Удобную интеграцию аналитических систем, движков обработки данных и AI-приложений.
Если упростить до одной фразы:
Arrow отвечает за формат данных в памяти, Flight — за их передачу, Flight SQL — за выполнение SQL-запросов, а ADBC — за удобный интерфейс доступа к этим возможностям из приложений.
@tldr_data
👍2
Продакшен Postgres:
— Пожалуйста, не надо…
Инженер данных:
— О, PostgreSQL. Отличная база для аналитики!
@tldr_data
— Пожалуйста, не надо…
Инженер данных:
— О, PostgreSQL. Отличная база для аналитики!
@tldr_data
🔥1
Train LLM From Scratch
Большинство туториалов по LLM заканчиваются на фразе загрузите модель из Hugging Face и запустите fine-tuning.
Этот репозиторий идет в противоположную сторону.
Автор реализовал Transformer с нуля на чистом PyTorch, опираясь на статью Attention Is All You Need. Без
Цель — не дообучить готовую модель, а разобраться, как она устроена.
Причем это уже не просто реализация архитектуры.
Репозиторий проводит через весь жизненный цикл современной LLM:
строим Transformer;
предобучаем на сырых текстах;
обучаем следовать инструкциям (SFT);
тренируем Reward Model;
применяем DPO/PPO;
доходим до GRPO и reasoning-моделей.
Основная идея идея репозитория:
превращаем текст в числа, затем учим модель предсказывать следующий токен, постепенно меняем данные и функцию потерь, пока модель не начинает делать то, что нам нужно.
Все алгоритмы написаны вручную на PyTorch, поэтому хорошо видно, что происходит на каждом этапе обучения.
По словам автора, модели можно обучать даже на одной GPU — от миллионов до миллиардов параметров.
Для тех, кто хочет понять, как на самом деле обучаются современные LLM, а не только пользоваться готовыми библиотеками, это один из самых интересных открытых проектов, которые я видел за последнее время.
@tldr_data
Большинство туториалов по LLM заканчиваются на фразе загрузите модель из Hugging Face и запустите fine-tuning.
Этот репозиторий идет в противоположную сторону.
Автор реализовал Transformer с нуля на чистом PyTorch, опираясь на статью Attention Is All You Need. Без
transformers, trl и peft. Цель — не дообучить готовую модель, а разобраться, как она устроена.
Причем это уже не просто реализация архитектуры.
Репозиторий проводит через весь жизненный цикл современной LLM:
строим Transformer;
предобучаем на сырых текстах;
обучаем следовать инструкциям (SFT);
тренируем Reward Model;
применяем DPO/PPO;
доходим до GRPO и reasoning-моделей.
Основная идея идея репозитория:
превращаем текст в числа, затем учим модель предсказывать следующий токен, постепенно меняем данные и функцию потерь, пока модель не начинает делать то, что нам нужно.
Все алгоритмы написаны вручную на PyTorch, поэтому хорошо видно, что происходит на каждом этапе обучения.
По словам автора, модели можно обучать даже на одной GPU — от миллионов до миллиардов параметров.
Для тех, кто хочет понять, как на самом деле обучаются современные LLM, а не только пользоваться готовыми библиотеками, это один из самых интересных открытых проектов, которые я видел за последнее время.
@tldr_data
🔥2
Netflix Cuts Cassandra Read Latency from Seconds to Milliseconds with Dynamic Partition Splitting
Инженеры Netflix рассказали о механизме динамического разделения партиций для Apache Cassandra, который позволил сократить задержку чтения из слишком больших партиций с временными рядами с нескольких секунд до нескольких десятков миллисекунд. При этом также снизились количество тайм-аутов при чтении, загрузка процессоров и очереди потоков в производственных кластерах. Разработанный для платформы TimeSeries Abstraction в Netflix, этот механизм автоматически разбивает растущие партиции на более мелкие дочерние партиции, не требуя изменений в приложениях, простоя системы или масштабного перепартиционирования данных.
@tldr_data
Инженеры Netflix рассказали о механизме динамического разделения партиций для Apache Cassandra, который позволил сократить задержку чтения из слишком больших партиций с временными рядами с нескольких секунд до нескольких десятков миллисекунд. При этом также снизились количество тайм-аутов при чтении, загрузка процессоров и очереди потоков в производственных кластерах. Разработанный для платформы TimeSeries Abstraction в Netflix, этот механизм автоматически разбивает растущие партиции на более мелкие дочерние партиции, не требуя изменений в приложениях, простоя системы или масштабного перепартиционирования данных.
@tldr_data
InfoQ
Netflix Cuts Cassandra Read Latency from Seconds to Milliseconds with Dynamic Partition Splitting
Netflix engineers introduced dynamic partition splitting for Cassandra to address wide partitions in time series workloads. The metadata-driven approach detects oversized partitions, splits them smaller units, and routes reads across child partitions. Netflix…
🔥1
Apache Ossie (incubating) is the universal standard for semantic data
Apache Ossie — это новый проект Apache Incubator, ранее известный как Open Semantic Interchange. Он предлагает единый слой описания данных: датасетов, колонок, метрик, измерений и их связей. Идея в том, чтобы разные BI-инструменты, платформы данных и ИИ-агенты работали с одними и теми же бизнес-определениями, а не каждый строил своё понимание данных.
@tldr_data
Apache Ossie — это новый проект Apache Incubator, ранее известный как Open Semantic Interchange. Он предлагает единый слой описания данных: датасетов, колонок, метрик, измерений и их связей. Идея в том, чтобы разные BI-инструменты, платформы данных и ИИ-агенты работали с одними и теми же бизнес-определениями, а не каждый строил своё понимание данных.
@tldr_data
ossie.apache.org
Home - Apache Ossie (incubating)
Apache Ossie (incubating) is a collaborative, open-source effort dedicated to standardizing semantic model exchange across analytics, AI, and BI platforms.
🔥1
Вышел новый выпуск dbt Developer Diaries, посвященный ИИ.
Данные продолжают расти, как по объему, так и по сложности, и все больше процессов теперь проходит через ИИ-агентов.
Вот что команда dbt выпустила этим летом.
Крупные обновления
dbt Wizard 🧙 — агент для управляемой аналитической разработки, уже доступен в платформе dbt.
можно использовать собственный API-ключ;
доступ к данным есть только у пользователя;
история запросов хранится 90 дней;
ваши промпты не используются для обучения моделей.
dbt MCP как коннектор для Claude — теперь можно подключить удаленный MCP-сервер платформы dbt к Claude без локальной установки. Это дает управляемый доступ в реальном времени к вашим моделям, метрикам, lineage и Semantic Layer — только в пределах разрешенных вами данных.
dbt Docs v2 (предварительная версия) — полностью переработанный каталог с REST API для ИИ-агентов и MCP-серверов, а также поддержкой column-level lineage в Fusion.
Также появились
Режим планирования (Plan mode) теперь включен по умолчанию. Перед изменением файлов dbt Wizard сначала показывает план действий и проходит многоуровневую проверку.
dbt compare и dbt lint теперь встроены в систему проверок dbt Wizard.
В dbt-mcp v1.20.0 стали общедоступными (GA) новые инструменты:
Подробнее в блоге dbt
@tldr_data
Данные продолжают расти, как по объему, так и по сложности, и все больше процессов теперь проходит через ИИ-агентов.
Вот что команда dbt выпустила этим летом.
Крупные обновления
dbt Wizard 🧙 — агент для управляемой аналитической разработки, уже доступен в платформе dbt.
можно использовать собственный API-ключ;
доступ к данным есть только у пользователя;
история запросов хранится 90 дней;
ваши промпты не используются для обучения моделей.
dbt MCP как коннектор для Claude — теперь можно подключить удаленный MCP-сервер платформы dbt к Claude без локальной установки. Это дает управляемый доступ в реальном времени к вашим моделям, метрикам, lineage и Semantic Layer — только в пределах разрешенных вами данных.
dbt Docs v2 (предварительная версия) — полностью переработанный каталог с REST API для ИИ-агентов и MCP-серверов, а также поддержкой column-level lineage в Fusion.
Также появились
Режим планирования (Plan mode) теперь включен по умолчанию. Перед изменением файлов dbt Wizard сначала показывает план действий и проходит многоуровневую проверку.
dbt compare и dbt lint теперь встроены в систему проверок dbt Wizard.
В dbt-mcp v1.20.0 стали общедоступными (GA) новые инструменты:
get_dimension_values — получение значений измерений из Semantic Layer;get_related_models — поиск связанных моделей для работы ИИ-агентов сразу с несколькими dbt-проектами.Подробнее в блоге dbt
@tldr_data
Linkedin
📓 AI in dbt: dbt Wizard comes to the dbt platform, dbt connector in Claude, and the Fivetran merger closes
Author: Alex Noonan, Senior Developer Experience Advocate at dbt Labs June was a big month for the dbt ecosystem. The Fivetran and dbt Labs merger finally closed, uniting us behind a single goal: building reliable, effective data infrastructure for AI agents…
👍2
Не только разработчики любят накрутить свой опыт. Иногда и крупные компании подкручивают результаты benchmark
На прошлой неделе Elastic опубликовал сравнение, в котором Qdrant оказался примерно в 7 раз медленнее DiskBBQ — проприетарного механизма в Enterprise-версии Elasticsearch.
Qdrant не остался в стороне и ответил очень язвительно.
Ниже прямой перевод.
Войны бенчмарков выходят на новый уровень.
И, наблюдать за ними иногда интереснее, чем за релизами самих продуктов 😃
@tldr_data
На прошлой неделе Elastic опубликовал сравнение, в котором Qdrant оказался примерно в 7 раз медленнее DiskBBQ — проприетарного механизма в Enterprise-версии Elasticsearch.
Qdrant не остался в стороне и ответил очень язвительно.
Ниже прямой перевод.
Окей, Elastic.
Ты сам этого захотел.
Вы ведь сделали бенчмарк, чтобы показать, что ваша платная премиум-функция лучше open-source решения, верно?
Вы опубликовали сравнение с Qdrant, так? Что ж… тогда поехали.
На прошлой неделе Elastic выпустил бенчмарк, в котором показал, что Qdrant работает в 7 раз медленнее, чем DiskBBQ.
Впечатляющий результат.
Но он становится еще более впечатляющим, если учесть, что этого удалось добиться, отключив наш асинхронный дисковый скорер, проигнорировав двухэтапную схему поиска, которую мы специально рекомендуем для таких сценариев, а затем измерив скорость неограниченного последовательного чтения с диска.
(Спойлер: она невысокая. Именно поэтому мы и реализовали все остальные механизмы.)
Поэтому мы запустили тот же датасет, с той же целевой полнотой поиска (recall) и той же загруженной моделью — но уже с Qdrant, действительно настроенным для работы с диском.
Результат: в два раза выше пропускная способность, в два раза ниже задержка, при этом используются узлы с в три раза меньшим количеством CPU и RAM. Даже на нашей самой маленькой конфигурации — 2 vCPU и 8 ГБ памяти — мы превзошли опубликованные Elastic результаты, полученные на кластере с 7 vCPU и 26 ГБ памяти.
И еще: DiskBBQ — это функция, доступная только в Enterprise-версии Elastic. Для ее нормальной работы требуется более 20 ГБ оперативной памяти на каждый pod, чтобы JVM чувствовала себя комфортно. Наша более экономичная по памяти альтернатива распространяется по лицензии Apache 2.0.
Полное описание методологии и набор для воспроизведения результатов — в публикации.
Тестируйте нас как угодно — только сначала прочитайте документацию.
Войны бенчмарков выходят на новый уровень.
И, наблюдать за ними иногда интереснее, чем за релизами самих продуктов 😃
@tldr_data
www.elastic.co
Elasticsearch vs. Qdrant: 7x faster vector search
Elasticsearch DiskBBQ delivers 7x faster vector search than Qdrant at comparable recall on network-attached storage. Explore full results and methodology.
🔥3
CocoIndex Code помогает агентам для написания кода находить нужные участки проекта ещё до того, как они начнут открывать файлы.
Он строит локальный семантический индекс с учётом AST (абстрактного синтаксического дерева), благодаря чему Claude Code, Codex, Cursor и OpenCode могут сразу находить нужные функции и классы, не сканируя исходные файлы целиком.
Для анализа кода используется Tree-sitter, который сохраняет границы отдельных сущностей (функций, классов и т.д.), а локальное обновление индекса поддерживает контекст в актуальном состоянии.
https://github.com/cocoindex-io/cocoindex-code
@tldr_data
Он строит локальный семантический индекс с учётом AST (абстрактного синтаксического дерева), благодаря чему Claude Code, Codex, Cursor и OpenCode могут сразу находить нужные функции и классы, не сканируя исходные файлы целиком.
Для анализа кода используется Tree-sitter, который сохраняет границы отдельных сущностей (функций, классов и т.д.), а локальное обновление индекса поддерживает контекст в актуальном состоянии.
https://github.com/cocoindex-io/cocoindex-code
@tldr_data
🔥2
Prefect приобретает Dagster Labs
Очень неожиданная новость. Если бы еще вчера меня спросили, кто кого купит — Prefect или Dagster, я бы точно не поставил на такой исход.
Prefect объявил о приобретении Dagster Labs.
За последние восемь лет Prefect и Dagster подталкивали друг друга к развитию, двигая вперед всю категорию инструментов оркестрации. То, что начиналось как два разных подхода, со временем стало всё более взаимодополняющим, особенно сейчас, когда ИИ меняет подход к выполнению задач и управлению рабочими процессами.
Для пользователей ничего не меняется: Dagster и Dagster+ продолжат развиваться, а команда обещает сохранить долгосрочные инвестиции в продукт и сообщество.
Интересно будет посмотреть, как объединение двух главных игроков на рынке оркестрации повлияет на развитие экосистемы. Особенно сейчас, когда границы между data orchestration, workflow orchestration и AI-агентами становятся всё менее заметными.
@tldr_data
Очень неожиданная новость. Если бы еще вчера меня спросили, кто кого купит — Prefect или Dagster, я бы точно не поставил на такой исход.
Prefect объявил о приобретении Dagster Labs.
За последние восемь лет Prefect и Dagster подталкивали друг друга к развитию, двигая вперед всю категорию инструментов оркестрации. То, что начиналось как два разных подхода, со временем стало всё более взаимодополняющим, особенно сейчас, когда ИИ меняет подход к выполнению задач и управлению рабочими процессами.
Для пользователей ничего не меняется: Dagster и Dagster+ продолжат развиваться, а команда обещает сохранить долгосрочные инвестиции в продукт и сообщество.
Интересно будет посмотреть, как объединение двух главных игроков на рынке оркестрации повлияет на развитие экосистемы. Особенно сейчас, когда границы между data orchestration, workflow orchestration и AI-агентами становятся всё менее заметными.
@tldr_data
Businesswire
Prefect Acquires Dagster, Uniting the Two Leading Modern Orchestrators
Prefect, the maker of critical AI and data automation software, today announced that it has agreed to acquire Dagster Labs, creators of the widely popular Da...
🤯2❤1
AI on Your Own Terms: Anaconda Acquires Kilo Code
Еще одна интересная сделка на рынке AI.
Anaconda — та самая компания, которую большинство знает по Python-окружению, Jupyter и инструментам для Data Science, — купила Kilo Code.
Если раньше Anaconda в первую очередь ассоциировалась с экосистемой для дата-сайентистов, то теперь явно делает ставку на AI-разработку. Kilo Code — один из самых быстрорастущих AI-кодинговых инструментов: за год вырос до 3+ млн пользователей и обрабатывает триллионы токенов каждую неделю.
Кажется, рынок постепенно приходит к тому, что недостаточно просто иметь LLM. Нужна полноценная экосистема вокруг разработки: IDE, агенты, управление окружениями, безопасность, инфраструктура.
Интересно наблюдать, как привычные инструменты для Data Engineering и Data Science постепенно превращаются в игроков рынка AI Engineering.
@tldr_data
Еще одна интересная сделка на рынке AI.
Anaconda — та самая компания, которую большинство знает по Python-окружению, Jupyter и инструментам для Data Science, — купила Kilo Code.
Если раньше Anaconda в первую очередь ассоциировалась с экосистемой для дата-сайентистов, то теперь явно делает ставку на AI-разработку. Kilo Code — один из самых быстрорастущих AI-кодинговых инструментов: за год вырос до 3+ млн пользователей и обрабатывает триллионы токенов каждую неделю.
Кажется, рынок постепенно приходит к тому, что недостаточно просто иметь LLM. Нужна полноценная экосистема вокруг разработки: IDE, агенты, управление окружениями, безопасность, инфраструктура.
Интересно наблюдать, как привычные инструменты для Data Engineering и Data Science постепенно превращаются в игроков рынка AI Engineering.
@tldr_data
❤1
Arroyo is joining Cloudflare
Cloudflare приобрела Arroyo — SQL-движок для потоковой обработки данных, написанный на Rust, — чтобы усилить свою платформу для разработчиков.
Arroyo поддерживает stateful JOIN’ы и агрегации, остается проектом с открытым исходным кодом под лицензией Apache 2.0. Первым шагом после сделки станет добавление SQL-обработки потоков в Cloudflare Pipelines.
Поглощения в мире data и AI пошли как грибы после дождя. За последние дни крупные компании одна за другой скупают сильных нишевых игроков:
• Anaconda → Kilo Code
• Prefect → Dagster
• Cloudflare → Arroyo
Похоже, начинается новый этап консолидации рынка. Вместо того чтобы годами разрабатывать собственные решения, крупным игрокам зачастую проще купить готовую команду, технологию и уже сформировавшееся сообщество.
@tldr_data
Cloudflare приобрела Arroyo — SQL-движок для потоковой обработки данных, написанный на Rust, — чтобы усилить свою платформу для разработчиков.
Arroyo поддерживает stateful JOIN’ы и агрегации, остается проектом с открытым исходным кодом под лицензией Apache 2.0. Первым шагом после сделки станет добавление SQL-обработки потоков в Cloudflare Pipelines.
Поглощения в мире data и AI пошли как грибы после дождя. За последние дни крупные компании одна за другой скупают сильных нишевых игроков:
• Anaconda → Kilo Code
• Prefect → Dagster
• Cloudflare → Arroyo
Похоже, начинается новый этап консолидации рынка. Вместо того чтобы годами разрабатывать собственные решения, крупным игрокам зачастую проще купить готовую команду, технологию и уже сформировавшееся сообщество.
@tldr_data
www.arroyo.dev
Arroyo is joining Cloudflare
Arroyo has been acquired by Cloudflare to bring serverless SQL stream processing to the Cloudflare Developer Platfrorm, integrated with Queues, Workers, and R2. The Arroyo Engine will remain open-source and self-hostable.
❤1
ingestr представил встроенную поддержку CDC.
Одна из главных идей проекта — сделать CDC максимально простым.
Без Kafka, Kafka Connect и дополнительной инфраструктуры, которая обычно сопровождает такие решения.
На старте поддерживаются PostgreSQL, MySQL, SQL Server и MongoDB.
Работать можно в двух режимах:
- Batch — чтение журнала изменений микро-батчами, удобно для ETL-пайплайнов.
- Streaming — непрерывная обработка изменений в режиме реального времени.
Что интересно:
не требуется отдельная инфраструктура — достаточно указать строку подключения;
всё работает в одном Go-бинарнике;
один и тот же инструмент поддерживает и batch, и streaming, поэтому можно начать с простого сценария и при необходимости перейти к постоянной синхронизации данных.
В последние годы CDC почти всегда ассоциировался с Debezium, Kafka и довольно сложным стеком. Любопытно видеть, как появляются инструменты, которые пытаются убрать большую часть этой сложности и сделать Change Data Capture доступнее. Если проект окажется стабильным в продакшене, это может стать хорошей альтернативой для многих задач.
@tldr_data
Одна из главных идей проекта — сделать CDC максимально простым.
Без Kafka, Kafka Connect и дополнительной инфраструктуры, которая обычно сопровождает такие решения.
На старте поддерживаются PostgreSQL, MySQL, SQL Server и MongoDB.
Работать можно в двух режимах:
- Batch — чтение журнала изменений микро-батчами, удобно для ETL-пайплайнов.
- Streaming — непрерывная обработка изменений в режиме реального времени.
Что интересно:
не требуется отдельная инфраструктура — достаточно указать строку подключения;
всё работает в одном Go-бинарнике;
один и тот же инструмент поддерживает и batch, и streaming, поэтому можно начать с простого сценария и при необходимости перейти к постоянной синхронизации данных.
В последние годы CDC почти всегда ассоциировался с Debezium, Kafka и довольно сложным стеком. Любопытно видеть, как появляются инструменты, которые пытаются убрать большую часть этой сложности и сделать Change Data Capture доступнее. Если проект окажется стабильным в продакшене, это может стать хорошей альтернативой для многих задач.
@tldr_data
bruin-data.github.io
Change Data Capture (CDC) | ingestr
Ingest & copy data between any source and any destination
❤2👍2