Я давно слежу за Alexander Noonan.
Еще с его времен в Dagster.

Мне всегда нравилось, как он объяснял новые фичи. Без ощущения, что тебе читают маркетинговый лендинг. Просто нормальный инженерный разбор того, как и зачем это работает. Многие вещи в Dagster я в свое время понял именно через его видео и посты.

Сейчас Alexander перешел в dbt Labs.
И, кажется, это очень хороший мэтч.

Недавно он написал про отчет 2026 State of Analytics Engineering. Там есть цифра, которая хорошо описывает то, что сейчас происходит почти во всех data-командах.

72% команд используют AI в первую очередь для генерации кода.
И только 24% — для тестирования, observability и управления пайплайнами.

Получается довольно знакомая история. Генерировать стало сильно быстрее. Проверять — почти нет.

SQL, dbt models, DAG-и и пайплайны теперь появляются быстрее, чем команды успевают разбираться, что именно уехало в production. А потом все удивляются hallucinated data, странным метрикам и потерянному доверию со стороны бизнеса.

И проблема тут даже не в AI.

Data-команды годами откладывали validation, ownership, lineage, тесты и monitoring «на потом». Просто раньше скорость изменений была ниже, и это не так бросалось в глаза. Теперь AI резко увеличил throughput, а процессы проверки остались примерно на том же уровне.

Мне кажется, ближайшие несколько лет будут не про кто быстрее пишет код через LLM. Скорее про то, кто сможет нормально масштабировать reliability вокруг этого кода.

Тесты, observability, документация, feedback loops — это постепенно становится не дополнительной инженерной культурой, а базовой частью платформы.

@tldr_data

MOR Isn’t a Storage Optimization. It’s an Architectural Shift

MOR — это не просто оптимизация хранения данных.
Это архитектурный сдвиг.

Многие описывают Merge-On-Read слишком упрощенно: COW — для чтения, MOR — для записи.
Формально это верно, но такое объяснение упускает главное.

MOR по сути переносит часть работы во времени, разделяя обработку изменений на этапе ingestion и оптимизацию на этапе хранения. Если смотреть на это с такой точки зрения, современная lakehouse-архитектура перестает быть набором отдельных фич и начинает выглядеть как последовательное следствие одного архитектурного решения.

Первым к этому подходу пришел Hudi еще в 2017 году. Iceberg фактически пришел к похожим выводам только в 2021, а Delta — в 2023. Вероятно, Hudi просто опередил свое время: тогда индустрия еще не до конца понимала, зачем вообще нужна подобная фундаментальная архитектура.

В посте разбирается сама архитектурная идея, реальные издержки MOR, временной разрыв между Hudi и другими форматами, а также production-кейсы. Например, ByteDance управляет 400 PB данных в одной MOR-таблице Hudi, а Walmart называет MOR единственным открытым файловым форматом, способным справиться с их workload с большим количеством обновлений.

Подробнее в посте

@tldr_data

The Evolution of Cassandra Data Movement at Netflix

Netflix заменил свой движок переноса данных из Cassandra в Iceberg на многоуровневую платформу, которая читает бэкапы напрямую из S3, преобразует их в Spark DataFrame и позволяет каждому уровню абстракции данных строить собственный оптимизированный коннектор.

Платформа обрабатывает около 3 ПБ данных в день. Для миграции использовались shadow validation, улучшенная observability и fallback-механизм через Maestro Decider на предыдущее решение. Это позволило выполнить прозрачное переключение без каких-либо изменений кода у downstream-потребителей.

@tldr_data

Объединение dbt Labs и Fivetran официально завершено.

Если раньше эти компании закрывали разные части современного data stack, то теперь они строят единую платформу вокруг идеи Open Data Infrastructure.

Но на этом новости не заканчиваются.

dbt Labs представила dbt Core v2.0 и открыла исходный код runtime-движка Fusion.
По сути, это фундамент для следующего поколения dbt. Проект становится не просто инструментом трансформации данных, а полноценной платформой со своим стандартом и экосистемой.

Подробности о dbt Core v2.0:

Из других анонсов особенно выделяются две вещи.

Первая — dbt State.
Теперь dbt становится stateful и начинает хранить состояние между запусками, что открывает новые возможности для оптимизации и управления пайплайнами.

Вторая — dbt Wizard.
Это AI-агент для работы с данными, который позиционируется как инструмент для решения сложных задач аналитической инженерии. По заявлениям команды, он показывает сильные результаты на ADE-Bench.

Обзор новых продуктов и видение объединённой компании:

Если посмотреть на всё вместе, становится заметен интересный тренд.
Analytics Engineering постепенно перестаёт быть просто набором SQL-моделей и оркестрации. Инструменты начинают объединять хранение данных, трансформации, контекст, состояние и AI-агентов в единую среду разработки.

Отдельно рекомендую почитать дорожную карту dbt Core v2.
Там много интересного про будущее стандарта dbt, Fusion Engine и развитие платформы:

Интересно будет посмотреть, насколько удачно dbt Labs и Fivetran смогут реализовать эту стратегию на практике. Но уже сейчас видно, что экосистема dbt движется в сторону гораздо более амбициозной платформы, чем многие представляли ещё пару лет назад.

@tldr_data

Launching Polars Distributed on Kubernetes

С сегодняшнего дня, Polars также доступен как распределённый движок (Distributed Engine) для Kubernetes.

Цель Polars всегда заключалась в том, чтобы сделать обработку данных на одном узле максимально производительной и удобной. Теперь Polars хочет распространить этот подход и на распределённые вычисления.

https://pola.rs/posts/polars-distributed-available-on-kubernetes/

@tldr_data

Anthropic наконец-то опубликовали свой секретный рецепт для агентной аналитики, и это…

Моделирование данных по Кимбаллу (Kimball Data Modeling)

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

Для дата-инженеров и аналитиков это примерно звучит как:

Секрет успешных AI-агентов? Сделайте нормальный DWH

@tldr_data

We Tried ty for Performance. It Found Real Bugs

Dagster заменил Pyright на новый инструмент проверки типов от Astral — ty,
во всём монорепозитории Dagster.
В результате время проверки типов в CI сократилось примерно с 12 минут до 2 минут на каждый запуск, это было ожидаемо.

Чего команда не ожидали, так это того, что ty обнаружит реальные ошибки времени выполнения (runtime bugs), которые Pyright ранее пропустил.

Это также стало отличным примером того, как много можно сделать с помощью агентных систем.
В Dagster поддерживается более 100 пакетов, и все их нужно было перевести на ty.

Первые несколько миграций выполнялись вручную, пока разбирались в тонких различиях между инструментами и определяли, какие подавления предупреждений (suppressions) безопасны. Но после того как рабочий процесс был отлажен, команда смогла запускать несколько агентов параллельно, чтобы раскатить изменения на все оставшиеся библиотеки.

Если вам интересно узнать больше о проверке типов или о том, как ИИ может повышать продуктивность разработчиков в крупных репозиториях, обязательно ознакомьтесь с этим материалом.

@tldr_data

Crack Any Codebase with AI

Начал сейчас читать эту книгу и вот первая цитата из книги прямо жиза.

Вы знаете эту боль. Это легаси-система, созданная восемь лет назад людьми, которые уже давно ушли, а документация описывает версию, которой больше не существует. Это инцидент в продакшене в 2 часа ночи, где ошибка находится в сервисе, который вы не писали, но чинить его приходится именно вам. Это ваш первый месяц на новой работе: перед вами 100 000 строк кода и задача, которую нужно выпустить через две недели. Это взгляд на собственный код, написанный шесть месяцев назад, когда вы уже не помните, почему сделали всё именно так. Во всех этих случаях код работает. Но никто до конца не понимает, почему он работает. Это то, что мы называем долгом понимания (comprehension debt).

Автор книги — Zezhou Huang, также известен как Zachary (Zach) Huang. Сейчас он работает исследователем в подразделении Microsoft Research AI Frontiers и занимается LLM-агентами и системами. До этого был связан с Microsoft Research⁠, учился в Columbia University⁠ и создал проект Codebase Knowledge Builder.

Интересно, что его основная мысль не про генерацию кода, а про понимание кода. В книге он противопоставляет vibe coding и code comprehension.

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

@tldr_data

LLM Zoomcamp starts

Успевайте зарегестрироваться на курс

https://t.me/tldr_data/84

Bruin Semantic Layer

Семантический слой — одна из тех вещей, которые все хотят иметь, но никто толком не знает, с чего начать.
Существует огромное количество способов его реализовать: некоторые встроены в SQL-уровень, например dbt MetricFlow, некоторые являются независимыми решениями, например Cube, а некоторые живут на стороне базы данных, например Snowflake Metric Views.
У каждого подхода есть свои компромиссы.

У семантического слоя Bruin есть несколько особенностей, которые делают его привлекательным:

- Вы можете определять семантический слой в той же кодовой базе, что и ваши data assets. Он хранится в системе контроля версий и находится в том же контексте, что и остальная часть вашей дата-платформы.

- Существующая CLI-команда query в Bruin позволяет выполнять семантические запросы напрямую локально. Это дает возможность использовать такие запросы вместе с AI-агентами.

- Он работает «из коробки» с dac — нашим продуктом для создания дашбордов как кода (dashboard-as-code), который также является open-source.

- Поддерживает вложенные ссылки (nested references), сегменты (segments) и графы соединений (join graphs).

- Может быть проверен с помощью команды bruin validate, чтобы убедиться в корректности определений метрик.

Это означает, что если вы используете агентов для построения пайплайнов, они смогут по ходу работы обновлять и ваш семантический слой. Если Bruin используется как контекстный слой для AI-аналитика данных, вы сразу получаете семантический слой, пригодный для использования этим аналитиком.
Семантический слой пока находится на ранней стадии развития, но уже работает на всех платформах, которые мы поддерживаем. Он совместим с любыми существующими агентами — будь то Claude Code, Codex или Pi.

@tldr_data

Datapitfalls — это инструмент с открытым исходным кодом на базе Claude, который проверяет графики, код, аналитические материалы и документы на наличие распространённых ошибок в работе с данными на всём протяжении цепочки рассуждений — от постановки вопроса до представления результатов.

Он выходит далеко за рамки обычной проверки графиков, используя таксономию Avoiding Data Pitfalls Бена Джонса для выявления таких проблем, как предвзятость, незаметные сбои в конвейерах обработки данных, некорректная агрегация, статистические ошибки, вводящие в заблуждение визуализации и неясная подача информации. После этого инструмент оценивает серьёзность каждой проблемы и предлагает способы её устранения.

@tldr_data

pg_kpart — это расширение для PostgreSQL, которое блокирует выполнение запросов к партиционированным таблицам, если они пытаются просканировать все партиции без использования условия по ключу партиционирования. Оно защищает от случайных полных сканирований, возникающих из-за отсутствующих условий WHERE или JOIN по ключу партиционирования.

Если вы работаете DBA, то наверняка сталкивались с ситуацией, когда запрос обращается к партиционированной таблице, но не использует ключ партиционирования. На таблицах с сотнями миллионов или миллиардами строк это превращается в настоящую катастрофу: PostgreSQL вынужден сканировать все партиции, подсистема ввода-вывода сервера перегружается, а производительность падает для всех пользователей, подключённых к базе.

Принцип работы расширения очень простой: если запрос к защищённой партиционированной таблице не позволяет исключить ни одну партицию (partition pruning), его выполнение запрещается. Вместо масштабной нагрузки на сервер разработчик получает понятную ошибку и вынужден переписать запрос так, чтобы он фильтровал данные по ключу партиционирования — именно под такой сценарий и создавались партиционированные таблицы.

По сути, pg_kpart превращает рекомендацию «всегда фильтруйте по ключу партиционирования» из негласного правила, которое легко забыть, в жёсткое ограничение, гарантированно контролируемое самой базой данных.

Расширение поддерживает режим аудита для безопасного внедрения, механизмы белых и чёрных списков для точечного применения только к важным таблицам, а также использует отдельный код SQLSTATE, позволяющий приложениям корректно обрабатывать подобные ошибки.

Если в вашей инфраструктуре есть крупные партиционированные таблицы и вы не хотите зависеть от следующего запроса, в котором кто-то забудет указать ключ партиционирования, pg_kpart может оказаться очень полезным инструментом.

@tldr_data

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

[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

[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

Команда Apache NiFi объявила о выпуске Apache NiFi 2.10.0.

Версия 2.10.0 добавляет поддержку пользовательского интерфейса для Connectors, делая новую платформу расширений доступной для практического использования.
В эту версию также входит реализация коннектора, поддерживающего передачу данных из Kafka в S3.

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

повышение производительности реализации репозитория контента (Content Repository) фреймворка;
более гибкая поддержка парсинга JSON.

Таким образом, релиз сосредоточен не только на новых возможностях, но и на повышении стабильности, производительности и удобства работы с системой.

@tldr_data

Ingestr опубликовал полный набор бенчмарков и код для их воспроизведения.

Команда утверждает, что ingestr сейчас является самым быстрым open-source инструментом для data ingestion.
В тестах сравнивали загрузку данных между DuckDB, PostgreSQL, MySQL, MongoDB и Snowflake, стараясь использовать оптимальные настройки для каждого решения.

Из интересного:

• Ingestr оказался лидером почти во всех тестах, проиграв лишь в двух сценариях с минимальным отставанием.
• Spark заметно уступает на небольших объёмах данных из-за высокого оверхеда, но показывает достойные результаты на крупных нагрузках.
• Airbyte (через PyAirbyte) оказался самым медленным участником сравнения — тест на 10 млн строк даже не удалось дождаться до завершения.

Авторы напоминают простую мысль: производительность — это тоже функциональность. А поскольку data ingestion часто становится узким местом в data-платформах, такие сравнения заслуживают внимания.

@tldr_data

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

The Best Developer Story I’ve Read This Year

Я уверен, что про эту эпичную историю в русскоязычном 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

databow — единый CLI-инструмент для работы с разными базами данных, построенный на Rust и ADBC.

Устали постоянно переключаться между разными клиентами для баз данных — psql, mysql, snowsql, bq, sqlite3 и другими?

А существующие мульти-СУБД клиенты кажутся слишком медленными и громоздкими?

databow позволяет выполнять запросы к любому SQL-источнику, для которого существует драйвер ADBC. На данный момент поддерживается уже более 30 различных систем, и их число продолжает расти.

Все это — прямо из терминала и с помощью одного простого инструмента.

@tldr_data

Stop rebuilding what production already built. Change-aware SQL pipelines with all state in the warehouse.

SQLBuild предлагает довольно простой подход: не пересобирать модели, которые не изменились. Инструмент отслеживает изменения, повторно использует уже готовые таблицы из продакшена и хранит всё состояние прямо в хранилище данных — без отдельной базы для метаданных и дополнительных сервисов.

Из интересного: работает поверх существующего dbt-проекта и не требует миграции или изменений в моделях.

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

@tldr_data