Что такое аналитическое хранилище Azure Cosmos DB?

Статья
03/21/2023
Чтение занимает 30 мин

ПРИМЕНИМО К: Nosql Mongodb Гремлин

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

Сложности крупномасштабного анализа операционных данных

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

Обычно для анализа больших объемов данных операционные данные извлекаются из хранилища транзакций Azure Cosmos DB и хранятся на отдельном уровне данных. Например, данные хранятся в хранилище данных или озере данных в подходящем формате. Эти данные позже используются для крупномасштабной аналитики и анализируются с помощью подсистемы вычислений, например кластеров Apache Spark. Такое разделение аналитического и вычислительного уровней для операционных данных приводит к дополнительной задержке, так как конвейеры ETL (извлечение, преобразование, загрузка) выполняются реже, чтобы сократить влияние на транзакционные рабочие нагрузки.

Конвейеры ETL также усложняются при обработке обновлений операционных данных по сравнению с обработкой только новых принимаемых операционных данных.

Аналитическое хранилище для столбцов

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

Используя Azure Synapse Link, можно создавать решения HTAP без ETL, напрямую связываясь с аналитическим хранилищем Azure Cosmos DB из Synapse Analytics. Благодаря этому можно выполнять крупномасштабную аналитику на операционных данных почти в реальном времени.

Возможности аналитического хранилища

При включении аналитического хранилища в контейнере Azure Cosmos DB новое хранилище столбцов создается на основе операционных данных в контейнере. Это хранилище столбцов сохраняется отдельно от транзакционного хранилища, ориентированного на строки для этого контейнера, в учетной записи хранения, которая полностью управляется Azure Cosmos DB, во внутренней подписке. Клиентам не нужно тратить время на администрирование хранилища. Операции вставки, обновления и удаления для операционных данных автоматически синхронизируются с аналитическим хранилищем. Для синхронизации данных не требуется канал изменений или ETL.

Хранилище столбцов для аналитических рабочих нагрузок в операционных данных

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

Например, если рабочие таблицы имеют следующий формат:

Пример операционной таблицы

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

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

На следующем рисунке показано хранилище транзакций и хранилище аналитических столбцов в Azure Cosmos DB:

Транзакционное хранилище строк и хранилище аналитических столбцов в Azure Cosmos DB

Несвязанная производительность для аналитических рабочих нагрузок

Аналитические запросы не влияют на производительность транзакционных рабочих нагрузок, так как аналитическое хранилище отделено от хранилища транзакций. Для аналитического хранилища не требуется выделять отдельные единицы запроса (ЕЗ).

Автосинхронизация

Автоматическая синхронизация — это полностью управляемая возможность Azure Cosmos DB, при которой операции вставки, обновления и удаления в операционных данных автоматически синхронизируются из хранилища транзакций в аналитическое хранилище практически в реальном времени. Задержка автоматической синхронизации обычно составляет менее 2 минут. В случае базы данных с общей пропускной способностью с большим количеством контейнеров задержка автоматической синхронизации отдельных контейнеров может быть дольше и составлять до 5 минут. Мы хотели бы узнать больше о том, насколько такая задержка подходит для ваших сценариев. Для этого обратитесь к команде Azure Cosmos DB.

В конце каждого выполнения процесса автоматической синхронизации ваши данные о транзакциях будут немедленно доступны для сред выполнения Azure Synapse Analytics.

Пулы Spark в Azure Synapse Analytics могут считывать все данные, включая самые последние обновления, из таблиц Spark, которые обновляются автоматически, или с помощью команды spark.read, которая всегда считывает последнее состояние данных.
Бессерверные пулы SQL в Azure Synapse Analytics могут считывать все данные, включая самые последние обновления, из представлений, которые обновляются автоматически, или с помощью SELECT и команд OPENROWSET, которые всегда считывают последнее состояние данных.

Примечание

Данные о транзакциях будут синхронизированы с аналитическим хранилищем, даже если срок жизни транзакции (TTL) меньше 2 минут.

Примечание

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

Масштабируемость и эластичность

Используя горизонтальное секционирование, хранилище транзакций Azure Cosmos DB может эластично масштабировать хранилище и пропускную способность без простоев. Горизонтальное секционирование в хранилище транзакций обеспечивает масштабируемость и эластичность при автоматической синхронизации, чтобы обеспечить синхронизацию данных с аналитическим хранилищем почти в реальном времени. Синхронизация данных выполняется независимо от объема трафика транзакций, который составляет 1000 операций/с или 1 000 000 операций/с, и не влияет на подготовленную пропускную способность в хранилище транзакций.

Автоматическая работа с обновлениями схемы

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

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

Примечание

В контексте аналитического хранилища мы рассматриваем следующие структуры как свойство:

"Элементы" JSON или "пары строка-значение с разделителем :".
Объекты JSON с разделителями { и }.
Массивы JSON с разделителями [ и ].

Ограничения схемы

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

Вы можете иметь не более 1000 свойств во всех вложенных уровнях в схеме документов, при это глубина вложения не может превышать 127 уровней.
- В аналитическом хранилище представлены только первые 1000 свойств.
- В аналитическом хранилище представлены только первые 127 уровней вложенности.
- Первый уровень документа JSON — это его уровень корня /.
- Свойства на первом уровне документа будут представлены в виде столбцов.
Пример сценариев.
- Если на первом уровне вашего документа 2000 свойств, будут представлены только первые 1000.
- Если в ваших документах 5 уровней с 200 свойств в каждом, будут представлены все свойства.
- Если в ваших документах 10 уровней с 400 свойствами в каждом, только 2 первых уровня будут полностью представлены в аналитическом хранилище. Половина третьего уровня также будет представлена.
Приведенный ниже гипотетический документ содержит 4 свойства и 3 уровня.
- Уровнями являются root, myArray и вложенная структура внутри myArray.
- Свойствами являются id, myArray, myArray.nested1 и myArray.nested2.
- В представлении аналитического хранилища будет 2 столбца: id и myArray. С помощью функции Spark или T-SQL можно представить в виде столбцов также вложенные структуры.

{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}

В документах JSON (и коллекциях и контейнерах Azure Cosmos DB) учитывается регистр с точки зрения уникальности, а аналитическое хранилище — нет.
- В одном документе. Имена свойств на одном уровне должны быть уникальными при сравнении без учета регистра. Например, следующий документ JSON содержит "Name" и "name" на одном и том же уровне. Хотя это допустимый документ JSON, он не удовлетворяет ограничению уникальности и поэтому не будет полностью представлен в аналитическом хранилище. В этом примере "Name" и "name" одинаковы при сравнении без учета регистра. В аналитическом хранилище будет представлен только "Name": "fred", так как он является первым экземпляром. При этом "name": "john" не будет представлен вообще.
```
{"id": 1, "Name": "fred", "name": "john"}
```
- В других документах. Свойства на одном и том же уровне и с тем же именем, но в разных случаях будут представлены в одном столбце с использованием формата имени первого вхождения. Например, следующие документы JSON содержат "Name" и "name" на одном и том же уровне. Так как формат первого документа — "Name", именно он будет использоваться для представления имени свойства в аналитическом хранилище. Другими словами, именем столбца в аналитическом хранилище будет "Name". "fred" и "john" будут представлены в столбце "Name".
```
{"id": 1, "Name": "fred"}
{"id": 2, "name": "john"}
```
В первом документе коллекции определена схема первоначального аналитического хранилища.
- Документы, содержащие больше свойств по сравнению с исходной схемой, создадут новые столбцы в аналитическом хранилище.
- Удалить столбцы невозможно.
- Удаление всех документов в коллекции не приводит к сбросу схемы аналитического хранилища.
- Управление версиями схем отсутствует. В аналитическом хранилище вы увидите последнюю версию, выводимую из хранилища транзакций.
В настоящее время Azure Synapse Spark не может считывать свойства, имена которых содержат перечисленные ниже специальные знаки. На бессерверный Azure Synapse SQL это не влияет.
- :
- `
- ,
- ;
- {}
- ()
- \n
- \t
- =
- "

Примечание

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

Если вы используете имена свойств с указанными выше символами, можно использовать указанные ниже варианты.
- Заранее измените модель данных, чтобы избежать этих символов.
- Так как в настоящее время мы не поддерживаем сброс схемы, вы можете изменить приложение, чтобы добавить избыточное свойство с похожим именем без таких символов.
- С помощью канала изменений создайте материализованное представление контейнера без этих символов в именах свойств.
- Используйте параметр Spark dropColumn, чтобы проигнорировать затронутые столбцы и загрузить все остальные столбцы в DataFrame. Синтаксис:

# Removing one column:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.synapse.dropColumn","FirstName,LastName")\
     .load()
     
# Removing multiple columns:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.synapse.dropColumn","FirstName,LastName;StreetName,StreetNumber")\
     .option("spark.cosmos.dropMultiColumnSeparator", ";")\
     .load()

Azure Synapse Spark теперь поддерживает свойства с пробелами в именах. Для этого необходимо использовать параметр Spark allowWhiteSpaceInFieldNames для загрузки затронутых столбцов в DataFrame, сохраняя исходное имя. Синтаксис:

df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.allowWhiteSpaceInFieldNames", "true")\
    .load()

Следующие типы данных BSON не поддерживаются и не будут представлены в аналитическом хранилище:
- Decimal128
- Регулярное выражение
- Указатель базы данных
- JavaScript
- Символ
- MinKey/MaxKey
При использовании строк даты и времени, соответствующих стандарту ISO 8601 UTC, следует ожидать следующее поведение:
- Пулы Spark в Azure Synapse будут представлять эти столбцы как string.
- Бессерверные пулы SQL в Azure Synapse будут представлять эти столбцы как varchar(8000).
Свойства с типами UNIQUEIDENTIFIER (guid) представлены как string в аналитическом хранилище и для правильной визуализации должны быть преобразованы в VARCHAR (в SQL) или в string (в Spark).
Бессерверные пулы SQL в Azure Synapse поддерживают результирующие наборы с количеством столбцов не более 1000. Предоставляемые вложенные столбцы также учитываются в этом ограничении. Учитывайте эти сведения при разработке архитектуры данных и моделировании данных о транзакциях.
Если переименовать свойство в одном или многих документах, оно будет считаться новым столбцом. Если выполнить одно и то же переименование во всех документах в коллекции, все данные будут перенесены в новый столбец, а старый столбец будет представлен значениями NULL.

Представление схемы

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

Четко определенное представление схемы, параметр по умолчанию для API для учетных записей NoSQL и Gremlin.
Представление схемы полной точности, параметр по умолчанию для API для учетных записей MongoDB.

Четко определенное представление схемы

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

В первом документе определяется базовая схема, а свойства должны всегда иметь один и тот же тип во всех документах. Все исключения перечислены ниже.
- От NULL к любому другому типу данных. Первый экземпляр, не имеющий значение NULL, определяет тип данных столбца. Любой документ с типом данных, где первое вхождение не отлично от NULL, не будет представлен в аналитическом хранилище.
- С float на integer. Все документы будут представлены в аналитическом хранилище.
- С integer на float. Все документы будут представлены в аналитическом хранилище. Но чтобы прочитать эти данные с помощью бессерверных пулов SQL в Azure Synapse, необходимо использовать предложение WITH для преобразования столбца в varchar. После этого первоначального преобразования можно снова преобразовать его в число. Посмотрите пример ниже, где первоначальное значение num было целым числом, а второе — float.

SELECT CAST (num as float) as num
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = '<your-connection',
                OBJECT = 'IntToFloat',
                SERVER_CREDENTIAL = 'your-credential'
) 
WITH (num varchar(100)) AS [IntToFloat]

Свойства, которые не соответствуют типу данных базовой схемы, не будут представлены в аналитическом хранилище. Например, рассмотрим два документа, приведенных ниже. Первый из них определяет базовую схему аналитического хранилища. Второй документ, где id — это "2", не имеет четко определенной схемы, поскольку свойство "code" — это строка, а в первом документе "code" — это число. В этом случае аналитическое хранилище регистрирует тип данных "code" как integer на время существования контейнера. Второй документ будет по-прежнему включен в аналитическое хранилище, но его свойство "code" включено не будет.
- {"id": "1", "code":123}
- {"id": "2", "code": "123"}

Примечание

Указанное выше условие не применяется к свойствам со значением NULL. Например, {"a":123} and {"a":NULL} по-прежнему четко определено.

Примечание

При обновлении "code" документа "1" до строки в транзакционном хранилище условие выше не меняется. В аналитическом хранилище "code" будет храниться как integer, поскольку в настоящее время мы не поддерживаем сброс схемы.

Типы массивов должны содержать один повторяющийся тип. Например, {"a": ["str",12]} не является четко определенной схемой, так как массив содержит сочетание целочисленных и строковых типов.

Примечание

Если аналитическое хранилище Azure Cosmos DB соответствует представлению четко определенной схемы, а приведенная выше спецификация нарушается определенными элементами, эти элементы не будут включаться в аналитическое хранилище.

В отношении разных типов четко определенной схемы реализуется другое поведение:
- Пулы Spark в Azure Synapse будут представлять эти столбцы как undefined.
- Бессерверные пулы SQL в Azure Synapse будут представлять эти столбцы как NULL.
В отношении явных значений NULL требуется другое поведение:
- Пулы Spark в Azure Synapse будут считывать эти значения как 0 (ноль). Значение изменится на undefined, как только в столбце будет указано значение, отличное от NULL.
- Бессерверные пулы SQL в Azure Synapse будут считывать эти значения как NULL.
В отношении отсутствующих значений требуется другое поведение:
- Пулы Spark в Azure Synapse будут представлять эти столбцы как undefined.
- Бессерверные пулы SQL в Azure Synapse будут представлять эти столбцы как NULL.

Обходные решения проблем с представлением

Возможно, для создания базовой схемы аналитического хранилища контейнера использовался старый документ с неправильной схемой. На основе всех правил, представленных выше, вы можете получить NULL определенные свойства при запросе к аналитическому хранилищу с помощью Azure Synapse Link. Удаление или обновление проблемных документов не поможет, так как сброс базовой схемы в настоящее время не поддерживается. Возможные решения:

Чтобы перенести данные в новый контейнер, убедитесь, что все документы имеют правильную схему.
Чтобы отказаться от свойства с неправильной схемой и добавить новое свойство с другим именем, которое имеет правильную схему во всех документах. Пример. В контейнере Orders есть миллиарды документов, свойство состояния которых является строкой. Но первый документ в этом контейнере имеет состояние , определенное целым числом. Таким образом, один документ будет иметь состояние правильно представлено, а все остальные документы будут иметь значение NULL. Вы можете добавить свойство status2 во все документы и начать использовать его вместо исходного свойства.

Представление схемы с полной достоверностью

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

Это достигается путем преобразования конечных свойств операционных данных в аналитическое хранилище в виде пар JSON key-value , где тип данных — , key а содержимое свойства — value. Это представление объекта JSON позволяет выполнять запросы без неоднозначности, и вы можете по отдельности анализировать каждый тип данных.

Иными словами, в представлении схемы полной точности каждый тип данных каждого свойства каждого документа создает key-valueпару в объекте JSON для этого свойства. Каждый из них считается одним из 1000 максимальных свойств.

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

{
name: "John Doe",
age: 32,
profession: "Doctor",
address: {
  streetNo: 15850,
  streetName: "NE 40th St.",
  zip: 98052
},
salary: 1000000
}

Вложенный объект address является свойством на корневом уровне документа и будет представлен в виде столбца. Каждое конечное свойство в объекте address будет представлено в виде объекта JSON: {"object":{"streetNo":{"int32":15850},"streetName":{"string":"NE 40th St."},"zip":{"int32":98052}}}.

В отличие от четко определенного представления схемы, метод полной точности позволяет вариативность типов данных. Если следующий документ в этой коллекции приведенного выше примера содержит streetNo строку, она будет представлена в аналитическом хранилище как "streetNo":{"string":15850}. В четко определенном методе схемы он не будет представлен.

Схема типов данных для схемы полной точности

Ниже приведена карта всех типов данных свойств и их представлений в аналитическом хранилище в представлении схемы полной точности:

Тип исходных данных	Суффикс	Пример
Double	".float64"	24.99
Array	".array"	["a", "b"]
Двоичные данные	".binary"	0
Логическое	".bool"	True
Int32	".int32"	123
Int64	".int64"	255486129307
NULL	".NULL"	NULL
Строка	".string"	"ABC"
Отметка времени	".timestamp"	Timestamp(0, 0)
ObjectId	".objectId"	ObjectId("5f3f7b59330ec25c132623a2")
Документ	".object"	{"a": "a"}

В отношении явных значений NULL требуется другое поведение:
- Пулы Spark в Azure Synapse будут считывать эти значения как 0 (ноль).
- Бессерверные пулы SQL в Azure Synapse будут считывать эти значения как NULL.
В отношении отсутствующих значений требуется другое поведение:
- Пулы Spark в Azure Synapse будут представлять эти столбцы как undefined.
- Бессерверные пулы SQL в Azure Synapse будут представлять эти столбцы как NULL.

Использование схемы полной точности со Spark

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

{
	"_id" : "1" ,
	"item" : "Pizza",
	"price" : 3.49,
	"rating" : 3,
	"timestamp" : 1604021952.6790195
},
{
	"_id" : "2" ,
	"item" : "Ice Cream",
	"price" : 1.59,
	"rating" : "4" ,
	"timestamp" : "2022-11-11 10:00 AM"
}

В то время как первый документ имеет rating число и timestamp в формате UTC, второй документ содержит rating и timestamp в виде строк. При условии, что эта коллекция была загружена в DataFrame без преобразования данных, выходные данные будут следующими df.printSchema() :

root
 |-- _rid: string (nullable = true)
 |-- _ts: long (nullable = true)
 |-- id: string (nullable = true)
 |-- _etag: string (nullable = true)
 |-- _id: struct (nullable = true)
 |    |-- objectId: string (nullable = true)
 |-- item: struct (nullable = true)
 |    |-- string: string (nullable = true)
 |-- price: struct (nullable = true)
 |    |-- float64: double (nullable = true)
 |-- rating: struct (nullable = true)
 |    |-- int32: integer (nullable = true)
 |    |-- string: string (nullable = true)
 |-- timestamp: struct (nullable = true)
 |    |-- float64: double (nullable = true)
 |    |-- string: string (nullable = true)
 |-- _partitionKey: struct (nullable = true)
 |    |-- string: string (nullable = true)

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

В приведенном ниже примере мы можем использовать для PySpark выполнения агрегирования:

df.groupBy(df.item.string).sum().show()

В приведенном ниже примере мы можем использовать для PySQL выполнения другого агрегата:

df.createOrReplaceTempView("Pizza")
sql_results = spark.sql("SELECT sum(price.float64),count(*) FROM Pizza where timestamp.string is not null and item.string = 'Pizza'")
sql_results.show()

Использование схемы полной точности с SQL

Учитывая те же документы из приведенного выше примера Spark, клиенты могут использовать следующий пример синтаксиса:

SELECT rating,timestamp_string,timestamp_utc
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating integer '$.rating.int32',    
timestamp varchar(50) '$.timestamp.string',
timestamp_utc float '$.timestamp.float64' 
) as HTAP 
WHERE timestamp is not null or timestamp_utc is not null

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

create view MyView as
SELECT MyRating=rating,MyTimestamp = convert(varchar(50),timestamp_utc)
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating integer '$.rating.int32',    
timestamp_utc float '$.timestamp.float64' 
) as HTAP 
WHERE  timestamp_utc is not null
union all 
SELECT MyRating=convert(integer,rating_string),MyTimestamp = timestamp_string
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating_string varchar(50) '$.rating.string',    
timestamp_string varchar(50) '$.timestamp.string' 
) as HTAP 
WHERE  timestamp_string is not null

Работа с полем `_id` MongoDB

Поле _id MongoDB является фундаментальным для каждой коллекции в MongoDB и изначально имеет шестнадцатеричное представление. Как видно из приведенной выше таблицы, схема полной точности сохранит свои характеристики, что создает трудности для ее визуализации в Azure Synapse Analytics. Для правильной визуализации необходимо преобразовать тип данных _id, как показано ниже:

Работа с полем MongoDB `_id` в Spark

import org.apache.spark.sql.types._
val simpleSchema = StructType(Array(
    StructField("_id", StructType(Array(StructField("objectId",BinaryType,true)) ),true),
    StructField("id", StringType, true)
  ))

df = spark.read.format("cosmos.olap")\
    .option("spark.synapse.linkedService", "<enter linked service name>")\
    .option("spark.cosmos.container", "<enter container name>")\
    .schema(simpleSchema)
    .load()

df.select("id", "_id.objectId").show()

Примечание

Это решение предназначено для работы со Spark 2.4.

Работа с полем MongoDB `_id` в SQL

SELECT TOP 100 id=CAST(_id as VARBINARY(1000))
FROM OPENROWSET('CosmosDB',
                'Your-account;Database=your-database;Key=your-key',
                HTAP) WITH (_id VARCHAR(1000)) as HTAP

Полная схема точности для учетных записей API для NoSQL или Gremlin

Можно использовать полную схему точности для учетных записей API для NoSQL вместо параметра по умолчанию, задав тип схемы при первом включении Synapse Link в учетной записи Azure Cosmos DB. Ниже приведены рекомендации по изменению типа представления схемы по умолчанию.

В настоящее время, если включить Synapse Link в учетной записи API NoSQL с помощью портала Azure, она будет включена как четко определенная схема.
В настоящее время, если вы хотите использовать схему полной точности с учетными записями API NoSQL или Gremlin, необходимо задать ее на уровне учетной записи в той же команде CLI или PowerShell, которая позволит Synapse Link на уровне учетной записи.
В настоящее время Azure Cosmso DB для MongoDB несовместима с такой возможностью изменения представления схемы. У всех учетных записей MongoDB всегда будет представление полноценной схемы.
Невозможно сбросить тип представления схемы от четко определенного до полной точности или наоборот.
В настоящее время схема контейнеров в аналитическом хранилище определяется при создании контейнера, даже если Synapse Link не включена в учетной записи базы данных.
- Контейнеры или графы, созданные до Synapse Link с полной схемой точности на уровне учетной записи, будут иметь четко определенную схему.
- Контейнеры или графы, созданные после включения Synapse Link со схемой полной точности на уровне учетной записи, будут иметь схему полной точности.

Необходимо принять решение о типе представления схемы вместе с включением Synapse Link в учетной записи с помощью Azure CLI или PowerShell.

С помощью Azure CLI:

az cosmosdb create --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup --subscription MySubscription --analytical-storage-schema-type "FullFidelity" --enable-analytical-storage true

Примечание

В приведенной выше команде замените create на update для существующих учетных записей.

С помощью PowerShell:

 New-AzCosmosDBAccount -ResourceGroupName MyResourceGroup -Name MyCosmosDBDatabaseAccount  -EnableAnalyticalStorage true -AnalyticalStorageSchemaType "FullFidelity"

Примечание

В приведенной выше команде замените New-AzCosmosDBAccount на Update-AzCosmosDBAccount для существующих учетных записей.

Аналитическое время жизни (TTL)

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

Аналитическое хранилище включено, если для значения ATTL установлено значение, отличающееся от NULL и 0. После его включения операции вставки, обновления и удаления в операционных данных автоматически синхронизируются из хранилища транзакций в аналитическое хранилище независимо от конфигурации для срока жизни транзакций. Хранением этих данных о транзакциях в аналитическом хранилище можно управлять на уровне контейнера, указав свойство AnalyticalStoreTimeToLiveInSeconds.

Возможные конфигурации ATTL:

Если задано значение 0 или NULL: аналитическое хранилище отключено, а данные из хранилища транзакций в аналитическое хранилище не реплицируются
Если задано значение -1: аналитическое хранилище сохраняет все исторические данные независимо от хранения данных в хранилище транзакций. Этот параметр указывает на бесконечное время хранения операционных данных в аналитическом хранилище.
Если задано любое положительное целое число n: срок хранения элементов в аналитическом хранилище истечет через n секунд после их последнего изменения в хранилище транзакций. Этот параметр можно использовать, если требуется сохранить операционные данные в течение ограниченного периода времени в аналитическом хранилище независимо от хранения данных в хранилище транзакций

Учитывайте следующие факторы.

После активации аналитического хранилища с заданным значением ATTL, это значение можно обновить до другого допустимого значения позднее.
Хотя параметр TTTL можно установить на уровне контейнера или элемента, ATTL можно задать только на уровне контейнера.
Длительное хранение операционных данных в аналитическом хранилище можно обеспечить, задав ATTL >= TTTL на уровне контейнера.
Аналитическое хранилище может быть создано для зеркалирования хранилища транзакций путем установки ATTL равным TTTL.
Если ATTL больше TTTL, через некоторое время вы будете иметь только данные из аналитического хранилища. Эти данные доступны только для чтения.
В настоящее время мы не удаляем данные из аналитического хранилища. Если для ATTL задано любое положительное целое число, данные не будут включены в запросы, и вам не будет выставляться счет за них. Но если вы измените значение ATTL обратно на -1, все данные будут отображаться снова, и вам начнет взиматься плата за весь объем данных.

Сведения о том, как включить аналитическое хранилище в контейнере.

На портале Azure для параметра ATTL (если он включен) устанавливается значение по умолчанию -1. Это значение можно изменить на "n" секунд, перейдя к параметрам контейнера в разделе "Обозреватель данных".
В пакете SDK для управления Azure, пакетах SDK для Azure Cosmos DB, PowerShell или интерфейсе командной строки Azure можно включить параметр ATTL, задав для него значение -1 или "n" секунд.

Дополнительные сведения см. в разделе Настройка аналитического времени жизни для контейнера.

Экономичный анализ исторических данных

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

После включения аналитического хранилища в зависимости от потребностей хранения данных транзакционных рабочих нагрузок можно настроить свойство "время жизни в хранилище транзакций" (transactional TTL), чтобы записи автоматически удалялись из хранилища транзакций по истечении определенного периода времени. Аналогично, "время жизни в аналитическом хранилище" (analytical TTL) позволяет управлять жизненным циклом данных, хранимых в аналитическом хранилище, которое не зависит от хранилища транзакций. Включив аналитическое хранилище и настроив свойства TTL для транзакционного и аналитического хранилищ, можно эффективно распределять данные и определять срок их хранения для двух хранилищ.

Примечание

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

Примечание

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

Устойчивость

Аналитическое хранилище использует службу хранилища Azure и обеспечивает следующую защиту от физического сбоя:

По умолчанию учетные записи базы данных Azure Cosmos DB выделяют аналитическое хранилище в учетных записях локально избыточного хранилища (LRS).
Если какой-либо географический регион учетной записи базы данных настроен для избыточности между зонами, он выделяется в учетных записях хранилища, избыточного между зонами (ZRS). Клиентам необходимо включить Зоны доступности в регионе учетной записи базы данных Azure Cosmos DB, чтобы аналитические данные этого региона хранились в ZRS.

Backup

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

Примечание

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

Synapse Link и, следовательно, аналитическое хранилище имеют разные уровни совместимости с режимами резервного копирования Azure Cosmos DB:

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

Политики резервного копирования

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

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

Теперь давайте посмотрим, как использовать резервное копирование и восстановление при наличии аналитического хранилища.

Восстановление контейнера в случае, когда TTTL >= ATTL

Если значение transactional TTL равно или больше analytical TTL, все данные в аналитическом хранилище сохраняются в транзакционном хранилище. В случае восстановления возможны две ситуации:

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

Восстановление контейнера в случае, когда TTTL < ATTL

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

С использованием восстановленного контейнера в качестве замены исходного контейнера. В этом случае при включении Synapse Link на уровне контейнера в новое аналитическое хранилище будут включены только данные, которые находились в хранилище транзакций. Но обратите внимание, что аналитическое хранилище исходного контейнера остается доступным для запросов до тех пор, пока существует исходный контейнер. Возможно, вам потребуется изменить приложение, чтобы отправлять запросы к обоим хранилищам.
С использованием восстановленного контейнер в качестве источника данных для резервного заполнения или обновления данных в исходном контейнере:
Аналитическое хранилище автоматически отражает операции с данными, которые хранятся в транзакционном хранилище.
При повторной вставке данных, которые ранее были удалены из хранилища транзакций вследствие transactional TTL, эти данные будут дублироваться в аналитическом хранилище.

Пример:

Для контейнера OnlineOrders задано значение TTTL, равное одному месяцу, а ATTL — одному году.
Если восстановить его до OnlineOrdersNew и включить аналитическое хранилище для его перестройки, в хранилище транзакций и аналитическом хранилище будут присутствовать данные только за один месяц.
Исходный контейнер OnlineOrders не удаляется, а его аналитическое хранилище остается доступным.
Новые данные принимаются только в OnlineOrdersNew.
Аналитические запросы выполнят операцию UNION ALL из аналитических хранилищ, пока исходные данные еще актуальны.

Если вы хотите удалить исходный контейнер, но не хотите потерять данные из его аналитического хранилища, вы можете сохранить аналитическое хранилище исходного контейнера в другой службе данных Azure. Synapse Analytics может выполнять операции объединения для данных, сохраненных в разных расположениях. Пример. Запрос Synapse Analytics объединяет данные аналитического хранилища с внешними таблицами в Хранилище BLOB-объектов Azure, Azure Data Lake Store и т. д.

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

Глобальное распределение

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

Секционирование

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

Безопасность

Проверка подлинности для аналитического хранилища совпадает с проверкой для хранилища транзакций в заданной базе данных. Для проверки подлинности можно использовать главные или дополнительные ключи, либо ключи только для чтения. Чтобы не вставлять ключи Azure Cosmos DB в записные книжки Spark, можно использовать связанную службу в Synapse Studio. Для бессерверного SQL в Azure Synapse можно использовать учетные данные SQL, чтобы также предотвратить вставку ключей Azure Cosmos DB в записные книжки SQL. Доступ к этим связанным службам или этим учетным данным SQL есть у всех, кто имеет доступ к рабочей области. Обратите внимание, что также можно использовать ключ только для чтения Azure Cosmos DB.
Сетевая изоляция с использованием частных конечных точек. Сетевым доступом к данным в транзакционных хранилищах и хранилищах аналитических данных можно управлять независимо друг от друга. Сетевая изоляция выполняется с помощью отдельных управляемых частных конечных точек для каждого хранилища в пределах управляемых виртуальных сетей в рабочих областях Azure Synapse. Дополнительные сведения см. в статье Настройка частных конечных точек для хранилища аналитических данных.
Шифрование неактивных данных — шифрование аналитического хранилища включено по умолчанию.
Шифрование с использованием ключей, управляемых клиентом. Можно легко автоматически и прозрачно шифровать данные в транзакционных хранилищах и хранилищах аналитических данных, используя одни и те же ключи, управляемые клиентом. Azure Synapse Link поддерживает только настройку ключей, управляемых клиентом, с помощью управляемого удостоверения учетной записи Azure Cosmos DB. Вам нужно настроить управляемое удостоверение учетной записи в политике доступа Azure Key Vault до того, как вы включите Azure Synapse Link в своей учетной записи. Дополнительные сведения см. в статье Настройка ключей, управляемых клиентом, с помощью управляемых удостоверений учетных записей Azure Cosmos DB.

Примечание

Если изменить учетную запись базы данных с first party на System or User Assigned Identy и включить Azure Synapse Link в учетной записи базы данных, вы не сможете вернуться к удостоверению первой стороны, так как вы не сможете отключить Synapse Link из учетной записи базы данных.

Поддержка нескольких сред выполнения Azure Synapse Analytics

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

Отделив систему аналитического хранилища от аналитической системы вычислений, данные в аналитическом хранилище Azure Cosmos DB можно запрашивать одновременно из разных сред выполнения аналитики, поддерживаемых Azure Synapse Analytics. На сегодняшний день Azure Synapse Analytics поддерживает Apache Spark и бессерверный пул SQL с аналитическим хранилищем Azure Cosmos DB.

Примечание

Чтение данных из аналитического хранилища можно выполнять только с помощью среды выполнения Azure Synapse Analytics. Верно и обратное: среда выполнения Azure Synapse Analytics может считывать данные только из аналитического хранилища. Только процесс автоматической синхронизации может изменять данные в аналитическом хранилище. Вы можете записывать данные обратно в хранилище транзакций Azure Cosmos DB с помощью пула Spark Azure Synapse Analytics, используя встроенный пакет SDK OLTP для Azure Cosmos DB.

Цены

Аналитическое хранилище соответствует модели ценообразования на основе потребления, в которой вы платите за:

Хранилище — объем данных, хранящихся в аналитическом хранилище в течение месяца, включая исторические данные в соответствии с аналитическим TTL.
Аналитические операции записи: полностью управляемая синхронизация обновлений операционных данных в хранилище транзакций (автоматическая синхронизация).
Аналитические операции чтения: операции чтения, выполняемые для аналитического хранилища из сред выполнения пула Spark в Azure Synapse Analytics и бессерверного пула SQL.

Цены на аналитическое хранилище определяются отдельно от модели ценообразования для хранилища транзакций. В аналитическом хранилище нет понятия подготовленных ЕЗ. Подробные сведения о модели ценообразования для аналитического хранилища см. на странице цен для Azure Cosmos DB.

Доступ к данным в аналитическом хранилище можно получить только с помощью Azure Synapse Link, что выполняется в средах выполнения Azure Synapse Analytics: пулы Azure Synapse Apache Spark и бессерверные пулы SQL Azure Synapse. Подробные сведения о модели ценообразования для доступа к данным аналитического хранилища см. на странице цен для Azure Synapse Analytics.

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

Оценки операций чтения аналитического хранилища не включаются в калькулятор затрат Azure Cosmos DB, так как они являются функцией аналитической рабочей нагрузки. Однако, по высокоуровневой оценке, сканирование 1 ТБ данных в аналитическом хранилище обычно приводит к 130 000 аналитических операций чтения и к затратам в размере 0,065 долл. США. Например, если вы используете Azure Synapse бессерверные пулы SQL для выполнения этого сканирования размером 1 ТБ, это будет стоить 5,00 долл. США в соответствии со страницей цен на Azure Synapse Analytics. Итоговая общая стоимость этого сканирования размером 1 ТБ составит 5,065 долл. США.

Хотя приведенная выше оценка относится к сканированию 1 ТБ данных в аналитическом хранилище, применение фильтров уменьшает объем сканируемых данных, и это определяет точное количество аналитических операций чтения для модели ценообразования с тарификацией по мере использования. Пробный проект на аналитической рабочей нагрузке позволил бы получить более точную оценку аналитических операций чтения. Эта оценка не включает затраты на Azure Synapse Analytics.

Дальнейшие действия

Дополнительные сведения см. в следующих документах:

Что такое аналитическое хранилище Azure Cosmos DB?

Сложности крупномасштабного анализа операционных данных

Аналитическое хранилище для столбцов

Возможности аналитического хранилища

Хранилище столбцов для аналитических рабочих нагрузок в операционных данных

Несвязанная производительность для аналитических рабочих нагрузок

Автосинхронизация

Масштабируемость и эластичность

Автоматическая работа с обновлениями схемы

Ограничения схемы

Представление схемы

Четко определенное представление схемы

Обходные решения проблем с представлением

Представление схемы с полной достоверностью

Схема типов данных для схемы полной точности

Использование схемы полной точности со Spark

Использование схемы полной точности с SQL

Работа с полем `_id` MongoDB

Работа с полем MongoDB `_id` в Spark

Работа с полем MongoDB `_id` в SQL

Полная схема точности для учетных записей API для NoSQL или Gremlin

Аналитическое время жизни (TTL)

Экономичный анализ исторических данных

Устойчивость

Backup

Политики резервного копирования

Восстановление контейнера в случае, когда TTTL >= ATTL

Восстановление контейнера в случае, когда TTTL < ATTL

Глобальное распределение

Секционирование

Безопасность

Поддержка нескольких сред выполнения Azure Synapse Analytics

Цены

Дальнейшие действия

Дополнительные ресурсы

Дополнительные ресурсы

Что такое аналитическое хранилище Azure Cosmos DB?

Сложности крупномасштабного анализа операционных данных

Аналитическое хранилище для столбцов

Возможности аналитического хранилища

Хранилище столбцов для аналитических рабочих нагрузок в операционных данных

Несвязанная производительность для аналитических рабочих нагрузок

Автосинхронизация

Масштабируемость и эластичность

Автоматическая работа с обновлениями схемы

Ограничения схемы

Представление схемы

Четко определенное представление схемы

Обходные решения проблем с представлением

Представление схемы с полной достоверностью

Схема типов данных для схемы полной точности

Использование схемы полной точности со Spark

Использование схемы полной точности с SQL

Работа с полем _id MongoDB

Работа с полем MongoDB _id в Spark

Работа с полем MongoDB _id в SQL

Полная схема точности для учетных записей API для NoSQL или Gremlin

Аналитическое время жизни (TTL)

Экономичный анализ исторических данных

Устойчивость

Backup

Политики резервного копирования

Восстановление контейнера в случае, когда TTTL >= ATTL

Восстановление контейнера в случае, когда TTTL < ATTL

Глобальное распределение

Секционирование

Безопасность

Поддержка нескольких сред выполнения Azure Synapse Analytics

Цены

Дальнейшие действия

Дополнительные ресурсы

Дополнительные ресурсы

Работа с полем `_id` MongoDB

Работа с полем MongoDB `_id` в Spark

Работа с полем MongoDB `_id` в SQL