Modernizando dados corporativos: Hadoop, Netezza e a mudança de rumo das plataformas de dados

O estado do ambiente de dados

Entre no ambiente de dados de qualquer banco de primeira linha e encontrará camadas de história. Um mainframe. Um warehouse Oracle adquirido nos anos 2000. Um appliance Netezza comprado para acomodar relatórios regulatórios. Um cluster Hadoop montado por uma equipe de análise. Cargas SAS. Tableau. SQL Server. Uma presença crescente de Azure ou AWS. Cada camada foi a resposta certa ao problema que alguém tinha no dia da compra.

O trabalho do arquiteto de dados corporativos não é substituir tudo isso por uma bela plataforma. É traçar os limites: quais cargas pertencem a qual plataforma, quais plataformas são estratégicas, quais são táticas e quais chegaram ao fim da vida útil. Depois, igualmente importante, é fazer esses limites serem respeitados — assessorando, aprovando e recomendando a escolha de plataforma para cada nova iniciativa.

Hadoop como zona estratégica de recepção

O Hadoop foi a aposta estratégica para cargas novas e não estruturadas. O esquema na leitura permitiu receber dados brutos sem negociar primeiro um esquema de destino; o HDFS e o metastore do Hive nos deram um local físico único para junções entre domínios; o ecossistema aberto (Spark, Hive, Impala e notebooks posteriores) deu às equipes de análise a flexibilidade necessária sem criar infraestrutura sob medida.

A regra arquitetural que escrevemos era simples: se uma nova carga recebe dados brutos de eventos, cruza domínios ou atende cientistas de dados que precisam de computação flexível, a plataforma escolhida é o Hadoop. Se gera relatórios regulatórios por linha em um data mart rigorosamente modelado, permanece onde está.

Netezza como motor tático de trabalho

O Netezza não precisava ser substituído. Precisava parar de acumular cargas para as quais não foi projetado. O appliance continua excelente no que faz bem: SQL estruturado, baseado em conjuntos e de formato previsível sobre tabelas de fatos de vários terabytes. Data marts regulatórios, relatórios financeiros e agregação de riscos — todas boas cargas para Netezza, todas permaneceram.

O que removemos do Netezza foram cargas que nunca deveriam ter estado ali: análises exploratórias ad hoc sobre fluxos brutos de eventos, junções entre domínios que deveriam ocorrer em uma zona de recepção e preparação ETL que usava o warehouse como tabela temporária. Removê-las liberou o appliance para cumprir melhor sua função real.

A árvore de decisão para selecionar plataformas

Aprovar escolhas de plataforma para novas iniciativas exige uma árvore de decisão repetível, não uma reunião. A que usamos:

• São relatórios regulatórios sobre um data mart modelado? → Estrutura de warehouse existente (Netezza ou Oracle).
• Recebe dados brutos de eventos com esquema flexível? → Zona de recepção do Hadoop.
• É uma carga transacional? → Banco de dados operacional, não o conjunto de warehouses.
• É uma análise exploratória baseada em notebooks? → Hadoop com acesso somente leitura a data marts modelados via federação.
• O conjunto de dados é novo e o consumidor é nativo da nuvem? → Caminho de plataforma de dados em nuvem, com fluxo unidirecional deliberado de volta ao ambiente local.

Essa árvore, somada a uma revisão de arquitetura de dados corporativos no início de cada iniciativa, evitou a expansão descontrolada do ambiente. A árvore é mais importante que as escolhas tecnológicas que produz.

Governança sem burocracia

A governança de dados tem má reputação porque muitas vezes é entregue como política sem meios para aplicá-la. A versão que funciona em um banco de primeira linha é aquela em que a governança entrega ferramentas e controles junto com as políticas: um catálogo de metadados realmente atualizado, um esquema de classificação de dados aplicado na ingestão, linhagem automática em vez de mantida manualmente e um caminho claro de escalonamento para as exceções que sempre existem.

Nosso papel como arquiteto de dados corporativos foi ser a ponte entre a equipe de governança e as equipes de entrega. A governança estabelecia as regras; nós garantíamos que elas aparecessem sempre na escolha de plataforma. Os projetos que fizeram isso direito foram mais rápidos, não mais lentos — porque não precisaram refazer a camada de dados seis meses depois.

O que isso significa para sua estratégia de dados

• Não procure a única plataforma perfeita. Procure o limite certo entre duas ou três delas.
• Desative removendo cargas, não plataformas. A plataforma diminui naturalmente quando você para de enviar o trabalho errado para ela.
• Revisão de arquitetura no início, não no fim. Aprovar a escolha da plataforma cedo custa dez vezes menos do que reconstruir.
• Linhagem e classificação na ingestão. Adicioná-las depois é a forma mais cara de dívida técnica em um ambiente de dados.
• A nuvem é um destino, não um prazo. Migre as cargas que se beneficiam; mantenha as que não se beneficiam.

Repensando seu ambiente de dados?

A SEYSO prestou consultoria de arquitetura de dados corporativos para bancos de primeira linha — selecionando plataformas, desativando duplicidades e governando ambientes de dados multiplataforma. Se você enfrenta uma estrutura de warehouses em expansão, um cluster Hadoop subutilizado ou uma migração de dados para a nuvem que precisa ser organizada em etapas, adoraríamos conversar.