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

Рекомендации по надежности

  • Статья

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

1. Проектирование сбоя

Использование формата данных, поддерживающего транзакции ACID

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

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

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

Apache Spark, как вычислительный модуль озера Azure Databricks, основан на устойчивой распределенной обработке данных. Если внутренняя задача Spark не возвращает ожидаемый результат, Apache Spark автоматически перепланирует отсутствующие задачи и продолжает выполнять все задание. Это полезно для сбоев вне кода, таких как краткая сетевая проблема или отозванная виртуальная машина. Работая как с API SQL, так и с API Кадра данных Spark, эта устойчивость встроена в подсистему.

В Databricks lakehouse, Photon, машинный векторизованный модуль полностью написан на C++, является высокопроизводительными вычислениями, совместимыми с API Apache Spark.

Автоматическое спасение недопустимых или несообразующих данных

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

  • Автозагрузчик Databricks:автозагрузчик — идеальное средство для потоковой передачи приема файлов. Он поддерживает спасаемые данные для JSON и CSV. Например, в формате JSON спасательный столбец данных содержит все данные, которые не были проанализированы, возможно, из-за отсутствия в данной схеме несоответствия типов или из-за несоответствия типа столбца. Столбец восстановленных данных является частью схемы, возвращаемой Автозагрузчиком как _rescued_data по умолчанию при выводе схемы.
  • Разностные динамические таблицы: другой вариант создания рабочих процессов для устойчивости — использовать разностные динамические таблицы с ограничениями качества. См. Управление качеством данных с использованием ожиданий конвейера. Delta Live Tables поддерживают три режима по умолчанию: сохранение, удаление и ошибка при недопустимых записях. Для карантина идентифицированных недопустимых записей правила ожидания можно определить определенным образом, чтобы недопустимые записи хранились ("карантин") в другой таблице. См. недопустимые записи в карантине.

Настройка заданий для автоматических повторных попыток и завершения

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

  • Задания Azure Databricks поддерживают политики повторных попыток для задач, определяющих время и количество неудачных запусков. См. раздел "Настройка политики повторных попыток".
  • Можно настроить необязательные пороговые значения длительности для задачи, включая ожидаемое время завершения для задачи и максимальное время завершения для задачи.
  • Delta Live Tables также автоматизирует восстановление сбоев с помощью эскалации повторных попыток для балансировки скорости и надежности. См. раздел Режим разработки и рабочий режим.

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

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

Для вывода пакетной и потоковой передачи используйте задания Azure Databricks и MLflow для развертывания моделей в качестве определяемых пользователем функций Apache Spark для использования планирования заданий, повторных попыток, автомасштабирования и т. д. Ознакомьтесь с моделями развертывания для пакетного вывода и прогнозирования.

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

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

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

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

2. Управление качеством данных

Использование многоуровневой архитектуры хранилища

Курировать данные путем создания многоуровневой архитектуры и обеспечения повышения качества данных по мере перемещения данных через слои. Распространенный подход к наслоениям:

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

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

Повышение целостности данных путем снижения избыточности данных

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

Временная или удаляемая копия данных сама по себе не вредна — иногда необходимо повысить гибкость, экспериментирование и инновации. Однако, когда эти копии становятся операционными и регулярно используются для принятия бизнес-решений, они становятся хранилищами данных. Когда эти серверы данных становятся не синхронизированными, она оказывает значительное негативное влияние на целостность и качество данных, что приводит к таким вопросам, как "Какой набор данных является главным?" или "Текущий набор данных?

Активное управление схемами

Неконтролируемые изменения схемы могут привести к недопустимым данным и неудачным заданиям, которые используют эти наборы данных. Azure Databricks имеет несколько методов для проверки и применения схемы:

  • Delta Lake поддерживает проверку схемы и принудительное применение схемы путем автоматической обработки вариантов схемы, чтобы предотвратить вставку плохих записей во время приема. См. сведения о принудительном применении схемы.
  • Автозагрузчик обнаруживает добавление новых столбцов при обработке данных. По умолчанию добавление нового столбца приводит к остановке потоков с помощью UnknownFieldException. Автозагрузчик поддерживает несколько режимов для эволюции схемы.

Использование ограничений и ожиданий данных

Разностные таблицы поддерживают стандартные предложения управления ограничениями SQL, которые обеспечивают автоматическую проверку качества и целостности данных, добавленных в таблицу. При нарушении ограничения Delta Lake выдает ошибку InvariantViolationException , чтобы сообщить о том, что новые данные не могут быть добавлены. См . ограничения в Azure Databricks.

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

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

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

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

3. Проектирование автомасштабирования

Включение автомасштабирования для рабочих нагрузок ETL

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

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

Включение автомасштабирования для хранилища SQL

Параметр масштабирования хранилища SQL задает минимальное и максимальное количество кластеров, по которым распределяются запросы, отправляемые в хранилище. Значение по умолчанию — один кластер без автомасштабирования.

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

4. Тестирование процедур восстановления

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

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

Восстановление заданий ETL с помощью возможностей перемещения данных

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

Это удобный способ сделать RESTORE это — команда.

Использование платформы автоматизации заданий с встроенным восстановлением

Задания Databricks предназначены для восстановления. Если задача в многозадачном задании терпит неудачу (и, следовательно, все зависимые задачи), задания Azure Databricks предоставляют матричное представление запусков, которое позволяет разобраться в проблеме, вызвавшей сбой. См. статью Просмотр запусков для одного задания. Будь то короткая сетевая проблема или реальная проблема в данных, ее можно исправить и запустить восстановление в заданиях Azure Databricks. Он будет выполнять только неудачные и зависимые задачи и сохранить успешные результаты из предыдущего запуска, экономии времени и денег, см. статью "Устранение неполадок и восстановление сбоев заданий"

Настройка шаблона аварийного восстановления

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

Azure Databricks часто является основной частью общей экосистемы данных, которая включает в себя множество служб, включая службы приема данных вышестоящей передачи (пакетная или потоковая передача), облачное хранилище, например Azure Data Lake Storage 2-го поколения, подчиненные инструменты и службы, такие как приложения бизнес-аналитики и средства оркестрации. Некоторые варианты использования могут быть особенно чувствительны к сбоям региональной службы.

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

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

См. статью "Операционное превосходство— автоматизация развертываний и рабочих нагрузок".

6. Мониторинг систем и рабочих нагрузок

См. статью "Операционное превосходство" — настройка мониторинга, оповещения и ведение журнала.