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