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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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