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

APLICA-SE A: NoSQL MongoDB Gremlin

Para começar a usar o Azure Synapse Link, visite "Introdução ao Azure Synapse Link"

O repositório analítico do Azure Cosmos DB é um repositório de colunas totalmente isolado para habilitar análises em grande escala em relação a dados operacionais em seu Azure Cosmos DB, sem qualquer impacto em suas cargas de trabalho transacionais.

O repositório transacional do Azure Cosmos DB é independente do esquema e permite que você itere em seus aplicativos transacionais sem ter que lidar com o gerenciamento de esquema ou índice. Em contraste com isso, o repositório analítico do Azure Cosmos DB é esquematizado para otimizar o desempenho da consulta analítica. Este artigo descreve detalhadamente sobre o armazenamento analítico.

Desafios com análises em larga escala em dados operacionais

Os dados operacionais de vários modelos em um contêiner do Azure Cosmos DB são armazenados internamente em um "repositório transacional" baseado em linha indexada. O formato de armazenamento de linhas foi projetado para permitir leituras e gravações transacionais rápidas na ordem de milissegundos, tempos de resposta e consultas operacionais. Se o conjunto de dados crescer, consultas analíticas complexas podem ser caras em termos de taxa de transferência provisionada nos dados armazenados nesse formato. O alto consumo de taxa de transferência provisionada, por sua vez, afeta o desempenho de cargas de trabalho transacionais que são usadas por seus aplicativos e serviços em tempo real.

Tradicionalmente, para analisar grandes quantidades de dados, os dados operacionais são extraídos do repositório transacional do Azure Cosmos DB e armazenados em uma camada de dados separada. Por exemplo, os dados são armazenados em um data warehouse ou data lake em um formato adequado. Esses dados são posteriormente usados para análises em larga escala e analisados usando mecanismos de computação, como os clusters Apache Spark. A separação dos dados analíticos dos operacionais resulta em atrasos para os analistas que desejam usar os dados mais recentes.

Os pipelines de ETL também se tornam complexos ao lidar com atualizações dos dados operacionais quando comparados ao tratamento apenas de dados operacionais recém-ingeridos.

Repositório analítico orientado por colunas

O repositório analítico do Azure Cosmos DB aborda os desafios de complexidade e latência que ocorrem com os pipelines ETL tradicionais. O repositório analítico do Azure Cosmos DB pode sincronizar automaticamente seus dados operacionais em um armazenamento de coluna separado. O formato de armazenamento de colunas é adequado para consultas analíticas em grande escala a serem executadas de forma otimizada, resultando na melhoria da latência dessas consultas.

Usando o Azure Synapse Link, agora você pode criar soluções HTAP sem ETL vinculando diretamente ao repositório analítico do Azure Cosmos DB a partir do Azure Synapse Analytics. Ele permite que você execute análises em larga escala quase em tempo real em seus dados operacionais.

Características da loja analítica

Quando você habilita o repositório analítico em um contêiner do Azure Cosmos DB, um novo repositório de colunas é criado internamente com base nos dados operacionais em seu contêiner. Esse repositório de coluna é mantido separadamente do repositório transacional orientado a linha para esse contêiner, em uma conta de armazenamento totalmente gerenciada pelo Azure Cosmos DB, em uma assinatura interna. Os clientes não precisam gastar tempo com a administração do armazenamento. As inserções, atualizações e exclusões dos dados operacionais são sincronizadas automaticamente com o armazenamento analítico. Você não precisa do Change Feed ou ETL para sincronizar os dados.

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

As cargas de trabalho analíticas normalmente envolvem agregações e verificações sequenciais de campos selecionados. O armazenamento analítico de dados é armazenado em uma ordem de coluna maior, permitindo que os valores de cada campo sejam serializados juntos, quando aplicável. Esse formato reduz as IOPS necessárias para digitalizar ou calcular estatísticas em campos específicos. Ele melhora drasticamente os tempos de resposta de consulta para verificações em grandes conjuntos de dados.

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

O armazenamento de linha persiste os dados acima em um formato serializado, por linha, no disco. Esse formato permite leituras, gravações e consultas operacionais transacionais mais rápidas, como "Retornar informações sobre o Produto 1". No entanto, à medida que o conjunto de dados cresce e se você quiser executar consultas analíticas complexas nos dados, isso pode ser caro. Por exemplo, se você quiser obter "as tendências de vendas de um produto na categoria chamada 'Equipamento' em diferentes unidades de negócios e meses", você precisa executar uma consulta complexa. Grandes verificações nesse conjunto de dados podem ficar caras em termos de taxa de transferência provisionada e também podem afetar o desempenho das cargas de trabalho transacionais que alimentam seus aplicativos e serviços em tempo real.

O armazenamento analítico, que é um armazenamento de colunas, é mais adequado para essas consultas porque serializa campos de dados semelhantes juntos e reduz as IOPS do disco.

A imagem a seguir mostra o repositório de linhas transacionais versus o armazenamento de colunas analíticas no Azure Cosmos DB:

Desempenho dissociado para cargas de trabalho analíticas

Não há impacto no desempenho de suas cargas de trabalho transacionais devido a consultas analíticas, pois o repositório analítico é separado do repositório transacional. O armazenamento analítico não precisa de unidades de solicitação separadas (RUs) para ser alocado.

Sincronização automática

A Sincronização Automática refere-se à capacidade totalmente gerenciada do Azure Cosmos DB, onde as inserções, atualizações e exclusões de dados operacionais são sincronizadas automaticamente do repositório transacional para o repositório analítico quase em tempo real. A latência de sincronização automática geralmente é de 2 minutos. Em casos de banco de dados de taxa de transferência compartilhado com um grande número de contêineres, a latência de sincronização automática de contêineres individuais pode ser maior e levar até 5 minutos.

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

• Os pools do Azure Synapse Analytics Spark podem ler todos os dados, incluindo as atualizações mais recentes, por meio de tabelas do Spark, que são atualizadas automaticamente, ou por meio do spark.read comando, que sempre lê o último estado dos dados.

• Os pools SQL Serverless do Azure Synapse Analytics podem ler todos os dados, incluindo as atualizações mais recentes, por meio de modos de exibição, que são atualizados automaticamente, ou por meio SELECT OPENROWSET dos comandos, que sempre lêem o status mais recente dos dados.

Escalabilidade e elasticidade

O repositório transacional do Azure Cosmos DB usa particionamento horizontal para dimensionar elasticamente o armazenamento e a taxa de transferência sem qualquer tempo de inatividade. O particionamento horizontal no repositório transacional fornece escalabilidade e elasticidade na sincronização automática para garantir que os dados sejam sincronizados com o repositório analítico quase em tempo real. A sincronização de dados acontece independentemente da taxa de transferência de tráfego transacional, seja 1000 operações/s ou 1 milhão de operações/seg, e não afeta a taxa de transferência provisionada no repositório transacional.

Lidar automaticamente com atualizações de esquema

O repositório transacional do Azure Cosmos DB é independente do esquema e permite que você itere em seus aplicativos transacionais sem ter que lidar com o gerenciamento de esquema ou índice. Em contraste com isso, o repositório analítico do Azure Cosmos DB é esquematizado para otimizar o desempenho da consulta analítica. Com o recurso de sincronização automática, o Azure Cosmos DB gerencia a inferência de esquema sobre as atualizações mais recentes do repositório transacional. Ele também gerencia a representação do esquema no repositório analítico pronto para uso, o que inclui o tratamento de tipos de dados aninhados.

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

Restrições de esquema

As restrições a seguir são aplicáveis aos dados operacionais no Azure Cosmos DB quando você habilita o repositório analítico para inferir e representar automaticamente o esquema corretamente:

• Você 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 repositório analítico.
  • Apenas os primeiros 127 níveis aninhados são representados no repositório analítico.
  • O primeiro nível de um documento JSON é o seu / nível 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 delas.
  • Se os 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 dentro do myArray.
  • As propriedades são id, myArray, myArray.nested1, e myArray.nested2.
  • A representação analítica da loja terá duas colunas, ide myArray. Você pode usar funções Spark ou T-SQL para também expor as estruturas aninhadas como colunas.

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

• Embora os documentos JSON (e coleções/contêineres do Azure Cosmos DB) diferenciem maiúsculas de minúsculas do ponto de vista da exclusividade, o repositório analítico não é.

  • No mesmo documento: Os nomes de propriedades no mesmo nível devem ser exclusivos quando comparados sem distinção entre maiúsculas e minúsculas. Por exemplo, o seguinte documento JSON tem "Name" e "name" no mesmo nível. Embora seja um documento JSON válido, ele não satisfaz a restrição de exclusividade e, portanto, não será totalmente representado no repositório analítico. Neste exemplo, "Nome" e "nome" são os mesmos quando comparados de forma que não diferencia maiúsculas de minúsculas. Só "Name": "fred" será representado no repositório analítico, pois é a primeira ocorrência. E "name": "john" não estará representado.

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

  • Em documentos diferentes: Propriedades no mesmo nível e com o mesmo nome, mas em casos diferentes, serão representadas dentro da mesma coluna, usando o formato de nome da primeira ocorrência. Por exemplo, os seguintes documentos JSON têm "Name" e "name" no mesmo nível. Como o primeiro formato de documento é "Name", é isso que será usado para representar o nome da propriedade no repositório analítico. Em outras palavras, o nome da coluna no repositório 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 armazenamento analítico inicial.

  • Documentos com mais propriedades do que o esquema inicial gerarão novas colunas no repositório analítico.
  • As colunas não podem ser removidas.
  • A exclusão de todos os documentos de uma coleção não redefine o esquema de armazenamento analítico.
  • Não há controle de versão de esquema. A última versão inferida do repositório transacional é o que você verá no repositório analítico.

• Atualmente, o Azure Synapse Spark não pode ler propriedades que contêm alguns caracteres especiais em seus nomes, listados abaixo. O Azure Synapse SQL serverless não é afetado.

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

• Se você tiver nomes de propriedades usando os caracteres listados acima, as alternativas são:
  • Altere seu modelo de dados com antecedência para evitar esses caracteres.
  • Como atualmente não suportamos a redefinição de esquema, você pode alterar seu aplicativo para adicionar uma propriedade redundante com um nome semelhante, evitando esses caracteres.
  • Use Alterar feed para criar uma exibição materializada do contêiner sem esses caracteres nos nomes das propriedades.
  • Use a dropColumn opção Spark para ignorar as colunas afetadas e carregar todas as outras colunas em 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()  

• O Azure Synapse Spark agora dá suporte a propriedades com espaços em branco em seus nomes. Para isso, você precisa usar a allowWhiteSpaceInFieldNames opção Spark para carregar as colunas afetadas em 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 repositório analítico:

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

• Ao usar cadeias de caracteres DateTime que seguem o padrão ISO 8601 UTC, espere o seguinte comportamento:

  • Os pools de faíscas no Azure Synapse representam essas colunas como string.
  • Os pools sem servidor do SQL no Azure Synapse representam essas colunas como varchar(8000).

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

• Os pools sem servidor do 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 essas informações em sua arquitetura e modelagem de dados transacionais.

• Se você renomear uma propriedade, em um ou vários documentos, ela será considerada uma nova coluna. Se você executar a mesma renomeação 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

Há dois métodos de representação de esquema no repositório analítico, válidos para todos os contêineres na conta de banco de dados. Eles têm compensações entre a simplicidade da experiência de consulta versus a conveniência de uma representação colunar mais inclusiva para esquemas polimórficos.

• Representação de esquema bem definida, opção padrão para API para contas NoSQL e Gremlin.
• Representação de esquema de fidelidade total, opção padrão para 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 repositório transacional. A representação de esquema bem definida tem as seguintes considerações:

• O primeiro documento define o esquema base e as propriedades devem ter sempre o mesmo tipo em todos os documentos. As únicas exceções são:
  • De para qualquer outro tipo de NULL dados. A primeira ocorrência não nula define o tipo de dados da coluna. Qualquer documento que não siga o primeiro tipo de dados não nulo não será representado no repositório analítico.
  • De float a integer. Todos os documentos são representados no repositório analítico.
  • De integer a float. Todos os documentos são representados no repositório analítico. No entanto, para ler esses dados com os pools sem servidor SQL do Azure Synapse, você deve usar uma cláusula WITH para converter a coluna em varchar. E após essa conversão inicial, é possível convertê-lo novamente em um número. Por favor, verifique o exemplo abaixo, onde um valor inicial era um inteiro e o segundo era um float.

SELECT CAST (num as float) as num
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) 
WITH (num varchar(100)) AS [IntToFloat]

• As propriedades que não seguem o tipo de dados do esquema base não serão representadas no repositório analítico. Por exemplo, considere os documentos abaixo: o primeiro definiu o esquema de base de armazenamento analítico. O segundo documento, onde id é "2", não tem um esquema bem definido, uma vez que a propriedade "code" é uma cadeia de caracteres e o primeiro documento tem "code" como um número. Nesse caso, o armazenamento analítico registra o tipo de dados como integer para o tempo de "code" vida do contêiner. O segundo documento ainda será incluído no repositório analítico, mas sua "code" propriedade não.

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

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

• Espere um comportamento diferente em relação a diferentes tipos em esquemas bem definidos:

  • Os pools de faíscas no Azure Synapse representam esses valores como undefined.
  • Os pools sem servidor do SQL no Azure Synapse representam esses valores como NULL.

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

  • Os pools de faíscas no Azure Synapse leem esses valores como 0 (zero) e assim undefined que a coluna tiver um valor não nulo.
  • Os pools sem servidor do SQL no Azure Synapse leem esses valores como NULL.

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

  • Os pools de faíscas no Azure Synapse representam essas colunas como undefined.
  • Os pools sem servidor do SQL no Azure Synapse representam essas colunas como NULL.

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

É possível que um documento antigo, com um esquema incorreto, tenha sido usado para criar o esquema base de armazenamento analítico do contêiner. Com base em todas as regras apresentadas acima, você pode estar recebendo NULL determinadas propriedades ao consultar seu repositório analítico usando o Azure Synapse Link. Excluir ou atualizar os documentos problemáticos não ajudará porque a redefinição do esquema base não é suportada no momento. Soluções possíveis:

• Para migrar os dados para um novo contêiner, certifique-se de que todos os documentos tenham 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: Você tem bilhões de documentos no contêiner Orders onde a propriedade status é uma cadeia de caracteres. Mas o primeiro documento nesse contêiner tem status definido com inteiro. Assim, um documento terá status corretamente representado e todos os outros documentos terão NULL. Você pode adicionar a propriedade status2 a todos os documentos e começar a usá-la, em vez da propriedade original.

Representação de esquema de fidelidade total

A representação de esquema de fidelidade total é projetada para lidar com toda a amplitude de esquemas polimórficos nos dados operacionais agnósticos de esquema. Nessa representação de esquema, nenhum item é descartado do repositório analítico, mesmo que as restrições de esquema bem definidas (ou seja, não há campos de tipo de dados mistos nem matrizes de tipo de dados mistos) sejam violadas.

Isso é conseguido traduzindo as propriedades de folha dos dados operacionais para o armazenamento analítico como pares JSON key-value , onde o tipo de dados é o key e o conteúdo da propriedade é o value. Essa representação de objeto JSON permite consultas sem ambiguidade, e você pode analisar individualmente cada tipo de dados.

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

Por exemplo, vamos pegar o seguinte documento de exemplo no repositório 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 raiz do documento e será representado como uma coluna. Cada propriedade leaf 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 variação nos tipos de dados. Se o próximo documento desta coleção do exemplo acima tiver streetNo como uma cadeia de caracteres, ele será representado no repositório analítico como "streetNo":{"string":15850}. No método de esquema bem definido, ele não seria representado.

Mapa de tipos de dados para esquema de fidelidade total

Aqui está um mapa dos tipos de dados do MongoDB e suas representações no repositório analítico em representação de esquema de fidelidade total. O mapa abaixo não é válido para contas de API NoSQL.

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

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

  • Os pools de faíscas no Azure Synapse lerão esses valores como 0 (zero).
  • Os pools sem servidor do SQL no Azure Synapse lerão esses valores como NULL.

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

  • Os pools de faíscas no Azure Synapse representarão essas colunas como undefined.
  • Os pools sem servidor do SQL no Azure Synapse representarão essas colunas como NULL.

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

  • Os pools de faíscas no Azure Synapse lerão esses valores como TimestampType, DateTypeou Float. Depende do intervalo e de como o carimbo de data/hora foi gerado.
  • Os pools do SQL Serverless no Azure Synapse lerão esses valores como DATETIME2, variando de 0001-01-01 até 9999-12-31. Valores além desse intervalo não são suportados e causarão uma falha de execução para suas consultas. Se este for o seu caso, pode:
    • Remova a coluna da consulta. Para manter a representação, você pode criar uma nova propriedade espelhando essa coluna, mas dentro do intervalo suportado. E use-o em suas consultas.
    • Use o Change Data Capture do armazenamento analítico, sem custo de RUs, para transformar e carregar os dados em um novo formato, dentro de um dos coletores suportados.

Usando o esquema de fidelidade total com o Spark

O Spark gerenciará cada tipo de dados como uma coluna ao carregar em um DataFramearquivo . Vamos supor 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"
}

Enquanto o primeiro documento tem rating como um número e timestamp em formato utc, o segundo documento tem rating e timestamp como strings. Supondo que essa coleção foi carregada sem DataFrame qualquer transformação de dados, a df.printSchema() saída do é:

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, ambos e rating timestamp do segundo documento não seriam representados. No esquema de fidelidade total, você pode usar os exemplos a seguir para acessar individualmente cada valor de cada tipo de dados.

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

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

No exemplo abaixo, podemos usar 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()

Usando o esquema de fidelidade total com SQL

Você pode usar o seguinte exemplo de sintaxe, com os mesmos documentos do exemplo do Spark acima:

SELECT rating,timestamp_string,timestamp_utc
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<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

Você pode implementar transformações usando casto , convert ou qualquer outra função T-SQL para manipular seus dados. Você também pode ocultar estruturas de tipo de dados complexas usando modos de exibição.

create view MyView as
SELECT MyRating=rating,MyTimestamp = convert(varchar(50),timestamp_utc)
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) ( 
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=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) WITH ( 
rating_string varchar(50) '$.rating.string',    
timestamp_string varchar(50) '$.timestamp.string' 
) as HTAP 
WHERE  timestamp_string is not null

Trabalhando com o campo MongoDB _id

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

Trabalhando com o campo MongoDB _id no Spark

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

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)

Trabalhando com o campo MongoDB _id em SQL

SELECT TOP 100 id=CAST(_id as VARBINARY(1000))
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
HTAP) WITH (_id VARCHAR(1000)) as HTAP

Trabalhando com o campo MongoDB id

A id propriedade nos contêineres do MongoDB é automaticamente substituída pela representação Base64 da propriedade "_id", ambas no repositório analítico. O campo "id" destina-se ao uso interno por aplicativos MongoDB. Atualmente, a única solução é renomear a propriedade "id" para algo diferente de "id".

Esquema de fidelidade total para API para contas NoSQL ou Gremlin

É possível usar o Esquema de fidelidade total para API para contas NoSQL, em vez da opção padrão, definindo o tipo de esquema ao habilitar o Synapse Link em uma conta do Azure Cosmos DB pela primeira vez. Aqui estão as considerações sobre como alterar o tipo de representação de esquema padrão:

• Atualmente, se você habilitar o Synapse Link em sua conta da API NoSQL usando o portal do Azure, ele será habilitado como esquema bem definido.
• Atualmente, se você quiser usar o esquema de fidelidade total com contas de API NoSQL ou Gremlin, será necessário defini-lo no nível da conta no mesmo comando CLI ou PowerShell que habilitará o Synapse Link no nível da conta.
• Atualmente, o Azure Cosmos DB para MongoDB não é compatível com essa possibilidade de alterar a representação do esquema. Todas as contas MongoDB têm tipo de representação de esquema de fidelidade total.
• O mapa de tipos de dados do esquema Full Fidelity mencionado acima não é válido para contas de API NoSQL que usam tipos de dados JSON. Como exemplo, float e integer os valores são representados como num no repositório analítico.
• Não é possível redefinir o tipo de representação de esquema, de bem definido para fidelidade total ou vice-versa.
• Atualmente, os esquemas de contêineres no repositório analítico são definidos quando o contêiner é criado, mesmo que o Synapse Link não tenha sido habilitado na conta do banco de dados.
  • Os contêineres ou gráficos criados antes do Synapse Link ser habilitado com esquema de fidelidade total no nível da conta terão um esquema bem definido.
  • Os contêineres ou gráficos criados após a ativação do Synapse Link com esquema de fidelidade total no nível da conta terão esquema de fidelidade total.

A decisão de tipo de representação de esquema deve ser tomada ao mesmo tempo em que o Synapse Link está habilitado na conta, usando 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

Com o PowerShell:

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

Tempo de Vida Analítico (TTL)

O TTL analítico (ATTL) indica por quanto tempo os dados devem ser retidos em seu armazenamento analítico, para um contêiner.

O armazenamento analítico é ativado quando a ATTL é definida com um valor diferente de NULL e 0. Quando habilitado, inserções, atualizações e exclusões de dados operacionais são sincronizados automaticamente do armazenamento transacional para o armazenamento analítico, independentemente da configuração de TTL transacional (TTTL). A retenção desses dados transacionais no armazenamento analítico pode ser controlada no nível do AnalyticalStoreTimeToLiveInSeconds contêiner pela propriedade.

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

• Se o valor for definido como 0: o repositório analítico será desativado e nenhum dado será replicado do repositório transacional para o repositório analítico. Abra um caso de suporte para desativar o armazenamento analítico em seus contêineres.

• Se o campo for omitido, nada acontece e o valor anterior é mantido.

• Se o valor for definido como -1: o repositório analítico retém todos os dados históricos, independentemente da retenção dos dados no repositório transacional. Essa configuração indica que o repositório analítico tem retenção infinita de seus dados operacionais

• Se o valor for definido como qualquer número inteiro n positivo: os itens expirarão do repositório n analítico segundos após a última modificação no repositório transacional. Essa configuração pode ser aproveitada se você quiser reter seus dados operacionais por um período limitado de tempo no repositório analítico, independentemente da retenção dos dados no repositório transacional

Alguns pontos a considerar:

• Depois que o repositório analítico é habilitado com um valor ATTL, ele pode ser atualizado para um valor válido diferente posteriormente.
• Enquanto o TTTL pode ser definido no nível do contêiner ou do item, o ATTL só pode ser definido no nível do contêiner atualmente.
• Você pode obter uma retenção mais longa de seus dados operacionais no repositório analítico definindo ATTL >= TTTL no nível do contêiner.
• O armazenamento analítico pode ser feito para espelhar o armazenamento transacional definindo ATTL = TTTL.
• Se você tiver ATTL maior que TTTL, em algum momento você terá dados que só existem no armazenamento analítico. Esses dados são somente leitura.
• Atualmente, não excluímos nenhum dado do repositório analítico. Se você definir sua ATTL para qualquer número inteiro positivo, os dados não serão incluídos em suas consultas e você não será cobrado por isso. Mas se você alterar ATTL de volta para -1, todos os dados aparecerão novamente, você começará a ser cobrado por todo o volume de dados.

Como habilitar o armazenamento analítico em um recipiente:

• No portal do Azure, a opção ATTL, quando ativada, é definida como o valor padrão de -1. Você pode alterar esse valor para 'n' segundos, navegando até as configurações de contêiner no Data Explorer.

• No SDK de Gerenciamento do Azure, SDKs do Azure Cosmos DB, PowerShell ou CLI do Azure, a opção ATTL pode ser habilitada definindo-a como -1 ou 'n' segundos.

Para saber mais, consulte como configurar o TTL analítico em um contêiner.

Análise econômica de dados históricos

A hierarquização de dados refere-se à separação de dados entre infraestruturas de armazenamento otimizadas para diferentes cenários. Melhorando assim o desempenho geral e a relação custo-benefício da pilha de dados de ponta a ponta. Com o repositório analítico, o Azure Cosmos DB agora oferece suporte à hierarquização automática de dados do repositório transacional para o repositório analítico com layouts de dados diferentes. Com o armazenamento analítico otimizado em termos de custo de armazenamento em comparação com o armazenamento transacional, permite reter horizontes muito mais longos de dados operacionais para análise histórica.

Depois que o repositório analítico estiver habilitado, com base nas necessidades de retenção de dados das cargas de trabalho transacionais, você poderá configurar transactional TTL a propriedade para que os registros sejam excluídos automaticamente do repositório transacional após um determinado período de tempo. Da mesma forma, o analytical TTL permite gerenciar o ciclo de vida dos dados retidos no repositório analítico, independentemente do repositório transacional. Ao habilitar o armazenamento analítico e configurar propriedades transacionais e analíticas TTL , você pode hierarquizar e definir perfeitamente o período de retenção de dados para os dois armazenamentos.

Resiliência

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

• Por padrão, as contas de banco de dados do Azure Cosmos DB alocam armazenamento analítico em contas LRS (Armazenamento Localmente Redundante). LRS fornece pelo menos 99,9999999999% (11 noves) de durabilidade de objetos ao longo de um determinado ano.
• Se qualquer região geográfica da conta de banco de dados estiver configurada para redundância de zona, ela será alocada em contas ZRS (Armazenamento com Redundância de Zona). Você precisa habilitar as Zonas de Disponibilidade em uma região de sua conta de banco de dados do Azure Cosmos DB para ter dados analíticos dessa região armazenados no Armazenamento com redundância de zona. O ZRS oferece uma durabilidade para recursos de armazenamento de pelo menos 99,9999999999% (12 9's) ao longo de um determinado ano.

Para obter mais informações sobre a durabilidade do Armazenamento do Azure, consulte este link.

Backup

Embora o armazenamento analítico tenha proteção integrada contra falhas físicas, o backup pode ser necessário para exclusões acidentais ou atualizações no armazenamento transacional. Nesses casos, você pode restaurar um contêiner e usar o contêiner restaurado para preencher os dados no contêiner original ou reconstruir totalmente o armazenamento analítico, se necessário.

O Synapse Link e o armazenamento analítico por consequência têm diferentes níveis de compatibilidade com os modos de backup do Azure Cosmos DB:

• O modo de backup periódico é totalmente compatível com o Synapse Link e esses 2 recursos podem ser usados na mesma conta de banco de dados.
• Synapse Link para contas de banco de dados usando o modo de backup contínuo é GA.
• O modo de backup contínuo para contas habilitadas para Synapse Link está em visualização pública. Atualmente, você não pode migrar para o backup contínuo se tiver desativado o Synapse Link em qualquer uma de suas coleções em uma conta do Cosmos DB.

Políticas de cópia de segurança

Há duas políticas de backup possíveis e, para entender como usá-las, os seguintes detalhes sobre os backups do Azure Cosmos DB são muito importantes:

• O contêiner original é restaurado sem armazenamento analítico em ambos os modos de backup.
• O Azure Cosmos DB não oferece suporte à substituição de contêineres de uma restauração.

Agora vamos ver como usar o backup e as restaurações do ponto de vista do repositório analítico.

Restaurando um contêiner com TTTL >= ATTL

Quando transactional TTL é igual ou maior que analytical TTL, todos os dados no repositório analítico ainda existem no repositório transacional. No caso de uma restauração, você tem duas situações possíveis:

• Para usar o contêiner restaurado como um substituto para o contêiner original. Para reconstruir o repositório analítico, basta ativar o Synapse Link no nível da conta e do contêiner.
• Para usar o contêiner restaurado como uma fonte de dados para preencher ou atualizar os dados no contêiner original. Nesse caso, o armazenamento analítico refletirá automaticamente as operações de dados.

Restaurando um contêiner com TTTL < ATTL

Quando transactional TTL é menor que analytical TTL, alguns dados só existem no armazenamento analítico e não estarão no contêiner restaurado. Novamente, você tem duas situações possíveis:

• Para usar o contêiner restaurado como um substituto para o contêiner original. Nesse caso, quando você habilita o Synapse Link no nível do contêiner, somente os dados que estavam no armazenamento transacional serão incluídos no novo repositório analítico. Mas tenha em atenção que o armazenamento analítico do recipiente original permanece disponível para consultas enquanto o recipiente original existir. Você pode querer alterar seu aplicativo para consultar ambos.
• Para usar o contêiner restaurado como uma fonte de dados para preencher ou atualizar os dados no contêiner original:
• O armazenamento analítico refletirá automaticamente as operações de dados para os dados que estão no armazenamento transacional.
• Se você reinserir dados que foram removidos anteriormente do armazenamento transacional devido ao transactional TTL, esses dados serão duplicados no repositório analítico.

Exemplo:

• Container OnlineOrders tem TTTL definido para um mês e ATTL definido para um ano.
• Quando você restaurá-lo OnlineOrdersNew e ativar o repositório analítico para reconstruí-lo, haverá apenas um mês de dados no repositório transacional e analítico.
• O contêiner OnlineOrders original não é excluído e seu armazenamento analítico ainda está disponível.
• Novos dados são ingeridos apenas no OnlineOrdersNew.
• As consultas analíticas farão uma UNIÃO ALL a partir de armazenamentos analíticos enquanto os dados originais ainda são relevantes.

Se você quiser excluir o contêiner original, mas não quiser perder seus dados de armazenamento analítico, poderá persistir o repositório analítico do contêiner original em outro serviço de dados do Azure. O Synapse Analytics tem a capacidade de realizar junções entre dados armazenados em locais diferentes. Um exemplo: uma consulta do Synapse Analytics une dados de armazenamento analítico com tabelas externas localizadas no Armazenamento de Blobs do Azure, no Repositório Azure Data Lake, etc.

É importante notar que os dados no repositório analítico têm um esquema diferente do que existe no repositório transacional. Embora você possa gerar instantâneos de seus dados de armazenamento analítico e exportá-los para qualquer serviço de Dados do Azure, sem custos de RUs, não podemos garantir o uso desse instantâneo para retroalimentar o repositório transacional. Este processo não é suportado.

Distribuição global

Se você tiver uma conta do Azure Cosmos DB distribuída globalmente, depois de habilitar o armazenamento analítico para um contêiner, ele estará disponível em todas as regiões dessa conta. Quaisquer alterações nos dados operacionais são replicadas globalmente em todas as regiões. Você pode executar consultas analíticas de forma eficaz na cópia regional mais próxima de seus dados no Azure Cosmos DB.

Criação de partições

O particionamento analítico do repositório é completamente independente do particionamento no repositório transacional. Por padrão, os dados no repositório analítico não são particionados. Se suas consultas analíticas tiverem filtros usados com freqüência, você terá a opção de particionar com base nesses campos para um melhor desempenho da consulta. Para saber mais, consulte Introdução ao particionamento personalizado e como configurar o particionamento personalizado.

Segurança

• A autenticação com o repositório analítico é a mesma que o armazenamento transacional para um determinado banco de dados.

• Isolamento de rede usando pontos de extremidade privados - Você pode controlar o acesso da rede aos dados nos armazenamentos transacionais e analíticos de forma independente. O isolamento de rede é feito usando pontos de extremidade privados gerenciados separados para cada loja, dentro de redes virtuais gerenciadas nos espaços de trabalho do Azure Synapse. Para saber mais, consulte o artigo Como configurar pontos de extremidade privados para armazenamento analítico.

• Criptografia de dados em repouso - A criptografia do repositório analítico está habilitada por padrão.

• Criptografia de dados com chaves gerenciadas pelo cliente - Você pode criptografar perfeitamente os dados em armazenamentos transacionais e analíticos usando as mesmas chaves gerenciadas pelo cliente de maneira automática e transparente. O Azure Synapse Link dá suporte apenas à configuração de chaves gerenciadas pelo cliente usando a identidade gerenciada da sua conta do Azure Cosmos DB. Você deve configurar a identidade gerenciada da sua conta em sua política de acesso do Cofre da Chave do Azure antes de habilitar o Azure Synapse Link em sua conta. Para saber mais, consulte o artigo Como configurar chaves gerenciadas pelo cliente usando as identidades gerenciadas das contas do Azure Cosmos DB.

Suporte para vários tempos de execução do Azure Synapse Analytics

O repositório analítico é otimizado para fornecer escalabilidade, elasticidade e desempenho para cargas de trabalho analíticas sem qualquer dependência dos tempos de execução de computação. A tecnologia de armazenamento é autogerenciada para otimizar suas cargas de trabalho de análise sem esforços manuais.

Os dados no repositório analítico do Azure Cosmos DB podem ser consultados simultaneamente a partir dos diferentes tempos de execução de análise suportados pelo Azure Synapse Analytics. O Azure Synapse Analytics dá suporte ao Apache Spark e ao pool SQL sem servidor com o repositório analítico do Azure Cosmos DB.

Preços

A loja analítica segue um modelo de preços baseado no consumo, onde você é cobrado por:

• Armazenamento: o volume de dados retidos no repositório 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 gerenciada de atualizações de dados operacionais para o repositório analítico a partir do repositório transacional (sincronização automática)

• Operações de leitura analítica: as operações de leitura executadas no repositório analítico do pool do Azure Synapse Analytics Spark e nos tempos de execução do pool SQL sem servidor.

O preço analítico da loja é separado do modelo de preços da loja de transações. Não há nenhum conceito de RUs provisionadas no repositório analítico. Consulte a página de preços do Azure Cosmos DB para obter detalhes completos sobre o modelo de preços para armazenamento analítico.

Os dados no repositório de análise só podem ser acessados por meio do Azure Synapse Link, o que é feito nos tempos de execução do Azure Synapse Analytics: pools do Azure Synapse Apache Spark e pools SQL sem servidor do Azure Synapse. Consulte a página de preços do Azure Synapse Analytics para obter detalhes completos sobre o modelo de preços para acessar dados no repositório analítico.

Para obter uma estimativa de custo de alto nível para habilitar o armazenamento analítico em um contêiner do Azure Cosmos DB, do ponto de vista do repositório analítico, você pode usar o planejador de capacidade do Azure Cosmos DB e obter uma estimativa de seus custos de operações analíticas de armazenamento e gravação.

As estimativas de operações de leitura do repositório analítico não estão incluídas na calculadora de custos do Azure Cosmos DB, pois são uma função da sua carga de trabalho analítica. Mas, como uma estimativa de alto nível, a varredura de 1 TB de dados no armazenamento analítico normalmente resulta em 130.000 operações de leitura analítica e resulta em um custo de US$ 0,065. Por exemplo, se você usar pools SQL sem servidor do Azure Synapse para executar essa verificação de 1 TB, ela custará US$ 5,00 de acordo com a página de preços do Azure Synapse Analytics. O custo total final para esta varredura de 1 TB seria de US $ 5.065.

Embora a estimativa acima seja para a digitalização de 1 TB de dados no armazenamento analítico, a aplicação de filtros reduz o volume de dados digitalizados e isso determina o número exato de operações de leitura analítica dado o modelo de preço 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.

Próximos passos

Para saber mais, consulte os seguintes documentos:

• Azure Synapse Link para o Azure Cosmos DB

• Confira o módulo de treinamento sobre como projetar processamento analítico e transacional híbrido usando o Azure Synapse Analytics

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

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

• Azure Synapse Link para casos de uso do Azure Cosmos DB