A maioria das equipas afoga-se em dados de eventos e passa fome de respostas.

Instrumentas o produto, a pipeline, os pagamentos. Armazenar é barato, por isso guardas tudo "para depois". E depois o depois chega, e a distância entre ter os dados e perceber o que dizem revela-se enorme: um armazém para manter, pipelines para conservar saudáveis, e uma query por detrás de cada gráfico que alguém com SQL tem de escrever.

As ferramentas que servem isto (conectores geridos, armazéns na cloud, frameworks de transformação, dashboards de BI) são genuinamente excelentes. Também assumem, discretamente, uma equipa de dados. Alguém modela as tabelas. Alguém trata das pipelines. Alguém escreve a query. Tira essa equipa e o "self-service analytics" torna-se, sem alarde, "self-service para quem já sabe SQL".

É essa a lacuna que o Event Horizon Data existe para fechar.

Não é mais um dashboard

A tentação era construir um dashboard mais bonito e encaixá-lo no armazém que já tens. Não o fizemos, porque os três quartos difíceis do problema vivem a montante do dashboard:

A ingestão é canalização, e canalização tem fugas. Meter eventos de forma fiável (tipados, normalizados no tempo, contados exatamente uma vez) é um problema de sistemas distribuídos que a maioria subestima.
O armazém é um custo e um compromisso. Os row stores dobram-se sob varrimentos analíticos; armazéns tarifados cobram-te a curiosidade.
A última milha ainda precisa de SQL, e portanto de um analista.

Por isso construímos o caminho inteiro: ingestão self-service (SDK plug-and-play, um agente agnóstico à linguagem, change-data-capture, webhooks), um armazém colunar desenhado para armazenamento barato por cliente e leituras sub-segundo, e uma última milha sem SQL: dashboards de arrastar e largar, exploração que um não-analista consegue conduzir, e mineração de dados (deteção de anomalias, previsão, análise de fatores) calculada no armazém em vez de num projeto de ML à parte.

O que se segue aqui

Este blog é onde vamos escrever as partes que valem a pena partilhar: as decisões de engenharia, as medições que nos surpreenderam, as coisas que corremos mal e corrigimos. Sem adjetivos onde um número serve.

Se quiseres o argumento mais longo, o whitepaper apresenta o problema, o espaço de soluções e a arquitetura por inteiro.

Em breve, mais.