Floci

Раньше любому локальному эмулятору AWS требовались гигабайты оперативной памяти.
Холодный старт занимал 30 секунд, чтобы протестировать всего одну функцию.
Теперь команда разработчиков открыла исходный код Floci.
Это единый бинарный файл на Go, который полностью запускает облако в памяти.
Его размер — всего 13 МиБ. Для сравнения, средняя вкладка Chrome потребляет примерно в 200 раз больше памяти.
Floci запускает 45 сервисов менее чем за секунду.
Достаточно указать стандартному AWS SDK адрес localhost, и существующие скрипты будут работать без каких-либо изменений.
Что можно запускать локально без зависимостей:
S3, Lambda, DynamoDB, SQS
IAM, KMS, Cognito, STS
Step Functions, EventBridge, CloudFormation
API Gateway, Kinesis, Secrets Manager
Никаких демонов, Python Runtime или Java VM.
Готовые бинарные файлы доступны для Linux, macOS и Windows.
Тесты завершаются быстрее, чем LocalStack Pro успевает скачать свой Docker-образ.
Репозиторий полностью открыт (100% open source) и не имеет платной версии.

@tldr_data

Spark Release 4.2.0

Spark продолжает развиваться: из распределённого вычислительного движка он превращается в платформу, которая изначально понимает современные задачи обработки данных и AI.

Вот четыре нововведения, которые особенно выделяются.

Нативные геопространственные типы
В Spark появились встроенные типы данных GEOMETRY и GEOGRAPHY для работы с геоданными и пространственной информацией.
Теперь геопространственные данные стали частью основной системы типов Spark и соответствуют отраслевым стандартам. Это делает пространственную аналитику в Spark SQL гораздо более естественной.


Стандартизированный CDC API
Одно из самых интересных нововведений. Spark получил единый API CHANGES для работы с изменениями на уровне строк через коннекторы Data Source V2.
Сейчас каждый табличный формат (Apache Iceberg, Hudi, Delta) предоставляет доступ к изменениям по-своему.
Перенос семантики CDC непосредственно в Spark — важный шаг к созданию переносимых инкрементальных пайплайнов независимо от формата таблиц.

Python UDF на Apache Arrow включены по умолчанию
Теперь Spark по умолчанию использует Apache Arrow для выполнения Python UDF и связанных операций PySpark.
Это уменьшает накладные расходы на сериализацию между JVM и Python, ускоряет обмен колонночными данными и должно дать заметный прирост производительности существующим PySpark-приложениям без каких-либо изменений в коде.

NEAREST BY JOIN
В Spark появился новый SQL-оператор для выполнения top-K similarity join (соединения по ближайшему сходству).
Вместо сложных запросов с CROSS JOIN и оконными функциями теперь можно выразить поиск ближайших соседей как обычную операцию JOIN.
Это открывает новые возможности для задач семантического поиска, рекомендательных систем, RAG и других AI-сценариев.

@tldr_data

How we built LangChain’s agent-first data stack

LangChain полностью перестроил свой стек для agent-native аналитики, полностью отказавшись от предыдущего BI-инструмента всего за шесть недель.

Hex объединяет dbt definitions, semantic models, trusted datasets, playbooks, LangSmith traces и другие артефакты в единый контекст. Благодаря этому агенты могут генерировать надежный SQL, а data-команда сохраняет полный контроль над data modeling и governance.

@tldr_data

The Modern Data Stack: Open-source edition

Datafold обновили свой большой обзор open-source инструментов для дата-стека — от сбора событий до BI.
Full report на 23 минуты чтения, а вот самое интересное коротко.

AI меняет расклад сил.
Вайб-кодинг довёл разработку до 80% результата за пару дней, но инфраструктуре нужны оставшиеся 20% — надёжность, архитектуру на это не отдашь.
Open-source инструменты как раз дают агентам хорошие строительные блоки, которые можно расширять под себя, а не переписывать с нуля.
Обратная сторона: у open-core вендоров, которые зарабатывали на enterprise-фичах, почва уходит из-под ног — если 80% ценности уже открыто, а оставшиеся 20% легко вайб-кодятся, коммерческий ров мельчает.

Лицензионные истории.
Snowplow ещё в начале 2024 перешёл на проприетарную лицензию (SLULA), и новая версия вообще запрещает прод с высокой доступностью.
MinIO прошёл через медленную смерть: убрали admin-консоль из community-версии, остановили дистрибуцию бинарников, а в феврале 2026 вообще заархивировали OSS-репозиторий.
Community-форк есть (pgsty/minio), но для новых проектов советуют смотреть на SeaweedFS.

Заброшенные проекты:
Mage, Amundsen, Hydra, Meltano (компания закрылась в декабре 2025) — фактически в спячке.
SQLMesh после покупки Fivetran просел на 87% по коммитам, хотя его и передали в Linux Foundation.

Fivetran консолидирует рынок.
Купили Census (май 2025), Tobiko/SQLMesh (сентябрь 2025) и dbt Labs целиком (октябрь 2025, all-stock).
Теперь одна компания контролирует и ведущий open-source SQL-трансформатор, и EL-платформу.
dbt Core остаётся на Apache 2.0, но фокус Fivetran — на новом коммерческом движке Fusion.

Кто выстрелил:
Kestra (оркестрация) — 26.6k звёзд, $25M Series A, 2B+ workflows за 2025 год, среди клиентов Bloomberg и JPMorgan;
dlt — лёгкая Python-альтернатива Airbyte;
DuckLake от команды DuckDB — упрощённый table format, где каталог — это просто SQL-база вместо manifest-файлов;
RisingWave — streaming database с PostgreSQL-совместимым SQL.

Главные победители по слоям стека:
Apache Iceberg выиграл войну table-форматов (~78% adoption, Hudi и Delta Lake уже сами добавляют совместимость с ним).
DuckDB — если данные помещаются на одну машину (а помещается больше, чем кажется), это правильный выбор: рост с 2.4k до 37.2k звёзд и 375 коммитов в неделю — больше, чем у любого другого проекта в обзоре.
ClickHouse — топ для sub-second OLAP, подняли $400M Series D и купили Langfuse.
Airflow остаётся стандартом оркестрации, но набирает обороты Dagster (для новых проектов) и Kestra (event-driven).

Итог автора:
production-grade дата-стек на open-source — реальность, экосистема устоялась вокруг победителей (Iceberg, DuckDB, Airflow 3.0/Dagster, dbt).
Тренд — на более лёгкие инструменты: DuckDB вместо Spark, если данных меньше терабайта;
dlt вместо Airbyte, если нужно просто перекинуть данные;
Kestra вместо Airflow, если команда не хочет писать Python.

Источник: The Modern Data Stack: Open-source edition

@tldr_data

Reddit Data Tech Stack

Reddit рассказал, как устроена его data platform.

Масштаб впечатляет: более 120 млн DAU, миллиарды комментариев и кластер из 500+ Kafka brokers, обрабатывающий десятки миллионов сообщений в секунду.

Архитектура при этом достаточно прямолинейная. Kafka используется как центральная event bus. Оттуда события попадают в Flink (внутренний проект Snooron) для потоковой обработки и применения content safety rules в реальном времени, а также в Spark, который отвечает за batch-пайплайны и подготовку данных для Druid.

Изменения в операционных базах захватываются через Debezium и публикуются в Kafka.
Оркестрацией занимается Airflow, сырые данные хранятся в S3, а аналитическое хранилище — BigQuery, куда Reddit ранее мигрировал с Redshift.

Интересен и подход к облакам.
Основная инфраструктура работает в AWS, а GCP появился благодаря коммерческому партнерству с Google. Вместе с ним в стек вошли BigQuery и Vertex AI.

Для Data Engineer здесь, пожалуй, нет ничего революционного.
Скорее это возможность посмотреть на реальную архитектуру, которая работает под очень высокой нагрузкой.
Kafka → Flink/Spark → Druid/BigQuery с Debezium для CDC — стек, который масштабируется и при этом остается достаточно понятным с точки зрения разделения ответственности между компонентами.

#datainfrastructure

@tldr_data

PGSimCity

PGSimCity — интерактивный образовательный симулятор, который представляет базу данных PostgreSQL в виде трёхмерного города.
В нём можно изменять параметры нагрузки и запускать различные сценарии: checkpoint storm, вытеснение данных из кеша, блокировки autovacuum, накопление блокировок и отставание репликации.
Это позволяет наглядно увидеть, как внутренние механизмы PostgreSQL влияют на производительность.

@tldr_data

How Rapport Labs Adopted StarRocks for Ad Performance Data

Rapport Labs рассказали, как перестроили систему аналитики рекламных кампаний после того, как MySQL-based pipeline перестал масштабироваться.

Изначально события хранились в двух MySQL-таблицах:

• ad_interaction_raw содержала показы, клики и другие пользовательские события, записываемые в реальном времени;

• ad_purchase_aggregated_events содержала покупки, связанные с рекламными показами или кликами, и обновлялась раз в пять минут.

Периодический batch job считывал новые строки по ID из global_pointer, агрегировал impressions, clicks, billed amount, purchase quantity и purchase amount по рекламной кампании, а затем публиковал инкременты в Kafka.

Kafka consumer обновлял агрегированные таблицы в MySQL и пересчитывал CTR, CVR и ROAS.
Campaign ID использовался как partition key, а transactional inbox pattern обеспечивал идемпотентность обработки.

Вначале архитектура работала нормально.
Проблемы появились, когда количество рекламных показов стало приближаться к 10 миллионам в день.

Каждый новый уровень агрегации требовал отдельного batch job, Kafka consumer и MySQL-таблицы.

В результате:

• росло количество дублирующихся пайплайнов;

• увеличивалась write-нагрузка на MySQL;

• cursor-based обработка могла приводить к пропускам данных;

• изменения исторических данных не попадали в агрегаты автоматически;

Высокая нагрузка на MySQL была критична: та же база участвовала в формировании billing source data, поэтому задержки могли влиять на рекламную выручку.

Команда решила вынести обработку performance data в отдельную OLAP-систему и сравнила BigQuery, ClickHouse и StarRocks.

BigQuery уже использовался внутри компании, но не подошел для частых near-real-time запросов: on-demand pricing становился дорогим, а capacity-based модель требовала постоянно держать избыточные ресурсы.

При тестировании ClickHouse команда столкнулась с проблемами интеграции с Glue Catalog и Iceberg.
Таблицы с timestamp-колонками не появлялись в SHOW TABLES, а SQL-запросы через Glue Catalog завершались ошибкой S3 URI.

StarRocks выбрали по нескольким причинам:

• стабильная интеграция с Glue и Iceberg;

• возможность читать source data напрямую из S3 без повторной загрузки;

• Data Cache для кэширования удаленных блоков на BE-узлах;

• Materialized Views для предварительной агрегации часто запрашиваемых данных;

• Cost-Based Optimizer для выполнения JOIN;

• совместимость с MySQL wire protocol, позволившая переиспользовать существующие драйверы и query libraries backend-приложения.

Source of truth при этом оставили вне StarRocks: данные хранятся в Apache Iceberg на Amazon S3, а метаданные — в AWS Glue Catalog.

StarRocks читает исходные Iceberg-таблицы как external tables, но данные, которые непосредственно выдаются продавцам, формируются во внутренних Materialized Views.

Сначала кластер развернули в shared-data конфигурации с FE и stateless CN.
В этой архитектуре внутренние таблицы и MV также хранились в S3.

Для near-real-time аналитики Materialized Views обновлялись каждые несколько минут.
Это генерировало большое количество S3 PutObject и привело к более высоким расходам, чем ожидалось.

После перехода на shared-nothing архитектуру с FE и BE внутренние данные и Materialized Views стали храниться на локальных дисках BE-узлов.
Связанные с этой частью инфраструктуры расходы снизились примерно на 95%, а мониторинг refresh Materialized Views стал проще.

Поскольку исходные данные оставались в Iceberg, для миграции команде не пришлось переносить source data: они развернули новый кластер и заново построили Materialized Views.

В результате Rapport Labs получили масштабируемую систему near-real-time агрегации, снизили нагрузку на MySQL, устранили пропуски в агрегатах и сократили восстановление после инцидентов с более чем четырех часов до менее чем 30 минут.

Этот кейс хорошо показывает архитектуру, в которой Iceberg используется как независимый storage layer и source of truth, а StarRocks — как OLAP-движок и serving layer для пользовательской аналитики.

@tldr_data

Forward-Deployed Engineer (FDE) — одна из самых быстрорастущих инженерных ролей в AI.

По данным a16z и TechCrunch, за последний год количество вакансий FDE выросло более чем на 1100%.
OpenAI, Anthropic, Palantir, Cursor, Redpanda и десятки других компаний активно нанимают таких специалистов.

При этом вокруг роли много путаницы.
Чаще всего обсуждают зарплаты, требования и способы попасть на позицию. Но гораздо интереснее понять, за что компании готовы платить миллионы долларов.

Идея FDE не нова. Ещё в 2007 году Palantir построила вокруг неё свою модель работы с корпоративными клиентами. Сегодня её используют многие AI-компании.

Что же делает FDE?

Если коротко, это инженер, который отвечает за внедрение AI-решения у конкретного клиента и доводит его до production.

В его задачи обычно входят:

изучение бизнес-процессов заказчика;
разработка production-кода, а не PoC;
интеграция с внутренними системами (API, базы данных, IAM, CRM, ERP);
деплой, наблюдаемость, эксплуатация и поддержка решения;
передача повторяющихся запросов обратно в продуктовую команду, чтобы улучшить платформу для всех клиентов.

По сути, FDE находится на пересечении сразу нескольких ролей: Software Engineer, Data Engineer, Platform Engineer и Solutions Architect.

Главное отличие от Solutions Engineer заключается в ответственности. Solutions Engineer чаще помогает спроектировать решение и провести демонстрацию. FDE отвечает за то, чтобы система действительно заработала в инфраструктуре клиента и приносила бизнес-результат.

Недавно Алексей Григорьев, автор Data Engineering Zoomcamp, опубликовал один из самых подробных разборов этой профессии. Вместо карьерных советов он проанализировал 113 вакансий AI Forward-Deployed Engineer и показал, какие навыки действительно требуются компаниям и чем эти инженеры занимаются каждый день.

Рекомендую к прочтению:

https://alexeyondata.substack.com/p/what-ai-forward-deployed-engineers

Если вы работаете с Data Engineering, AI Platform, LLM-инфраструктурой или строите внутренние платформы для разработчиков, есть большая вероятность, что многие из этих задач уже знакомы.
Возможно, вы уже выполняете часть обязанностей FDE, просто эта роль появилась на рынке относительно недавно.

@tldr_data

Pipelines you own. Author locally, deploy to your servers.

Duckle — это open-source ETL-платформа для команд, которые хотят запускать свои пайплайны на собственной инфраструктуре.

Разрабатывать пайплайны можно локально на ноутбуке — с помощью визуального canvas, Python или SQL, — а затем отправить тот же файл на сервер. Команда duckle-runner serve позволяет запускать его без GUI по расписанию: в Docker или на собственном сервере. При этом доступны веб-консоль, управление ролями и журнал аудита.

Каждый пайплайн хранится в Git как один файл, поэтому он не зависит от конкретного разработчика, который его создал.

Duckle компилирует пайплайны в SQL и выполняет их на DuckDB, используя все доступные процессорные ядра. Поэтому чем мощнее сервер, тем быстрее работает пайплайн. Например, 96 миллионов строк из PostgreSQL в Parquet были обработаны за 39,9 секунды.

Никакого облака конкретного вендора. Никакой оплаты за количество обработанных строк. Никакого vendor lock-in.

@tldr_data

Spark observability skills

Skills предназначенные для диагностики и оптимизации нагрузок Apache Spark.

Каждый навык представляет собой отдельный файл SKILL.md, содержащий упорядоченный список наиболее значимых потенциальных причин проблем, которые следует проверить в первую очередь.

Кроме того, в директории scripts/ находится read-only REST-клиент для Spark History Server, который собирает данные о выполнении Spark-приложения в единый ограниченный по объёму snapshot для последующего анализа.

@tldr_data

Apache Airflow 3.3.1: совместимость с pandas 3 и исправления безопасности

Главное изменение касается передачи DataFrame через XCom. В pandas 3 класс теперь записывается как pandas.DataFrame, а не pandas.core.frame.DataFrame.
Airflow 3.3.1 поддерживает оба варианта, поэтому старые XCom остаются доступными.

Обновлять нужно все компоненты Airflow до появления pandas 3 на workers. Старые версии Airflow не смогут десериализовать созданные ими DataFrame XCom. Также стоит проверить DAG, которые зависят от конкретных dtype: строки теперь могут возвращаться как str вместо object, а пропущенные значения — как nan вместо None.

Исправлена миграция с Airflow 2.x при использовании custom Dag bundles. Раньше legacy DAG автоматически получали bundle_name='dags-folder', из-за чего запуск завершался ошибкой. Теперь Airflow определяет bundle по пути к файлу. Принудительно обновить данные можно через airflow dags reserialize.

В релиз также вошли исправления безопасности: маскирование team-scoped sensitive config, защита от получения секрета другой команды, очистка secrets в audit logs и Rendered Templates.

Из операционных исправлений: устранены зависания deferrable tasks, CrashLoopBackOff Triggerer при json_logs, блокировки базы из-за медленных asset listeners и несколько проблем с retries, scheduler и Dag bundles.

Источник: [Apache Airflow 3.3.1 Release Notes]

@tldr_data

А вы знали, что первая версия Apache Airflow называлась Flux?

И её UI выглядел вот так.

Уже тогда была заложена главная идея Airflow: описывать data pipelines на Python как DAG’и, запускать их по расписанию и мониторить через UI.

Забавно смотреть, как один из самых популярных инструментов для оркестрации данных начинался с такого минималистичного интерфейса.

@tldr_data

Apache Airflow 3.3.0: Stateful Tasks and Multi-Language Support

В Airflow 3.3 появился AIP-108 — Language Task SDK. Теперь отдельные tasks можно реализовывать на Java или Go, при этом сам DAG и scheduling остаются в Python.

В DAG задача объявляется как stub:

@task.stub(queue="golang")

Дальше Airflow через Coordinator передает выполнение нужному runtime: JavaCoordinator для JVM или ExecutableCoordinator для Go.

При этом задача остается частью Airflow: доступны XCom, Variables, Connections, retries и стандартный logging.

Это особенно интересно для команд, где orchestration построен на Airflow, а часть production-кода уже написана на Java или Go. Теперь такую логику не обязательно переписывать на Python или выносить за пределы task model Airflow.

Пока Language Task SDK — experimental feature, поэтому API и protocol еще могут меняться.

Документация

@tldr_data

chdb-go

В chdb-go стало проще встраивать ClickHouse прямо в Go-приложение.
Теперь достаточно добавить
blank import:

import _ "github.com/chdb-io/chdb-go/lib/embedded"

Он подтягивает подходящий prebuilt chDB engine для Linux/macOS и amd64/arm64.

При первом запуске движок распаковывается в локальный cache, после чего переиспользуется.
Отдельно устанавливать libchdb больше не нужно.

chDB — это in-process OLAP engine на базе ClickHouse: без отдельного сервера, но с ClickHouse SQL и возможностью напрямую работать с Parquet, CSV, JSON, S3, Iceberg и другими источниками.

Для Go это особенно интересно в контексте CLI, self-contained сервисов и небольших контейнеров, где отдельная native dependency только усложняет deployment.

@tldr_data

Analyst Gym

Analyst Gym — ежедневная тренировка аналитического мышления

AI уже отлично умеет выполнять техническую часть работы аналитика: писать SQL, трансформировать данные, считать метрики. Но интерпретировать результаты, задавать правильные вопросы и принимать решения всё ещё приходится человеку.

На этом и построен Analyst Gym.

Каждый день вы получаете короткое задание примерно на две минуты с ситуацией, которая вполне может произойти на работе: неожиданно изменилась метрика, стейкхолдер просит конкретную цифру или нужно выбрать определение показателя, которое выдержит проверку.

Здесь не проверяют знание SQL, синтаксиса или инструментов обработки данных. Вместо этого нужно принять решение, указать, насколько вы в нём уверены, а затем посмотреть подробный разбор своей логики.

Хороший формат для ежедневной тренировки аналитического мышления в мире, где execution всё чаще можно делегировать AI.

@tldr_data

AI Dev Tools Zoomcamp 2026 launches tomorrow.

The course teaches you how to:

- Choose the right AI tools
- Give them the right context
- Extend them with the right capabilities
- Ship safely with review, audit, security, and DevOps controls

The cohort starts tomorrow. Register now to join from the beginning and stay on track with homework, peer review, and the final project.

Register here: https://courses.datatalks.club/register/ai-dev-tools/
Join the launch: https://luma.com/tsiusx8s

Gridex — database IDE для AI-агентов

Gridex — open-source database IDE для macOS, Windows и Linux. Поддерживает PostgreSQL, MySQL, SQLite, Redis, MongoDB, SQL Server и ClickHouse.

Есть встроенный MCP server и единый MCP layer для всех подключений.

Он включает:
→ permissions
→ SQL sanitization
→ row count estimation
→ audit logs

То есть AI-агент работает с базами через контролируемый слой, а не получает прямой доступ.

@tldr_data

Free Airflow AI Crash Course with Marc Lamberti

В прошлом году виртуальная конференция Astronomer собрала более 8 000 инженеров по данным.

В этом году Orchestrate Everything начнётся с бесплатного интенсивного курса Марка Ламберти о том, как оркестрировать AI с помощью Airflow. За участие вы также получите бесплатный код на сертификационный экзамен стоимостью $150.

Затем вы увидите, как на самом деле выглядит оркестрация AI в production: своими кейсами поделятся инженеры из Lyft, Ramp и Wix.

Участие бесплатное. Подходит для data engineers любого уровня.

@tldr_data

dbt Doctor — это open-source инструмент статического анализа, который сканирует dbt-проекты и выявляет отсутствие документации и тестов, расхождения в схемах, устаревшие модели, чрезмерную сложность DAG и пробелы в управлении данными.

Он может запускаться локально, через coding-агентов или в CI, чтобы оценивать состояние проекта и блокировать изменения, которые приводят к проблемам с качеством.

@tldr_data