Arquitetura Analítica
Nesta página é destinada a compreensão do conceito de arquitetura analíticas
Atualizado
Isto foi útil?
Nesta página é destinada a compreensão do conceito de arquitetura analíticas
Atualizado
Isto foi útil?
Escrito por
Como abordado anteriormente, as arquiteturas transacionais (OLTP) são modelos arquitetônicos projetados para realizar e processar transações. Em tecnologia, sempre existirá um tradeoff; por esse motivo, dois grandes pensadores, Ralph Kimball e Bill Inmon, propuseram a separação do ambiente transacional do ambiente analítico.
Essa separação ocorre principalmente por dois motivos: tempo (no sentido amplo) e recursos. Vamos começar falando de recursos, pois isso facilitará o entendimento do fator tempo. Anteriormente, os recursos eram limitados (principalmente devido ao custo), e trabalhava-se basicamente com escalonamento vertical (upgrade). Vamos a um exemplo:
Uma empresa possui um ERP baseado em um modelo Cliente-Servidor, em que os dados são arquivados em um banco relacional (SQL Server, Oracle) projetado e moldado em formas normais para evitar redundância de dados. Esse banco está preparado, principalmente, para receber três tipos de transações: INSERT (inserção de novos registros), UPDATES (atualização de dados) e DELETE (exclusão/cancelamento).
Ao se realizar uma consulta analítica (por exemplo, um relatório de um sistema qualquer) utilizando o SELECT e, por consequência, o uso de JOINs (união) de várias tabelas, o sistema gerenciador do banco montará um plano de execução dessa consulta. Dependendo de como o banco estiver configurado, as transações de Inserção, Atualização e Exclusão podem ser "travadas" ou bloqueadas.
Aqui podemos observar uma limitação de recursos: para que a consulta seja processada mais rapidamente (além de estar bem escrita), seria necessário também melhorar o processamento do servidor onde o banco está instalado; neste caso, seria necessário um escalonamento vertical (upgrade).
Agora, imagine se, no dia a dia, seria viável para o usuário de negócio travar o banco para que as consultas alimentassem seus relatórios e painéis visuais. Com base nisso, e levando em consideração o tempo, foi proposta a criação de arquiteturas resilientes, capazes de comportar consultas. Este modelo é desnormalizado das formas normais para que seja modelado em formato analítico.
As primeiras arquiteturas analíticas (OLAP) foram o Data Mart (DM), proposto por Bill Inmon, e o Data Warehouse (DW), proposto por Ralph Kimball. Ambas arquiteturas são concebidas na desnormalização das formas normais, base para modelagem de sistemas transacionais, e modeladas em tabelas fatos e dimensões.
Abordaremos mais detalhes sobre essa modelagem de dados, seus modelos de tabelas e as diferenças entre uma e outra; por ora, foquemos na grande vantagem dessas arquiteturas, que não era mais evitar a redundância de dados, mas sim garantir menores tempos de resposta quando os dados eram requisitados (SELECTs).
Com o advento da Web 3.0 e o crescente número de dados de diversos tipos (estruturados, semi-estruturados e não estruturados), principalmente devido às redes sociais como Facebook, Twitter (atual X), entre outros, começaram a surgir questionamentos quanto à capacidade dos DW e DM para lidar com essa nova realidade.
Dessa forma, em 2010, surge pela primeira vez o conceito de Data Lake, proposto por James Dixon. Nessa arquitetura, baseada principalmente no conceito do Hadoop File System (HDFS), começa-se a armazenar diversos tipos de dados em seu formato "bruto", tais como: áudio, vídeo, txt, csv, planilhas eletrônicas etc. Eles passam por camadas e são disponibilizados para consumo. Abordaremos mais sobre os Data Lakes em uma sessão específica.
Os Data Lakes se tornaram comuns nas arquiteturas de empresas que possuíam grandes volumes de dados (Big Data). Porém, essa tecnologia tinha algumas deficiências, como a governança de dados e o controle de transações no acrônimo ACID (oriundo dos sistemas transacionais).
Diante disso, em meados de 2018, a Databricks, empresa dos criadores do Apache Spark (que substituiu o Hadoop), começou a introduzir um novo conceito: o Data Lakehouse. Esta arquitetura é flexível, sendo a junção do melhor dos Data Lakes (processamento e armazenamento) com o Data Warehouse (modelagem, governança e transações ACID). Essa evolução trouxe consigo alguns novos formatos de arquivos, como: Delta (inicialmente um formato proprietário da Databricks e depois aberto à comunidade), Apache HUDI (criado pela Uber e também cedido à comunidade Apache) e Iceberg (criado pela Netflix e também cedido à comunidade Apache).
Na tecnologia da informação, palavras comuns de se ouvir são: abstração, resiliência, escalabilidade, segurança e tolerância a falhas. Para abordar essas questões, é necessário compreender duas topologias de arquiteturas: Kappa e Lambda. Entender essas arquiteturas é fundamental na modelagem e construção de Datalakes e Lakehouses.
Esse modelo arquitetural foi proposto por Nathan Marz, em meados de 2011. Ele é composto por processamentos em lote (Batch Layer) e em tempo real (Speed Layer), posteriormente disponibilizados para consumo nas aplicações (Serving Layer). Cada camada dessa arquitetura consiste em:
Ingestion Layer: é a camada de origem dos dados, ou seja, o transacional.
Batch Layer: é a camada que processa dados no formato "lote", com uma frequência pré-determinada, por exemplo, duas ou três vezes ao dia. Essa camada, também chamada de camada fria, geralmente usa técnicas de CDC para coleta de dados.
Speed Layer: é a camada que processa dados em tempo real (ou próximo a isso); os dados são consumidos à medida em que chegam. Nessa camada, também chamada de camada quente, faz-se necessário o uso de alguma ferramenta de mensageria.
Serving Layer: é a camada de armazenamento dos dados processados pelas camadas anteriores, onde se fornece acesso às aplicações analíticas com dados tratados para geração de insights a partir de ferramentas de visualização.
Esse modelo arquitetural foi proposto por Jay Kreps (criador do Apache Kafka e co-fundador da Confluent), em meados de 2014. A grande diferença entre ela e a Kappa é que unifica as camadas de processamento, tornando-a apenas uma (Speed Layer). As camadas dessa arquitetura consistem em:
Ingestion Layer: é a camada de origem dos dados, ou seja, o transacional.
Speed Layer: é a camada que processa dados em tempo real (ou próximo a isso); os dados são consumidos à medida que chegam e também em "lote", com uma frequência pré-determinada, por exemplo, duas ou três vezes ao dia. Nela, podem ser usadas diversas técnicas e ferramentas para processamento dos dados, como técnicas de CDC para processamento em lote e ferramentas de mensageria (Kafka) para consumo em tempo real.
Serving Layer: é a camada de armazenamento dos dados processados na Speed Layer, com o objetivo de fornecer acesso às aplicações analíticas aos dados tratados, para geração de insights a partir de ferramentas de visualização.
ACID - Atomicity, Consistency, Isolation, Durability
CDC - Change Data Capture
CSV - Comma-separated values
DM - Data Mart
DW - Data Warehouse
ERP - Enterprise Resource Planning
HDFS - Hadoop File System
HUDI - Hadoop Upserts Deletes and Incrementals
TXT - Text
