01. Escolha de armazenamento e ferramentas

Antes de escolher uma linguagem, determine que dados precisam chegar, com qual atualidade e como serão consumidos. Arquivos de sensores, tabelas de vendas e cadastros corporativos podem compartilhar o OneLake e ainda exigir mecanismos diferentes de escrita, transformação e consulta.

Lakehouse e Warehouse

O Lakehouse reúne arquivos e tabelas Delta e favorece engenharia com Spark, dados de formatos variados e preparação em camadas. Seu endpoint de análise SQL oferece leitura das tabelas compatíveis, mas não deve ser tratado como um Warehouse com todas as operações de escrita. A transformação precisa usar um caminho suportado pelo item.

O Warehouse privilegia estruturas relacionais gerenciadas, T-SQL e operações analíticas sobre fatos e dimensões. Uma equipe que já mantém regras relacionais pode executar transformações perto das tabelas sem deslocar todo o conjunto para outro motor. A decisão depende da superfície SQL suportada e do padrão de carga, não apenas da extensão dos arquivos recebidos.

Ambos podem fazer parte da mesma arquitetura. O Lakehouse pode preservar dados brutos e realizar engenharia, enquanto uma camada relacional atende consumidores específicos. Essa composição exige contratos de atualização e qualidade; compartilhar uma base de armazenamento não torna toda cópia uma versão lógica automaticamente sincronizada.

Considere duas tabelas estruturadas com volumes semelhantes. Uma é preparada por bibliotecas Spark e convive com arquivos brutos; a outra integra uma solução relacional mantida por uma equipe T-SQL. O formato tabular, isoladamente, não decide entre Lakehouse e Warehouse. Linguagem de escrita, transações, processamento e consumo são critérios mais informativos. A arquitetura também pode combinar experiências, mas cada passagem precisa justificar custo e responsabilidade. Copiar dados para outro motor sem uma necessidade clara acrescenta um estado que terá de ser atualizado e reconciliado.

Eventhouse e eventos contínuos

Eventhouse organiza bancos KQL para ingestão e análise de eventos, logs e séries temporais. É uma opção natural quando filtros de tempo, agregações e investigação de telemetria dominam o consumo. Eventstream atua na recepção, transformação e roteamento de fluxos de eventos de fontes suportadas. Os dois recursos são complementares, não nomes diferentes para o mesmo item.