Обзор Azure Data Lake Storage для облачной аналитики

Azure Data Lake — это масштабируемое и безопасное хранилище данных для высокопроизводительных рабочих нагрузок аналитики. Учетные записи хранения можно создать в одной группе ресурсов для облачной аналитики. Рекомендуется подготовить три учетных записи Azure Data Lake Storage 2-го поколения в одной группе ресурсов, аналогичной storage-rg группе ресурсов, описанной в статье о целевой зоне данных архитектуры облачной аналитики.

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

• Необработанные данные (бронза)
• Обогащенные данные (серебро) и курированные данные (золото)
• Озера данных для разработки

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

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

• Безопасное хранение данных с помощью шифрования неактивных данных.
• Элементы управления доступом для пользователей Microsoft Entra и групп безопасности с помощью интеграции Microsoft Entra.

Планирование озера данных

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

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

Группы потребителей и производителей на основе их потребностей в доступе к данным. Рекомендуется планировать внедрение и управление доступом в озере данных.

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

Аналогия с болотом данных

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

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

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

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

Учетные записи хранения в логическом озере данных

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

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

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

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

Развертывание в нескольких регионах.

Если они определяются правилами расположения данных или требованием хранения данных близко к базе пользователей, может потребоваться создать учетные записи Azure Data Lake в нескольких регионах Azure. Необходимо создать целевую зону данных в одном регионе, а затем реплицировать глобальные данные с помощью AzCopy, Фабрика данных Azure или партнерских продуктов. Локальные данные находятся в регионе, а глобальные данные реплицируются в нескольких регионах.

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