Оптимизация и устранение неполадок моделей dbt на Databricks

Обновлен

Databricks

dbt Core

dbt Cloud

Intermediate

Menu

Введение

Продолжая Настройка вашего проекта dbt с Databricks, мы хотели бы обсудить оптимизацию производительности. В этом последующем посте мы описываем простые стратегии оптимизации затрат, производительности и простоты при проектировании конвейеров данных. Мы объединили эти стратегии в акроним:

• Компоненты платформы
• Шаблоны и лучшие практики
• Устранение неполадок производительности

Компоненты платформы

Когда вы начинаете разрабатывать свои проекты dbt, одним из первых решений, которое вам предстоит принять, будет выбор типа инфраструктуры, на которой будут выполняться ваши модели. Databricks предлагает SQL-склады, All-Purpose Compute и Jobs Compute, каждый из которых оптимизирован для соответствующих рабочих нагрузок. Мы рекомендуем использовать SQL-склады Databricks для всех ваших SQL-нагрузок. SQL-склады оптимизированы для SQL-нагрузок по сравнению с другими вариантами вычислений, кроме того, они могут масштабироваться как вертикально для поддержки больших нагрузок, так и горизонтально для поддержки параллельности. Также SQL-склады проще в управлении и предоставляют готовые функции, такие как история запросов, для помощи в аудите и оптимизации ваших SQL-нагрузок. Среди типов SQL-складов Serverless, Pro и Classic, которые предлагает Databricks, наша стандартная рекомендация для вас — использовать серверные склады Databricks. Вы можете изучить функции этих типов складов в разделе Сравнение функций на странице цен Databricks.

С серверными складами вы значительно уменьшаете время ожидания запуска кластера и время масштабирования, когда вашему кластеру необходимо горизонтальное масштабирование. Это снижает необходимость держать кластеры в режиме ожидания, так как серверные склады быстро запускаются, когда начинается рабочая нагрузка, и затем останавливаются, когда рабочая нагрузка завершена. Кроме того, серверные склады используют наш движок Photon из коробки для оптимальной производительности как в ELT, так и в рабочих нагрузках обслуживания.

Следующим шагом будет решение о размере вашего серверного SQL-склада. Это не точная наука, но эти подразделы предоставят вам несколько быстрых советов, которые приведут к значительным улучшениям производительности.

Определение размера ваших SQL-складов

Чтобы выбрать подходящий размер вашего SQL-склада, учитывайте случай использования и рабочую нагрузку, которую вы выполняете, и соответствующие требования к задержке. Вы можете выбрать размер на основе объема данных и автоматического масштабирования в зависимости от потребностей в параллельности. Хорошее правило — начать с Medium склада и двигаться оттуда. Для больших и сложных рабочих нагрузок более крупные склады — это правильный путь, и это не обязательно означает более высокие затраты. Это потому, что более крупные склады выполняют единицу работы за более короткое время. Например, если Small склад выполняет конвейер за час, то Medium склад выполнит его за полчаса. Эта линейная тенденция продолжается, пока есть достаточно работы для склада.

Предоставление складов по рабочей нагрузке

Еще одна техника, которую стоит внедрить, — это предоставление отдельных SQL-складов для построения конвейеров dbt вместо ad hoc, интерактивного SQL-анализа. Это связано с тем, что шаблоны проектирования запросов и использование вычислений различны для этих двух типов рабочих нагрузок. Выбирайте размеры на основе объемов данных и SLA (принцип масштабирования вверх), и выбирайте автоматическое масштабирование на основе требований к параллельности (принцип масштабирования наружу). Для более крупных развертываний этот подход можно расширить, чтобы сопоставить различные размеры рабочих нагрузок с несколькими "конвейерными" складами, если это необходимо. На стороне dbt учитывайте количество потоков, которые у вас есть, то есть сколько моделей dbt вы можете запускать параллельно. Чем больше количество потоков, тем больше вычислительных ресурсов вам потребуется.

Настройка автоостановки

Благодаря способности серверных складов запускаться за считанные секунды, установка конфигурации автоостановки на более низкий порог не повлияет на SLA и опыт конечного пользователя. В интерфейсе SQL Workspace значение по умолчанию составляет 10 минут, и вы можете установить его на 5 минут для более низкого порога с помощью интерфейса. Если вы хотите более настраиваемые параметры, вы можете установить порог до 1 минуты с помощью API.

Шаблоны и лучшие практики

Теперь, когда у нас есть четкое представление о компонентах инфраструктуры, мы можем переключить наше внимание на лучшие практики и шаблоны проектирования при разработке конвейеров. Мы рекомендуем подход staging/intermediate/mart, который аналогичен архитектуре медальонов bronze/silver/gold, рекомендованной Databricks. Давайте разберем каждый этап подробнее.

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

Бронзовый / Слой подготовки:

Существует несколько различных вариантов материализации бронзовых таблиц delta на Databricks. В рекомендуемом рабочем процессе dbt вы должны сначала загрузить ваши плоские файлы в таблицу, прежде чем использовать dbt для их преобразования. Для этого вы можете использовать инструмент EL для обработки этого процесса загрузки.

Однако мы знаем, что это не всегда возможно, поэтому для наборов данных в облачном хранилище мы рекомендуем использовать нашу функцию COPY INTO или подготовить внешнюю таблицу. Что касается подхода COPY INTO, у вас будет несколько различных вариантов. Первый вариант — запустить логику COPY INTO как pre-hook перед построением ваших серебряных/промежуточных моделей. Второй вариант — вызвать макрос databricks COPY INTO с помощью dbt run-operation, а затем выполнить ваши запуски моделей. Вы можете увидеть пример реализации макроса COPY INTO в документации dbt-databricks.

Основное преимущество использования COPY INTO заключается в том, что это инкрементная операция, и она гарантирует, что данные записываются в формате Delta (когда мы говорим о Delta, мы просто имеем в виду открытые таблицы Parquet с журналом транзакций). Если вы вместо этого решите подготовить внешнюю таблицу, бронзовая таблица сохраняет свою исходную структуру (будь то CSV, Parquet, JSON и т.д.). Это предотвратит возможность использования преимуществ производительности, надежности и управления, присущих Delta. Более того, внешние таблицы Parquet требуют дополнительной ручной работы, такой как выполнение операций восстановления, чтобы гарантировать, что новая метадата разделов учтена. Тем не менее, подготовка внешних таблиц может быть приемлемым вариантом, если вы мигрируете на Databricks из другой облачной системы хранения данных, где вы активно использовали эту функциональность.

Серебряный / Промежуточный слой

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

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

dbt имеет инкрементную материализацию моделей для облегчения этой структуры. Как это работает на высоком уровне: Databricks создаст временное представление со снимком данных, а затем объединит этот снимок в серебряную таблицу. Вы можете настроить временной диапазон снимка в соответствии с вашим конкретным случаем использования, настроив условие where в вашей логике is_incremental. Наиболее простая реализация заключается в объединении данных, используя временную метку, которая позже текущей максимальной временной метки в серебряной таблице, но, безусловно, существуют обоснованные случаи увеличения временного диапазона исходного снимка.

Хотя объединение должно быть достаточно производительным из коробки, если у вас особенно жесткие SLA, существуют более продвинутые методы настройки, которые вы можете включить в вашу логику. Давайте обсудим несколько примеров подробнее.

Компактация файлов

Большинство вычислительных движков работают лучше всего, когда размеры файлов находятся в диапазоне от 32 МБ до 256 МБ. В Databricks мы заботимся об оптимальном размере файлов под капотом с помощью наших функций автооптимизации. Автооптимизация состоит из двух различных функций: авто-компактации и оптимизированных записей. В SQL-складах Databricks оптимизированные записи включены по умолчанию. Мы рекомендуем вам включить авто-компактацию.

Пропуск данных

Под капотом Databricks естественным образом кластеризует данные на основе времени их загрузки. Поскольку многие запросы включают временные метки в условиях where, это естественным образом приводит к большому количеству пропуска файлов для повышения производительности. Тем не менее, если у вас есть другие столбцы с высокой кардинальностью (в основном столбцы с большим количеством уникальных значений, такие как столбцы id), которые часто используются в ключах join или условиях where, производительность обычно можно дополнительно улучшить, используя Z-order.

Синтаксис SQL для команды Z-Order: OPTIMIZE table_name ZORDER BY (col1,col2,col3,etc). Одно предостережение, о котором следует помнить, заключается в том, что вы редко захотите использовать Z-Order более чем по трем столбцам. Вы, вероятно, захотите либо запускать Z-order в конце выполнения после построения вашей модели, либо запускать Z-Order как отдельную запланированную задачу с постоянной периодичностью, будь то ежедневно, еженедельно или ежемесячно.

config(

materialized='incremental',

zorder="column_A" | ["column_A", "column_B"]

)

Анализ таблицы

Команда ANALYZE TABLE гарантирует, что наша система имеет самые актуальные статистические данные для выбора оптимального плана объединения. Вы, вероятно, захотите либо запускать анализ таблицы как posthook после построения вашей модели, либо запускать анализ таблицы как отдельную запланированную задачу dbt с постоянной периодичностью, будь то ежедневно, еженедельно или ежемесячно. Синтаксис SQL для этого:

ANALYZE TABLE mytable COMPUTE STATISTICS FOR

COLUMNS col1, col2, col3

Важно уточнить, что вы захотите приоритизировать статистику для столбцов, которые часто используются в объединениях.

Удаление

Когда вы удаляете запись из таблицы Delta, это мягкое удаление. Это означает, что запись удаляется из журнала транзакций и не включается в последующие запросы, но основной файл все еще остается в облачном хранилище. Если вы хотите удалить основные файлы (будь то для снижения стоимости хранения или улучшения производительности при объединениях), вы можете выполнить команду vacuum. Фактор, о котором вы должны быть очень внимательны, — это восстановление старых версий таблицы. Допустим, вы выполняете vacuum таблицы, чтобы удалить все неиспользуемые файлы, которые старше 7 дней. Вы не сможете восстановить версии таблицы, которые старше 7 дней и зависят от этих удаленных файлов, поэтому используйте с осторожностью. Если/когда вы решите использовать vacuum, вы, вероятно, захотите запускать vacuum, используя функциональность dbt on-run-end после построения вашей модели или запускать vacuum как отдельную запланированную задачу dbt с постоянной периодичностью (будь то ежедневно, еженедельно или ежемесячно) с использованием команды dbt run-operation (с заявлением vacuum в макросе).

Золотой / Слой витрин

Теперь перейдем к самому последнему слою — золотым витринам, с которыми бизнес-стейкхолдеры обычно взаимодействуют через свои предпочитаемые BI-инструменты. Соображения здесь будут довольно похожи на серебряный слой, за исключением того, что эти витрины более вероятно будут обрабатывать агрегации. Более того, вы, вероятно, захотите быть еще более намеренными в отношении Z-Ordering этих таблиц, так как SLA, как правило, ниже с этими таблицами, ориентированными на прямых стейкхолдеров.

Кроме того, эти таблицы хорошо подходят для определения метрик, чтобы обеспечить простоту и согласованность ваших ключевых бизнес KPI! Используя MetricFlow, вы даже можете запрашивать метрики внутри вашего собственного проекта dbt. С предстоящей интеграцией семантического слоя вы также сможете запрашивать метрики в любом из интегрированных инструментов партнеров.

Фильтрация строк в целевом и/или исходном

Это можно сделать с помощью incremental_predicates, как в этом примере:

{{

config(

materialized='incremental',

incremental_strategy = 'merge',

unique_key = 'id',

incremental_predicates = [

"dbt_internal_target.create_at >= '2023-01-01'",	"dbt_internal_source.create_at >= '2023-01-01'"],

)

}}

Устранение неполадок производительности

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

Профиль запроса SQL-склада

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

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

Три общих примера узких мест производительности, которые могут быть выявлены профилем запроса:

Неэффективное обрезание файлов

По умолчанию таблицы Databricks Delta собирают статистику по первым 32 столбцам, определенным в вашей схеме таблицы. При преобразовании данных из бронзового/подготовительного слоя в серебряный/промежуточный слой рекомендуется переупорядочить ваши столбцы, чтобы учесть эти статистические данные на уровне файлов и улучшить общую производительность. Переместите числовые ключи и высококардинальные предикаты запросов влево от 32-й позиции, и переместите строки и сложные типы данных после 32-й позиции таблицы. Стоит упомянуть, что хотя вы можете изменить свойство таблицы по умолчанию, чтобы собирать статистику по большему количеству столбцов, это добавит больше накладных расходов при записи файлов. Вы можете изменить это значение по умолчанию, используя свойство таблицы, delta.dataSkippingNumIndexedCols.

Полные сканирования таблиц

Профиль запроса предоставляет метрики, которые позволяют вам определить наличие полных сканирований таблиц. Полное сканирование таблицы — это операция запроса, которая включает сканирование всей таблицы для извлечения записей. Это может быть проблемой производительности, особенно для больших таблиц с миллиардами или триллионами строк. Это связано с тем, что сканирование всей таблицы может быть времязатратным и ресурсоемким, что приводит к высокому использованию памяти и ЦП и более медленным временам отклика. Техники компоновки таблиц, такие как компактация файлов и Z-Ordering, описанные в предыдущем разделе этой статьи, помогут решить эту проблему.

Взрывающиеся объединения

Концепция взрывающихся объединений относится к операции join, которая производит гораздо больший набор результатов таблицы, чем любая из входных таблиц, используемых, что приводит к декартовому произведению. Эта проблема производительности может быть определена путем включения настройки режима verbose в профиле запроса, путем просмотра количества записей, произведенных оператором объединения. Существует несколько шагов, которые вы можете предпринять, чтобы предотвратить взрывающиеся объединения. В качестве первого шага сделайте условия объединения более специфичными, чтобы уменьшить количество строк, которые сопоставляются. Другим шагом является использование техник предварительной обработки данных, таких как агрегация, фильтрация и выполнение выборки данных перед операцией объединения. Эти техники могут уменьшить размер входных таблиц и помочь предотвратить взрывающиеся объединения.

Лучшие практики материализации

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

Databricks стремится постоянно улучшать свою производительность. Например, в Delta и DBSQL мы недавно значительно улучшили производительность операций MERGE с помощью low-shuffle merge и Photon. С множеством будущих реализаций в разработке, таких как векторы удаления для эффективных удалений и вставок. Вот основные стратегии для ускорения:

1. Читайте только важные разделы, применяя фильтры для сканирования источника и цели, используя фильтры в модели и incremental_predicates
2. Обновляйте только важные строки
3. Улучшите поиск ключей, определив только один материализованный ключ
4. Обновляйте только важные столбцы

API обнаружения dbt Cloud

Теперь вы можете задаться вопросом, как определить возможности для улучшения производительности внутри dbt? Что ж, с каждым запуском задания dbt Cloud генерирует метаданные о времени, конфигурации и свежести моделей в вашем проекте dbt. API обнаружения dbt — это служба GraphQL, которая поддерживает запросы на эти метаданные, используя графический исследователь или сам конечный пункт. Команды могут передавать эти данные в свой склад данных и анализировать их, как любой другой источник данных в платформе бизнес-аналитики. Пользователи dbt Cloud также могут использовать данные из вкладки времени модели, чтобы визуально определить модели, которые занимают больше всего времени и могут потребовать рефакторинга.

API администратора dbt Cloud

С помощью API администратора dbt Cloud вы можете извлечь артефакты dbt из вашего запуска dbt Cloud, поместить сгенерированный manifest.json в корзину S3, подготовить его и смоделировать данные, используя пакет артефактов dbt. Этот пакет может помочь вам выявить неэффективности в ваших моделях dbt и определить, где есть возможности для улучшения.

Заключение

Это основывается на содержании Настройка вашего проекта dbt с Databricks.

Мы приглашаем вас попробовать эти стратегии на нашем примере реализации TPC-H с открытым исходным кодом и предоставить нам свои мысли/обратную связь, когда вы начнете внедрять эти функции в производство. Ждем ваших отзывов в канале Slack #db-databricks-and-spark!