Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Облачные хранилища данных и озера данных обогащают данные, централизуют информацию и позволяют проводить мощную аналитику. Но реальная ценность данных заключается в том, чтобы превратить аналитические сведения в реальные решения и взаимодействие с клиентами. Чтобы достичь этой цели, чистые надежные данные должны выйти из хранилища или озера данных в операционные системы. Обратный ETL перемещает данные из уровня хранилища данных, например Delta Lake в Azure Databricks или Microsoft Fabric, обратно в операционные системы. Этот шаг миграции позволяет подчиненным приложениям использовать самые последние обогащенные данные для оперативной аналитики в режиме реального времени. Обратный ETL играет важную роль в разблокировке полного потенциала ресурсов данных, преодолев разрыв между аналитикой и операциями, что позволяет лучше принимать решения.
Azure Cosmos DB для NoSQL предназначен для обеспечения низкой задержки, глобального распределения и масштабируемости NoSQL, что делает его идеальным для приложений в режиме реального времени. С помощью обратного ETL можно синхронизировать данные, обогащённые с использованием Delta, в Azure Cosmos DB, обеспечивая оперативную аналитику в режиме реального времени. Этот шаблон можно использовать для отправки данных, таких как каталоги продуктов, персонализированные сведения о клиенте, обновления цен, данные инвентаризации и рекомендации по функциям. Эти данные можно отправить в рабочее хранилище данных, что позволяет подчиненным приложениям мгновенно принимать решения, управляемые данными.
Архитектура решения
Упрощенная архитектура для реализации обратного ETL состоит из Apache Spark и Azure Databricks. Эта архитектура извлекает очищенные и обогащенные данные из источников, таких как Delta Tables, и записывает данные обратно в рабочее хранилище в Azure Cosmos DB для NoSQL.
Эта схема включает следующие компоненты:
Источники данных , включающие такие данные, как; данные о продуктах, данные CRM, сведения о заказе и сведения о рекламе.
Рабочий процесс ETL перемещает данные из исходных источников данных в хранилище данных или озеро данных для хранения и обогащения данных с помощью таких решений, как Azure Databricks или Microsoft Fabric.
Обратный рабочий процесс ETL для переноса обогащенных данных в рабочее хранилище данных с помощью таблиц Apache Spark и Delta
Хранилище данных операций , например Azure Cosmos DB для NoSQL, использует обогащенные данные в приложениях в режиме реального времени.
Обратный процесс ETL включает такие сценарии, как:
решенияReal-Time: Приложения получают доступ к самым свежим данным, не опираясь на аналитиков или SQL.
Активация данных: Информация отправляется туда, где она необходима, а не только в дашбордах.
Единый источник истины: Delta Lake выступает в качестве канонического слоя, обеспечивая согласованность между системами.
Этапы приема данных
Для таких сценариев, как хранилище компонентов, подсистемы рекомендаций, обнаружение мошенничества или каталоги продуктов в режиме реального времени, важно разделить поток данных на два этапа. На этих этапах предполагается, что у вас есть обратный конвейер ETL из Delta Lake в Azure Cosmos DB для NoSQL.
Этапы этой схемы состоят из следующих этапов:
Начальная загрузка: начальная загрузка — это однократный этап пакетного процесса для приема всех исторических данных из разностных таблиц в Azure Cosmos DB для NoSQL. Он задает основу для обратного конвейера ETL, гарантируя, что рабочее хранилище данных имеет полные исторические данные. Эта нагрузка является основным шагом перед началом добавочной синхронизации данных.
Синхронизация отслеживания измененных данных (CDC): этот шаг реализует добавочную непрерывную синхронизацию изменений из разностных таблиц в Azure Cosmos DB для NoSQL. Изменения в разностной таблице можно записать после включения канала данных delta Change (CDF). Вы можете реализовать пакетную или потоковую синхронизацию отслеживания измененных данных (CDC).
Существует два варианта синхронизации CDC в Azure Cosmos DB для NoSQL:
Пакетная синхронизация CDC: этот параметр выполняется по расписанию (например, ежедневно или почасово) и загружает инкрементный моментальный снимок данных на основе изменений, зафиксированных с момента последней версии или временной метки.
Подсказка
Переключитесь на новый снимок Azure Cosmos DB, чтобы избежать несоответствий данных при загрузке больших объемов данных из разностной таблицы в Azure Cosmos DB с поддержкой NoSQL. Например, при записи в новый контейнер или с помощью флага версии переверните указатель на более новый снимок экрана после полной загрузки новых данных.
Потоковая синхронизация CDC: этот параметр непрерывно синхронизирует добавочные изменения почти в режиме реального времени, сохраняя целевую систему в актуальном состоянии с минимальным задержкой. Этот параметр использует структурированную потоковую передачу Apache Spark для непрерывного отслеживания и записи изменений. Таблица Delta выступает в роли источника потоковой передачи с
readChangeData = true, а соединитель Azure Cosmos DB для NoSQL выступает в роли приемника потоковой передачи.Подсказка
Укажите расположение контрольной точки для отслеживания хода выполнения и предотвращения повторяющихся операций записи.
Лучшие практики
Чтобы выполнить начальный шаг загрузки, используйте пакетные задания Apache Spark с соединителем Azure Cosmos DB для NoSQL.
Оптимизируйте скорость обработки данных, переключившись на стандартную (зарезервированную) пропускную способность, если ожидается, что начальная нагрузка будет потреблять большое количество RU/s относительно вашей выделенной пропускной способности. В частности, используйте стандартную подготовленную пропускную способность, если максимальное количество единиц запросов в секунду (ЕЗ/с) используется согласованно в течение большей части начального процесса загрузки. Не используйте пропускную способность автомасштабирования для начального шага загрузки в этом сценарии.
Подсказка
Если нормализованная метрика потребления ЕЗ последовательно составляет 100%, то метрика указывает, что начальная нагрузка согласованно использует максимальное количество единиц запросов автомасштабирования (ЕЗ). Это пороговое значение является четким показателем того, что этот сценарий применяется к рабочей нагрузке и следует использовать стандартную подготовленную пропускную способность.
Выберите эффективный ключ разбиения, который максимизирует параллелизм. Дополнительные сведения см. в рекомендациях по секционированию и ключу раздела.
Запланируйте общее количество секций и общих единиц запросов в секунду во всех секциях для приема больших данных. Дополнительные сведения и рекомендации см. в рекомендациях по секционированию и пропускной способности.
Используйте управление пропускной способностью Apache Spark, чтобы ограничить потребление единиц запроса (RU) заданиями. Управление пропускной способностью помогает предотвратить перегрузку целевого операционного контейнера.
Используйте автоматическое масштабирование пропускной способности, если это возможно, в Azure Cosmos DB для NoSQL для синхронизации CDC, поскольку это масштабирование автоматически увеличивается и уменьшается на основе использования. Пропускная способность автомасштабирования идеально подходит для периодических и скачкообразных рабочих нагрузок, таких как запланированные задания синхронизации CDC. Дополнительные сведения см. в рекомендациях по пропускной способности.
Оцените начальное время обработки для первого шага загрузки данных. Дополнительные сведения и пример см. в статье об оценке пропускной способности.