Este post do blog foi escrito por: Sahaj Saini, PM da equipe do Microsoft Analytics Platform System (APS).

Neste post do blog, vamos dar uma rápida visão geral do Symmetric Multi-Processing (SMP) vs. Massively Parallel Processing (MPP) systems, como identificar triggers para migração de SMP para MPP, considerações chave ao migrar para o Microsoft Analytics Platform System (APS), e uma discussão sobre como aproveitar o poder de uma solução MPP como APS.

Deixe-nos começar com um cenário. Emma é a Administradora de Banco de Dados da Adventure Works Cycles, uma empresa fabricante de bicicletas. Na Adventure Works, Emma e sua equipe estão usando o tradicional SMP do SQL Server como solução de armazenamento de dados. A empresa tem vindo a crescer rapidamente e com a crescente concorrência na indústria de bicicletas, os analistas de negócios da Adventure Works Cycles gostariam de ter uma visão mais rápida dos seus dados. A Emma está agora enfrentando os seguintes desafios com a implantação do SMP –

• Alto Volume de Dados e Crescimento de Dados: Com o aumento das vendas e uma base crescente de clientes, o volume de dados cresceu rapidamente para cruzar 10 TB.
• Tempos mais longos de carregamento de dados/ETL: Com a necessidade de produzir relatórios diários para a gerência, a Emma considera a velocidade ETL atual inadequada para receber e processar a quantidade crescente de dados que fluem de outros sistemas OLTP e não-relacionais.
• Execução lenta de consultas: Os tempos de execução das consultas estão diminuindo devido ao aumento de dados e está se tornando cada vez mais difícil gerar insights para relatórios diários de forma oportuna.
• Long Cube Processing Time: Com o tempo atual de processamento dos cubos, é difícil atender às necessidades de relatórios em tempo real da empresa.

Para superar esses desafios, Emma e sua equipe avaliam a compra de um conjunto maior, mais caro e mais poderoso de hardware de servidor e armazenamento para seu data center. Esta abordagem resolveria o problema deles, mas apenas a curto prazo, pois espera-se que o crescimento dos dados exploda nos próximos 12 meses. Com o crescimento de dados que a Adventure Works espera ver, mesmo as maiores e mais poderosas soluções SMP atingiriam uma parede muito rapidamente. A Emma gostaria de ver uma solução que se dimensiona conforme suas necessidades de dados crescem.

Antes de saltarmos para a solução dos problemas da Emma, vamos definir rapidamente o que são SMP e MPP. Symmetric Multi-Processing (SMP) é um sistema de multiprocessadores firmemente acoplado onde os processadores compartilham recursos – instâncias únicas do Sistema Operacional (SO), memória, dispositivos de E/S e conectados usando um barramento comum. O SMP é a arquitetura paralela primária empregada em servidores e está representado na imagem a seguir.

Massively Parallel Processing (MPP) é o processamento coordenado de uma única tarefa por vários processadores, cada processador usando seu próprio SO e memória e comunicando-se uns com os outros usando alguma forma de interface de troca de mensagens. O MPP pode ser configurado com um nada compartilhado ou arquitetura de disco compartilhado.

Em uma arquitetura de nada compartilhado, não há um único ponto de contenção através do sistema e os nós não compartilham memória ou armazenamento em disco. Os dados são particionados horizontalmente entre nós, de modo que cada nó tem um subconjunto de linhas de cada tabela no banco de dados. Cada nó então processa apenas as linhas em seus próprios discos. Sistemas baseados nesta arquitetura podem alcançar uma escala massiva, já que não há um único gargalo para diminuir a velocidade do sistema. Isto é o que Emma está procurando.

MPP com arquitetura shared-nothing é representado na imagem seguinte.

Microsoft Parallel Data Warehouse (PDW) rodando em um dispositivo de sistema da plataforma Microsoft Analytics Platform é implementado como uma arquitetura MPP shared-nothing. Consiste em um nó de controle e armazenamento conectado a nós de computação inter-conectados por Ethernet e Infiniband. O nó de controle hospeda o mecanismo PDW – o cérebro do sistema MPP – que cria planos de consulta paralelos, coordena a execução da consulta nos nós de computação e a agregação de dados em todo o dispositivo. Todos os nós, incluindo controle e computação, hospedam um Serviço de Movimento de Dados (DMS) para transferir dados entre nós.

Para mais detalhes sobre a arquitetura PDW, você pode ler a Arquitetura do Sistema da Plataforma Microsoft Analytics post.

Transição para MPP

Para perceber o valor oferecido pelo MPP, Emma e sua equipe adquirem um dispositivo APS da Microsoft e iniciam a transição para MPP. Vamos dar uma olhada em como eles adaptam sua solução para tirar o máximo proveito da arquitetura MPP compartilhada de nada do APS.

Concepção de mesa

Como mencionado anteriormente, o APS é baseado em uma arquitetura MPP de nada compartilhado, o que significa que os nós são auto-suficientes e não compartilham memória ou discos. A arquitetura, portanto, requer que você distribua suas grandes tabelas pelos nós para obter os benefícios do processamento maciçamente paralelo. O APS permite a definição de uma tabela como distribuída ou replicada. A decisão de escolher uma versus a outra depende do volume de dados e da necessidade de acesso a todos os dados em um único nó.

Tabelas distribuídas

Uma tabela distribuída é aquela em que os dados da linha dentro da tabela são distribuídos entre os nós dentro do aparelho para permitir uma escala massiva. Cada linha termina em uma distribuição em um nó de computação, conforme representado pela imagem abaixo.

Para aproveitar a natureza distribuída do APS, a Emma modifica as tabelas grandes, tipicamente tabelas de Fato e de grande dimensão, para serem distribuídas no APS da seguinte forma:

CREATE TABLE .( NOT NULL, NOT NULL, . . NULL) WITH( DISTRIBUTION = HASH(ProductKey),CLUSTERED COLUMNSTORE INDEX);

Como você pode ver, esta é uma declaração DDL típica para criação de tabelas, com uma pequena adição para tabelas distribuídas. As tabelas são distribuídas por uma função hash determinística aplicada à Coluna de distribuição escolhida para aquela tabela. A Emma seleciona Chave de Produto como coluna de distribuição na tabela FactInternetSales devido à alta cardinalidade e ausência de inclinação, portanto distribuindo a tabela uniformemente entre nós.

Tabelas replicadas

Se todas as tabelas fossem distribuídas, no entanto, seria necessário um grande movimento de dados entre nós antes de executar operações de junção para todas as operações. Portanto, para tabelas de dimensões menores, como idioma, países, etc., faz sentido replicar a tabela inteira em cada nó de computação. Ou seja, os benefícios de permitir operações locais de join com estas tabelas superam o custo de armazenamento extra consumido. Uma tabela replicada é aquela que é replicada em todos os nós de computação como mostrado abaixo.

Emma desenha as tabelas pequenas, tipicamente de dimensões, para serem replicadas da seguinte forma:

 CREATE TABLE .( NOT NULL, . . (10) NOT NULL,)WITH(CLUSTERED COLUMNSTORE INDEX);

Ao desenhar apropriadamente tabelas distribuídas e replicadas, Emma alinha sua solução com as melhores práticas comuns de desenho MPP e permite o processamento eficiente de grandes volumes de dados. Por exemplo, uma consulta contra 100 bilhões de linhas em um ambiente SMP SQL Server exigiria o processamento de todos os dados em um único espaço de execução. Com o MPP, o trabalho é distribuído por muitos nós para dividir o problema em formas mais fáceis e gerenciáveis de executar tarefas. Em um dispositivo de quatro nós (veja a figura acima), cada nó é solicitado a processar apenas cerca de 25 bilhões de linhas – uma tarefa muito mais rápida. Como resultado, Emma observa melhorias significativas no tempo de execução da consulta e seu negócio pode agora tomar melhores decisões, mais rapidamente. Além disso, a Emma pode aumentar o data warehouse para qualquer lugar, desde alguns terabytes até mais de 6 petabytes de dados, adicionando “unidades de escala” ao APS.

Carregamento de dados

Com o SQL Server SMP, Emma e sua equipe estavam usando processos ETL através de um conjunto de pacotes SSIS para carregar dados no data warehouse – (1) Extraindo dados do OLTP e outros sistemas; (2) Transformando os dados em formato dimensional; e (3) Carregando os dados para as tabelas de dimensões ou fatos alvo no Data Warehouse. Com volumes crescentes de dados, a separação SSIS no meio torna-se um gargalo de estrangulamento enquanto executa transformações, resultando em carregamento lento de dados.

Com o APS, Emma e sua equipe podem usar o ELT, para extrair os dados do OLTP e de outros sistemas e carregá-los para um local de encenação no APS. Então, os dados podem ser Transformados em formato dimensional não com SSIS mas com o motor APS utilizando a natureza distribuída do aparelho e a potência do processamento paralelo. Em um aparelho de 4 nós, quatro servidores estariam fazendo as transformações em subconjuntos de dados versus o servidor SSIS de nó único.

Este processamento paralelo resulta em um aumento significativo no desempenho do carregamento de dados. Emma pode então usar a instrução Create Table As Select (CTAS) para criar a tabela a partir da tabela de preparação da seguinte forma.

CREATE TABLE . WITH( CLUSTERED COLUMN INDEX, DISTRIBUTION = HASH (CustomerKey))ASSELECT * FROM .;

Ao mudar para um processo ELT, Emma utiliza o poder de processamento paralelo do APS para ver ganhos de desempenho no carregamento de dados.

Em conclusão, Emma e sua equipe encontraram respostas para seus problemas de SMP com MPP. Eles agora podem se sentir confiantes no manuseio do volume de dados e crescimento na Adventure Works com a capacidade de escalar o data warehouse conforme necessário. Com o ELT e o poder do processamento paralelo no APS, eles podem carregar os dados no APS mais rapidamente e dentro da janela de tempo esperada. E, alinhando-se ao design MPP do APS, eles podem alcançar um desempenho revolucionário na consulta, permitindo relatórios em tempo real e uma visão dos seus dados.