5 уроков, извлеченных из тестирования Databricks SQL Serverless + DBT

5 уроков, полученных во время тестирования Databricks SQL Serverless + DBT

Мы провели эксперимент стоимостносй 12 000 долларов США для проверки стоимости и производительности Serverless-складов и dbt с concurrent-потоками и получили неожиданные результаты.

Автор: Джефф Чоу, Стюарт Брайсон

Изображение от Los Muertos Crew

Продукты Databricks’ SQL warehouse являются привлекательным предложением для компаний, стремящихся оптимизировать свои SQL-запросы и склады производства. Однако по мере роста использования стоимость и производительность этих систем становятся критическими для анализа.

В этом блоге мы изучаем стоимость и производительность их serverless SQL warehouse, используя стандартный бенчмарк TPC-DI. Мы надеемся, что инженеры данных и менеджеры платформы данных смогут использовать представленные здесь результаты для принятия более обоснованных решений в отношении своей инфраструктуры данных.

Что предлагают SQL-склады от Databricks’?

Прежде чем мы углубимся в конкретный продукт, давайте шагнем назад и рассмотрим различные варианты, доступные сегодня. Databricks в настоящее время предлагает 3 различных варианта складов:

  • SQL Classic — Самый основной склад, работает в облачной среде клиента
  • SQL Pro — Улучшенная производительность и хорошо подходит для исследовательской работы с данными, работает в облачной среде клиента
  • SQL Serverless — «Лучшая» производительность, вычисления полностью управляются Databricks.

С точки зрения стоимости, и классический, и Pro работают в облачной среде пользователя. Это означает, что вы получите две счета за использование Databricks — один за чистую стоимость Databricks (DBU) и другой от вашего облачного провайдера (например, счет AWS EC2).

Для более полного понимания сравнения стоимости давайте рассмотрим пример разбивки стоимости работы на складе Small на основе их указанных типов экземпляров:

Сравнение стоимости вычислений заданий и различных вариантов SQL Serverless. Показанные цены основаны на отказоустойчивых прайс-листах. Цены для вариантов с прерывистыми соединениями могут быть другими и были выбраны на момент публикации. Изображение от автора.

В таблице выше мы также рассмотрели сравнение стоимости для запрашиваемых и прерывистых соединений. Из таблицы видно, что вариант serverless не имеет облачной составляющей, потому что все управляется Databricks.

Serverless может быть экономически выгодным по сравнению с Pro, если вы используете все запросы динамической выделенности. Однако, если доступны дешевые прерывистые узлы, то Pro может быть дешевле. В общем, цена на serverless, на мой взгляд, достаточно разумная, так как она также включает облачные затраты, хотя она по-прежнему является «премиальной» ценой.

Мы также включили эквивалентный вычислительный кластер для заданий, который является самым дешевым вариантом в общем сравнении. Если вас беспокоит стоимость, то вы также можете выполнять SQL-запросы в заданиях на вычислительном кластере!

Преимущества и недостатки Serverless

Опция Databricks serverless — это полностью управляемая вычислительная платформа. Это практически идентично тому, как работает Snowflake, где все детали вычислений скрыты от пользователей. В общих словах, это имеет свои преимущества и недостатки:

Плюсы:

  • Вам не нужно думать о экземплярах или конфигурациях
  • Время запуска значительно меньше, чем если бы вы запускали кластер с нуля (по нашим наблюдениям, занимает 5-10 секунд)

Минусы:

  • У предприятий может быть проблемы с безопасностью, так как все вычисления выполняются внутри Databricks
  • Предприятия могут не иметь возможности использовать преимущества своих облачных контрактов, которые могут предоставлять специальные скидки на определенные экземпляры
  • Нет возможности оптимизировать кластер, поэтому вы не знаете, насколько хорошо выбраны Databricks экземпляры и конфигурации для вашей работы
  • Databricks является “черным ящиком”, пользователи не знают, что происходит или какие изменения реализуются Databricks, что может вызвать проблемы стабильности

В связи с врожденной непрозрачностью серверного режима, нас интересовало исследовать различные настраиваемые параметры, влияющие на производительность. Давайте рассмотрим, что мы исследовали:

Настройка эксперимента

Мы постарались подойти к изучению с практической точки зрения и имитировать то, что реальная компания могла бы сделать, когда они хотят запустить SQL-склад. Поскольку DBT является таким популярным инструментом в современном стеке данных, мы решили рассмотреть 2 параметра для просмотра и оценки:

  • Размер склада — [‘2X-Small’, ‘X-Small’, ‘Small’, ‘VoAGI’, ‘Large’, ‘X-Large’, ‘2X-Large’, ‘3X-Large’, ‘4X-Large’]
  • Потоки DBT — [‘4’, ‘8’, ’16’, ’24’, ’32’, ’40’, ’48’]

Причина, по которой мы выбрали именно эти два параметра, заключается в том, что они являются “универсальными” настраиваемыми параметрами для любой рабочей нагрузки, и оба они влияют на сторону вычислений задачи. Потоки DBT в особенности позволяют настроить параллелизм выполнения задач при пересчете DAG.

Мы выбрали популярный бенчмарк TPC-DI с коэффициентом масштабирования 1000. Этот бенчмарк представляет собой полноценную модель трубопровода, имитирующую более реалистичные рабочие нагрузки с данными. Например, ниже приведен скриншот нашего DAG DBT, который показывает его сложность, и изменение числа потоков DBT может повлиять на производительность.

DBT DAG from our TPC-DI Benchmark, Image by author

Кстати, у Databricks есть замечательный открытый репозиторий, который поможет быстро установить бенчмарк TPC-DI в Databricks целиком (мы не использовали его, так как работаем с DBT).

Чтобы погрузиться в детали того, как мы проводили эксперимент, мы использовали Databricks Workflows с типом задачи dbt в качестве “запускающей системы” для dbt CLI, и все задачи выполнялись одновременно; не должно быть никаких отклонений из-за неизвестных условий в среде Databricks.

Каждая задача запускала новый SQL-склад и закрывала его после выполнения, работая с уникальными схемами в той же Unity Catalog. Мы использовали пакет Elementary dbt package для сбора результатов выполнения и запускали Python-ноутбук в конце каждого запуска для сбора этих метрик в централизованной схеме.

Стоимость извлекалась с помощью системных таблиц Databricks, в частности, таблиц Billable Usage.

Попробуйте этот эксперимент самостоятельно и клонируйте репозиторий на Github здесь

Результаты

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

Для энтузиастов CS это всего лишь основной принцип CS – Закон Амдаля.

Один необычный наблюдение заключается в том, что склад VoAGI превосходил следующие 3 больших размера (от большого до 2xlarge). Мы несколько раз повторяли эту определенную точку данных и получали последовательные результаты, поэтому это не странное совпадение. Из-за черного ящика, свойственного serverless, к сожалению, мы не знаем, что происходит “под капотом” и не можем дать объяснения.

Время выполнения в минутах в разных размерах склада. Изображение автора

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

Стоимость в $ в разных размерах склада. Изображение автора

На графике ниже показано относительное изменение времени выполнения при изменении числа потоков и размера склада. Значения выше горизонтальной нулевой линии означают увеличение времени выполнения (это плохо).

Процентное изменение времени выполнения при увеличении потоков. Изображение автора

Данные здесь немного шумные, но есть несколько интересных выводов, основанных на размере склада:

  • 2x-small – Повышение числа потоков обычно приводило к увеличению времени выполнения задания.
  • От x-small до large – Увеличение числа потоков обычно помогало ускорить выполнение задания примерно на 10%, хотя прирост был довольно незначительным, поэтому дальнейшее увеличение числа потоков не имело ценности.
  • 2x-large – Существует оптимальное число потоков, равное 24.
  • 3x-large – Выявлена очень необычная вспышка времени выполнения с числом потоков 8. Почему? Неизвестно.

Чтобы объединить все в один комплексный график, мы можем увидеть диаграмму ниже, которая отображает стоимость по отношению к длительности всей работы. Различные цвета представляют различные размеры склада, а размер пузырей – количество потоков DBT.

Стоимость по сравнению с длительностью работы. Размер пузырей представляет количество потоков. Изображение автора

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

  • VoAGI – лучший – С точки зрения стоимости и времени выполнения, VoAGI является лучшим выбором склада.
  • Влияние потоков DBT – Для маленьких складов изменение числа потоков, похоже, меняло длительность примерно на +/- 10%, но почти не влияло на стоимость. Для больших складов число потоков существенно влияло на стоимость и время выполнения.

Вывод

В заключение, наши 5 основных уроков изучения Databricks SQL serverless + продуктов DBT:

  1. Правила-признаки плохи – Нельзя просто полагаться на «правила-признаки» относительно размера склада или числа потоков dbt. Некоторые ожидаемые тенденции существуют, но они не постоянны и непредсказуемы, и все зависит от вашей рабочей нагрузки и данных.
  2. Огромный разброс – Для одной и той же рабочей нагрузки затраты колебались от 5 до 45 долларов, а время выполнения – от 2 до 90 минут, всё из-за различных комбинаций числа потоков и размера склада.
  3. Ограничения масштабирования – Serverless склады не масштабируются бесконечно, и в конечном итоге более крупные склады перестают обеспечивать ускорение, а только увеличивают затраты без преимущества.
  4. VoAGI – отличный выбор? – Мы обнаружили, что серверный SQL-склад VoAGI превосходит многие более крупные размеры складов как по стоимости, так и по длительности работы в бенчмарке TPC-DI. У нас нет ни малейшего понятия, почему.
  5. Кластеры заданий могут быть более дешевыми – Если стоимость является проблемой, переход на компьютерное задание с записями может быть значительно дешевле.

В данном отчете сообщается, что работа чёрного ящика в системах “без сервера” может привести к некоторым необычным аномалиям. Поскольку всё это происходит за стенами Databricks, мы не знаем, что происходит на самом деле. Возможно, всё это запускается на огромных кластерах Spark на Kubernetes, а может быть, у них есть специальные соглашения с Amazon по определенным экземплярам? В любом случае, непредсказуемость делает управление затратами и производительностью затруднительным.

Поскольку каждая рабочая нагрузка уникальна в таком множестве измерений, нельзя полагаться на “правила приближенного определения” или дорогостоящие эксперименты, которые справедливы только для текущего состояния нагрузки. Более хаотичная природа систем без сервера поднимает вопрос, нужна ли этим системам система управления с обратной связью, чтобы их держать в узде?

Как заметка для размышлений – бизнес-модель систем без сервера действительно привлекательна. Предполагая, что Databricks – разумный бизнес и не хочет снизить свои доходы, а хочет снизить свои затраты, нужно задаться вопросом: “Получает ли Databricks стимулы для улучшения вычислений внутри системы?

Проблема в том, что если они сделают систему без сервера в 2 раза быстрее, то сразу же их доход от системы без сервера снизится на 50% – это очень плохой день для Databricks. Если бы они могли ускорить ее в 2 раза, а затем увеличить стоимость DBU в 2 раза, чтобы компенсировать ускорение, тогда они оставались бы прибыльными (это то, что они сделали на самом деле для Photon).

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

Вас интересует узнать больше о том, как улучшить свои конвейеры Databricks? Свяжитесь с Джеффом Чоу и остальной командой Sync.

Ресурсы

  • Попробуйте этот эксперимент самостоятельно и клонируйте репозиторий Github здесь