Поделиться через


Изменение отслеживания данных в аналитическом хранилище Azure Cosmos DB

Область применения: Nosql MongoDB

Отслеживание измененных данных (CDC) в аналитическом хранилище Azure Cosmos DB позволяет эффективно использовать непрерывный и добавочный веб-канал измененных (вставленных, обновленных и удаленных) данных из аналитического хранилища. Простая интеграция с Azure Synapse и Фабрика данных Azure обеспечивает масштабируемую работу без кода для большого объема данных. Так как функция отслеживания измененных данных основана на аналитическом хранилище, она не использует подготовленные ЕЗ, не влияет на рабочие нагрузки транзакций, обеспечивает низкую задержку и имеет более низкую TCO.

Функция отслеживания измененных данных в аналитическом хранилище Azure Cosmos DB может записывать данные в различные приемники с помощью потока данных Azure Synapse или Фабрика данных Azure.

Схема аналитического хранилища в Azure Cosmos DB и способ ее записи с помощью отслеживания измененных данных может записываться в различные целевые службы первого и стороннего разработчика.

Дополнительные сведения о поддерживаемых типах приемников в потоке данных сопоставления см. в поддерживаемых типах приемников потока данных.

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

  • Поддерживает запись удаленных и промежуточных обновлений
  • Возможность фильтрации веб-канала изменений для определенного типа операции (вставка | обновления | удаления | TTL)
  • Поддерживает применение фильтров, проекций и преобразований в канале изменений с помощью исходного запроса
  • Одновременно можно использовать несколько веб-каналов изменений в одном контейнере.
  • Каждое изменение контейнера отображается ровно один раз в канале отслеживания измененных данных, а контрольные точки управляются внутренне для вас
  • Изменения можно синхронизировать "с начала" или "из заданной метки времени" или "отныне"
  • Не существует ограничений на фиксированный период хранения данных, для которого доступны изменения.

Эффективное добавочное сбор данных с помощью внутренних управляемых контрольных точек

Каждое изменение в контейнере Cosmos DB отображается ровно один раз в веб-канале CDC, а контрольные точки управляются внутри вас. Это помогает устранить следующие недостатки общего шаблона использования пользовательских контрольных точек на основе значения _ts:

  • Фильтр "_ts" применяется к файлам данных, которые не всегда гарантируют минимальное сканирование данных. Внутренние управляемые контрольные точки НА основе GLSN в новой возможности CDC гарантируют, что добавочная идентификация данных выполняется только на основе метаданных и поэтому гарантирует минимальное сканирование данных в каждом потоке.

  • Процесс синхронизации аналитического хранилища не гарантирует упорядочение на основе _ts, что означает, что в добавочном потоке может быть пропущена добавочная запись "_ts" меньше последней контрольной точки "_ts" и может быть пропущена в добавочном потоке. Новый CDC не рассматривает "_ts" для идентификации добавочных записей и таким образом гарантирует, что ни одна из добавочных записей отсутствует.

Функции

Сбор измененных данных в аналитическом хранилище Azure Cosmos DB поддерживает следующие ключевые функции.

Запись изменений с самого начала

Start from beginning При выборе параметра начальная загрузка включает полный снимок данных контейнера в первом запуске, а также изменения или добавочные данные записываются в последующих запусках. Это ограничено свойством analytical TTL и документами, удаленными из аналитического хранилища, не включены в канал изменений. Пример. Представьте контейнер с analytical TTL установленным значением 31536000 секунд, что эквивалентно 1 году. Если вы создаете процесс CDC для этого контейнера, в начальную загрузку будут включены только документы, более чем 1 год.

Запись изменений из заданной метки времени

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

Запись изменений с этого момента

Start from timestamp При выборе параметра все прошлые операции контейнера не записываются.

Запись удаленных, промежуточных обновлений и списков TTL

Функция отслеживания измененных данных для аналитического хранилища записывает удаления, промежуточные обновления и операции TTL. Захваченные удаления и обновления можно применять к приемникам, поддерживающим операции удаления и обновления. Значение {_rid} однозначно идентифицирует записи и поэтому указывая {_rid} в качестве ключевого столбца на стороне приемника, операции обновления и удаления будут отражены в приемнике.

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

Фильтрация канала изменений для определенного типа операции

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

Применение фильтров, проекций и преобразований в канале изменений с помощью исходного запроса

При необходимости можно использовать исходный запрос для указания фильтров, проекций и преобразований, которые будут отправляться в аналитическое хранилище столбцов. Ниже приведен пример исходного запроса, который будет записывать только добавочные записи с фильтром Category = 'Urban'. Этот пример проектов запросов выполняет только пять полей и применяет простое преобразование:

SELECT ProductId, Product, Segment, concat(Manufacturer, '-', Category) as ManufacturerCategory
FROM c 
WHERE Category = 'Urban'

Несколько процессов CDC

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

Изоляция пропускной способности, низкая задержка и более низкая TCO

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

Сценарии

Ниже приведены распространенные сценарии, в которых можно использовать запись измененных данных и аналитическое хранилище.

Использование добавочных данных из Cosmos DB

Вы можете использовать сбор измененных данных аналитического хранилища, если вы используете или планируете использовать:

  • Добавочное сбор данных с помощью Фабрика данных Azure Поток данных или действие Copy.
  • Однократная пакетная обработка с помощью Фабрика данных Azure.
  • Потоковая передача данных Cosmos DB
    • Аналитическое хранилище имеет до 2-минутной задержки для синхронизации данных транзакционного хранилища. Вы можете планировать Поток данных в Фабрика данных Azure каждую минуту.
    • Если необходимо выполнить потоковую передачу без указанной выше задержки, рекомендуется использовать функцию канала изменений хранилища транзакций.
  • Запись удаления, добавочных изменений, применение фильтров к данным Cosmos DB.
    • Если вы используете триггеры Функции Azure или любой другой вариант с каналом изменений и хотите записать удаления, добавочные изменения, применить преобразования и т. д.; рекомендуется изменить запись данных в аналитическом хранилище.

Добавочный веб-канал к аналитической платформе вашего выбора

Возможность отслеживания измененных данных позволяет комплексному аналитическому решению обеспечить гибкость использования данных Azure Cosmos DB с любым из поддерживаемых типов приемников. Дополнительные сведения о поддерживаемых типах приемников см. в поддерживаемых типах приемников потока данных. Запись измененных данных также позволяет перенести данные Azure Cosmos DB в централизованное озеро данных и присоединить данные с данными из других различных источников. Вы можете расположить данные, секционировать их и применить дополнительные преобразования в Azure Synapse Analytics или Фабрика данных Azure.

Изменение записи данных в контейнерах Azure Cosmos DB для MongoDB

Интерфейс связанной службы для API для MongoDB пока недоступен в Фабрика данных Azure потоках данных. Вы можете использовать конечную точку учетной записи MongoDB с интерфейсом связанной службы Azure Cosmos DB для NoSQL , пока связанная служба Mongo не поддерживается напрямую.

В интерфейсе для новой связанной службы NoSQL выберите ввод вручную , чтобы указать сведения об учетной записи Azure Cosmos DB. Здесь используйте конечную точку документа NoSQL учетной записи (пример https://<account-name>.documents.azure.com:443/: ) вместо конечной точки Mongo DB (пример: mongodb://<account-name>.mongo.cosmos.azure.com:10255/)

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