![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-18-v-21.51.06.png\")
\n<\/div>\n\n
R2 SQL: Глубокое погружение в наш новый движок для распределенных запросов<\/h4>\n
Авторы:<\/b> Yevgen Safronov, Nikita Lapkov, Jérôme Schneider. ( Привет Никита и Евген :)<\/p>\n
Как выполнить SQL-запросы над петабайтами данных… без сервера?
\nУ нас есть ответ: R2 SQL<\/b>, бессерверный движок запросов, который может просеивать огромные наборы данных и возвращать результаты за секунды.<\/p>\n
В этом посте подробно описывается архитектура и методы, которые делают это возможным. Мы пройдемся по нашему Планировщику запросов<\/b> (Query Planner), который использует `R2 Data Catalog` для отсечения терабайтов данных еще до чтения первого байта, и объясним, как мы распределяем работу по глобальной сети Cloudflare, используя `Workers` и `R2` для массивного параллельного выполнения.<\/p>\nОт каталога к запросу<\/h5>\n
Во время Developer Week 2025 мы запустили `R2 Data Catalog` — управляемый каталог `Apache Iceberg`, встроенный непосредственно в ваш бакет Cloudflare R2. Iceberg — это открытый формат таблиц, который предоставляет критически важные функции баз данных (такие как транзакции и эволюция схемы) для объектного хранилища петабайтного масштаба. Он дает вам надежный каталог ваших данных, но сам по себе не предоставляет способа их запрашивать.<\/p>\n
До сих пор чтение вашего каталога `R2 Data Catalog` требовало настройки отдельного сервиса, такого как `Apache Spark` или Trino. Эксплуатация этих движков в большом масштабе непроста: вам нужно создавать кластеры, управлять использованием ресурсов и отвечать за их доступность — ничто из этого не способствует главной цели: получению ценности из ваших данных.<\/p>\n
`R2 SQL` полностью устраняет этот этап. Это бессерверный движок запросов, который выполняет SQL-запросы на чтение (retrieval) к вашим таблицам Iceberg прямо там, где живут ваши данные.<\/p>\n
поясненИИе: Что такое Apache Iceberg?<\/b><\/summary><\/p>\n
Представьте, что у вас есть огромная куча файлов (CSV, Parquet, JSON) в облачном хранилище. Это “озеро данных”. Проблема в том, что если вы начнете менять один файл, пока кто-то другой его читает, все сломается. Трудно понять, какая версия данных актуальна.<\/p>\n
Apache Iceberg<\/b> — это слой управления поверх этих файлов. Он работает как библиотекарь: он не хранит сами книги (данные), но ведет идеальный учет (метаданные). Он точно знает: “Таблица ‘Пользователи’ сейчас состоит из вот этих 100 файлов”. Объектное хранилище фундаментально отличается от хранилища традиционной базы данных. База данных структурирована по своей природе; `R2 `— это океан объектов, где одна логическая таблица может состоять из миллионов отдельных файлов, больших и маленьких, и новые поступают каждую секунду.<\/p>\n Apache Iceberg предоставляет мощный слой логической организации поверх этой реальности. Он работает, управляя состоянием таблицы как неизменяемой серией мгновенных снимков (snapshots), создавая надежное, структурированное представление таблицы путем манипулирования “легкими” файлами метаданных вместо перезаписи самих файлов данных.<\/p>\n Однако эта логическая структура не меняет физической проблемы, лежащей в основе: эффективный движок запросов всё равно должен найти конкретные данные, необходимые ему, в этой огромной коллекции файлов. Это требует преодоления двух основных технических барьеров:<\/p>\n Наша архитектура для `R2 SQL` разработана для решения этих двух проблем с помощью двухэтапного подхода: Планировщик запросов<\/b> (Query Planner), который использует метаданные для интеллектуального отсечения (pruning) пространства поиска, и система Выполнения запросов<\/b> (Query Execution), которая распределяет работу по глобальной сети Cloudflare для параллельной обработки данных.<\/p>\n Самый эффективный способ обработки данных — не читать их вовсе. Это ключевая стратегия планировщика `R2 SQL`. Вместо исчерпывающего сканирования каждого файла планировщик использует структуру метаданных, предоставляемую каталогом `R2 Data Catalog`, чтобы “подрезать” пространство поиска, то есть избежать чтения огромных массивов данных, не относящихся к запросу.<\/p>\n Это расследование “сверху вниз”, где планировщик перемещается по иерархии слоев метаданных Iceberg, используя статистику (stats<\/b>) на каждом уровне для построения быстрого плана, точно указывающего, какие диапазоны байтов должен прочитать движок.<\/p>\n Когда мы говорим, что планировщик использует “статы”, мы имеем в виду сводные метаданные, которые Iceberg хранит о содержимом файлов данных. Эта статистика создает грубую карту данных, позволяя планировщику принимать решения о том, какие файлы читать, а какие игнорировать, даже не открывая их.<\/p>\n Есть два основных уровня статистики, которые планировщик использует для отсечения (pruning):<\/p>\n Процесс отсечения — это расследование “сверху вниз”, которое происходит в три основных этапа:<\/p>\n Результатом этого многослойного отсечения является точный список файлов Parquet и групп строк внутри этих файлов. Они становятся рабочими единицами (work units), которые отправляются в систему Выполнения запросов.<\/p>\n поясненИИе: Формат Parquet и Row Groups<\/b><\/p>\n Apache Parquet<\/b> — это колоночный формат хранения данных. В отличие от CSV, где данные хранятся строка за строкой, в Parquet данные хранятся столбец за столбцом. Это идеально для аналитики (когда вам нужно посчитать среднее по одной колонке, не читая остальные 50).<\/p>\n Внутри себя файл Parquet делится на Row Groups<\/b> (группы строк). Представьте файл на 1 миллион строк. Он может быть разбит на 10 групп по 100,000 строк. У каждой группы есть свой мини-заголовок со статистикой (min\/max значения).<\/p>\n Пример:<\/b> Вы ищете `id = 950,000`. Это называется “I\/O skipping” и экономит огромное количество времени и денег на трафике.<\/p>\n В `R2 SQL` описанное выше многослойное отсечение не является монолитным процессом. Для таблицы с миллионами файлов метаданные могут быть слишком большими, чтобы обработать их полностью до начала реальной работы. Ожидание полного плана внесет значительную задержку (latency).<\/p>\n Вместо этого `R2 SQL` рассматривает планирование и выполнение как единый конкурентный конвейер (pipeline). Работа планировщика — производить поток рабочих единиц (work units), которые исполнитель (executor) потребляет, как только они становятся доступны.<\/p>\n С этого момента запрос обрабатывается в потоковом режиме. По мере того как Планировщик читает файлы манифестов (и, следовательно, файлы данных, на которые они указывают) и отсекает их, он немедленно отправляет любые подходящие файлы данных\/группы строк как рабочие единицы в очередь выполнения.<\/p>\n Такая конвейерная структура гарантирует, что вычислительные узлы могут начать дорогую работу по вводу-выводу данных практически мгновенно, задолго до того, как планировщик закончит свое полное расследование.<\/p>\n На вершине этой модели конвейера планировщик добавляет критически важную оптимизацию: преднамеренное упорядочивание<\/b> (deliberate ordering). Файлы манифестов не стримятся в случайной последовательности. Вместо этого планировщик обрабатывает их в порядке, соответствующем условию `ORDER BY` вашего запроса, руководствуясь статистикой метаданных. Это гарантирует, что данные, которые с наибольшей вероятностью содержат желаемые результаты, обрабатываются первыми.<\/p>\n Благодаря тому, что Планировщик передает рабочие единицы в порядке, соответствующем `ORDER BY`, система выполнения сначала обрабатывает данные, которые с наибольшей вероятностью попадут в итоговый набор результатов.<\/p>\n Например, для запроса типа `... ORDER BY timestamp DESC LIMIT 5`: по мере того как движок выполнения обрабатывает рабочие единицы и отправляет результаты обратно, планировщик одновременно делает две вещи:<\/p>\n В момент, когда самая старая временная метка в нашей “Топ-5 куче” оказывается новее, чем “ватерлиния” оставшегося потока (максимально возможная дата в еще не прочитанных файлах), весь запрос может быть остановлен<\/b>.<\/p>\n В этот момент мы можем доказать, что ни одна оставшаяся рабочая единица не может содержать результат, который попал бы в топ-5. Конвейер останавливается, и пользователю возвращается полный, корректный результат, часто после чтения лишь крошечной доли потенциально подходящих данных.<\/p>\n Планировщик передает работу кусочками, называемыми Row Groups<\/b>. Сервер, который получает запрос пользователя, берет на себя роль координатора запроса<\/b>. Он распределяет работу между воркерами<\/b> (query workers) и агрегирует результаты.<\/p>\n Сеть Cloudflare огромна. Координатор связывается с внутренним API Cloudflare, чтобы убедиться, что для выполнения выбираются только здоровые серверы. Соединения между координатором и воркерами проходят через `Cloudflare Argo Smart Routing` для обеспечения быстрой и надежной связи.<\/p>\n Серверы, получающие задачи от координатора, становятся воркерами. Они служат точкой горизонтального масштабирования в `R2 SQL`. При большем количестве воркеров `R2 SQL` может обрабатывать запросы быстрее, распределяя работу между множеством серверов. Это особенно актуально для запросов, охватывающих большие объемы файлов.<\/p>\n Внутри каждый воркер использует `Apache DataFusion` для выполнения SQL-запросов к группам строк. `DataFusion` — это аналитический движок запросов с открытым исходным кодом, написанный на Rust<\/b>.<\/p>\n Разделы (partitions) в `DataFusion` идеально ложатся на модель данных `R2 SQL`, поскольку каждая группа строк (row group) может рассматриваться как независимый раздел. Благодаря этому каждая группа строк обрабатывается параллельно. `DataFusion` имеет первоклассную поддержку Parquet. Используя ranged reads (чтение диапазонов) в R2, он способен считывать только части файлов Parquet, содержащие запрошенные столбцы, пропуская остальные.<\/p>\n Оптимизатор `DataFusion` также позволяет нам “проталкивать” фильтры (push down filters) на самые низкие уровни плана запроса. Другими словами, мы можем применять фильтры прямо в момент чтения значений из файлов Parquet.<\/p>\n Когда воркер заканчивает вычисления, он возвращает результаты координатору через протокол gRPC<\/b>. `R2 SQL` использует `Apache Arrow` для внутреннего представления результатов. Это формат в оперативной памяти (in-memory), который эффективно представляет массивы структурированных данных. Arrow также определяет формат сериализации `Arrow IPC`, который идеально подходит для передачи данных между процессами по сети.<\/p>\n поясненИИе: Векторизация и Apache Arrow<\/b><\/summary> Apache Arrow:<\/b> Это стандарт того, как хранить эти “пачки” данных в оперативной памяти, чтобы процессору было максимально удобно их читать. Хотя `R2 SQL` и так хорош в фильтрации, мы планируем быстро добавлять новые возможности:<\/p>\n Мы также исследуем различные виды индексов, чтобы сделать запросы еще быстрее, и планируем добавить полнотекстовый поиск, геопространственные запросы и многое другое.<\/p>\n Это ранние дни для `R2 SQL`, но он уже доступен в открытой бете! Переходите к нашему руководству по началу работы, чтобы создать сквозной конвейер данных. Мы ждем вашей обратной связи в нашем Discord для разработчиков.<\/p>\n ***<\/p>\n Итог:<\/b> Cloudflare выпустила мощный инструмент, который превращает их объектное хранилище (R2) в полноценную аналитическую базу данных. Используя открытые стандарты (Iceberg, Parquet, Arrow, DataFusion) и свою глобальную сеть периферийных вычислений (Edge), они решили главную проблему Big Data — необходимость платить за простой серверов. Здесь вы платите только за время выполнения конкретного SQL-запроса.<\/p>\n СоображенИИя:<\/b><\/p>\n Еще можно почитать про https:\/\/vegafusion.io<\/a> и про формат https:\/\/lance.org<\/a> – он как раз и добавит векторочков.<\/p>\n",
"date_published": "2026-02-18T21:56:56+03:00",
"date_modified": "2026-02-18T21:57:57+03:00",
"tags": [
"big data",
"Data",
"Data Engineer",
"Platform",
"Serverless"
],
"image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-18-v-21.51.06.png",
"_date_published_rfc2822": "Wed, 18 Feb 2026 21:56:56 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "319",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-18-v-21.51.06.png"
]
}
},
{
"id": "304",
"url": "https:\/\/gavrilov.info\/all\/epoha-tolstogo-brauzera-i-revolyuciya-lokalnyh-dannyh-na-wasm\/",
"title": "Эпоха «Толстого» браузера и революция локальных данных на WASM",
"content_html": " В истории IT-архитектуры маятник всегда качался между двумя крайностями: централизацией и децентрализацией. Сначала были мейнфреймы (центр), затем «толстые» клиенты на ПК (локальные вычисления), а потом пришла эра веб-приложений, и индустрия массово мигрировала в Облака.<\/p>\n Мы привыкли считать браузер лишь «тонким окном», интерфейсом, где вся магия, сложные вычисления и хранение происходят где-то далеко — на серверах AWS или Google. Но сегодня правила игры меняются. Благодаря технологиям WebAssembly (WASM), современному «железу» и новым подходам, браузер превращается в полноценную операционную систему для анализа данных или еще чего-то blog.openreplay.com<\/a>. Посмотрите статью о “Руководство по Разработке Local-First Приложений”.<\/p>\n Эра миграции в облака:<\/b> Проблемы сегодняшнего дня:<\/b><\/p>\n Решение: Приложения Local-First<\/b><\/p>\n Технология WebAssembly (WASM) позволила запускать нативный код (C++, Rust, Go) прямо в песочнице браузера со скоростью, близкой к нативной habr.com<\/a>. Это породило новый класс ПО, которое выглядит как веб-сайт, но работает как десктопное приложение. Вы заходите на страницу, она загружает легковесный движок, и далее вы можете отключить интернет — приложение продолжит «перемалывать» ваши данные локально.<\/p>\n Уже сейчас существуют продукты, которые меняют представление о работе с данными. Они объединяют UX веб-приложений с мощностью десктопного софта, создавая ощущение, что сервер находится прямо у вас в RAM.<\/p>\n Проект DataKit.page<\/b> — яркий пример такой архитектуры. Это не просто “просмотрщик файлов”, это полноценная ETL\/Analytics платформа, живущая в вашем браузере.<\/p>\n Команда DuckDB в сотрудничестве с MotherDuck выпустила официальный локальный UI, работающий через расширение. Это прямой ответ на боль пользователей консольных утилит и отличный пример гибридного подхода habr.com<\/a>.<\/p>\n https:\/\/gavrilov.info\/all\/tetradki-nashe-vsyo-marimo-io-i-utochkadb\/<\/a><\/p>\n Многие аналитики и инженеры привыкли к классическим клиентам баз данных (DBeaver, DataGrip). Это мощные, но «тяжелые» инструменты, требующие установки, настройки драйверов и обновлений. Новый WASM-тренд предлагает более гибкую альтернативу.<\/p>\n Сценарий «Мгновенной аналитики»:<\/b> Еще вариант, лог 30ГБ и вы заказали функционал в другой команде, она с радостью сказала, что через два спринта сделает пайплайн за неделю, но ей надо требования. Вы их конечно написали на основе небольшого семпла строк из excel или на основе документации и отдали в разработку. А через месяц получили отличный пайплайн или, который не нужен или его нужно еще доработать.<\/p>\n Технологическая магия за кулисами:<\/b><\/p>\n Для архитекторов платформ данных этот тренд открывает удивительную экономическую модель «Bring Your Own Compute» или «Client-side computing» (Принеси Свои Вычисления)<\/b>.<\/p>\n Мы движемся к миру, где браузер — это не тонкий клиент, а универсальная песочница для гибридных вычислений<\/b>.<\/p>\n Разработчикам и Архитекторам:<\/b><\/p>\n Пользователям и Аналитикам:<\/b><\/p>\n Ренессанс локальных вычислений начался. Ваш браузер способен на большее, чем просто отображать HTML. Он становится вашей персональной дата-лабораторией.<\/p>\n",
"date_published": "2025-12-13T01:20:55+03:00",
"date_modified": "2025-12-13T01:20:35+03:00",
"tags": [
"Architecture",
"Data",
"Dev",
"Platform"
],
"_date_published_rfc2822": "Sat, 13 Dec 2025 01:20:55 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "304",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "293",
"url": "https:\/\/gavrilov.info\/all\/novye-arhitektury-sovremennoy-infrastruktury-dannyh-a16z\/",
"title": "Новые архитектуры современной инфраструктуры данных: a16z",
"content_html": " Источник:<\/b> Emerging Architectures for Modern Data Infrastructure<\/a> Индустрия инфраструктуры данных продолжает стремительно развиваться. С момента публикации первой версии эталонных архитектур в 2020 году, на рынке появилось множество новых продуктов, а метрики ключевых компаний достигли рекордных высот. Эта статья представляет собой обновленный анализ ключевых архитектурных шаблонов и трендов, основанный на опыте ведущих специалистов в области данных.<\/p>\n Основная гипотеза заключается в том, что, хотя ядро систем обработки данных осталось относительно стабильным<\/b>, вокруг него произошел “Кембрийский взрыв” — стремительное размножение поддерживающих инструментов и приложений. Это явление можно объяснить формированием настоящих платформ данных<\/b>, которые становятся фундаментом для новой экосистемы.<\/p>\n Статья предлагает два общих взгляда на современный стек данных.<\/p>\n Эта схема дает комплексное представление о стеке данных, охватывая все основные варианты использования — от аналитики до операционных систем.<\/p>\n Схема демонстрирует путь данных от источников (`Sources`) через этапы загрузки и транспортировки (`Ingestion and Transport`), хранения (`Storage`), обработки запросов (`Query and Processing`), трансформации (`Transformation`) до конечного анализа и вывода (`Analysis and Output`).<\/p>\n Вторая схема подробно рассматривает сложную и все более независимую цепочку инструментов для машинного обучения.<\/p>\n Здесь показан жизненный цикл ML-модели: от трансформации данных и разработки модели (`Data Transformation`, `Model Training and Development`) до ее развертывания (`Model Inference`) и интеграции в конечные продукты (`Integration`).<\/p>\n Несмотря на активное развитие рынка, базовые архитектурные паттерны сохранили свою актуальность. По-прежнему существует разделение между:<\/p>\n Ключевые технологии в ядре стека доказали свою устойчивость и продолжают доминировать:<\/p>\n Вокруг стабильного ядра наблюдается бурный рост новых инструментов и приложений, которые можно разделить на две категории:<\/p>\n Этот шаблон предназначен для компаний любого размера, которые строят облачную BI-аналитику.<\/p>\n Этот шаблон развивает концепцию “озера данных” (`Data Lake`) для поддержки как аналитических, так и операционных задач. Часто используется компаниями, которые “мигрировали” с `Hadoop`.<\/p>\n Стек для разработки, тестирования и эксплуатации ML-моделей.<\/p>\n Ключевая идея статьи — объяснить наблюдаемые изменения через формирование платформ данных<\/b>.<\/p>\n В широком смысле, платформа — это то, на чем могут строить свои продукты другие разработчики. Определяющей чертой является взаимная зависимость между поставщиком платформы и большим пулом сторонних разработчиков.<\/p>\n Применительно к данным, “бэкенд” стека (загрузка, хранение, обработка) консолидируется вокруг небольшого числа облачных вендоров. Эти вендоры (`Snowflake`, `Databricks`) активно инвестируют в то, чтобы сделать данные легкодоступными для других через стандартные интерфейсы (например, SQL).<\/p>\n В свою очередь, “фронтенд” разработчики пользуются этим, создавая множество новых приложений поверх единой точки интеграции, не беспокоясь о сложностях базовой инфраструктуры. Это приводит к появлению нового класса `warehouse-native` (или `lakehouse-native`) приложений, которые работают непосредственно с данными клиента в его хранилище.<\/p>\n Эта модель объясняет, почему поставщики ядра данных (`Snowflake`, `Databricks`) так высоко ценятся (они борются за долгосрочную позицию платформы) и почему наблюдается взрывной рост в экосистеме инструментов (`Reverse ETL`, `Metrics Layer`) — они становятся важными компонентами, встроенными в эту новую платформенную архитектуру.<\/p>\n Оригинал:<\/b><\/p>\n A platform is a set of software and a surrounding ecosystem of resources that helps you to grow your business. A platform enables growth through connection: its value comes not only from its own features, but from its ability to connect external tools, teams, data, and processes.<\/p>\n<\/blockquote>\n Перевод:<\/b><\/p>\n Платформа — это комплекс программных решений и окружающая их экосистема ресурсов, которые способствуют росту вашего бизнеса. Платформа стимулирует рост за счёт связности: её ценность заключается не только в собственных функциях, но и в способности объединять внешние инструменты, команды, данные и процессы.<\/p>\n<\/blockquote>\n Приведённая цитата — отличное базовое определение. Однако современное понимание платформ стало значительно шире и глубже. Сегодня платформа — это не просто технологический фундамент, а ключевой стратегический актив для трансформации всего бизнеса.<\/p>\n Вот несколько ключевых аспектов, дополняющих это определение:<\/p>\n
\nЭто позволяет делать с обычными файлами в облаке то, что раньше умели только дорогие базы данных:<\/p>\n\n
Проектирование движка запросов для петабайтов<\/h5>\n
\n
Планировщик запросов (Query Planner)<\/h5>\n
Что мы подразумеваем под “статистикой”?<\/h6>\n
\n
\n
Отсечение пространства поиска (Pruning)<\/h6>\n
\n
\nПланировщик начинает с запроса к каталогу о местоположении текущих метаданных таблицы. Это JSON-файл, содержащий текущую схему таблицы, спецификации разделов и журнал всех исторических снимков. Затем планировщик выбирает последний снимок для работы.<\/li>\n<\/ol>\n\n
\nТекущий снимок указывает на единый *список манифестов* (manifest list) Iceberg. Планировщик читает этот файл и использует статистику уровня разделов для каждой записи, чтобы выполнить первый, самый мощный шаг отсечения, отбрасывая любые манифесты, чьи диапазоны значений разделов не удовлетворяют запросу. Например, для таблицы, партиционированной по дням, планировщик может отбросить манифесты за ненужные даты.<\/li>\n<\/ol>\n\n
\nДля оставшихся манифестов планировщик читает каждый из них, чтобы получить список фактических файлов данных Parquet. Эти файлы манифестов содержат более детальную статистику уровня столбцов. Это позволяет выполнить второй шаг отсечения, отбрасывая целые файлы данных, которые не могут содержать строки, соответствующие фильтрам запроса.<\/li>\n<\/ol>\n\n
\nНаконец, для конкретных файлов данных, которые всё еще являются кандидатами, Планировщик использует статистику, хранящуюся внутри *футеров* (footers) файлов Parquet, чтобы пропускать целые группы строк (row groups).<\/li>\n<\/ol>\n
\nДвижок читает футер файла и видит:<\/p>\n\n
Конвейер планирования (The Planning pipeline)<\/h5>\n
Начало выполнения как можно раньше<\/h6>\n
Ранняя остановка: как закончить, не читая всё<\/h6>\n
\n
\nВыполнение запросов (Query Execution)<\/h5>\n
Внутреннее устройство: Apache DataFusion<\/h6>\n
\nПоскольку группы строк обычно содержат как минимум 1000 строк, `R2 SQL` выигрывает от векторизованного выполнения<\/b>. Каждый поток DataFusion может выполнять SQL-запрос сразу на множестве строк за один проход, амортизируя накладные расходы на интерпретацию запроса.<\/p>\nПоддержка Parquet и Arrow<\/h6>\n
\nВекторизованное выполнение (Vectorized execution):<\/b> Традиционные базы данных обрабатывали одну строку за раз (Row-at-a-time). Это медленно, потому что процессор постоянно переключается. Векторизация означает обработку данных “пачками” (например, сложить сразу 1000 чисел из колонки А с 1000 чисел из колонки Б). Это использует современные возможности CPU (SIMD инструкции) и работает в разы быстрее.<\/p>\n
\nГлавный плюс Arrow: Zero-copy<\/b>. Если один инструмент (DataFusion) передает данные другому (по сети координатору), и оба понимают Arrow, им не нужно тратить время на перекодирование (сериализацию\/десериализацию) данных. Они просто “передают указатель” или копируют сырые байты как есть.<\/p>\nБудущие планы<\/h5>\n
\n
Попробуйте сейчас!<\/h5>\n
Итог и СоображенИИя<\/h4>\n
\n
Почему мы уходили в облака и почему возвращаемся?<\/h3>\n
\nВ 2010-х локальные машины были «бутылочным горлышком». Чтобы обработать гигабайты данных, требовались серверные стойки. Облака давали бесконечную масштабируемость. Архитектура сводилась к простой формуле: *данные пользователя → загрузка через сеть (latency) → обработка на сервере ($$$) → результат обратно клиенту*.<\/p>\n\n
Новые герои: Сервер внутри вкладки<\/h3>\n
1. DataKit — Швейцарский нож аналитика<\/h4>\n
\n
\n
2. DuckDB Local UI — SQL без инсталляции<\/h4>\n
\n
3. Marimo – тетрадки, почти тот же подход имеет<\/h4>\n
3. PGlite и PondPilot — Postgres и SQL-песочницы<\/h4>\n
\n
Сдвиг парадигмы: От DBeaver к Браузеру<\/h3>\n
\nПредставьте, что вам прислали ссылку на лог-файл в S3 размером 5 ГБ или Parquet-дамп.<\/p>\n\n
\n
Органическое масштабирование и новая экономика<\/h3>\n
\n
\n
Итого<\/h3>\n
\n
\n
\nАвторы:<\/b> Matt Bornstein, Jennifer Li, and Martin Casado
\nPDF: Тут<\/a><\/p>\n
\nОбновленные эталонные архитектуры<\/h4>\n
1. Единая инфраструктура данных (Unified Data Infrastructure 2.0)<\/h5>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-222.png\")
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-223.png\")
\n<\/div>\n2. Инфраструктура для машинного обучения (Machine Learning Infrastructure 2.0)<\/h5>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-224.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-225.png\")
\n<\/div>\nЧто изменилось? Стабильное ядро и “Кембрийский взрыв”<\/h4>\n
Что не изменилось: стабильность в ядре<\/h5>\n
\n
\n
Что нового: “Кембрийский взрыв”<\/h5>\n
\n
\n
\n
\n
Три основных архитектурных шаблона (Blueprints)<\/h4>\n
Шаблон 1: Современная Business Intelligence (BI)<\/h5>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-226.png\")
\n\n
\n
Шаблон 2: Мультимодальная обработка данных<\/h5>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-227.png\")
\n<\/div>\n\n
\n
Шаблон 3: Искусственный интеллект и машинное обучение (AI\/ML)<\/h5>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-228.png\")
\n\n
\n
Гипотеза о “платформе данных”<\/h4>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-229.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-230.png\")
\n<\/div>\nИтог и акценты в трендах<\/h4>\n
\n
\n
\n
\n
\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-28-v-23.36.14.png\")
\n<\/div>\n\n
\n
Дополнение с учетом современных трендов и опыта<\/h4>\n
\n
\nСовременные лидеры рынка рассматривают платформы не как набор инструментов, а как основу для полного переосмысления своего бизнеса. Платформенный подход позволяет заново выстроить всю цепочку поставок, клиентский путь и процессы принятия решений. Это критический компонент «цифрового ядра» компании, стремящейся к постоянному обновлению и росту accenture.com https:\/\/www.accenture.com\/us-en\/insights\/strategy\/platform-strategy.<\/a><\/li>\n<\/ol>\n\n
\nПлатформа сама по себе не является готовым решением. Она требует значительных инвестиций в настройку и интеграцию для того, чтобы начать генерировать ценность. Как отмечает Forrester, пустой аккаунт в `Amazon Web Services` (AWS) бесполезен до тех пор, пока вы не установите и не настроите на нём программное обеспечение и не окружите его дополнительными возможностями forrester.com https:\/\/www.forrester.com\/blogs\/a-simple-definition-of-platform.<\/a><\/li>\n<\/ol>\n\n
\nЭпоха единых монолитных IT-приложений, которые должны были решать все задачи бизнеса, подходит к концу. Современная парадигма — это создание гибкой архитектуры, в которой решения от разных поставщиков могут быть бесшовно развёрнуты и интегрированы. Такие «инновационные платформы» позволяют компаниям быстро адаптироваться к изменениям и использовать лучшие в своём классе инструменты для каждой функции cimdata.com https:\/\/www.cimdata.com\/en\/platformization-some-common-definitions.<\/a><\/li>\n<\/ol>\n\n
\nПлатформенные бизнес-модели — это проверенный способ достижения успеха. Они позволяют технологическим компаниям монетизировать свои продукты через модели `as-a-service` (по подписке или на основе потребления), повышать лояльность клиентов за счёт связанных сервисов и масштабироваться гораздо быстрее. Для 80% компаний, ещё не перешедших на платформенную модель, главным вызовом становится растущая конкуренция со стороны тех, кто уже сделал этот шаг ey.com https:\/\/www.ey.com\/en_nz\/insights\/technology\/how-can-your-platform-business-model-fuel-competitiveness-and-growth.<\/a><\/li>\n<\/ol>\n\n