Azure Data Lake Storage ключевых аспектов

  • Статья

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

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

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

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

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

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

  • Горячий, холодный и архивный уровни можно задать на уровне BLOB-объекта во время отправки или после отправки.

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

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

Дополнительные сведения см. в разделе Горячий, Холодный и Архивный уровни доступа для данных BLOB-объектов.

Внимание!

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

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

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

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

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

Важно!

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

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

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

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

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

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

Наблюдение

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

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

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

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

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

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

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

Важно!

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

Дальнейшие действия