Amazon S3 annotations: attach rich, queryable context directly to your objects
Amazon S3 представил Annotations — новую функцию метаданных, которая позволяет пользователям прикреплять к каждому объекту до 1 ГБ бизнес-контекста, распределённого по 1 000 именованным аннотациям. Эти аннотации можно изменять без перезаписи самого объекта, а также они автоматически индексируются в таблицы Apache Iceberg, доступные для запросов.
Функция уже доступна во всех регионах AWS и предназначена для поддержки AI-агентов и автономных рабочих процессов. Она позволяет хранить расширенные метаданные — например, транскрипты, возрастные рейтинги контента, технические характеристики и другую контекстную информацию — непосредственно рядом с объектами в S3.
Все аннотации можно искать и анализировать через Amazon Athena, что избавляет от необходимости поддерживать отдельные базы данных для хранения метаданных.
@tldr_data
Amazon S3 представил Annotations — новую функцию метаданных, которая позволяет пользователям прикреплять к каждому объекту до 1 ГБ бизнес-контекста, распределённого по 1 000 именованным аннотациям. Эти аннотации можно изменять без перезаписи самого объекта, а также они автоматически индексируются в таблицы Apache Iceberg, доступные для запросов.
Функция уже доступна во всех регионах AWS и предназначена для поддержки AI-агентов и автономных рабочих процессов. Она позволяет хранить расширенные метаданные — например, транскрипты, возрастные рейтинги контента, технические характеристики и другую контекстную информацию — непосредственно рядом с объектами в S3.
Все аннотации можно искать и анализировать через Amazon Athena, что избавляет от необходимости поддерживать отдельные базы данных для хранения метаданных.
@tldr_data
Amazon
Amazon S3 annotations: attach rich, queryable context directly to your objects | Amazon Web Services
Amazon S3 now lets you attach up to 1 GB of rich, mutable, and queryable context directly to your objects using annotations, purpose-built for AI agents and autonomous workflows that need to discover, understand, and act on data at scale without maintaining…
🔥1
[1/2] Как Meta разрушила свою инженерную культуру за два месяца
Meta (признана экстремистской и запрещена на территории РФ) — двадцать лет у компании была одна из лучших инженерных культур в Big Tech.
Сначала «move fast and break things», затем «move fast with stable infra». Инженеры сами выбирали проекты через bootcamp, ценился impact, а не строчки кода.
Всё это закончилось в апреле 2026, когда Марк Цукерберг решил, что главный приоритет — догнать OpenAI и Anthropic в гонке моделей. Meta купила 49% Scale AI за $14.8B и поставила Александра Ванга (CEO Scale AI) руководить AI-стратегией.
Это не первый дорогостоящий pivot Цукерберга: Reality Labs до этого сожгла $83B на метавселенной, которая так и не стала мейнстримом. Теперь ставка — на AI, и цена снова платится инженерами. Applied AI — новое подразделение из ~6 500 инженеров и продакт-менеджеров — возглавил Maher Saba, 12-летний ветеран Meta, ранее вице-президент в Reality Labs. До 50 сотрудников на одного менеджера. Дальше начался разгром.
1️⃣ Тотальная слежка за инженерами
В конце апреля всем инженерам объявили: каждый клик и каждое нажатие клавиш будет логироваться для тренировки моделей. Opt-out невозможен. Более 1 600 сотрудников подписали петицию против этой программы. В Великобритании трекинг заблокировали из-за GDPR, в США — запустили. Позже Meta пошла на уступки: разрешила ставить сбор на паузу до 30 минут и запрашивать exemption, но осадок остался.
2️⃣ Принудительный перевод на разметку данных
30–50% инженеров из продуктовых и инфраструктурных команд перевели в ADO (Agent Data Optimisation) — разметка данных и RLHF. Людей забирали через surprise email; процесс называли «quite random». Выбор был простой: join or quit. Сами инженеры называют себя draftees — призывниками. Около 5000 инженеров теперь полный день оценивают сгенерированный код. Цукерберг объяснил, почему не наняли подрядчиков: «the average Meta employee has significantly higher intelligence than third-party contractors». Сами инженеры называют происходящее «гулагом»: «You have zero purpose in life all of a sudden, you barely interact with anyone, you just have these tasks every week.» Другой сотрудник: «Most people find the work soul-crushing.»
3️⃣ Увольнения как дамоклов меч
20 апреля Reuters сообщил: 10% сотрудников уволят через месяц. Четыре недели все знали, что могут потерять работу. Часть увольнений позже отменили (в UK), но атмосфера уже была отравлена.
4️⃣ Токены стали KPI
Менеджерам сказали: при performance review учитывайте использование AI-токенов. Результат — инженеры начали tokenmaxxing: генерировать токены ради токенов. За 30 дней Meta сожгла 60.2 триллиона токенов — эквивалент $900M по API-ценам Anthropic.
5️⃣ Instagram взломали через дыру в AI-коде
30 мая — самый позорный инцидент в истории Meta. Злоумышленник мог угнать любой Instagram-аккаунт (включая Obama White House), просто сказав AI-саппорту «аккаунт взломан» и указав свой email для кодов восстановления. Zero-auth password reset в продакшене. Причина: AI-сгенерированный код, AI-ревью без участия человека и команда Trust & Safety, урезанная на 50%. CISO уволился на следующий день.
6️⃣ Руководство признало провал
На livestream-презентации для сотрудников кто-то прервал выступление с криком: «tell him that he's a piece of shit» — про senior AI-руководителя. Один из ведущих закрыл лицо руками. Chief Product Officer Крис Кокс на общей встрече: «It's like what the fuck. It is like what the fuck» — про «insanity of this company» последних месяцев. CTO Эндрю Босворт признал, что AI-реорг был «atrocious». 12 июня Цукерберг разослал внутренний мемо, где признал, что изменения «caused distress» и компания «made mistakes». North star, по его словам, — «to be the best place for the most talented people in the world to make an impact». Звучит как издёвка над ситуацией, в которой эти самые talented people массово ищут выход.
@tldr_data
Meta (признана экстремистской и запрещена на территории РФ) — двадцать лет у компании была одна из лучших инженерных культур в Big Tech.
Сначала «move fast and break things», затем «move fast with stable infra». Инженеры сами выбирали проекты через bootcamp, ценился impact, а не строчки кода.
Всё это закончилось в апреле 2026, когда Марк Цукерберг решил, что главный приоритет — догнать OpenAI и Anthropic в гонке моделей. Meta купила 49% Scale AI за $14.8B и поставила Александра Ванга (CEO Scale AI) руководить AI-стратегией.
Это не первый дорогостоящий pivot Цукерберга: Reality Labs до этого сожгла $83B на метавселенной, которая так и не стала мейнстримом. Теперь ставка — на AI, и цена снова платится инженерами. Applied AI — новое подразделение из ~6 500 инженеров и продакт-менеджеров — возглавил Maher Saba, 12-летний ветеран Meta, ранее вице-президент в Reality Labs. До 50 сотрудников на одного менеджера. Дальше начался разгром.
1️⃣ Тотальная слежка за инженерами
В конце апреля всем инженерам объявили: каждый клик и каждое нажатие клавиш будет логироваться для тренировки моделей. Opt-out невозможен. Более 1 600 сотрудников подписали петицию против этой программы. В Великобритании трекинг заблокировали из-за GDPR, в США — запустили. Позже Meta пошла на уступки: разрешила ставить сбор на паузу до 30 минут и запрашивать exemption, но осадок остался.
2️⃣ Принудительный перевод на разметку данных
30–50% инженеров из продуктовых и инфраструктурных команд перевели в ADO (Agent Data Optimisation) — разметка данных и RLHF. Людей забирали через surprise email; процесс называли «quite random». Выбор был простой: join or quit. Сами инженеры называют себя draftees — призывниками. Около 5000 инженеров теперь полный день оценивают сгенерированный код. Цукерберг объяснил, почему не наняли подрядчиков: «the average Meta employee has significantly higher intelligence than third-party contractors». Сами инженеры называют происходящее «гулагом»: «You have zero purpose in life all of a sudden, you barely interact with anyone, you just have these tasks every week.» Другой сотрудник: «Most people find the work soul-crushing.»
3️⃣ Увольнения как дамоклов меч
20 апреля Reuters сообщил: 10% сотрудников уволят через месяц. Четыре недели все знали, что могут потерять работу. Часть увольнений позже отменили (в UK), но атмосфера уже была отравлена.
4️⃣ Токены стали KPI
Менеджерам сказали: при performance review учитывайте использование AI-токенов. Результат — инженеры начали tokenmaxxing: генерировать токены ради токенов. За 30 дней Meta сожгла 60.2 триллиона токенов — эквивалент $900M по API-ценам Anthropic.
5️⃣ Instagram взломали через дыру в AI-коде
30 мая — самый позорный инцидент в истории Meta. Злоумышленник мог угнать любой Instagram-аккаунт (включая Obama White House), просто сказав AI-саппорту «аккаунт взломан» и указав свой email для кодов восстановления. Zero-auth password reset в продакшене. Причина: AI-сгенерированный код, AI-ревью без участия человека и команда Trust & Safety, урезанная на 50%. CISO уволился на следующий день.
6️⃣ Руководство признало провал
На livestream-презентации для сотрудников кто-то прервал выступление с криком: «tell him that he's a piece of shit» — про senior AI-руководителя. Один из ведущих закрыл лицо руками. Chief Product Officer Крис Кокс на общей встрече: «It's like what the fuck. It is like what the fuck» — про «insanity of this company» последних месяцев. CTO Эндрю Босворт признал, что AI-реорг был «atrocious». 12 июня Цукерберг разослал внутренний мемо, где признал, что изменения «caused distress» и компания «made mistakes». North star, по его словам, — «to be the best place for the most talented people in the world to make an impact». Звучит как издёвка над ситуацией, в которой эти самые talented people массово ищут выход.
@tldr_data
🔥1
[2/2] Как Meta разрушила свою инженерную культуру за два месяца
Это не просто drama Meta (признана экстремистской и запрещена на территории РФ).
Митчелл Хашимото (основатель HashiCorp, создатель Ghostty) говорит, что наблюдает похожее поведение у многих основателей: «Системы могут выглядеть здоровыми по локальным метрикам, но становиться глобально непостижимыми.
Баг-репорты падают, а скрытые риски взрываются. Тестовое покрытие растёт, а семантическое понимание падает.
Мы уже проходили этот урок в инфраструктуре: можно автоматизировать себя до очень устойчивой катастрофы.»
Meta — канарейка в шахте. Если компания с выручкой больше $100B и 25 000 инженеров может развалить инженерную культуру за восемь недель ради AI-гонки — это может случиться где угодно.
Выводы:
- AI-ревью без человеческого участия приводит к катастрофе. Instagram-взлом доказал это публично.
- Метрики токенов как KPI создают извращённые стимулы: инженеры оптимизируют токены, а не качество.
- Принудительная реаллокация убивает автономию, а без автономии senior-инженеры уходят.
- Meta сейчас — лучший источник найма: тысячи сильных инженеров с глубоким опытом работы с AI ищут выход.
Источники:
Why is Meta destroying its engineering organization? — The Pragmatic Engineer, Gergely Orosz;
Meta's months-old AI unit is a soul-crushing gulag, say the engineers stuck inside it — TechCrunch
@tldr_data
Это не просто drama Meta (признана экстремистской и запрещена на территории РФ).
Митчелл Хашимото (основатель HashiCorp, создатель Ghostty) говорит, что наблюдает похожее поведение у многих основателей: «Системы могут выглядеть здоровыми по локальным метрикам, но становиться глобально непостижимыми.
Баг-репорты падают, а скрытые риски взрываются. Тестовое покрытие растёт, а семантическое понимание падает.
Мы уже проходили этот урок в инфраструктуре: можно автоматизировать себя до очень устойчивой катастрофы.»
Meta — канарейка в шахте. Если компания с выручкой больше $100B и 25 000 инженеров может развалить инженерную культуру за восемь недель ради AI-гонки — это может случиться где угодно.
Выводы:
- AI-ревью без человеческого участия приводит к катастрофе. Instagram-взлом доказал это публично.
- Метрики токенов как KPI создают извращённые стимулы: инженеры оптимизируют токены, а не качество.
- Принудительная реаллокация убивает автономию, а без автономии senior-инженеры уходят.
- Meta сейчас — лучший источник найма: тысячи сильных инженеров с глубоким опытом работы с AI ищут выход.
Источники:
Why is Meta destroying its engineering organization? — The Pragmatic Engineer, Gergely Orosz;
Meta's months-old AI unit is a soul-crushing gulag, say the engineers stuck inside it — TechCrunch
@tldr_data
Pragmaticengineer
Why is Meta destroying its engineering organization?
Leadership at the social media giant has been on an AI-fueled rampage through its engineering org. We report what’s happened
💯2
Команда Apache NiFi объявила о выпуске Apache NiFi 2.10.0.
Версия 2.10.0 добавляет поддержку пользовательского интерфейса для Connectors, делая новую платформу расширений доступной для практического использования.
В эту версию также входит реализация коннектора, поддерживающего передачу данных из Kafka в S3.
В этом релизе устранено более 160 проблем, выполнено множество обновлений зависимостей, а также внесены различные исправления ошибок и функциональные улучшения. Среди доработок существующих возможностей:
повышение производительности реализации репозитория контента (Content Repository) фреймворка;
более гибкая поддержка парсинга JSON.
Таким образом, релиз сосредоточен не только на новых возможностях, но и на повышении стабильности, производительности и удобства работы с системой.
@tldr_data
Версия 2.10.0 добавляет поддержку пользовательского интерфейса для Connectors, делая новую платформу расширений доступной для практического использования.
В эту версию также входит реализация коннектора, поддерживающего передачу данных из Kafka в S3.
В этом релизе устранено более 160 проблем, выполнено множество обновлений зависимостей, а также внесены различные исправления ошибок и функциональные улучшения. Среди доработок существующих возможностей:
повышение производительности реализации репозитория контента (Content Repository) фреймворка;
более гибкая поддержка парсинга JSON.
Таким образом, релиз сосредоточен не только на новых возможностях, но и на повышении стабильности, производительности и удобства работы с системой.
@tldr_data
Apache NiFi
Download
Apache NiFi is an easy to use, powerful, and reliable system to process and distribute data
👍1
Ingestr опубликовал полный набор бенчмарков и код для их воспроизведения.
Команда утверждает, что ingestr сейчас является самым быстрым open-source инструментом для data ingestion.
В тестах сравнивали загрузку данных между DuckDB, PostgreSQL, MySQL, MongoDB и Snowflake, стараясь использовать оптимальные настройки для каждого решения.
Из интересного:
• Ingestr оказался лидером почти во всех тестах, проиграв лишь в двух сценариях с минимальным отставанием.
• Spark заметно уступает на небольших объёмах данных из-за высокого оверхеда, но показывает достойные результаты на крупных нагрузках.
• Airbyte (через PyAirbyte) оказался самым медленным участником сравнения — тест на 10 млн строк даже не удалось дождаться до завершения.
Авторы напоминают простую мысль: производительность — это тоже функциональность. А поскольку data ingestion часто становится узким местом в data-платформах, такие сравнения заслуживают внимания.
@tldr_data
Команда утверждает, что ingestr сейчас является самым быстрым open-source инструментом для data ingestion.
В тестах сравнивали загрузку данных между DuckDB, PostgreSQL, MySQL, MongoDB и Snowflake, стараясь использовать оптимальные настройки для каждого решения.
Из интересного:
• Ingestr оказался лидером почти во всех тестах, проиграв лишь в двух сценариях с минимальным отставанием.
• Spark заметно уступает на небольших объёмах данных из-за высокого оверхеда, но показывает достойные результаты на крупных нагрузках.
• Airbyte (через PyAirbyte) оказался самым медленным участником сравнения — тест на 10 млн строк даже не удалось дождаться до завершения.
Авторы напоминают простую мысль: производительность — это тоже функциональность. А поскольку data ingestion часто становится узким местом в data-платформах, такие сравнения заслуживают внимания.
@tldr_data
Bruin
ingestr Benchmarks
ingestr vs. Sling, dlt, Airbyte & Spark — reproducible data movement benchmarks.
🔥1
Databricks объявил конец эпохи пайплайнов.
На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами.
Последние двадцать лет типичная архитектура выглядела примерно так:
PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI
Каждый новый слой добавлял задержки, повышал стоимость владения и создавал новые точки отказа. Особенно болезненно это стало с появлением AI-агентов, которым нужны актуальные данные в реальном времени, а не копия пятиминутной давности.
Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных.
Конечно, заявления о «смерти пайплайнов» стоит воспринимать осторожно. Интеграции между компаниями, обмен данными с внешними системами, специализированные стриминговые сценарии и гибридные архитектуры никуда не денутся.
Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе:
Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных?
Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering.
@tldr_data
На Data + AI Summit 2026 компания представила новую архитектуру LTAP (Lake Transactional/Analytical Processing), которая должна объединить транзакционные системы, аналитику, стриминг и AI на одной копии данных. Идея радикальная: приложения, BI-системы и AI-агенты работают с одним источником данных напрямую, без CDC, ETL и бесконечных репликаций между OLTP и аналитическими хранилищами.
Последние двадцать лет типичная архитектура выглядела примерно так:
PostgreSQL → CDC → Kafka → ETL → Data Warehouse → BI → AI
Каждый новый слой добавлял задержки, повышал стоимость владения и создавал новые точки отказа. Особенно болезненно это стало с появлением AI-агентов, которым нужны актуальные данные в реальном времени, а не копия пятиминутной давности.
Ответ Databricks — хранить операционные и аналитические данные в одном месте. В основе подхода лежит Lakebase, PostgreSQL-совместимая система, работающая поверх объектного хранилища и интегрированная с Lakehouse. Компания называет это первым LTAP-подходом, который должен заменить как традиционные ETL-процессы, так и многочисленные реплики баз данных.
Конечно, заявления о «смерти пайплайнов» стоит воспринимать осторожно. Интеграции между компаниями, обмен данными с внешними системами, специализированные стриминговые сценарии и гибридные архитектуры никуда не денутся.
Но сам тренд выглядит очень интересным. Если раньше индустрия спорила, что лучше — Data Lake или Data Warehouse, то теперь главный вопрос звучит иначе:
Нужно ли вообще перемещать данные между системами, если все сервисы, аналитика и AI могут работать поверх одной копии данных?
Похоже, именно вокруг этого вопроса и будет строиться следующая большая битва в мире Data Engineering.
@tldr_data
🔥1
The Best Developer Story I’ve Read This Year
Я уверен, что про эту эпичную историю в русскоязычном IT-сообществе практически никто не слышал, но она определённо заслуживает внимания.
Preston Thorpe работает software engineer в Turso и участвует в разработке Limbo — проекта по созданию SQLite-совместимой базы данных на Rust.
Есть одна деталь, он делает это из тюрьмы.
В молодости Престон ушёл из дома, связался с наркотиками и в итоге получил длительный срок заключения.
Казалось бы, на этом история должна была закончиться.
Но в тюрьме штата Мэн он получил доступ к образовательной программе, компьютеру и ограниченному интернету. У него появилась возможность изучать Linux, базы данных, системы хранения данных и программирование.
Со временем программирование стало его главным занятием.
Затем он наткнулся на проект Limbo и начал отправлять pull request’ы.
Сначала его оценивали только по коду, никто не видел заключённого, никто не видел уголовного прошлого.
Люди видели инженера, который пишет хороший код, участвует в технических обсуждениях и помогает развивать проект.
Через несколько месяцев он стал одним из самых активных контрибьюторов.
А потом получил предложение о работе от CEO Turso.
Мне очень понравился его взгляд на обучение.
Особенно это выглядит полезным для самоучек, таких как я.
Вот что он пишет в своем блоге:
По его мнению, компании нанимают не разработчиков Rust, Go или Python.
Они нанимают инженеров, которые понимают, как устроены компьютеры и программные системы. Языки и инструменты меняются, фундаментальные знания остаются.
Он советует писать собственные проекты:
— реализовать структуры данных;
— написать shell;
— сделать HTTP-сервер на сокетах;
— разобраться с компиляторами и интерпретаторами;
— глубоко изучить Linux и CLI-инструменты.
Для меня конечно самое интересное в этой истории даже не сам факт найма.
А то, что open source в данном случае сработал именно так, как многие мечтают: человека реально оценили по знаниям, а не по его диплому и не по умению проходить алгоритмическую секцию.
Его оценивали по результату и только потом узнали его биографию.
А вот ссылки на его историю:
How I got here
Learn systems, not languages
Подкаст на YouTube из тюрьмы
@tldr_data
Я уверен, что про эту эпичную историю в русскоязычном IT-сообществе практически никто не слышал, но она определённо заслуживает внимания.
Preston Thorpe работает software engineer в Turso и участвует в разработке Limbo — проекта по созданию SQLite-совместимой базы данных на Rust.
Turso — это distributed database platform, которая даёт совместимый с SQLite движок (LibSQL) для использования как edge-ориентированной базы данных: с репликацией, низкой задержкой и возможностью работать ближе к пользователю, как альтернатива классическим централизованным PostgreSQL/MySQL-схемам в некоторых сценариях.
Есть одна деталь, он делает это из тюрьмы.
В молодости Престон ушёл из дома, связался с наркотиками и в итоге получил длительный срок заключения.
Казалось бы, на этом история должна была закончиться.
Но в тюрьме штата Мэн он получил доступ к образовательной программе, компьютеру и ограниченному интернету. У него появилась возможность изучать Linux, базы данных, системы хранения данных и программирование.
Со временем программирование стало его главным занятием.
Затем он наткнулся на проект Limbo и начал отправлять pull request’ы.
Сначала его оценивали только по коду, никто не видел заключённого, никто не видел уголовного прошлого.
Люди видели инженера, который пишет хороший код, участвует в технических обсуждениях и помогает развивать проект.
Через несколько месяцев он стал одним из самых активных контрибьюторов.
А потом получил предложение о работе от CEO Turso.
Мне очень понравился его взгляд на обучение.
Особенно это выглядит полезным для самоучек, таких как я.
Вот что он пишет в своем блоге:
Сегодня многие пытаются изучать очередной язык программирования или новый фреймворк.
Я же считаю, что это ошибка.
Мой главный совет:
Изучайте системы, а не языки.
Не React, а то, как работает браузер и HTTP.
Не ORM, а SQL и базы данных.
Не Kubernetes по гайдам, а Linux, процессы, файловые системы, сеть и системные вызовы.
По его мнению, компании нанимают не разработчиков Rust, Go или Python.
Они нанимают инженеров, которые понимают, как устроены компьютеры и программные системы. Языки и инструменты меняются, фундаментальные знания остаются.
Он советует писать собственные проекты:
— реализовать структуры данных;
— написать shell;
— сделать HTTP-сервер на сокетах;
— разобраться с компиляторами и интерпретаторами;
— глубоко изучить Linux и CLI-инструменты.
Для меня конечно самое интересное в этой истории даже не сам факт найма.
А то, что open source в данном случае сработал именно так, как многие мечтают: человека реально оценили по знаниям, а не по его диплому и не по умению проходить алгоритмическую секцию.
Его оценивали по результату и только потом узнали его биографию.
А вот ссылки на его историю:
How I got here
Learn systems, not languages
Подкаст на YouTube из тюрьмы
@tldr_data
Turso
Turso - Millions of Databases. One Architecture.
Turso is the SQLite-based database architecture for millions of databases. Spin up a database for every user, agent, and tenant, with embedded replication, per-database encryption, and economics that scale with you.
🔥3👍2🫡1
databow — единый CLI-инструмент для работы с разными базами данных, построенный на Rust и ADBC.
Устали постоянно переключаться между разными клиентами для баз данных — psql, mysql, snowsql, bq, sqlite3 и другими?
А существующие мульти-СУБД клиенты кажутся слишком медленными и громоздкими?
databow позволяет выполнять запросы к любому SQL-источнику, для которого существует драйвер ADBC. На данный момент поддерживается уже более 30 различных систем, и их число продолжает расти.
Все это — прямо из терминала и с помощью одного простого инструмента.
@tldr_data
Устали постоянно переключаться между разными клиентами для баз данных — psql, mysql, snowsql, bq, sqlite3 и другими?
А существующие мульти-СУБД клиенты кажутся слишком медленными и громоздкими?
databow позволяет выполнять запросы к любому SQL-источнику, для которого существует драйвер ADBC. На данный момент поддерживается уже более 30 различных систем, и их число продолжает расти.
Все это — прямо из терминала и с помощью одного простого инструмента.
@tldr_data
Columnar
Introducing databow
One command-line tool to query them all, built with Rust and ADBC
👍3⚡2
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