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

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

  • Статья

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

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

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

  • Используйте "горячий уровень" для хранения часто запрашиваемых данных.

  • Используйте уровень холодного хранения для хранения редко используемых данных. На этом уровне хранятся данные по крайней мере 30 дней.

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

  • Используйте архив уровня для хранения редко доступных данных. На этом уровне хранятся данные по крайней мере 180 дней. Доступ к этим данным может иметь гибкие требования к задержке, что означает, что для получения данных может потребоваться несколько часов.

Внимание

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

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

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

  • Задайте горячие, холодные и архивные уровни на уровне блоба во время загрузки или после неё.

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

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

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

Внимание

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

Подключение к хранилищам данных

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

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

Внимание

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

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

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

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

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

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

Наблюдение

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

Дополнительную информацию см. в разделе Мониторинг ресурсов Azure с помощью Azure Monitor и Мониторинг хранилища Blob.

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

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

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

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

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

Внимание

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

Безопасность зоны озера данных

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

  • Необработанное использование позволяет доступ к данным только с использованием имен субъектов безопасности (SPNs). Рекомендуется использовать управляемые удостоверения.

  • обогащенное использование разрешает доступ к данным только с помощью SPN (имен субъектов-служб). Рекомендуется использовать управляемые удостоверения.

  • Управляемое использование позволяет получать доступ к данным с помощью SPN и имен субъектов-пользователей (UPN).

Для получения дополнительной информации см. модель управления доступом в хранилище Data Lake Storage.

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