Поделиться через


Рекомендации по обеспечению эффективности работы

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

1. Оптимизация процессов сборки и выпуска

Создание выделенной группы операций Lakehouse

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

Использование управления исходным кодом Enterprise (SCM)

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

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

Стандартизация процессов DevOps (CI/CD)

Непрерывная интеграция и непрерывная доставка (CI/CD) относится к разработке и развертыванию программного обеспечения в коротких, частых циклах с помощью автоматизированных конвейеров. Хотя это не новый процесс, будучи вездесущим в традиционной программной инженерии в течение десятилетий, он становится все более необходимым процессом для инженерии и обработки и анализа данных команд. Чтобы продукты данных были ценными, они должны быть своевременно доставлены. Кроме того, потребители должны иметь уверенность в действительности результатов в этих продуктах. Автоматив процесс создания, тестирования и развертывания кода, команды разработчиков могут предоставлять выпуски чаще и надежно, чем процессы вручную, которые по-прежнему доминируют во многих командах по проектированию и обработке и анализу данных. Узнайте , что такое CI/CD в Azure Databricks?.

Дополнительные сведения о рекомендациях по разработке кода с помощью папок Databricks Git см. в методах CI/CD с папками Git и Databricks Git (Repos). Вместе с REST API Databricks можно создавать автоматизированные процессы развертывания с помощью действий GitHub, конвейеров Azure DevOps или заданий Jenkins.

Стандартизация процессов MLOps

Процессы MLOps обеспечивают воспроизводимость конвейеров машинного обучения, обеспечивая более тесное взаимодействие между командами данных, уменьшая конфликт с devops и ИТ и ускоряя скорость выпуска. Так как многие модели используются для решения ключевых бизнес-решений, стандартизация процессов MLops гарантирует, что модели разрабатываются, тестируются и развертываются последовательно и надежно.

Создание и развертывание моделей машинного обучения является сложным. Существует множество вариантов, доступных для этого, но мало в том, как хорошо определенные стандарты. В результате за последние несколько лет мы видели появление операций машинного обучения (MLOps). MLOps — это набор процессов и автоматизации для управления моделями, данными и кодом для повышения стабильности производительности и долгосрочной эффективности в системах машинного обучения. Он охватывает подготовку данных, анализ аналитических данных (EDA), проектирование признаков, обучение моделей, проверку модели, развертывание и мониторинг.

MLOps на платформе Databricks поможет оптимизировать производительность и долгосрочную эффективность системы машинного обучения:

  • Всегда помните о ваших бизнес-задачах: так же, как основная цель машинного обучения в бизнесе заключается в том, чтобы принимать решения и продукты, управляемые данными, основной целью MLOps является обеспечение того, чтобы эти приложения, управляемые данными, оставались стабильными, сохранялись в актуальном состоянии и продолжают иметь положительные последствия для бизнеса. При приоритете технической работы в MLOps рассмотрите влияние на бизнес: включает ли он новые варианты использования бизнеса? Улучшает ли она производительность команд данных? Снижает ли она операционные затраты или риски?
  • Управление моделями машинного обучения с помощью специализированного средства, но открытого средства. Вы можете использовать MLflow, предназначенный для жизненного цикла модели машинного обучения, для отслеживания моделей машинного обучения и управления ими. См. MLflow для агента генерации ИИ и жизненного цикла модели машинного обучения.
  • Реализуйте MLOps в модульном режиме: как и в любом программном приложении, качество кода имеет первостепенное значение для приложения машинного обучения. Модульный код позволяет тестировать отдельные компоненты и устранять трудности с последующим рефакторингом кода. Определите четкие шаги (например, обучение, оценка или развертывание), супер-шаги (например, конвейер обучения к развертыванию) и обязанности по уточнению модульной структуры приложения машинного обучения.

Это подробно описано в электронной книге Databricks Большой книги MLOps.

Определение стратегии изоляции среды

Если организация использует платформу данных, например Databricks, часто необходимо иметь границы изоляции данных между средами (например, разработкой и рабочей средой) или между операционными подразделениями.

Стандарты изоляции могут отличаться для вашей организации, но обычно они включают следующие ожидания:

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

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

  • Изолируйте различные бизнес-подразделения с собственными рабочими областями, чтобы избежать совместного использования администратора рабочей области и обеспечить, чтобы ресурсы в Databricks не были совместно совместно использоваться между подразделениями.
  • Изоляция сред жизненного цикла разработки программного обеспечения (таких как разработка, промежуточное развертывание и рабочая среда). Например, отдельная рабочая область позволяет протестировать новые параметры рабочей области перед применением к рабочей среде. Или в рабочей среде могут потребоваться более строгие параметры рабочей области, чем среда разработки. Если необходимо развернуть разработку, промежуточные и рабочие среды в разных виртуальных сетях, вам также нужны разные рабочие области для трех сред.
  • Разделение рабочих областей для преодоления ограничений ресурсов: облачные учетные записи и подписки имеют ограничения ресурсов. Разделение рабочих областей на разные подписки и учетные записи — один из способов обеспечения доступности достаточного количества ресурсов для каждой рабочей области. Кроме того, рабочие области Databricks также имеют ограничения ресурсов. Разделение рабочих областей гарантирует, что нагрузки в каждой рабочей области всегда имеют доступ к полному набору ресурсов.

Однако существуют некоторые недостатки общих рабочих областей, которые также следует учитывать:

  • Совместная работа записных книжек не работает в рабочих областях.

  • Для нескольких рабочих областей необходимо полностью автоматизировать настройку и обслуживание (с помощью Terraform, ARM, REST API или других средств). Это особенно важно для целей миграции.

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

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

Определение стратегии каталога для предприятия

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

Организации может потребоваться, чтобы определенные типы данных хранились в определенных учетных записях или контейнерах в своем облачном клиенте. Хранилище метаданных каталога Unity позволяет структурировать метаданные с помощью трехуровневого пространства имен catalog > schema > tables/views/volumes с расположениями хранения, настроенными на уровне хранилища, каталога или схемы, в соответствии с такими требованиями.

Требования к организации и соответствию часто определяют, что некоторые данные хранятся только в определенных средах. Вы также можете сохранить рабочие данные изолированными от сред разработки или убедиться, что определенные наборы данных и домены никогда не объединяются. В Databricks рабочая область является основной вычислительной средой, а каталоги — основным доменом данных. Используя хранилище метаданных Unity Catalog, администраторы и владельцы каталогов могут привязывать каталоги к конкретным рабочим пространствам. Эти привязки с поддержкой среды помогают обеспечить доступность только определенных каталогов в рабочей области независимо от разрешений конкретного объекта данных, предоставленных пользователю.

Полное обсуждение этих тем см. в разделе лучшие практики каталога Unity

2. Автоматизация развертываний и рабочих нагрузок

Использование инфраструктуры в качестве кода (IaC) для развертываний и обслуживания

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

HashiCorp Terraform — это популярное средство с открытым кодом для создания безопасной и прогнозируемой облачной инфраструктуры для нескольких поставщиков облачных служб. Поставщик Databricks Terraform управляет рабочими областями Azure Databricks и связанной облачной инфраструктурой с помощью гибкого, мощного инструмента. Цель поставщика Databricks Terraform — поддерживать все ИНТЕРФЕЙСы REST API Azure Databricks, поддерживая автоматизацию самых сложных аспектов развертывания и управления платформами данных. Поставщик Databricks Terraform — это рекомендуемое средство для надежного развертывания кластеров и заданий, подготовки рабочих областей Azure Databricks и настройки доступа к данным.

Стандартизация конфигураций вычислений

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

Стандартизация охватывает как настройку среды, так и текущее управление ресурсами. Для согласованной настройки Databricks рекомендует использовать инфраструктуру в качестве кода. Чтобы обеспечить согласованность настройки вычислительных ресурсов с течением времени, используйте политики вычислений. Администраторы рабочей области Databricks могут ограничить привилегии создания вычислительных ресурсов пользователя или группы на основе набора правил политики. Они могут применять параметры конфигурации Spark и применять установки библиотеки с областью действия кластера. Вы также можете использовать политики вычислений для определения кластеров размера футболки (S, M, L) для проектов в качестве стандартной рабочей среды.

Использование автоматизированных рабочих процессов для заданий

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

  • Задания Databricks:

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

    • Задания Databricks — это способ выполнения приложений обработки и аналитики данных в рабочей области Databricks. Задание может быть одной задачей или большим многофакторным рабочим процессом с сложными зависимостями. Databricks управляет оркестрацией задач, управлением кластерами, мониторингом и отчетом об ошибках для всех заданий.
    • Delta Live Tables — это декларативная платформа для создания надежных, поддерживаемых и тестируемых конвейеров обработки данных. Вы определяете преобразования, которые необходимо выполнить для ваших данных, а Delta Live Tables управляет оркестрацией задач, управлением кластерами, мониторингом, качеством данных и обработкой ошибок.
  • Внешние оркестраторы:

    Комплексный REST API Azure Databricks используется внешними оркестраторами для оркестрации ресурсов, записных книжек и заданий Databricks. См.

Мы рекомендуем использовать задания Databricks для всех зависимостей задач в Databricks и (при необходимости) интеграции этих инкапсулированных рабочих процессов во внешний оркестратор

Использование автоматической и управляемой событиями приема файлов

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

Автозагрузчик постепенно и эффективно обрабатывает новые файлы данных по мере их поступления в облачное хранилище. Он может получать множество форматов файлов, таких как JSON, CSV, PARQUET, AVRO, ORC, TEXT и BINARYFILE. При использовании входной папки в облачном хранилище автозагрузчик автоматически обрабатывает новые файлы по мере их поступления.

Для одноуровневых приемов рекомендуется использовать команду COPY INTO .

Использование платформ ETL для конвейеров данных

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

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

С помощью разностных динамических таблиц можно определить сквозные конвейеры данных в SQL или Python: укажите источник данных, логику преобразования и целевое состояние данных. Delta Live Tables поддерживает зависимости и автоматически определяет инфраструктуру, в которой выполняется задание.

Для управления качеством данных Delta Live Tables отслеживает тенденции качества данных с течением времени и предотвращает ввод плохих данных с помощью проверок проверки и целостности с предопределенными политиками ошибок. См. Что такое Delta Live Tables?.

Следуйте подходу к развертыванию кода для рабочих нагрузок машинного обучения

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

  • развернуть код: проект машинного обучения закодирован в среде разработки, и этот код затем перемещается в промежуточную среду, где она тестируется. После успешного тестирования код проекта развертывается в рабочей среде, где она выполняется.
  • развертывание модели: обучение модели выполняется в среде разработки. Затем созданный артефакт модели перемещается в промежуточную среду для проверок модели перед развертыванием модели в рабочей среде.

См . шаблоны развертывания модели.

Databricks рекомендует подход к развертыванию кода для большинства вариантов использования. Основными преимуществами этой модели являются:

  • Это подходит для традиционных рабочих процессов проектирования программного обеспечения, используя знакомые инструменты, такие как системы Git и CI/CD.
  • Она поддерживает автоматическое переобучение в заблокированной среде.
  • Для этого требуется только рабочая среда, чтобы иметь доступ на чтение к данным обучения prod.
  • Он обеспечивает полный контроль над средой обучения, помогая упростить воспроизведение.
  • Она позволяет команде по обработке и анализу данных использовать модульный код и итеративное тестирование, помогая в координации и разработке в более крупных проектах.

Это подробно описано в электронной книге Databricks Большой книги MLOps.

Использование реестра моделей для уменьшения жизненного цикла кода и модели

Так как жизненные циклы модели не соответствуют жизненным циклам кода один к одному, каталог Unity позволяет управлять полным жизненным циклом моделей машинного обучения в размещенной версии реестра моделей MLflow. модели в Unity Catalog расширяют преимущества Unity Catalog до моделей машинного обучения, включая централизованное управление доступом, аудит, наследование и обнаружение моделей в рабочих областях. Модели в каталоге Unity совместимы с клиентом Python с открытым кодом MLflow.

Автоматизация отслеживания экспериментов машинного обучения

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

Автологирование Databricks — это решение без кода, которое расширяет автоматическое ведение журнала MLflow для обеспечения автоматического отслеживания экспериментов для сеансов обучения машинного обучения в Azure Databricks. Автоматическое логирование в Databricks автоматически фиксирует параметры модели, метрики, файлы и сведения о происхождении при обучении моделей, с записями обучающих запусков в качестве запусков отслеживания MLflow.

Повторное использование той же инфраструктуры для управления конвейерами машинного обучения

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

Используйте поставщик Databricks Terraform для автоматизации развертывания сред машинного обучения. Машинное обучение требует развертывания инфраструктуры, например заданий вывода, конечных точек обслуживания и заданий признаков. Все конвейеры машинного обучения могут быть автоматизированы как задания, а многие конвейеры машинного обучения, ориентированные на данные, могут использовать более специализированные Auto Loader для приема изображений и других данных и Delta Live Tables для расчета признаков или мониторинга метрик.

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

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

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

Наборы активов Databricks (DAB) — это средство для упрощения разработки сложных проектов данных, аналитики и машинного обучения для платформы Databricks. Пакеты упрощают управление сложными проектами во время активной разработки, предоставляя возможности CI/CD в рабочем процессе разработки программного обеспечения с помощью одного, краткого и декларативного синтаксиса YAML. С помощью пакетов для автоматизации тестирования, развертывания и управления конфигурацией проекта можно сократить количество ошибок при продвижении рекомендаций по программному обеспечению в организации в качестве шаблонных проектов.

3. Управление емкостью и квотами

Управление ограничениями и квотами служб

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

В частности, для платформы Databricks существуют различные типы ограничений:

Ограничения платформы Databricks: это конкретные ограничения для ресурсов Azure Databricks. Ограничения для общей платформы задокументированы в ограничениях ресурсов.

ограничения каталога Unity :квоты ресурсов каталога Unity

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

Дополнительные сведения см. в разделе "Увеличение квот виртуальных ЦП семейства виртуальных машин".

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

Инвестируйте в планирование емкости

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

  • Ограничения технологий и служб и ограничения облака. См. раздел "Управление емкостью и квотами".
  • Соглашения об уровне обслуживания для определения служб, используемых в проектировании.
  • Анализ затрат, чтобы определить, сколько улучшений в приложении реализуется, если стоимость увеличивается. Оцените, стоит ли цена стоит инвестиций.

Важно понимать и планировать события высокого приоритета (тома). Если подготовленные облачные ресурсы недостаточно и рабочие нагрузки не могут масштабироваться, такие увеличение объема может привести к сбою.

4. Настройка мониторинга, оповещений и ведения журнала

Установка процессов мониторинга

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

Использование собственных и внешних средств для мониторинга платформы

Платформа аналитики данных Databricks имеет встроенные решения для мониторинга и интегрирует внешние системы мониторинга:

  • Мониторинг платформы с помощью решений мониторинга Azure

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

  • Мониторинг Databricks Lakehouse

    Databricks Lakehouse Monitoring позволяет отслеживать статистические свойства и качество данных во всех таблицах в вашей учетной записи. Мониторинг качества данных предоставляет количественные меры для отслеживания и подтверждения согласованности данных с течением времени, а также помогает выявлять и оповещать пользователей о изменениях в распределении данных и производительности модели. Вы также можете отслеживать производительность моделей машинного обучения, отслеживая таблицы вывода, содержащие входные данные модели и прогнозы.

    Сведения о стоимости мониторинга Lakehouse см. в разделе "Просмотр расходов на мониторинг Lakehouse".

  • Мониторинг хранилища SQL

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

  • Оповещения Databricks SQL

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

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

  • Мониторинг автозагрузчика

    Автозагрузчик предоставляет API SQL для проверки состояния потока. С помощью функций SQL можно найти метаданные о файлах, обнаруженных потоком автозагрузчика. См. раздел "Мониторинг автозагрузчика".

    С помощью интерфейса прослушивателя запросов потоковой передачи Apache Spark потоки автозагрузчика можно отслеживать.

  • Мониторинг заданий

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

  • Мониторинг Delta Live Tables

    Журнал событий создается и поддерживается для каждого конвейера Delta Live Tables. Журнал событий содержит все сведения, связанные с конвейером, включая журналы аудита, проверки качества данных, ход конвейера и происхождение данных. Журнал событий можно использовать для отслеживания, понимания и мониторинга состояния конвейеров данных.

  • Мониторинг потоковой передачи

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

  • Мониторинг машинного обучения и искусственного интеллекта

    Мониторинг производительности моделей в рабочих процессах является важным аспектом жизненного цикла модели искусственного интеллекта и машинного обучения. Таблицы вывода результатов упрощают мониторинг и диагностику моделей путем непрерывной фиксации входных данных и ответов (прогнозов) запросов из конечных точек предоставления модели Mosaic AI и сохранения их в таблице Delta в каталоге Unity. Затем можно использовать все возможности платформы Databricks, такие как запросы DBSQL, записные книжки и мониторинг Lakehouse для мониторинга, отладки и оптимизации моделей.

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

  • Мониторинг безопасности

    См. сведения о безопасности, соответствии и конфиденциальности — мониторинг безопасности.

  • Мониторинг затрат

    См. статью "Оптимизация затрат— мониторинг и управление затратами".