Зоны и контейнеры озера данных

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

Общие сведения о озерах данных см. в обзоре Azure Data Lake Storage для аналитики в облаке.

Обзор

Три учетные записи озера данных должны соответствовать типичным слоям озера данных.

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

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

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

Дополнительные сведения о командах см. в статье "Общие сведения о ролях и командах для облачной аналитики в Azure".

Каждый продукт данных должен содержать две папки в контейнере продуктов данных, которым владеет ваша группа продуктов данных.

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

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

Сочетание списков управления доступом и группами Microsoft Entra ограничивает доступ к данным. Эти списки и группы управляют тем, что другие группы могут и не могут получить доступ. Владельцы данных и команды приложений данных могут утвердить или отклонить доступ к их ресурсам данных.

Дополнительные сведения см. в разделе "Конфиденциальность данных".

Необработанный слой (бронза) или озеро данных один

Подумайте о необработанном слое как водохранилище, которое хранит данные в своем естественном и исходном состоянии. Этот резервуар не отфильтрован и не очищен. Данные могут храниться в исходном формате, например JSON или CSV. Или это может быть экономично для хранения содержимого файла в виде столбца в сжатом формате файла, например Avro, Parquet или Databricks Delta Lake.

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

При загрузке данных из исходных систем в необработанную зону можно сделать следующее:

• Полная загрузка для извлечения полного набора данных.
• Разностные загрузки для загрузки только измененных данных.

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

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

Различия между полными нагрузками и разностной нагрузкой:

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

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

• Разностная загрузка — добавочные данные из источника можно подключить, если:

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

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

Макет целевого контейнера

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

.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full

Контейнер соответствия необработанным слоям

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

.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}

Обогащенный слой (серебро) или озеро данных два

Подумайте о обогащенном слое как слое фильтрации. Он удаляет примеси и может также включать обогащение.

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

Стандартизированный контейнер

.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}

На следующей схеме показан поток озер данных и контейнеров из исходных данных в стандартизированный контейнер.

Курированный слой (золото) или озеро данных два

Ваш курированный уровень — это уровень потребления. Она оптимизирована для аналитики, а не для приема или обработки данных. Курированный слой может хранить данные в денормализованных киосках данных или схемах звезд.

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

Используйте такие средства, как Spark или Фабрика данных, для моделирования измерений вместо того, чтобы выполнять его внутри ядра СУБД. Это использование инструментов становится ключевой точкой, если вы хотите сделать озеро единственным источником истины.

Если вы выполняете моделирование измерений за пределами озера, возможно, потребуется опубликовать модели обратно в озеро для согласованности. Этот уровень не является заменой для хранилища данных. Его производительность обычно не подходит для адаптивных панелей мониторинга или пользовательской и пользовательской интерактивной аналитики. Этот уровень лучше всего подходит для внутренних аналитиков и специалистов по обработке и анализу данных, которые выполняют крупномасштабные импровизированные запросы или анализ, а также для передовых аналитиков, которые не нуждаются в отчетности с учетом времени. Так как затраты на хранение в озере данных ниже, чем в вашем хранилище данных, это может быть экономически эффективным для хранения детализированных, низкоуровневых данных в озере. Храните агрегированные данные в хранилище. Создайте эти агрегаты с помощью Spark или Фабрика данных Azure. Сохраните их в озере данных перед загрузкой их в хранилище данных.

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

Контейнер продуктов данных

.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}

Уровень разработки или озеро данных три

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

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

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

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

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