Основные рекомендации по Azure Data Lake Storage

  • Статья

Узнайте о ключевых рекомендациях по хранилищу данных Azure.

Управление жизненным циклом

служба хранилища Azure предлагает различные уровни доступа, что позволяет хранить данные объектов BLOB-объектов самым экономичным способом. Ниже перечислены возможные уровни доступа.

  • Горячий уровень оптимизирован для хранения часто используемых данных.
  • Прохладно: оптимизировано для хранения данных, которые редко обращаются. Данные хранятся не менее 30 дней.
  • Холодный уровень: оптимизирован для хранения данных, которые редко обращаются или изменяются. Данные хранятся не менее 90 дней. На холодном уровне хранилища данные хранить дешевле, зато доступ к ним стоит дороже по сравнению с горячим уровнем.
  • Архивный уровень оптимизирован для хранения данных, которые используются редко. Данные хранятся не менее 180 дней. Требования к задержке для таких данных нестрогие (порядка нескольких часов).

Внимание

Нет компромиссов надежности, безопасности, операционного превосходства или эффективности производительности между различными уровнями доступа в Интернете, что оставляет выбор онлайн-уровня финансовым решением для каждого большого двоичного объекта на основе размера данных доступа к рабочей нагрузке, операционного взаимодействия и времени перед удалением большого двоичного объекта. Выберите правильный уровень для каждого большого двоичного объекта на основе вычисления предыдущих факторов. Дополнительные сведения см. в разделе "Планирование затрат и управление затратами на Хранилище BLOB-объектов Azure".

При использовании уровней доступа следует учитывать следующие сведения:

  • На уровне учетной записи можно задать только уровни горячего и холодного доступа. Уровень доступа к архиву недоступен на уровне учетной записи.

  • Горячие, холодные и архивные уровни можно задать на уровне БОЛЬШОго двоичного объекта во время отправки или после отправки.

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

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

Дополнительные сведения см. в разделе "Уровни доступа" для данных BLOB-объектов.

Внимание

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

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

Возможность подключения к озера данных

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

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

Внимание

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

Обратимое удаление для контейнеров

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

Включите следующие функции защиты данных, чтобы обеспечить сквозную защиту данных BLOB-объектов:

Предупреждение

Удаление учетной записи хранения невозможно отменить. Обратимое удаление контейнера не защищает от удаления учетной записи хранения только от удаления контейнеров в учетной записи. Чтобы защитить учетную запись хранения от удаления, настройте блокировку для ресурса учетной записи хранения. Дополнительные сведения о блокировке ресурсов Azure Resource Manager см. в статье Блокировка ресурсов для предотвращения непредвиденных изменений.

Наблюдение

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

Дополнительные сведения об использовании данных мониторинга служба хранилища Azure см. в статье "Мониторинг ресурсов Azure" с помощью Azure Monitor. Дополнительные сведения о журналах и метриках, служба хранилища Azure создания, см. в разделе "Мониторинг Хранилище BLOB-объектов Azure".

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

  • Успешные запросы
  • Неудачные запросы, в том числе из-за ошибок, связанных со временем ожидания, регулированием, сетью, авторизацией и т. п.
  • Запросы, в которых используется подписанный URL-адрес (SAS) или OAuth, в том числе неудачные и успешные запросы.
  • Запросы к аналитическим данным, таким как классические данные журнала в контейнере $logs и данные метрик класса в $metric таблицах

Запросы, выполненные самой службой хранилища, например создание или удаление журнала, не регистрируются. Регистрируются анонимные запросы следующих типов:

  • Успешные запросы
  • Ошибки сервера.
  • Ошибки времени ожидания для клиента и сервера.
  • Неудачные HTTP-запросы GET с кодом ошибки 304 (Not Modified)

Остальные неудачные анонимные запросы не регистрируются.

Внимание

Задайте политику мониторинга по умолчанию для аудита хранилища и отправки журналов в подписку управления корпоративного масштаба.

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

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

Дополнительные сведения см. в разделе "Модель управления доступом" в Azure Data Lake Storage.

Следующие шаги