Certas construções são tão bem feitas que merecem reconhecimento, principalmente
daqueles que estão envolvidos com aquela ciência/arte: Arquitetura, Engenharia,
Música, Computação ou outras. Como qualquer interprete tem orgulho e gosto ao
cantar Under Pressure,
engenheiros/desenvolvedores de software também sentem-se felizes ao utilizarem
aquele framework que deixa sua aplicação mais bonita e gostosa de se
desenvolver.
Imagina esses 2 gênios esconderem Under Pressure da gente
Eu já introduzi a vocês o Incrível
BigQuery:
solução de armazém de dados do Google, uma das construções de software mais
inteligentes dos últimos anos quando o assunto é Bancos de Dados Distribuídos e
Motores de
Consulta
e que resolve grandes dores pra quem tem dados massivos para processar.
Mas não é só a estética da ferramenta que conta. Lembrei que construir uma
arquitetura complexa de processamento de dados distribuídos normalmente **sai
bastante caro, **seja em gastos com infra ou com pessoal. De nada adianta ser
uma solução perfeitamente estética e bem construída se ela é cara, demorada,
difícil de se implantar e, pior, longe de resolver os mais importantes
problemas da sua organização.
The Data Swamp
Você satisfeitão no seu Data Lake
Na onda do hype do Big
Data,
muitas organizações estão começando a aplicar o conceito de Data
Lake
em suas operações de tecnologia. Estão se distanciando das ferramentas e
técnicas tradicionais de Business
Intelligence*. Tudo na
ilusão de que trazendo tudo que há de dados desestruturados rolando no negócio
para um repositório único vai magicamente trazer insights que seus analistas
de dados nunca tiveram antes. E vão surfando nessa onda… até por terem pouca
maturidade, serem pouco
data-driven
intrinsecamente, vão sem perceber que essa onda criada artificialmente na sua
piscina tem todo um aparato shiny new and disruptive que é muito custoso*.
A empresa quer ser disruptiva. Quer virar data-driven, sem se tocar que
isso é uma cultura, quase um hábito. Olha pra fora e contrata vários
sabichões técnicos em Hadoop, famosos queimadores de créditos AWS.
E constrói aquela armadilha gigantesca e começa a colocar de tudo lá dentro:
tabelas de negócio do produto mais importante, logs de acesso da aplicação,
planilhas do pessoal do financeiro, videos do sistema de segurança interno,
registro de ponto em PDF do rapaz que entrega o lanche, tudo… TUDO… vai
jogando lá…
E é claro que faz sentido… dizem que o IBM
Watson consegue entender até
que o atraso nas segundas do rapaz do lanche implica numa piora de desempenho da
galera de DevOps que por sua vez interfere na disponibilidade da aplicação,
resultando aumento em 0,5% do churn rate e por consequência queda da receita!
Oh God! Que ferramenta incrível! Vou só montar um Data Lake aqui então…Ué… TUDO
TA INTERLIGADO! Só basta um “Machine Learning” pra resolver esse negócio não é
não?
Diz aí Fausto: ERRROOOOUU!!1!
E é assim que grande parte dos projetos de Big Data tem surgido: Ferramenta -> Solução -> Problema. Exatamente o inverso do que deveria ser: Problema -> Solução -> Ferramenta
Aqui então vai minha sugestão para o enfrentamento deste cenário de maneira
pragmaticamente correta:
Problema:
Sem Governança dos Dados, sem Curadoria dos Dados, seu Data Lake vai virar um
Data Swamp! Ninguém, absolutamente ninguém, vai conseguir pescar nada de lá.
Nem mesmo seu time de Dados vai saber diferenciar bem o que é peixe e o que é
bota na hora que puxar a rede. Não tem documentação que acompanhe a variedade e
volume dos dados. Não tem time suficiente para mastigar tudo para entregar
informações úteis para o negócio. Seu Data Swamp não vai passar de um
estorvo gigantesco dentro da sua organização e cedo ou tarde vai ter que ser
limado de lá — junto com os sabichões — a fim de otimizar os custos.
Solução:
Construir algo que acompanhe os dados de ponta a ponta, explicando sua
evolução e transformação. Algo que extraia valor somente do que há de valor.
A construção do Data Lake deve ser iterativa e entregar valor a cada
entrega, assim como já aprendemos com Desenvolvimento de
Software. Ele também deve ser
inteligível para todas as áreas de negócio, deixando de empatar seu time de
dados para que ele atue realmente no que lhe interessa: melhoria contínua do
processo de aquisição de dados para** disponibilização de informação**.
Nossos pilares
Um dos maiores desafios em qualquer empresa que tem crescimento acelerado é
manter todo o time, novo e antigo, focado na Cultura e nas Metas. Para
Cultura, há métodos de RH e Gestão comumente aplicados que conseguem manter a
missão e visão da empresa fresca na memória dos colaboradores mais
antigos e bem fixada na mente dos colaboradores novos.
Para Metas, o desafio já ultrapassa o RH, com treinamentos e ações de
ambientação e até cultura data-driven: Vontade e Gestão Eficiente não basta.
É necessária a Democratização dos Dados para a facilitar a Tomada de
Decisão.
É isso que tem guiado todas decisões de arquitetura do time de Dados da
MaxMilhas. Ter poucos “consultores”
independentes, que monopolizam o entendimento dos dados de negócio da empresa
não é saudável e muito menos contribuem para o crescimento da organização como
um todo.
Sendo assim, levantamos como requisitos de uma Arquitetura Democrática de
Dados:
- **Inteligibilidade: **Toda área deve ser capaz de ver e entender os dados
que lhes interessam sem necessidade de *consultoria *especial do time de Dados a
todo momento. - **Integrabilidade: **Todas fontes de dados devem ser mutuamente integráveis,
de forma que partes do negócio não se isolem, deixando de entregar valor para
toda a organização. - **Rastreabilidade: **Todos dados devem ser rastreáveis e acompanhados de ponta
a ponta, de forma que, ao menos o time de Dados, seja Autoridade sobre as
fontes, suas transformações e disponibilização final, sejam brutos ou em
insights. - **Escalabilidade: **Toda a arquitetura de dados deve ser construída de forma a
suportar o crescimento exponencial da empresa, evitando gargalos e erros ao
prover informação de valor para os decisores. - Confiança: Toda a arquitetura de dados deve prover confiança total dos
dados que disponibiliza. Isso implica em dados idealmente sem erros, sem
atraso e sem perdas.
Entender nossos clientes, TODOS eles, com Dados, e CADA UM deles, com UX/Design,
é essencial para guiar todo rumo do negócio de nossa empresa.
Tais pilares nos guiam para as escolhas de arquitetura corporativa e também de
nosso produto. São esses pilares inclusive alguns dos motivos de **nosso time de
Dados ser uma célula dentro de nosso time de Produto ***— buscando sempre o
conceito de Data-Driven Product contando com profissionais de qualidade, design, engenharia e desenvolvimento.
