Большие данные мертвы. Те из нас, кто провел последнее десятилетие, работая над системами управления данными, знают, что реальные бизнес-наборы данных гораздо меньше, чем те, о которых говорят в бенчмарках. Куда менее очевидно то, насколько быстрее стало привычное нам «железо». Нагрузки, для которых когда-то требовалась распределенная система, теперь могут выполняться на iPhone. Чтобы доказать, что это не преувеличение, я взял и сделал именно это.

В качестве рабочей нагрузки я выбрал TPC-H. TPC-H — это набор из 22 аналитических запросов к базе данных воображаемого оптового поставщика.

TPC-H можно генерировать в разных масштабах. Я хотел выбрать масштаб, репрезентативный для верхней границы реалистичных рабочих нагрузок бизнес-пользователей. Snowflake и Amazon публиковали статистику о реальном распределении объемов запросов, которую мы можем использовать для калибровки нашего бенчмарка. Я запустил тест на 4 масштабах: 25, 50, 100 и 200 ГБ, чтобы приблизиться к верхней границе реального распределения.

Я выполнял запросы на своем телефоне с помощью DuckDB, а также на кластерах Databricks трех разных размеров — XS, S и M — с использованием Databricks Serverless SQL. DuckDB на моем iPhone оказался быстрее кластеров Databricks на всех масштабах, кроме самого крупного, и даже там он показал конкурентоспособный результат.

Это удивительно: даже у самого маленького кластера Databricks больше ядер процессора, чем у iPhone:‍

Этим результатам есть две причины. Во-первых, хотя по меркам реальной бизнес-аналитики эта нагрузка велика, она весьма скромна по сравнению с возможностями современных CPU. Поэтому фиксированные накладные расходы на планирование и компиляцию запросов в этом бенчмарке велики. Архитектура DuckDB отлично оптимизирована для быстрого выполнения небольших запросов.

Во-вторых, DuckDB — это одноузловая база данных, тогда как даже Databricks XS — многоузловая система. При каждом крупном JOIN и GROUP BY Databricks приходится выполнять shuffle (перераспределение данных между узлами):

Если ваш запрос помещается на одном узле, эффективнее избежать этих накладных расходов. Сегодня существует крайне мало запросов, которые не помещаются на одном узле: серия AWS c9 доступна в конфигурациях со 192 ядрами Graviton5.

Самый важный вывод из этого наблюдения касается затрат. Если вы используете такую систему, как Databricks или Snowflake, просто для выполнения SQL-запросов или датафреймов Python на бизнес-данных, вы платите огромную наценку за базовые вычислительные ресурсы.

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

Запуск TPC-H на iPhone — это забавный трюк. Большинство компаний не собираются переходить на iPhone в качестве хранилища данных — хотя, если вы решитесь, я рекомендую положить его на пакет со льдом, иначе вы потеряете около 30% производительности из-за троттлинга.

Этот эксперимент показывает, что реалистичные бизнес-нагрузки не представляют никакой сложности для современных компьютеров. Большинство реальных задач можно запускать на отдельных машинах с использованием таких движков, как DuckDB и Polars, спроектированных так, чтобы извлекать выгоду из эффективности нераспределенного выполнения. Важно отметить: использование одноузлового движка не означает, что вся рабочая нагрузка вашей компании должна выполняться на одной машине. Запросы от множества пользователей можно распределять по множеству воркеров.

Именно так работает наш сервис Lake Compute: у нас есть большой пул рабочих узлов, но каждый рабочий узел обрабатывает только одну модель dbt клиента за раз. Оценить, подходит ли ваша нагрузка для одноузловых движков, несложно: во все основные платформы данных теперь встроена разговорная аналитика, так что просто спросите!

‍«Покажи гистограмму объема данных, считываемых запросами в моем проде хранилища данных, с логарифмической шкалой по оси X, в гигабайтах».

Обещаю, вы будете шокированы тем, насколько малы объемы подавляющего большинства ваших запросов. Мы все используем дорогие распределенные движки выполнения для запросов, которые могли бы работать на iPhone. Способ воспользоваться более дешевыми вычислениями — это переход на новую архитектуру, в которой все участники lakehouse напрямую обращаются к уровню хранения данных.

Внедрять эту архитектуру можно поэтапно, уровень за уровнем.

Настройте инжест на запись в таблицы Iceberg. Если вы используете Fivetran, вы можете воспользоваться нашим процессом миграции Managed Data Lake, чтобы преобразовать существующие таблицы, включая исторические данные, в Iceberg. Существующие таблицы в вашем хранилище данных будут прозрачно переведены во внешние таблицы, так что ваши запросы продолжат работать.
Перенастройте трансформации на вывод в Iceberg. Все основные вычислительные движки поддерживают вывод в Iceberg, так что это в основном вопрос изменения одной настройки. Если вы используете dbt, вы можете применять наш сервис Lake Compute для выполнения моделей dbt. Под капотом он использует DuckDB и одноузловое выполнение.
Перенесите отдельные нагрузки на чтение, такие как блокноты и ad-hoc запросы, на локальные вычисления. Самый дешевый процессор — тот, что стоит у вас на столе!

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

Подробности для воспроизведения этого бенчмарка находятся в github.com/fivetran/iphone_benchmark

[CTA_MODULE]