Что такое архитектура медальона в гибридном решении "хранилище и озеро данных"?

Архитектура медальона описывает ряд слоев данных, которые соответствуют качеству данных, хранящихся в гибридном решении "хранилище и озеро данных". Azure Databricks рекомендует использовать многоуровневый подход к созданию единого источника истины для корпоративных продуктов данных.

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

Архитектура Medallion в виде шаблона проектирования данных

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

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

После архитектуры медальона рекомендуется, но не обязательно.

Вопрос	Бронзовая	Серебряная	Золотая
Что происходит в этом слое?	Прием необработанных данных	Очистка и проверка данных	Моделирование измерений и агрегирование
Кто является предполагаемым пользователем?	— Инженеры данных — Операции с данными — группы соответствия требованиям и аудита	— Инженеры данных — Аналитики данных (используйте уровень Silver для более точного набора данных, который по-прежнему сохраняет подробные сведения, необходимые для подробного анализа). — Специалисты по обработке и анализу данных (создание моделей и выполнение расширенной аналитики)	— Бизнес-аналитики и разработчики бизнес-аналитиков - Инженеры по обработке и анализу данных (ML) - Руководители и лица, принимающие решения — операционные группы

Пример архитектуры медальона

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

• Бронзовый слой (ops.bronze): прием необработанных данных из облачного хранилища, Kafka и Salesforce. Здесь не выполняется очистка или проверка данных.
• Серебряный слой (ops.silver): очистка и проверка данных выполняются в этом слое.
  • Данные о клиентах и транзакциях очищаются путем удаления значений NULL и карантина недопустимых записей. Эти наборы данных объединяются в новый набор customer_transactionsданных. Специалисты по обработке и анализу данных могут использовать этот набор данных для прогнозной аналитики.
  • Аналогичным образом учетные записи и наборы данных возможностей из Salesforce присоединяются к созданию account_opportunities, что улучшено с помощью сведений об учетной записи.
  • Данные leads_raw очищаются в наборе данных с именем leads_cleaned.
• Золотой слой (ops.gold): этот уровень предназначен для бизнес-пользователей. Он содержит меньше наборов данных, чем серебро и золото.
  • customer_spending: средняя и общая сумма расходов для каждого клиента.
  • account_performance: ежедневная производительность для каждой учетной записи.
  • sales_pipeline_summary: сведения о сквозном конвейере продаж.
  • business_summary: высоко агрегированная информация для исполнительного персонала.

Прием необработанных данных на бронзовом уровне

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

• Содержит и поддерживает необработанное состояние источника данных в исходных форматах.
• добавляются постепенно и со временем увеличиваются в объеме;
• Предназначен для использования рабочими нагрузками, которые обогащают данные для серебряных таблиц, а не для доступа аналитиков и специалистов по обработке и анализу данных.
• Служит одним источником истины, сохраняя точность данных.
• Включает повторную обработку и аудит, сохраняя все исторические данные.
• Может быть любое сочетание потоковых и пакетных транзакций из источников, включая облачное хранилище объектов (например, S3, GCS, ADLS), автобусы сообщений (например, Kafka, Kinesis и т. д.), а также федеративные системы (например, Федерация Lakehouse).

Ограничение очистки или проверки данных

Минимальная проверка данных выполняется в бронзовом слое. Чтобы обеспечить удаление данных, Azure Databricks рекомендует хранить большинство полей в виде строки, VARIANT или двоичного файла для защиты от непредвиденных изменений схемы. Можно добавить столбцы метаданных, например прованство или источник данных (например, _metadata.file_name ).

Проверка и дедупликация данных на серебряном уровне

Очистка и проверка данных выполняются на серебряном слое.

Создание серебряных таблиц из бронзового слоя

Чтобы создать серебряный слой, считывайте данные из одной или нескольких бронзовых или серебряных таблиц и записывайте данные в серебряные таблицы.

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

Серебряный слой представляет проверенные, чистые и обогащенные версии данных. Серебряный слой:

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

Обеспечение качества данных

Следующие операции выполняются в серебряных таблицах:

• Принудительное применение схем
• Обработка значений NULL и отсутствующих значений
• Дедупликация данных
• Решение проблем с неупорядоченными и поздними поступлениями данных
• Проверки качества данных и принудительное применение
• Развитие схемы
• Приведение типов
• Объединения

Запуск данных моделирования

Обычно выполняется моделирование данных на уровне серебра, включая выбор представления сильно вложенных или частично структурированных данных:

• Используйте VARIANT тип данных.
• Используйте JSON строки.
• Создание структур, карт и массивов.
• Плоская схема или нормализация данных в нескольких таблицах.

Power Analytics с золотом уровнем

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

Золотой слой:

• Состоит из агрегированных данных, адаптированных для аналитики и отчетности.
• Соответствует бизнес-логике и требованиям.
• Оптимизирован для повышения производительности запросов и панелей мониторинга.

Соответствие бизнес-логике и требованиям

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

Поскольку золотой слой моделирует бизнес-домен, некоторые клиенты создают несколько слоев золота для удовлетворения различных бизнес-потребностей, таких как персонал, финансы и ИТ.

Создание статистических выражений, адаптированных для аналитики и отчетности

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

CREATE OR REPLACE MATERIALIZED VIEW weekly_sales AS
SELECT week,
       prod_id,
       region,
       SUM(units) AS total_units,
       SUM(units * rate) AS total_sales
FROM orders
GROUP BY week, prod_id, region

Оптимизация производительности в запросах и панелях мониторинга

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

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

Управляйте затратами, определяя частоту приема данных.

Частота приема данных	Себестоимость	Задержка	Декларативные примеры	Процедурные примеры
Непрерывное добавочное прием	Выше	Lower	— Потоковая таблица, используемая spark.readStream для приема из облачного хранилища или шины сообщений. — Конвейер разностных динамических таблиц, обновляющий эту потоковую таблицу, выполняется непрерывно. — Структурированный код потоковой передачи с помощью spark.readStream записной книжки для приема из облачного хранилища или шины сообщений в разностную таблицу. — Записная книжка управляется с помощью задания Azure Databricks с триггером непрерывного задания.
Активация добавочного приема	Lower	Выше	— прием потоковой таблицы из облачного хранилища или шины сообщений с помощью spark.readStream. — Конвейер, обновляющий эту потоковую таблицу, активируется запланированным триггером задания или триггером прибытия файла. — Структурированный код потоковой передачи в записной книжке с триггером Trigger.Available . — Эта записная книжка активируется запланированным триггером задания или триггером прибытия файла.
Прием пакетной службы с помощью добавочного приема вручную	Lower	Самый высокий из-за редких запусков.	— прием потоковой таблицы из облачного хранилища с помощью spark.read. — Не использует структурированную потоковую передачу. Вместо этого используйте примитивы, такие как перезапись секций, чтобы одновременно обновлять всю секцию. — Требуется обширная вышестоящей архитектуры для настройки добавочной обработки, которая позволяет выполнять затраты, аналогичные структурированной потоковой передаче чтения и записи. — Также требуется секционирование исходных данных по datetime полю, а затем обработка всех записей из этой секции в целевой объект.