Azure SQL Data Warehouse – Minha opinião – Parte 1

Olá pessoal, tudo bem?
Vou escrever algo aqui que pode contrariar a muitos ou aqueles que “vendem” a solução, mas que nunca a utilizaram de fato em casos reais de produção.
De imediato alerto que o artigo não é uma crítica, mas algumas ressalvas que você deve considerar antes de investir tão pesado nesta solução e não sair implantando porque disseram que é legal.

Introdução

O Azure Data Warehouse é um banco de dados SQL que roda em arquitetura MPP – Multi Parallel Processing, a seguir um esquema de como isso funciona:

Basicamente, você tem um único ponto de conexão, aqui chamado de Control Node, todavia, as requisições que são realizadas elas operam paralelamente em diversos nós computacionais, algo fantástico não é mesmo? As informações podem estar distribuídas por esses nós dando assim maior poder de processamento paralelo.

Até aí tudo lindo, mas vamos a alguns fatos sobre esta tecnologia.

Fatos sobre o Azure DW

Fato 1 – Ausência de comandos T-SQL

Alguns comandos e tipos de dados que eu entendo que seriam fundamentais e que não existem no Azure Data Warehouse e que para os meus projetos, foram prejudiciais a certo ponto, mas que contornei de outras formas:

Função FORMAT

Maiores informações sobre o comando https://docs.microsoft.com/pt-br/sql/t-sql/functions/format-transact-sql?view=sql-server-2017

Precisa montar um relatório para mostrar o nome do mês ou o dia da semana em Português?

Esquece, você terá que fazer um monte de CASE como era antes de ter surgido este comando no SQL Server tradicional ou recorrer ao SET LANGUAGE Portuguese, para definir em sua sessão o idioma corrente.

MERGE

Maiores informações sobre o MERGE https://docs.microsoft.com/pt-br/sql/t-sql/statements/merge-transact-sql?view=sql-server-2017

Ao meu ver, é um absurdo um comando tão clássico de ser utilizado em ambientes de DW para carregamento de dados em tabelas fatos, não ser suportado.

Ou seja, se você tem a seguinte lógica de carregamento:

  • Possuo dados a serem carregados;
  • Se já existir, eles devem ser atualizados;
  • Se não existirem, eles devem ser carregados;
  • Se não existirem mais na origem e tem no destino, deverão ser excluídos.

Esqueça o MERGE, você não poderá utilizá-lo mais. Recorra as comandos CTAS – Create Table As SELECT, conforme recomendação a seguir:

https://docs.microsoft.com/pt-br/azure/sql-data-warehouse/sql-data-warehouse-develop-ctas#replace-merge-statements

UPDATE com JOIN

Esquece, não tem. Você deverá adotar a estratégia de utilizar o CTAS, semelhante ao caso do MERGE.

Saiba como fazer em https://docs.microsoft.com/pt-br/azure/sql-data-warehouse/sql-data-warehouse-develop-ctas#ansi-join-replacement-for-update-statements

DELETE com JOIN

Esquece, não tem. Você deverá adotar a estratégia de utilizar o CTAS, semelhante ao caso do MERGE.

Saiba como fazer em https://docs.microsoft.com/pt-br/azure/sql-data-warehouse/sql-data-warehouse-develop-ctas#ansi-join-replacement-for-delete-statements

Fato 2 – Ausência de tipos ou objetos T-SQL

Geography

Sobre o tipo de dados https://docs.microsoft.com/pt-br/sql/t-sql/spatial-geography/spatial-types-geography?view=sql-server-2017

Sim, quem hoje em pleno século XXI guarda dados do tipo geográfico em formato DECIMAL?! Pois você optando pelo Azure DW, deverá guardar, pois os dados geográficos não são suportados. Então, se você tem dois pontos geográficos e quer analisar a distância entre eles, você não poderá faze-lo. Existem alternativas, mas todas elas passam por armazenar os dados em outro local e pelo Azure DW External Tables fazer a leitura, saiba mais em Using Elastic Query to Support SQL Spatial in Azure SQL DW.

JSON

Sobre o tipo de dados https://docs.microsoft.com/pt-br/sql/relational-databases/json/json-data-sql-server?view=sql-server-2017

Vou forçar a barra, pois eu sei que informações não estruturadas como JSON, poderiam ser armazenadas em um Blob Storage do Azure, mas e se você quisesse armazenar dentro do DW? Não seria possível também, pois este tipo de dado não é suportado.

Outros tipos não suportados

São eles geometry, hierarchyid, image, xml e outros que realmente não precisariam ter ao meu ver, veja a lista completa em https://docs.microsoft.com/pt-br/azure/sql-data-warehouse/sql-data-warehouse-tables-data-types.

Views Indexadas

Existe algo tão clássico em um Data Warehouse que a utilização de views indexadas? Pois, é não consigo entender porque este recurso não está disponível. Saiba mais sobre isto em https://docs.microsoft.com/pt-br/sql/relational-databases/views/create-indexed-views?view=sql-server-2017.

Computed Columns

Um recurso tão fantástico e simples de utilizar são as colunas computadas, ao qual, possibilitam você persistir certas operações no banco de dados. Exemplo, se você sempre faz um determinado calculo “DATEDIFF(HH, [DataInicio], [DataChegada]) TempoHoras_ViagemReal”, você poderia persistir esta informação no banco de dados para que o SQL Server não necessite processar tal expressão. Exemplo:

ALTER TABLE dbo.Products ADD RetailValue AS (QtyAvailable * UnitPrice * 1.5) PERSISTED

Maiores informações em https://docs.microsoft.com/pt-br/sql/relational-databases/tables/specify-computed-columns-in-a-table?view=sql-server-2017, mas o fato é que no Azure SQL DW este recurso não está disponível.

Conclusão

Tudo isto foi o que eu senti falta, este artigo irá ser sempre atualizado que eu perceber algo importante e comum no ambiente de Data Warehouse e que o Azure SQL DW não suportar.

Eu iria escrever neste artigo, mas deixarei em uma parte 2 minha opinião sobre o Sistema de Armazenamento (Distribuições) que são possíveis de serem implementadas no Azure DW.

Portanto, fique atento ao decidir implementar o Azure SQL DW, não quero dizer que é ruim, pelo contrário é uma solução fantástica, mas talvez você precisará adaptar muitos processos que antes você realizava no banco de dados em outras camadas.

Gostou do artigo? Tem uma opinião diferente? Comente aí!

Vithor da Silva e Silva | Consultor e Instrutor | SQL Server e Power BI
vithor@vssti.com.br