Ferramenta aberta

FinOps Databricks

Framework open source de assessment de FinOps para Databricks: score de maturidade e recomendações para priorizar onde otimizar custo primeiro.

O que é o FinOps Databricks Framework

Um framework open source de assessment de FinOps para Databricks. Ele coleta métricas do workspace, organiza em arquitetura medalhão (bronze, silver, gold), calcula um score de maturidade e gera recomendações acionáveis — para priorizar onde otimizar custo primeiro. Não substitui a fatura da nuvem nem é veredito de conformidade: é um levantamento para decidir onde agir.

Estado honesto

Vale começar pelo que a ferramenta ainda não garante, porque é justamente isso que a torna crível. O núcleo de assessment — coleta, medalhão, score, recomendações e relatório — é executável e testado nas partes puras. Já o motor de custo medido (via as system tables de billing) e a atribuição de custo por modelo dbt estão implementados, mas ainda não validados contra um Databricks de produção. Aqui eles são tratados como "prontos para validação", não como resultado garantido. É uma escolha deliberada declarar isso em vez de inflar.

O que é real hoje

Arquitetura medalhão de ponta a ponta em notebooks: coleta, processamento, análise e revalidação.

Coleta de clusters, jobs, runs e storage via API e SQL do Databricks.

Estimativa de custo DBU por uptime vezes taxa — declarada como estimativa, não medição: a fatura real depende de preço negociado e descontos.

Baseline versionado, que compara maturidade e custo entre períodos.

Recomendações acionáveis ancoradas ao recurso, com os comandos de automação não-executáveis por padrão: o framework mostra o comando e o rollback, e só um modo opt-in, desligado por padrão, libera a execução de ações de baixo risco.

Relatório técnico autocontido com a matriz Desperdício, Esforço e Risco, um SWOT executivo e uma seção de metodologia e limitações.

Testes de unidade das fórmulas puras — custo, alocação, parser de tags, thresholds — que rodam sem Spark.

Implementado, ainda a validar

Motor de custo medido, via as system tables de billing e utilização, com as limitações escritas no próprio código: DBU a preço de lista (tipicamente abaixo do total faturado), a janela de retenção das system tables, e um campo de cobertura para o que ficou sem preço.

Atribuição de custo por modelo dbt e por tag, que cruza o identificador da query no histórico com o comentário que o dbt injeta, atribuindo o custo do warehouse ao modelo que o gerou.

Limites declarados

O custo "real" via system tables é DBU a preço de lista — sem desconto de contrato. Use como ordem de grandeza e tendência, não como valor de fatura.

A atribuição por pipeline, produto ou SLA depende de convenção de nome de job e tags. Onde não há convenção, é heurística explícita, marcada como tal na saída, não medição.

Os limiares de nível (bom, médio, ruim) são referências heurísticas internas, não benchmark de indústria — são ponto de partida configurável.

O motor de custo medido e a atribuição dbt ainda não foram executados contra um Databricks de produção; a validação em ambiente real é a próxima frente.

O motor de custo real exige Unity Catalog (as system tables são UC-only); o caminho Hive Metastore cobre só a coleta básica.

O que é aberto e o que é serviço

Aberto, neste repositório sob Apache 2.0: toda a arquitetura, o modelo de dados, os scripts de coleta, as regras de diagnóstico, o motor de custo estimado e medido, a atribuição por dbt e tag, o baseline e o relatório.

Serviço profissional da mldata: a implementação e validação em ambiente real, a calibração da reconciliação com a fatura da nuvem, os playbooks de correção profunda e os dashboards executivos. Não é código escondido — é o trabalho de aplicar e validar o framework no seu ambiente. Rodar o assessment, validar as estimativas contra a fatura real e executar a otimização é o passo seguinte.

Ver no GitHub ↗

Código aberto sob Apache 2.0. Implementar e validar no seu ambiente é o trabalho da mldata.