O que é o arquivo analítico do Azure Cosmos DB?

APLICA-SE A: NoSQL MongoDB Gremlin

O arquivo analítico do Azure Cosmos DB é um arquivo de colunas totalmente isolado para permitir análises em grande escala contra dados operacionais no Azure Cosmos DB, sem qualquer impacto nas cargas de trabalho transacionais.

O arquivo transacional do Azure Cosmos DB é agnóstico de esquema e permite-lhe iterar nas suas aplicações transacionais sem ter de lidar com a gestão de esquemas ou índices. Ao contrário disso, o arquivo analítico do Azure Cosmos DB é esquematizado para otimizar o desempenho de consultas analíticas. Este artigo descreve detalhadamente sobre o armazenamento analítico.

Desafios com análises em grande escala em dados operacionais

Os dados operacionais de vários modelos num contentor do Azure Cosmos DB são armazenados internamente num "arquivo transacional" baseado em linhas indexadas. O formato do arquivo de linhas foi concebido para permitir leituras e escritas transacionais rápidas nos tempos de resposta de ordem de milissegundos e consultas operacionais. Se o conjunto de dados aumentar, as consultas analíticas complexas e grandes poderão ser dispendiosas em termos de débito aprovisionado nos dados armazenados neste formato. Por sua vez, o elevado consumo do débito aprovisionado afeta o desempenho das cargas de trabalho transacionais utilizadas pelas suas aplicações e serviços em tempo real.

Tradicionalmente, para analisar grandes quantidades de dados, os dados operacionais são extraídos do arquivo transacional do Azure Cosmos DB e armazenados numa camada de dados separada. Por exemplo, os dados são armazenados num armazém de dados ou data lake num formato adequado. Estes dados são posteriormente utilizados para análise em grande escala e analisados com motores de computação, como os clusters do Apache Spark. A separação da análise dos dados operacionais resulta em atrasos para os analistas que pretendem utilizar os dados mais recentes.

Os pipelines de ETL também se tornam complexos ao processar atualizações para os dados operacionais quando comparados com o processamento apenas de dados operacionais recentemente ingeridos.

Arquivo analítico orientado para colunas

O arquivo analítico do Azure Cosmos DB aborda os desafios de complexidade e latência que ocorrem com os pipelines ETL tradicionais. O arquivo analítico do Azure Cosmos DB pode sincronizar automaticamente os seus dados operacionais num arquivo de colunas separado. O formato do arquivo de colunas é adequado para que as consultas analíticas de grande escala sejam executadas de forma otimizada, o que resulta na melhoria da latência dessas consultas.

Com o Azure Synapse Link, agora pode criar soluções HTAP sem ETL ao ligar diretamente ao arquivo analítico do Azure Cosmos DB a partir do Azure Synapse Analytics. Permite-lhe executar análises em grande escala quase em tempo real nos seus dados operacionais.

Funcionalidades do arquivo analítico

Quando ativa o arquivo analítico num contentor do Azure Cosmos DB, é criado internamente um novo arquivo de colunas com base nos dados operacionais no contentor. Este arquivo de colunas é mantido separadamente do arquivo transacional orientado para linhas para esse contentor, numa conta de armazenamento totalmente gerida pelo Azure Cosmos DB, numa subscrição interna. Os clientes não precisam de passar tempo com a administração do armazenamento. As inserções, atualizações e eliminações dos seus dados operacionais são sincronizadas automaticamente com o arquivo analítico. Não precisa do Feed de Alterações ou ETL para sincronizar os dados.

Arquivo de colunas para cargas de trabalho analíticas em dados operacionais

Normalmente, as cargas de trabalho analíticas envolvem agregações e análises sequenciais de campos selecionados. Ao armazenar os dados numa ordem principal de colunas, o arquivo analítico permite que um grupo de valores para cada campo seja serializado em conjunto. Este formato reduz o IOPS necessário para analisar ou calcular estatísticas em campos específicos. Melhora significativamente os tempos de resposta da consulta para análises em conjuntos de dados grandes.

Por exemplo, se as tabelas operacionais estiverem no seguinte formato:

O arquivo de linhas mantém os dados acima num formato serializado, por linha, no disco. Este formato permite leituras transacionais, escritas e consultas operacionais mais rápidas, tais como "Devolver informações sobre o Produto1". No entanto, à medida que o conjunto de dados cresce grande e se quiser executar consultas analíticas complexas nos dados, pode ser dispendioso. Por exemplo, se quiser obter "as tendências de vendas de um produto na categoria denominada "Equipamento" em diferentes unidades de negócio e meses, tem de executar uma consulta complexa. As análises grandes neste conjunto de dados podem ser dispendiosas em termos de débito aprovisionado e também podem afetar o desempenho das cargas de trabalho transacionais que alimentam as suas aplicações e serviços em tempo real.

O arquivo analítico, que é um arquivo de colunas, é mais adequado para essas consultas porque serializa campos semelhantes de dados em conjunto e reduz o IOPS do disco.

A imagem seguinte mostra o arquivo de linhas transacional vs. arquivo de colunas analíticas no Azure Cosmos DB:

Desempenho desacoplado para cargas de trabalho analíticas

Não há impacto no desempenho das cargas de trabalho transacionais devido a consultas analíticas, uma vez que o arquivo analítico está separado do arquivo transacional. O arquivo analítico não precisa de unidades de pedido (RUs) separadas para serem alocadas.

Sincronização Automática

A Sincronização Automática refere-se à capacidade totalmente gerida do Azure Cosmos DB, onde as inserções, atualizações e eliminações de dados operacionais são automaticamente sincronizadas do arquivo transacional para o arquivo analítico em tempo quase real. Normalmente, a latência de sincronização automática é de 2 minutos. Em casos de base de dados de débito partilhado com um grande número de contentores, a latência de sincronização automática de contentores individuais pode ser maior e demorar até 5 minutos.

No final de cada execução do processo de sincronização automática, os seus dados transacionais estarão imediatamente disponíveis para Azure Synapse runtimes do Analytics:

• Azure Synapse conjuntos do Spark de Análise podem ler todos os dados, incluindo as atualizações mais recentes, através de tabelas do Spark, que são atualizadas automaticamente ou através do spark.read comando, que lê sempre o último estado dos dados.

• Azure Synapse conjuntos sem SERVIDOR SQL do Analytics podem ler todos os dados, incluindo as atualizações mais recentes, através de vistas, que são atualizadas automaticamente ou através SELECTOPENROWSET dos comandos, que leem sempre o estado mais recente dos dados.

Nota

Os dados transacionais serão sincronizados com o arquivo analítico, mesmo que o tempo transacional (TTL) seja inferior a 2 minutos.

Nota

Tenha em atenção que, se eliminar o contentor, o arquivo analítico também será eliminado.

Elasticidade da escalabilidade &

Ao utilizar a criação de partições horizontais, o arquivo transacional do Azure Cosmos DB pode dimensionar elasticamente o armazenamento e o débito sem qualquer período de inatividade. A criação de partições horizontais no arquivo transacional proporciona elasticidade de escalabilidade & na sincronização automática para garantir que os dados são sincronizados com o arquivo analítico em tempo quase real. A sincronização de dados ocorre independentemente do débito de tráfego transacional, seja 1000 operações/seg ou 1 milhão de operações/seg, e não afeta o débito aprovisionado no arquivo transacional.

Processar automaticamente as atualizações de esquema

O arquivo transacional do Azure Cosmos DB é agnóstico de esquema e permite-lhe iterar nas suas aplicações transacionais sem ter de lidar com a gestão de esquemas ou índices. Ao contrário disso, o arquivo analítico do Azure Cosmos DB é esquematizado para otimizar o desempenho de consultas analíticas. Com a capacidade de sincronização automática, o Azure Cosmos DB gere a inferência do esquema através das atualizações mais recentes do arquivo transacional. Também gere a representação do esquema no arquivo analítico que inclui o processamento de tipos de dados aninhados.

À medida que o esquema evolui e as novas propriedades são adicionadas ao longo do tempo, o arquivo analítico apresenta automaticamente um esquema sindicalizado em todos os esquemas históricos no arquivo transacional.

Nota

No contexto do arquivo analítico, consideramos as seguintes estruturas como propriedade:

• JSON "elementos" ou "pares de valor de cadeia separados por " : .
• Objetos JSON, delimitados por { e }.
• Matrizes JSON, delimitadas por [ e ].

Restrições de esquema

As seguintes restrições são aplicáveis aos dados operacionais no Azure Cosmos DB quando ativa o arquivo analítico para inferir automaticamente e representar o esquema corretamente:

• Pode ter um máximo de 1000 propriedades em todos os níveis aninhados no esquema do documento e uma profundidade máxima de aninhamento de 127.

  • Apenas as primeiras 1000 propriedades são representadas no arquivo analítico.
  • Apenas os primeiros 127 níveis aninhados são representados no arquivo analítico.
  • O primeiro nível de um documento JSON é o nível / de raiz.
  • As propriedades no primeiro nível do documento serão representadas como colunas.

• Cenários de exemplo:

  • Se o primeiro nível do documento tiver 2000 propriedades, o processo de sincronização representará as primeiras 1000.
  • Se os seus documentos tiverem cinco níveis com 200 propriedades em cada um, o processo de sincronização representará todas as propriedades.
  • Se os seus documentos tiverem 10 níveis com 400 propriedades em cada um, o processo de sincronização representará totalmente os dois primeiros níveis e apenas metade do terceiro nível.

• O documento hipotético abaixo contém quatro propriedades e três níveis.

  • Os níveis são root, myArraye a estrutura aninhada no myArray.
  • As propriedades são id, myArray, myArray.nested1e myArray.nested2.
  • A representação do arquivo analítico terá duas colunas, ide myArray. Pode utilizar as funções Spark ou T-SQL para expor também as estruturas aninhadas como colunas.

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

• Embora os documentos JSON (e as coleções/contentores do Azure Cosmos DB) sejam sensíveis a maiúsculas e minúsculas da perspetiva de exclusividade, o arquivo analítico não é.

  • No mesmo documento: Os nomes das propriedades no mesmo nível devem ser exclusivos quando comparados sem maiúsculas e minúsculas. Por exemplo, o seguinte documento JSON tem "Nome" e "nome" no mesmo nível. Apesar de ser um documento JSON válido, não satisfaz a restrição de exclusividade e, por conseguinte, não estará totalmente representado no arquivo analítico. Neste exemplo, "Nome" e "nome" são os mesmos quando comparados de forma não sensível a maiúsculas e minúsculas. Só "Name": "fred" será representado no arquivo analítico, uma vez que é a primeira ocorrência. E "name": "john" não será representado de todo.

  {"id": 1, "Name": "fred", "name": "john"}
  

  • Em documentos diferentes: As propriedades no mesmo nível e com o mesmo nome, mas em casos diferentes, serão representadas na mesma coluna, utilizando o formato de nome da primeira ocorrência. Por exemplo, os seguintes documentos JSON têm "Name" e "name" no mesmo nível. Uma vez que o primeiro formato de documento é "Name", é o que será utilizado para representar o nome da propriedade no arquivo analítico. Por outras palavras, o nome da coluna no arquivo analítico será "Name". Ambos "fred" e "john" serão representados, na "Name" coluna.

  {"id": 1, "Name": "fred"}
  {"id": 2, "name": "john"}
  

• O primeiro documento da coleção define o esquema de arquivo analítico inicial.

  • Os documentos com mais propriedades do que o esquema inicial irão gerar novas colunas no arquivo analítico.
  • As colunas não podem ser removidas.
  • A eliminação de todos os documentos numa coleção não repõe o esquema do arquivo analítico.
  • Não existe controlo de versões de esquema. A última versão inferida do arquivo transacional é o que verá no arquivo analítico.

• Atualmente Azure Synapse Spark não consegue ler propriedades que contenham alguns carateres especiais nos respetivos nomes, listados abaixo. Azure Synapse SQL sem servidor não é afetado.

  • :
  • `
  • ,
  • ;
  • {}
  • ()
  • \n
  • \t
  • =
  • "

Nota

Os espaços brancos também estão listados na mensagem de erro do Spark devolvida quando atinge esta limitação. Mas adicionámos um tratamento especial para espaços brancos. Veja mais detalhes nos itens abaixo.

• Se tiver nomes de propriedades com os carateres listados acima, as alternativas são:
  • Altere o modelo de dados com antecedência para evitar estes carateres.
  • Uma vez que atualmente não suportamos a reposição do esquema, pode alterar a sua aplicação para adicionar uma propriedade redundante com um nome semelhante, evitando estes carateres.
  • Utilize o Feed de Alterações para criar uma vista materializada do contentor sem estes carateres nos nomes das propriedades.
  • Utilize a opção dropColumn Spark para ignorar as colunas afetadas e carregar todas as outras colunas para um DataFrame. A sintaxe é:

# 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.cosmos.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.cosmos.dropColumn","FirstName,LastName;StreetName,StreetNumber")\
     .option("spark.cosmos.dropMultiColumnSeparator", ";")\
     .load()  

• Azure Synapse Spark agora suporta propriedades com espaços brancos nos respetivos nomes. Para tal, tem de utilizar a opção allowWhiteSpaceInFieldNames Spark para carregar as colunas afetadas para um DataFrame, mantendo o nome original. A sintaxe é:

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()

• Os seguintes tipos de dados BSON não são suportados e não serão representados no arquivo analítico:

  • Decimal128
  • Expressão Regular
  • Ponteiro da BD
  • JavaScript
  • Símbolo
  • MinKey/MaxKey

• Ao utilizar cadeias DateTime que seguem a norma ISO 8601 UTC, espere o seguinte comportamento:

  • Os conjuntos do Spark no Azure Synapse representam estas colunas como string.
  • Os conjuntos sem servidor SQL no Azure Synapse representam estas colunas como varchar(8000).

• As propriedades com UNIQUEIDENTIFIER (guid) tipos são representadas como string no arquivo analítico e devem ser convertidas VARCHAR em SQL ou string no Spark para visualização correta.

• Os conjuntos sem servidor SQL no Azure Synapse suportam conjuntos de resultados com até 1000 colunas e a exposição de colunas aninhadas também conta para esse limite. É uma boa prática considerar estas informações na sua arquitetura e modelação de dados transacionais.

• Se mudar o nome de uma propriedade, num ou em muitos documentos, esta será considerada uma nova coluna. Se executar o mesmo nome em todos os documentos da coleção, todos os dados serão migrados para a nova coluna e a coluna antiga será representada com NULL valores.

Representação do esquema

Existem dois métodos de representação de esquema no arquivo analítico, válidos para todos os contentores na conta da base de dados. Têm desvantagens entre a simplicidade da experiência de consulta e a conveniência de uma representação columnar mais inclusiva para esquemas polimórficos.

• Representação de esquema bem definida, opção predefinida para API para contas NoSQL e Gremlin.
• Representação de esquema de fidelidade total, opção predefinida para a API para contas mongoDB.

Representação de esquema bem definida

A representação de esquema bem definida cria uma representação tabular simples dos dados agnósticos de esquema no arquivo transacional. A representação de esquema bem definida tem as seguintes considerações:

• O primeiro documento define o esquema base e as propriedades têm de ter sempre o mesmo tipo em todos os documentos. As únicas exceções são:
  • De NULL para qualquer outro tipo de dados. A primeira ocorrência não nula define o tipo de dados de coluna. Qualquer documento que não siga o primeiro tipo de dados não nulo não será representado no arquivo analítico.
  • De float a integer. Todos os documentos são representados no arquivo analítico.
  • De integer a float. Todos os documentos são representados no arquivo analítico. No entanto, para ler estes dados com Azure Synapse conjuntos sem servidor SQL, tem de utilizar uma cláusula WITH para converter a coluna em varchar. Depois desta conversão inicial, é possível convertê-la novamente num número. Verifique o exemplo abaixo, em que o valor inicial numérico era um número inteiro e o segundo era um flutuante.

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]

• As propriedades que não seguem o tipo de dados de esquema base não serão representadas no arquivo analítico. Por exemplo, considere os documentos abaixo: o primeiro definiu o esquema base do arquivo analítico. O segundo documento, em que id é "2", não tem um esquema bem definido, uma vez que a propriedade é uma cadeia "code" e o primeiro documento tem "code" como número. Neste caso, o arquivo analítico regista o tipo de dados como "code"integer para a duração do contentor. O segundo documento continuará a ser incluído no arquivo analítico, mas a respetiva "code" propriedade não.

  • {"id": "1", "code":123}
  • {"id": "2", "code": "123"}

Nota

A condição acima não se aplica a NULL propriedades. Por exemplo, {"a":123} and {"a":NULL} ainda está bem definido.

Nota

A condição acima não será alterada se atualizar "code" o documento "1" para uma cadeia no seu arquivo transacional. No arquivo analítico, "code" será mantido como, uma vez integer que atualmente não suportamos a reposição do esquema.

• Os tipos de matriz têm de conter um único tipo repetido. Por exemplo, {"a": ["str",12]} não é um esquema bem definido porque a matriz contém uma combinação de tipos inteiros e de cadeias.

Nota

Se o arquivo analítico do Azure Cosmos DB seguir a representação de esquema bem definida e a especificação acima for violada por determinados itens, esses itens não serão incluídos no arquivo analítico.

• Espere um comportamento diferente em relação a diferentes tipos num esquema bem definido:

  • Os conjuntos do Spark no Azure Synapse representam estes valores como undefined.
  • Os conjuntos sem servidor SQL no Azure Synapse representam estes valores como NULL.

• Espere um comportamento diferente em relação aos valores explícitos NULL :

  • Os conjuntos do Spark no Azure Synapse ler estes valores como 0 (zero) e assim undefined que a coluna tiver um valor não nulo.
  • Os conjuntos sem servidor SQL no Azure Synapse ler estes valores como NULL.

• Espere um comportamento diferente em relação às colunas em falta:

  • Os conjuntos do Spark no Azure Synapse representam estas colunas como undefined.
  • Os conjuntos sem servidor SQL no Azure Synapse representam estas colunas como NULL.

Soluções alternativas para desafios de representação

É possível que um documento antigo, com um esquema incorreto, tenha sido utilizado para criar o esquema base do arquivo analítico do contentor. Com base em todas as regras apresentadas acima, poderá estar a NULL receber determinadas propriedades ao consultar o seu arquivo analítico com o Azure Synapse Link. Para eliminar ou atualizar os documentos problemáticos não ajudará porque a reposição do esquema base não é atualmente suportada. Soluções possíveis:

• Para migrar os dados para um novo contentor, certifique-se de que todos os documentos têm o esquema correto.
• Para abandonar a propriedade com o esquema errado e adicionar um novo com outro nome que tenha o esquema correto em todos os documentos. Exemplo: tem milhares de milhões de documentos no contentor Encomendasem que a propriedade status é uma cadeia. Mas o primeiro documento nesse contentor tem o estado definido com número inteiro. Assim, um documento terá o estado corretamente representado e todos os outros documentos terão NULL. Pode adicionar a propriedade status2 a todos os documentos e começar a utilizá-la, em vez da propriedade original.

Representação de esquema de fidelidade total

A representação de esquema de fidelidade total foi concebida para processar toda a amplitude dos esquemas polimórficos nos dados operacionais agnósticos de esquema. Nesta representação de esquema, não são removidos itens do arquivo analítico, mesmo que as restrições de esquema bem definidas (que não sejam campos de tipo de dados mistos nem matrizes de tipos de dados mistos) sejam violadas.

Isto é conseguido ao traduzir as propriedades de folha dos dados operacionais para o arquivo analítico como pares JSON key-value , em que o tipo de dados é o key e o conteúdo da propriedade é o value. Esta representação de objetoS JSON permite consultas sem ambiguidade e pode analisar individualmente cada tipo de dados.

Por outras palavras, na representação de esquema de fidelidade total, cada tipo de dados de cada propriedade de cada documento irá gerar um key-valuepar num objeto JSON para essa propriedade. Cada um deles conta como um dos 1000 limite máximo de propriedades.

Por exemplo, vamos utilizar o seguinte documento de exemplo no arquivo transacional:

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

O objeto address aninhado é uma propriedade no nível de raiz do documento e será representado como uma coluna. Cada propriedade de folha no address objeto será representada como um objeto JSON: {"object":{"streetNo":{"int32":15850},"streetName":{"string":"NE 40th St."},"zip":{"int32":98052}}}.

Ao contrário da representação de esquema bem definida, o método de fidelidade total permite a variação nos tipos de dados. Se o próximo documento nesta coleção do exemplo acima tiver streetNo como cadeia, será representado no arquivo analítico como "streetNo":{"string":15850}. No método de esquema bem definido, não seria representado.

Mapa de tipos de dados para o esquema de fidelidade total

Eis um mapa dos tipos de dados do MongoDB e as respetivas representações no arquivo analítico na representação de esquema de fidelidade total. O mapa abaixo não é válido para contas da API NoSQL.

Tipo de dados original	Sufixo	Exemplo
Double (Duplo)	".float64"	24.99
Matriz	".array"	["a", "b"]
Binário	".binário"	0
Booleano	".bool"	Verdadeiro
Int32	".int32"	123
Int64	".int64"	255486129307
NULL	". NULL"	NULL
String	".string"	"ABC"
CarimboDeDataEHora	".timestamp"	Carimbo de data/hora(0, 0)
ObjectId	".objectId"	ObjectId("5f3f7b59330ec25c132623a2")
Documento	".object"	{"a": "a"}

• Espere um comportamento diferente em relação aos valores explícitos NULL :

  • Os conjuntos do Spark no Azure Synapse lerão estes valores como 0 (zero).
  • Os conjuntos sem servidor SQL no Azure Synapse lerão estes valores como NULL.

• Espere um comportamento diferente em relação às colunas em falta:

  • Os conjuntos do Spark no Azure Synapse representarão estas colunas como undefined.
  • Os conjuntos sem servidor SQL no Azure Synapse representarão estas colunas como NULL.

• Espere um comportamento diferente em relação aos timestamp valores:

  • Os conjuntos do Spark no Azure Synapse lerão estes valores como TimestampType, DateTypeou Float. Depende do intervalo e da forma como o carimbo de data/hora foi gerado.
  • Os conjuntos sem SQL Server no Azure Synapse lerão estes valores como DATETIME2, que vão de 0001-01-01 até 9999-12-31. Os valores para além deste intervalo não são suportados e causarão uma falha de execução nas suas consultas. Se for este o seu caso, pode:
    • Remova a coluna da consulta. Para manter a representação, pode criar uma nova propriedade que espelha essa coluna, mas dentro do intervalo suportado. E utilize-o nas suas consultas.
    • Utilize a Captura de Dados alterados do arquivo analítico, sem custos de RUs, para transformar e carregar os dados num novo formato, num dos sinks suportados.

Utilizar o esquema de fidelidade total com o Spark

O Spark irá gerir cada tipo de dados como uma coluna ao carregar para um DataFrame. Vamos assumir uma coleção com os documentos abaixo.

{
	"_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"
}

Embora o primeiro documento tenha rating como número e timestamp em formato utc, o segundo documento tem rating e timestamp como cadeias. Partindo do princípio de que esta coleção foi carregada DataFrame sem qualquer transformação de dados, a saída do 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)

Na representação de esquema bem definida, tanto rating o timestamp como o segundo documento não seriam representados. No esquema de fidelidade total, pode utilizar os seguintes exemplos para aceder individualmente a cada valor de cada tipo de dados.

No exemplo abaixo, podemos utilizar PySpark para executar uma agregação:

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

No exemplo abaixo, podemos utilizar PySQL para executar outra agregação:

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()

Utilizar o esquema de fidelidade total com o SQL

Tendo em conta os mesmos documentos do exemplo do Spark acima, os clientes podem utilizar o seguinte exemplo de sintaxe:

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

A partir da consulta acima, os clientes podem implementar transformações com castou convert qualquer outra função T-SQL para manipular os seus dados. Os clientes também podem ocultar estruturas de tipos de dados complexas com vistas.

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

Trabalhar com o campo MongoDB _id

o campo MongoDB _id é fundamental para todas as coleções no MongoDB e tem originalmente uma representação hexadecimal. Como pode ver na tabela acima, o esquema de fidelidade total preservará as suas características, criando um desafio para a sua visualização no Azure Synapse Analytics. Para uma visualização correta, tem de converter o _id tipo de dados como abaixo:

Trabalhar com o campo MongoDB _id no Spark

O exemplo abaixo funciona nas versões 2.x e 3.x do Spark:

val df = spark.read.format("cosmos.olap").option("spark.synapse.linkedService", "xxxx").option("spark.cosmos.container", "xxxx").load()

val convertObjectId = udf((bytes: Array[Byte]) => {
    val builder = new StringBuilder

    for (b <- bytes) {
        builder.append(String.format("%02x", Byte.box(b)))
    }
    builder.toString
}
 )

val dfConverted = df.withColumn("objectId", col("_id.objectId")).withColumn("convertedObjectId", convertObjectId(col("_id.objectId"))).select("id", "objectId", "convertedObjectId")
display(dfConverted)

Trabalhar com o campo MongoDB _id no 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

Esquema de fidelidade total para a API para contas NoSQL ou Gremlin

É possível utilizar o Esquema de fidelidade total para a API para contas NoSQL, em vez da opção predefinida, ao definir o tipo de esquema ao ativar Synapse Link numa conta do Azure Cosmos DB pela primeira vez. Eis as considerações sobre como alterar o tipo de representação de esquema predefinido:

• Atualmente, se ativar Synapse Link na sua conta da API NoSQL com o portal do Azure, este será ativado como esquema bem definido.
• Atualmente, se quiser utilizar o esquema de fidelidade total com contas noSQL ou a API do Gremlin, tem de o definir ao nível da conta no mesmo comando da CLI ou do PowerShell que irá ativar Synapse Link ao nível da conta.
• Atualmente, o Azure Cosmos DB para MongoDB não é compatível com esta possibilidade de alterar a representação do esquema. Todas as contas do MongoDB têm um tipo de representação de esquema de fidelidade total.
• O mapa de tipos de dados de esquema fidelidade completo mencionado acima não é válido para contas da API NoSQL que utilizam tipos de dados JSON. Por exemplo, float e integer os valores são representados como num no arquivo analítico.
• Não é possível repor o tipo de representação de esquema, de bem definido para fidelidade total ou vice-versa.
• Atualmente, os esquemas de contentores no arquivo analítico são definidos quando o contentor é criado, mesmo que Synapse Link não tenha sido ativado na conta da base de dados.
  • Os contentores ou gráficos criados antes de Synapse Link ter sido ativado com um esquema de fidelidade total ao nível da conta terão um esquema bem definido.
  • Os contentores ou gráficos criados após Synapse Link ter sido ativado com o esquema de fidelidade total ao nível da conta terão um esquema de fidelidade total.

A decisão do tipo de representação de esquema tem de ser tomada ao mesmo tempo que Synapse Link está ativada na conta, com a CLI do Azure ou o PowerShell.

Com a CLI do Azure:

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

Nota

No comando acima, substitua create por update para contas existentes.

Com o PowerShell:

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

Nota

No comando acima, substitua New-AzCosmosDBAccount por Update-AzCosmosDBAccount para contas existentes.

TTL (Time to Live) Analítico

O TTL Analítico (ATTL) indica durante quanto tempo os dados devem ser retidos no seu arquivo analítico, para um contentor.

O arquivo analítico é ativado quando a ATTL é definida com um valor diferente de NULL e 0. Quando ativadas, as inserções, as atualizações e as eliminações de dados operacionais são automaticamente sincronizadas do arquivo transacional para o arquivo analítico, independentemente da configuração TTL (TTTL) transacional. A retenção destes dados transacionais no arquivo analítico pode ser controlada ao nível do AnalyticalStoreTimeToLiveInSeconds contentor pela propriedade .

As possíveis configurações attl são:

• Se o valor estiver definido como 0 ou definido como NULL: o arquivo analítico está desativado e nenhum dados é replicado do arquivo transacional para o arquivo analítico

• Se o valor estiver definido como -1: o arquivo analítico retém todos os dados históricos, independentemente da retenção dos dados no arquivo transacional. Esta definição indica que o arquivo analítico tem uma retenção infinita dos seus dados operacionais

• Se o valor estiver definido para qualquer número inteiro n positivo: os itens expirarão a partir do arquivo n analítico segundos após a hora da última modificação no arquivo transacional. Esta definição pode ser aproveitada se quiser manter os dados operacionais durante um período de tempo limitado no arquivo analítico, independentemente da retenção dos dados no arquivo transacional

Alguns pontos a considerar:

• Depois de o arquivo analítico ser ativado com um valor ATTL, pode ser atualizado para um valor válido diferente mais tarde.
• Embora o TTTL possa ser definido ao nível do contentor ou do item, a ATTL só pode ser definida ao nível do contentor atualmente.
• Pode obter uma retenção mais longa dos seus dados operacionais no arquivo analítico ao definir ATTL >= TTTL ao nível do contentor.
• O arquivo analítico pode ser feito para espelhar o arquivo transacional ao definir ATTL = TTTL.
• Se tiver o ATTL maior que o TTTL, em algum momento terá dados que só existem no arquivo analítico. Estes dados são só de leitura.
• Atualmente, não eliminamos dados do arquivo analítico. Se definir o SEU ATTL para qualquer número inteiro positivo, os dados não serão incluídos nas suas consultas e não lhe será faturado. No entanto, se alterar o ATTL de volta para -1, todos os dados serão apresentados novamente, começará a ser cobrado por todo o volume de dados.

Como ativar o arquivo analítico num contentor:

• No portal do Azure, a opção ATTL, quando ativada, está definida para o valor predefinido de -1. Pode alterar este valor para "n" segundos ao navegar para as definições do contentor em Data Explorer.

• A partir do SDK de Gestão do Azure, dos SDKs do Azure Cosmos DB, do PowerShell ou da CLI do Azure, a opção ATTL pode ser ativada ao defini-la como -1 ou "n" segundos.

Para saber mais, veja como configurar o TTL analítico num contentor.

Análise económica em dados históricos

A camada de dados refere-se à separação de dados entre infraestruturas de armazenamento otimizadas para diferentes cenários. Deste modo, melhora o desempenho geral e a relação custo-eficácia da pilha de dados ponto a ponto. Com o arquivo analítico, o Azure Cosmos DB suporta agora a camada automática de dados do arquivo transacional para o arquivo analítico com esquemas de dados diferentes. Com o arquivo analítico otimizado em termos de custo de armazenamento em comparação com o arquivo transacional, permite-lhe manter horizontes muito mais longos de dados operacionais para análise histórica.

Após a ativação do arquivo analítico, com base nas necessidades de retenção de dados das cargas de trabalho transacionais, pode configurar transactional TTL a propriedade para que os registos sejam eliminados automaticamente do arquivo transacional após um determinado período de tempo. Da mesma forma, permite-lhe analytical TTL gerir o ciclo de vida dos dados retidos no arquivo analítico, independentemente do arquivo transacional. Ao ativar o arquivo analítico e configurar propriedades transacionais e analíticas TTL , pode colocar em camadas e definir de forma totalmente integrada o período de retenção de dados para os dois arquivos.

Nota

Quando analytical TTL for maior do que transactional TTL, o contentor terá dados que só existem no arquivo analítico. Estes dados são só de leitura e atualmente não suportamos o nível TTL do documento no arquivo analítico. Se os dados do contentor precisarem de uma atualização ou de uma eliminação em algum momento no futuro, não utilize analytical TTL maior do que transactional TTL. Esta capacidade é recomendada para dados que não precisarão de atualizações ou eliminações no futuro.

Nota

Se o seu cenário não exigir eliminações físicas, pode adotar uma abordagem lógica de eliminação/atualização. Insira no arquivo transacional outra versão do mesmo documento que só existe no arquivo analítico, mas que precisa de uma eliminação/atualização lógica. Talvez com um sinalizador a indicar que é uma eliminação ou uma atualização de um documento expirado. Ambas as versões do mesmo documento coexistirão no arquivo analítico e a sua aplicação deve considerar apenas a última.

Resiliência

O arquivo analítico depende do Armazenamento do Azure e oferece a seguinte proteção contra falhas físicas:

• Por predefinição, as contas de base de dados do Azure Cosmos DB alocam o arquivo analítico em contas de Armazenamento Localmente Redundante (LRS). O LRS fornece, pelo menos, 99,9999999999% (11 noves) durabilidade de objetos durante um determinado ano.
• Se alguma região geográfica da conta de base de dados estiver configurada para redundância entre zonas, será alocada em contas de Armazenamento com Redundância entre zonas (ZRS). Os clientes precisam de ativar Zonas de Disponibilidade numa região da respetiva conta de base de dados do Azure Cosmos DB para terem dados analíticos dessa região armazenados no Armazenamento com Redundância entre zonas. O ZRS oferece durabilidade para recursos de armazenamento de, pelo menos, 99,999999999999% (12 9 s) durante um determinado ano.

Para obter mais informações sobre a durabilidade do Armazenamento do Azure, clique aqui.

Backup

Embora o arquivo analítico tenha proteção incorporada contra falhas físicas, a cópia de segurança pode ser necessária para eliminações acidentais ou atualizações no arquivo transacional. Nesses casos, pode restaurar um contentor e utilizar o contentor restaurado para efetuar o backfill dos dados no contentor original ou reconstruir totalmente o arquivo analítico, se necessário.

Nota

Atualmente, não é efetuada uma cópia de segurança do arquivo analítico, pelo que não pode ser restaurado. Não é possível planear a política de cópia de segurança com base nisso.

Synapse Link, e arquivo analítico por consequência, tem diferentes níveis de compatibilidade com os modos de cópia de segurança do Azure Cosmos DB:

• O modo de cópia de segurança periódica é totalmente compatível com Synapse Link e estas 2 funcionalidades podem ser utilizadas na mesma conta de base de dados.
• Atualmente, o modo de cópia de segurança contínua e Synapse Link não são suportados na mesma conta de base de dados. Os clientes têm de escolher uma destas duas funcionalidades e esta decisão não pode ser alterada.

Políticas de cópia de segurança

Existem duas políticas de cópia de segurança possíveis e para compreender como utilizá-las, os seguintes detalhes sobre as cópias de segurança do Azure Cosmos DB são muito importantes:

• O contentor original é restaurado sem arquivo analítico em ambos os modos de cópia de segurança.
• O Azure Cosmos DB não suporta a substituição de contentores de um restauro.

Agora, vamos ver como utilizar a cópia de segurança e os restauros a partir da perspetiva do arquivo analítico.

Restaurar um contentor com TTTL >= ATTL

Quando transactional TTL é igual ou maior que analytical TTL, todos os dados no arquivo analítico ainda existem no arquivo transacional. Em caso de restauro, tem duas situações possíveis:

• Para utilizar o contentor restaurado como substituto do contentor original. Para reconstruir o arquivo analítico, basta ativar Synapse Link ao nível da conta e ao nível do contentor.
• Para utilizar o contentor restaurado como uma origem de dados para efetuar o backfill ou atualizar os dados no contentor original. Neste caso, o arquivo analítico refletirá automaticamente as operações de dados.

Restaurar um contentor com o TTTL < ATTL

Quando transactional TTL é menor que analytical TTL, alguns dados só existem no arquivo analítico e não estarão no contentor restaurado. Mais uma vez, tem duas situações possíveis:

• Para utilizar o contentor restaurado como substituto do contentor original. Neste caso, quando ativar Synapse Link ao nível do contentor, apenas os dados que estavam no arquivo transacional serão incluídos no novo arquivo analítico. No entanto, tenha em atenção que o arquivo analítico do contentor original permanece disponível para consultas, desde que o contentor original exista. Poderá querer alterar a sua aplicação para consultar ambos.
• Para utilizar o contentor restaurado como uma origem de dados para efetuar o backfill ou atualizar os dados no contentor original:
• O arquivo analítico refletirá automaticamente as operações de dados dos dados que estão no arquivo transacional.
• Se voltar a inserir dados que foram removidos do arquivo transacional devido a transactional TTL, estes dados serão duplicados no arquivo analítico.

Exemplo:

• O contentor OnlineOrders tem o TTTL definido como um mês e o ATTL definido para um ano.
• Ao restaurá-lo OnlineOrdersNew e ativar o arquivo analítico para o reconstruir, haverá apenas um mês de dados no arquivo transacional e analítico.
• O contentor OnlineOrders original não é eliminado e o respetivo arquivo analítico ainda está disponível.
• Os novos dados só são ingeridos no OnlineOrdersNew.
• As consultas analíticas farão uma UNION ALL a partir de arquivos analíticos enquanto os dados originais ainda são relevantes.

Se quiser eliminar o contentor original, mas não quiser perder os dados do arquivo analítico, pode manter o arquivo analítico do contentor original noutro serviço de dados do Azure. O Synapse Analytics tem a capacidade de realizar associações entre dados armazenados em localizações diferentes. Um exemplo: uma consulta do Synapse Analytics associa dados de arquivo analítico a tabelas externas localizadas no Armazenamento de Blobs do Azure, no Azure Data Lake Store, etc.

É importante ter em atenção que os dados no arquivo analítico têm um esquema diferente do que existe no arquivo transacional. Embora possa gerar instantâneos dos seus dados de arquivo analítico e exportá-los para qualquer serviço de Dados do Azure, sem custos de RUs, não podemos garantir a utilização deste instantâneo para voltar a alimentar o arquivo transacional. Este processo não é suportado.

Distribuição global

Se tiver uma conta do Azure Cosmos DB distribuída globalmente, depois de ativar o arquivo analítico para um contentor, este estará disponível em todas as regiões dessa conta. Todas as alterações aos dados operacionais são replicadas globalmente em todas as regiões. Pode executar consultas analíticas de forma eficaz na cópia regional mais próxima dos seus dados no Azure Cosmos DB.

Criação de partições

A criação de partições de arquivo analítico é completamente independente da criação de partições no arquivo transacional. Por predefinição, os dados no arquivo analítico não são particionados. Se as consultas analíticas tiverem utilizado filtros frequentemente, tem a opção de criar partições com base nestes campos para melhorar o desempenho das consultas. Para saber mais, veja introdução à criação de partições personalizadas e como configurar a criação de partições personalizadas.

Segurança

• A autenticação com o arquivo analítico é igual ao arquivo transacional de uma determinada base de dados. Pode utilizar chaves primárias, secundárias ou só de leitura para autenticação. Pode tirar partido do serviço ligado no Synapse Studio para evitar colar as chaves do Azure Cosmos DB nos blocos de notas do Spark. Para Azure Synapse SQL sem servidor, pode utilizar credenciais SQL para impedir também a colagem das chaves do Azure Cosmos DB nos blocos de notas SQL. O Acesso a estes Serviços Ligados ou a estas credenciais do SQL está disponível para qualquer pessoa que tenha acesso à área de trabalho. Tenha em atenção que a chave só de leitura do Azure Cosmos DB também pode ser utilizada.

• Isolamento de rede com pontos finais privados – pode controlar o acesso de rede aos dados nos arquivos transacionais e analíticos de forma independente. O isolamento de rede é feito através de pontos finais privados geridos separados para cada arquivo, dentro de redes virtuais geridas em Azure Synapse áreas de trabalho. Para saber mais, veja como Configurar pontos finais privados para o artigo arquivo analítico .

• Encriptação de dados inativa – a encriptação do arquivo analítico está ativada por predefinição.

• Encriptação de dados com chaves geridas pelo cliente – pode encriptar os dados de forma totalmente integrada em arquivos transacionais e analíticos com as mesmas chaves geridas pelo cliente de forma automática e transparente. Azure Synapse Link só suporta a configuração de chaves geridas pelo cliente com a identidade gerida da sua conta do Azure Cosmos DB. Tem de configurar a identidade gerida da sua conta na política de acesso do Azure Key Vault antes de ativar o Azure Synapse Link na sua conta. Para saber mais, veja o artigo Configurar chaves geridas pelo cliente com as identidades geridas das contas do Azure Cosmos DB .

Nota

Se alterar a sua conta de base de dados de First Party para System ou User Assigned Identy e ativar o Azure Synapse Link na sua conta de base de dados, não poderá regressar à identidade de Primeira Parte, uma vez que não pode desativar Synapse Link da sua conta de base de dados.

Suporte para vários runtimes do Azure Synapse Analytics

O arquivo analítico está otimizado para proporcionar escalabilidade, elasticidade e desempenho para cargas de trabalho analíticas sem qualquer dependência nos tempos de execução de computação. A tecnologia de armazenamento é gerida automaticamente para otimizar as cargas de trabalho de análise sem esforços manuais.

Ao desassociar o sistema de armazenamento analítico do sistema de computação analítica, os dados no arquivo analítico do Azure Cosmos DB podem ser consultados em simultâneo a partir dos diferentes runtimes de análise suportados pelo Azure Synapse Analytics. A partir de hoje, o Azure Synapse Analytics suporta o Apache Spark e o conjunto de SQL sem servidor com o arquivo analítico do Azure Cosmos DB.

Nota

Só pode ler a partir do arquivo analítico com runtimes do Azure Synapse Analytics. E o contrário também é verdade, Azure Synapse os runtimes do Analytics só podem ser lidos a partir do arquivo analítico. Apenas o processo de sincronização automática pode alterar os dados no arquivo analítico. Pode voltar a escrever dados no arquivo transacional do Azure Cosmos DB com o conjunto do Spark do Azure Synapse Analytics, com o SDK OLTP incorporado do Azure Cosmos DB.

Preços

O arquivo analítico segue um modelo de preços baseado no consumo pelo qual lhe é cobrado:

• Armazenamento: o volume dos dados retidos no arquivo analítico todos os meses, incluindo dados históricos, conforme definido pelo TTL analítico.

• Operações de escrita analítica: a sincronização totalmente gerida de atualizações de dados operacionais para o arquivo analítico a partir do arquivo transacional (sincronização automática)

• Operações de leitura analíticas: as operações de leitura efetuadas no arquivo analítico do conjunto do Spark do Azure Synapse Analytics e os tempos de execução do conjunto de SQL sem servidor.

Os preços do arquivo analítico são separados do modelo de preços do arquivo de transações. Não existe nenhum conceito de RUs aprovisionadas no arquivo analítico. Consulte a página de preços do Azure Cosmos DB para obter detalhes completos sobre o modelo de preços do arquivo analítico.

Os dados no arquivo de análise só podem ser acedidos através do Azure Synapse Link, que é feito nos runtimes do Azure Synapse Analytics: Azure Synapse conjuntos do Apache Spark e Azure Synapse conjuntos de SQL sem servidor. Veja Azure Synapse página de preços do Analytics para obter detalhes completos sobre o modelo de preços para aceder aos dados no arquivo analítico.

Para obter uma estimativa de custos de alto nível para ativar o arquivo analítico num contentor do Azure Cosmos DB, na perspetiva do arquivo analítico, pode utilizar o Planeador de Capacidade do Azure Cosmos DB e obter uma estimativa dos custos de operações de armazenamento e escrita analíticos.

As estimativas de operações de leitura do arquivo analítico não estão incluídas na calculadora de custos do Azure Cosmos DB, uma vez que são uma função da carga de trabalho analítica. Mas, como estimativa de alto nível, a análise de 1 TB de dados no arquivo analítico normalmente resulta em 130.000 operações de leitura analítica e resulta num custo de $0,065. Por exemplo, se utilizar Azure Synapse conjuntos de SQL sem servidor para efetuar esta análise de 1 TB, custará 5,00 $ de acordo com a página de preços do Azure Synapse Analytics. O custo total final desta análise de 1 TB seria $5,065.

Embora a estimativa acima seja para analisar 1 TB de dados no arquivo analítico, a aplicação de filtros reduz o volume de dados analisados, o que determina o número exato de operações de leitura analíticas, dado o modelo de preços de consumo. Uma prova de conceito em torno da carga de trabalho analítica forneceria uma estimativa mais fina das operações de leitura analítica. Esta estimativa não inclui o custo do Azure Synapse Analytics.

Passos seguintes

Para saber mais, veja os seguintes documentos:

• Azure Synapse Link para o Azure Cosmos DB

• Veja o módulo de preparação sobre como Estruturar o processamento transacional e analítico híbrido com o Azure Synapse Analytics

• Introdução ao Azure Synapse Link para o Azure Cosmos DB

• Perguntas mais frequentes sobre o Synapse Link para o Azure Cosmos DB

• Casos de utilização do Azure Synapse Link para o Azure Cosmos DB