#02-[Série] SQL Server Big Data Clusters – Arquitetura

Falla Guys,

Continuando a série dos artigos sobre o Big Data Clusters (BDC), nesse post vamos entender a arquitetura dessa nova engine, no post anterior falei sobre o que é o Big Data Clusters, caso tenha ficado alguma duvida, comente aqui ou me envie um e-mail, que vamos conversando 🙂

A arquitetura do BDC é bem simples, baseando-se em camadas de Controle (CONTROL PLAN), de Computação (COMPUTE PLANE) e de Dados (DATA PLANE).
Todos esses componentes são criados em Dockers (containers) e gerenciados pelo cluster do Kubernetes o que possibilita escalar horizontalmente (scale-out) caso seja necessário. Esse é um dos pontos mais incríveis do BDC, escalar conforme a demada de forma simples e rápida possibilita o processamento e análise de grandes volumes de dados, habilitando vários cenários de uso onde essa tecnologia pode ser aproveitada, como virtualização de dados, estrutura para Data lake, criação de pipelines para Machine Learning (ML) e também no uso de Inteligência Artificial (IA).

A imagem a seguir representa a arquitetura “global” do BDC, repare as “camadas” destacadas em vermelho, observe também as conexões com o SQL Server Masters Instance, Integração com External Data Sources (Data Virtualization), IoT (simulando uma entrada de dados via streaming) e na parte inferior os nodes (nós) do cluster de Kubernetes onde toda essa estrutura é alocada.

Neste post vamos dar ênfase onde está destacado em vermelho:


Control Plane (Controller)

Control Plane (ou Plano de Controle) pode ser considerado o cérebro lógico do Big Data Clusters.

Durante a inicialização o deploy ocorre no node do Kubernetes e todo o controle e gerenciamento dos componentes são hospedados neste nó. Com o utilitário azdata via linha de comando é possível analisar os serviços e os principais endpoints de acesso aos serviços. Ainda durante o deploy o primeiro serviço instalado pelo usuário administrador é o “Controller Services” e a partir dele será coordenado a instalação e configuração dos demais, como SQL Server Master Instance, Data Pool, Storage Pool, Compute Pool, serviços do grafana, kibana e também os metastore do hive.

Alguns serviços e funções alocados no Control Plane (Controller):

  • Gerenciamento do Clusters, status, inicialização dos serviços. atualização e configuração dos componentes do cluster.
  • SQL Server Master Instance (ess vale um post e será publicado em breve).
  • Gerenciamento do Compute Pool, Data Pool e Storage Pool.
  • Gerenciamento de segurança, via exposição de endpoints, criação de usuários e roles, configuração de credencias.
  • Ferramentas de monitoração do clusters, como Grafana e Kibana.

Para acessar o Controller, podemos utilizar o azdata listando configurções dos serviços do BDC. Também podemos utilizar o Kubectl para executar comando diretamente no cluster Kubernetes, facilitando o gerenciamento a nível de cluster e pods do BDC, vamos utiliza-los muitos em nossas demos aqui no blog.

Além dos utilitários via linha de comando apresentado anteriormente, também podemos usar o Azure Data Studio para acessar alguns serviços do Controller.

Por baixo dos panos a comunicação com o Controller é via API REST com protocolo HTTP, protegendo as variáveis CONTROLLER_USER e CONTROLLER_PASSWORD com certificados e senhas definidas pelo usuário master no momento da criação do cluster, tudo isso aumenta a segurança do acesso ao cérebro lógico do Big Data Clusters.


Compute Plane

Compute Plane (Plano de Computação) é a barreira lógica que aloca os Pools de Computação. Costumo brincar que o Compute Pool é cavalaria do Big Data Clusters (rsrs), pois essa camada é responsável pelos recursos de computação que “mastigam” os dados via engine Polybase (vou escrever mais sobre Polybase em breve) que podem ser tanto no Storage Pool, Data Pool ou nas várias fontes extenas, como Oracle, Teradada (engine mpp), CosmosDB, HDFS entre outras.

O Compute Pool é formado por um ou vários pods alocados no cluster Kubernetes e disponibilizam instâncias stateless como recurso computacional expansível, possibilitando a escalabilidade horizontal (scale-out) dos pods. Com isso aumentamos o poder computacional e inclusive fazendo uso do processamento paralelo entre os pods.

Na imagem a seguir, podemos observar o Compute Pool com três nodes e na parte inferior os nodes do HDFS. Neste caso, o usuário executa uma query contra uma external table onde o external data source é o HDFS, com isso, o SQL Master instance faz a chamada do Polybase que executa a query em paralelo nos pods do compute pool processando os dados no HDFS que estão em pods no storage pool, lembrando que o Polybase tenta empurrar o máximo de processamento para a sua fonte de origem com objetivo de transferir o mínimo possível de dados. O Optmizer Query faz uso das estatísticas da external table enviando o predicate pushdown para o HDFS gerando o MapReduce, processando a “query” e retornado os dados já agrupados e filtrados para o SQL Masters Instance. Em um exemplo como este, também poderíamos fazer uso do scale-out, escalando horizontalmente os nodes do compute pool (polybase) para aumentar o poder de processamento paralelo nas fontes de origem.

Data Plane

Podemos dividir o Data Plane em duas partes, Data Pool e Storage Pool, explico mais detalhes a seguir:

Storage Pool

O Storage Pool consiste em pods do Cluster Kubernetes e é um dos grandes responsáveis pela integração entre os mundos SQL e NoSQL. Podem existir dois ou mais pods nessa camada e são compostos pelo HDFS (datanode), Spark e instância SQL. Importante dizer que cada nó do datanode do HDFS que está alocado no Storage Pool faz parte de um cluster HDFS, ou seja, o NameNode que por padrão é criado no pod nmnode-0-0 controla os metastore dos danodes. O Yarn também está presente e faz o gerenciamento dos recursos do cluster com base nas chamadas distribuíndo em filas de execução, isso significa que as execuções oriundas do BDC são orquestradas pelo Yarn e não é algo que é executado por fora, isso garante uma armonia e estabilidade do HDFS.

Pooow Garetti, agora complicou:
O que é HDFS? Resumindo, HDFS é um sistema de arquivo distribuído e altamente resiliente projetado para armazenar grandes volumes de dados, ele é um sub-projeto do Apache Hadoop, primo do MapReduce e do Yarn… para mais detalhes, da uma olha nesse link.

Por último e não menos importante, o Spark é um dos grandes responsáveis pela ingestão dos dados no HDFS (pode ser feito de outras formas também), na criação de um pipeline de Machine Learning o Spark é fundamental durante o processamento dos dados.

O master node do Spark por padrão é alocado no pod sparkhead-0, o fluxo de processamento segue basicamente da seguinte forma: O usuário submete uma query, essa query está utilizando uma external table que está associada a um diretório no HDFS que por sua vez é um external data source configurado e conhecido pelo Controller. Quando a query é executada, o compute pool é invocado, acionando a cavalaria (pods com polybase) que por sua vez enviam o predicate pushdown para o Resource Manager que está alocado no pod sparkhead-0. O RM solicita uma instância Application Master (AM) e um vez iniciado, o AM solicita recursos ao RM (prioridade, memória, cpu, etc), o RM gerência e passa os IDs dos containers para os Sparks Drives e a execução é iniciada, finalizando, os dados são enviados para a Master Instance ou também podem ser direcionados para o Data Pool (explico mais à frente).

Assim como o MapReduce, o Spark tem a característica de levar o processamento onde estão os dados, ou seja, no nosso caso o processamento ocorrerá nos nós do Storage Pool (datanodes do HDFS). Conseguimos validar isso facilmente com o Grafana (já vem configurado no BDC), colocando uma query via MapReduce é possível ver os discos trabalhando, quando mudamos o kernel para PySpark (Python + Spark) podemos observar o cache da memória sendo utilizado.

Data Pool

O Data Pool são pods alocados no cluster Kubernetes que lógicamente faz parte da camada de dados do BDC. O “recheio principal” dos data pool são as instâncias SQL Server que garantem o armazenamento persistente e o melhor, com as tabelas criadas no data source “sqldatapool://controller-svc/default” consguimos distribuir os dados entre as instâncias, o que chamamos de shards de dados. O que isso significa? que se no nosso cluster o data pool é composto por 4 pods, toda ingestão de dados é distribuída entre as instâncias, na prática, é processamento paralelo (MPP) comendo quente . Isso é sensacional, se pensarmos em cenários de grandes ingestões e consumo massivo de dados, ganhamos tanto na parte de computação (compute pool) quanto na parte de armazenamento, diminuíndo pontos de de gargalo para grandes volumes de dados.

A distribuíção dos dados entre as instâncias é coordenado pela Master Instance e utilza algoritimos de distribuição de dados, como por exemplo o ROUND_ROBIN que pode ser configurado no momento da criação da external table.

Para auxiliar no entendimento, vamos pensar no seguinte cenário:
O Governo federal precisa processar o Imposto de Renda (IR) de todos os contribuintes e depois disponibilizar para o público geral, que irá entrar e visualizar os resultados, valores de restituição, multas ou se caiu na boca do leão (rs).

Utilizando o BDC, poderíamos resolver da seguinte forma: Imagine que os dados estão espalhados em vários banco de dados, como SQL, Oracle, MongoDB e também em arquivos no HDFS. Processar isso a cada acesso ao site tornaria uma arquitetura inviável, então, podemos processar isso em batch, via spark acessando as external table do SQL, Oracle, MongoDB e no HDFS, e literalmente fazendo join (virtualização de dados) entre as fontes. Uma vez processado, o resultado pode ser enviado para uma tabela no SQL que está alocada no data pool distribuíndo os dados entre os pods no momento da ingestão (round_robin). Posteriomente quando o fulano for acessar os dados do IR a aplicação bate nessa tabela X e via compute pool os dados são consumidos na camada data pool, com processamento paralelo, otimizando muito a consulta.

Esse é apenas um exemplo hipotético, onde o processamento massivo dos dados ocorreu em batch (via spark consumindo n fontes) e a consulta foi online, consumindo da camada data pool.


Segue alguns links interessantes que utilizei durante os estudos, como são muitos, quem tiver interesse me envia um e-mail ou comente aqui que envio o restante ;)…


Ainda vamos tratar muitos assuntos sobre BDC aqui no blog, estou preparando algumas demos de ingestão no Storage e Data Pool, de gerenciamento entre outras. O objetivo é estudar e ir compartilhando. Fiquem a vontade para comentar.

See you next post
Luiz Henrique Garetti
www.dataisbig.com.br

3 thoughts on “#02-[Série] SQL Server Big Data Clusters – Arquitetura

Comente sobre isso: