Plataforma Moderna de Dados — Parte 1/2
A Fantástica Fábrica de Produtos de Dados
Entendo que não há como descrever uma Saga sem iniciar fornecendo um “Big Picture” sobre a personagem principal: A Plataforma Moderna de Dados ou Modern Data Stack ou ainda MDS.
E por mais que a Saga do Dataverso seja pra contar uma história prática de como esta personagem será construída em termos tecnológicos e aplicados, eu acho ainda mais importante iniciar descrevendo um conjunto de capacidades ou super-poderes que são a estrutura desta personagem.
Umas das motivações para termos uma visão geral destas capacidades é que elas são auto-contidas e fáceis de serem explicadas, de forma que seus conceitos não se confundam ou não se sobreponham. E um outro motivo para contextualizar isso é que ao contrário de muitos artigos que li sobre Modern Data Stack, onde há uma ênfase nas tecnologias para cada super-poder, iremos descobrir que muitas vezes você pode usar um conjunto bem restrito de tecnologias pra atacar mais de uma competência.
Mais um ponto: O objetivo não é ficar necessariamente comparando uma tecnologia com a outra e nem advogar para a tecnologia A ou B, pois já tem inúmeros artigos bacanudos que fazem isso e vou até citá-los durante a Saga. O principal objetivo é explorar as opções existentes e mostrar que temos várias formas de atender cada competência desta plataforma. E dependendo da capacidade do seu time, budget, plataforma tecnológica atual, caso de uso e o tempo disponível, dentre outros fatores, você poderá lançar mão de algumas das opções apresentadas para a plataforma que precisa construir.
Capacidades ou super-poderes
Baseado no diagrama que coloquei acima, vou descrever cada uma das capacidades ou super-poderes que uma plataforma moderna de dados deveria ter. Pra cada uma destas capacidades, há disciplinas ou tópicos importantes de serem destacados, pois estes se conectam mais com as tecnologias que estaremos trabalhando.
Ingerir
Acho que não há dúvidas que sem dados, não há plataforma de dados, portanto a primeira competência que gostaria de destacar aqui é justamente a de ingerir dados para a plataforma de moderna de dados.
A ingestão de dados consiste basicamente em realizar um processo de integração onde alguns componentes obtém acesso a fontes diversas de dados que são de interesse da plataforma, tais como: repositórios de arquivos, bancos de dados, APIs, websites, mobile apps, webapps, eventos de dispositivos de IoT, streaming de dados, etc. De posse do acesso a estas fontes, este processo de ingestão extrai (E) os dados de origem e dependendo da estratégia de processamento (ETL ou ELT), carrega (L) os mesmos para a plataforma de dados, tornando-os disponíveis para os demais processos ou competências, incluindo tratamento e/ou transformação (T) ou disponibiliza os dados em uma área de staging para que possam ser transformados (T) e posteriormente carregados (L) na plataforma de dados.
Ressalto que um dos aspectos que influenciou muito na evolução das plataformas modernas de dados foi justamente uma sensível mudança de paradigma entre a abordagem de ETL (Extract-Transform-Load) para ELT (Extract-Load-Transform). Vários são os fatores pra esta mudança que ainda está ocorrendo nas empresas, mas listo principalmente:
- A flexibilidade e agilidade de se trabalhar com dados brutos, estruturados, semi-estruturados e não-estruturados
- O advento dos data lakes como forma de baratear o custo de armazenamento e dos cloud data warehouses para realizar as transformações para consumo
- Reduzir tempo de processamento, sobretudo com o aumento estrondoso no volume de dados
Quero destacar que há muitos outros fatores pra esta mudança e que não necessariamente a abordagem de ELT vai substituir totalmente a abordagem de ETL. Acho realmente que dependendo do caso de uso, você pode acabar usando as duas abordagens ao mesmo tempo, usando o que de melhor cada uma oferece.
Pra fechar este tópico, além de termos componentes e tecnologias para realizar ingestões em lote (batch) ou em tempo real (streaming), há uma categoria específica de ferramentas que geralmente figura nas discussões sobre Modern Data Stack que são as CDI (Customer Data Infrastructure), cujo foco é coletar e ingerir dados de comportamento de usuários (behavioral data), seja de fontes primárias como mobile apps, web apps, websites e devices ou de fontes secundárias (formas indiretas que o usuário interage com as aplicações) como sistemas de pagamento, frameworks de autenticação (OAuth), ferramentas de avaliação ou feedback (Disqus), etc. Durante a Saga, veremos como implementar e usar este tipo de plataforma.
Armazenar
Eu sei que estou falando de plataforma moderna de dados e portanto, eu deveria falar de armazenar dados. Mas numa plataforma moderna de dados, há uma diversidade de elementos e objetos que precisam ser armazenados, portanto acho importante separar logo "o joio do trigo".
Quando se trata de armazenar os dados que irão transitar na plataforma de com o objetivo primário de torná-los disponíveis para a criação de produtos de dados, existe uma série de práticas, tratativas e abordagens que precisam ser consideradas, tais como: qual a arquitetura de armazenamento a ser usada, formato de arquivo para dados brutos, formato de arquivos para dados transformados pra consumo, particionamento, organização dos dados com base em domínio de negócio, organização dos dados com base no estágio ou maturidade que os mesmos se encontram, nomenclatura de objetos, etc.
Estes tópicos acima serão explorados ao longo da Saga e representam uma parte muito importante para o sucesso na implementação de uma plataforma moderna de dados.
Mas há outros tipos de objetos que precisam ser armazenados e que também fazem parte das plataformas modernas de dados, tais como: experimentos de data science, modelos de machine learning, metadados, bancos de dados de suporte às ferramentas da plataforma, demais produtos de dados (dashboards, reports), logs de processamento e monitoramento, etc. Para estes itens, teremos que pensar em parte das práticas, tratativas e abordagens que listei acima e tópicos como: qual banco de dados vai trazer mais performance e escalabilidade pra este componente da plataforma, pensando em metadados qual estrutura de armazenamento me fornece algo amplo que eu possa aplicar em qualquer tipo de objeto. A motivação pra se dar a atenção devida para esta outra categoria é manter a plataforma de dados resiliente, rápida e apta pra ser evoluída constantemente.
Não posso terminar este tópico sem falar das principais arquiteturas de dados, que possuem abordagens distintas no que tange a armazenamento.
Os Data Warehouses tradicionais, criados no final dos anos 80, tinham como principal característica, em termos de armazenamento, uma estrutura similar aos SGBDs (Sistemas Gerenciadores de Bancos de Dados), porém com enfoque em grandes volumes, por vezes orientados a colunas ao invés de linhas (registros) e com suporte para modelagem multidimensional.
Os Data Lakes vieram com o propósito de ampliar o leque de formatos, permitindo o armazenamento de dados estruturados, semi-estruturados e não estruturados em sistemas de arquivos ou object storages. Os Data Lakes são utilizados para armazenar dados das mais diversas fontes e em diferentes estágios de maturidade, também com foco em grandes volumes e com a promessa de baixo custo, se comparado aos Data Warehouses tradicionais.
Os Data Lakehouses vieram com a missão de unificar as características dos modelos de Data Warehouse e Data Lake. Na arquitetura de Data Lakehouse, o dado reside armazenado em uma estrutura de Data Lake, mas recebe uma "camada" adicional similar a de um Data Warehouse, permitindo transações ACID, definição de estruturas de tabelas e schemas, versionamento de dados, dentre outras características.
Da forma análoga como comentei sobre ETL e ELT, por mais que a arquitetura de Data Lakehouse tenha se popularizado rapidamente, inclusive sendo incorporada por plataformas de Data Warehouse modernas (e Cloud Data Warehouses), não é possível afirmar que será a arquitetura definitiva daqui em diante. Ainda é comum ver cenários onde a arquitetura de Data Warehouse é predominante nas empresas e em outras situações, há um processo de convivência entre mais de uma arquitetura, o que será explorado durante a Saga.
Transformar
Para que o dado bruto obtido na ingestão possa ser utilizado para consumo dos produtos de dados, é necessário que ele passe por processos de transformação, os quais eu gosto de separar em dois principais grupos: tratamento de dados e engenharia de analytics.
A engenharia de analytics, disciplina que surgiu por volta de 2016, veio com o propósito de preencher um espaço entre a engenharia de dados e análise de dados e BI. A ideia é que o profissional desta área trabalhe em práticas de engenharia de software para entregar conjuntos de dados tratados e consistentes que respondam aos desafios do negócio, num formato de fácil acesso aos analistas de dados.
Um outro aspecto que contribuiu muito para o advento e crescimento da área de engenharia de analytics foi a mudança para a abordagem de ELT que citei no tópico da competência Ingerir. Com o processo de transformação ficando no "final da linha", surgiram uma série de ferramentas especializadas, utilizando do poder de fogo dos cloud data warehouses e com foco em facilitar o processo de criação de conjuntos de dados, através de padrões já consagrados como o SQL.
Ao meu ver, os processos de tratamento de dados visam entregar o dado num estado consistente e pronto para ser modelado pela engenharia de analytics. Eu sei que tem algumas literaturas que descrevem que a engenharia de analytics engloba tarefas de tratamento de dados, mas a minha opinião pessoal é que fica mais fácil separar estes dois grupos.
No grupo de tratamento de dados, eu considero tarefas como padronização de tipos de dados, tratamento de valores inconsistentes ou nulos, mascaramento de dados sensíveis, identificação e tratamento de anomalias, validação e adaptação de schemas, dentre outras tarefas ligadas à garantia de qualidade e integridade de dados.
No grupo de engenharia de analytics, eu incluo tarefas como padronização de nomenclatura, enriquecimento de dados, agregação de dados, modelagem de dados, dentre outras tarefas ligadas à disponibilização para consumo de produtos de dados.
Pra concluir esta competência, como comentei sobre engenharia de analytics e especificamente que a tarefa modelagem de dados, a ideia da Saga é explorar pelo menos três padrões de modelagem de mercado: Star Schema (Kimball), OBT (One Big Table) e Data Vault (Dan Linstedt). Ao meu ver, são padrões bem diferentes e portanto, será interessante explorar modelagens distintas para um mesmo problema ou mesmo pensar na modelagem ideal que facilite o processo de criação de produtos de dados.
Servir
Fazendo uma analogia com um restaurante, imagine que você peça o melhor prato da casa, aquele que é a especialidade do chef e digno de inúmeras críticas positivas em redes sociais, sites e revistas especializadas. Um prato que tem uma série de processos complexos a serem seguidos minuciosamente, para que o aroma, o sabor e a temperatura estejam ideais ao chegar na sua mesa.
Pois agora imagine se na hora de empratar, alguém da cozinha resolve escolher um tupperware fundo ao invés de um lindo prato de porcelana? Ou imagine que este prato seja uma entrada como uma sopa ou um caldo super elaborado, servido num prato super raso?
Eu sei que você deve estar pensando que a analogia é um tanto exagerada, mas para a pessoa que está sendo servida, a experiência com o serviço conta muito e precisa ser a melhor possível. E numa plataforma de dados, se você tiver aplicado todas as melhores práticas de ingerir, armazenar e transformar os dados, mas não servir estes dados de uma forma adequada a um usuário de qualquer natureza, que permita que ele consiga responder às questões de negócio com produtos de dados, provavelmente este usuário ficará frustrado e tentará arrumar alguma outra forma de resolver os problemas fora da plataforma de dados (capturando dados em sistemas e criando planilhas é uma destas formas).
Numa plataforma de dados, a estratégia para servir deve levar em conta alguns aspectos como: onde o dado está armazenado (data lake, data warehouse, data lakehouse), quais produtos de dados irão consumir estes dados, qual o nível de alfabetização em dados que o usuário possui, qual o tempo de resposta esperado pelo usuário ao consumir estes dados, qual o volume de dados que irá transitar nesta camada, quais camadas ou estágios de maturidade de dados serão servidos, dentre outros aspectos.
Não vou me ater neste bloco de falar de outros tipos de componentes que são servidos na plataforma de dados, como modelos de machine learning, dashboards e demais produtos de dados. Eles serão tratados na competência Criar (Produtos de Dados).
No que tange a disciplinas que atendam à competência de servir (dados), eu acredito ser extremamente necessária a disponibilização de uma camada semântica de dados, que seja uma camada entre o armazenamento e os produtos de dados que entregue uma "tradução" de conceitos comuns para o negócio, que possa ser evoluída ou ajustada independente da fonte do dado e independente do produto de dados que irá utilizar. Esta camada é importante e necessária tanto para acelerar o entendimento de usuários para prover um ambiente de self-service analytics quanto para permitir que o time de dados possa evoluir ou modernizar a plataforma de dados nos bastidores, sem comprometer a semântica e experiência que o usuário já está acostumado.
Existem ferramentas especificamente para este fim, mas uma camada semântica pode ser construída também com uma integração de ferramentas como query engines ou data lake engines associados com catálogos de dados ou ferramentas de data discovery.
Outro tópico, muitas vezes tratado ou citado como camada semântica e que frequentemente é lista como parte da plataforma moderna de dados, é a Metrics Store. A ideia de uma ferramenta de Metrics Store é dar a capacidade de poder escrever uma lógica que calcule e mantenha métricas disponíveis para serem consumidas por produtos de dados, ao invés de construir a métrica diretamente em um produto de dados, como por exemplo uma ferramenta de BI ou dashboard e ter que replicar a mesma para novos produtos, dificultando a manutenibilidade.
Por fim, análogo ao conceito de Metrics Store, mas com a função de servir dados para modelos de machine learning e demais produtos de data science, temos as Feature Stores. Eu pensei algumas vezes se deveria colocar este tópico aqui ou quando eu fosse comentar sobre MLOps. Preferi já citar este tipo de componente aqui, mas ele será melhor aprofundado quando estivermos trabalhando com modelos de machine learning e especificamente com feature engineering durante nossa Saga. As Feature Stores são plataformas que têm o propósito de disponibilizar um ambiente onde você possa construir, armazenar e servir features para modelos de machine learning, seja para o treinamento e validação dos modelos, quanto na inferência em produção.
No próximo artigo, vou concluir esta introdução a Plataforma Moderna de Dados descrevendo as competências de Criar (Produtos de Dados), Orquestrar e Governar, além de apresentar um diagrama detalhado sobre minha visão de plataforma moderna de dados.
Até logo menos !!! :)
