Reverse ETL vs. nuvem privada: um guia conceitual de sobrevivência

Reverse ETL vs. nuvem privada: um guia conceitual de sobrevivência

O encontro entre a "força imparável" e o "objeto imóvel"

As arquiteturas de dados modernas geralmente têm um objetivo comum: colocar os dados do warehouse nas mãos das equipes que precisam deles. Mas quando você está trabalhando em ambientes com segurança de rede rigorosa, muitas vezes chega a um impasse.

De um lado, você tem o Segment Reverse ETL, que precisa de um endpoint HTTPS público para fazer seu trabalho. Por outro lado, você tem um Databricks SQL Warehouse protegido dentro de uma rede virtual (VNet) privada do Azure, inacessível pela internet pública.

Isso introduziu duas restrições principais:

• A Segment requer um endpoint HTTPS publicamente acessível
• O Databricks SQL Warehouse não era acessível ao público

Isso criou um gap entre os requisitos de conectividade e o isolamento da rede, tornando a integração direta inviável. A segurança diz "Sem acesso público". A Segment diz "Não consigo ver você". Veja como construímos uma ponte entre elas sem violar as regras.

Segment Reverse ETL em ação: Três maneiras de falhar (e uma maneira de ganhar)

Para enfrentar esse desafio, várias abordagens foram avaliadas durante a proof of concept (prova de conceito). Não acertamos no primeiro dia. Tratamos essa prova de conceito (POC) como um sprint para encontrar os "bloqueadores" específicos na cadeia de conectividade. Cada etapa ajudou a identificar o que era necessário para uma solução de trabalho.

Tentativa de conectividade direta

Tentamos a linha reta primeiro. Tentamos conectar o Segment Reverse ETL diretamente ao Databricks SQL Warehouse.

• O resultado: silêncio total.
• A lição: você não pode "apertar a mão" de um servidor que não esteja na lista de convidados. Os endpoints privados são privados por um motivo.

Isso não foi bem-sucedido porque:

• O Databricks não era acessível ao público
• A Segment não conseguiu alcançar endpoints privados

Isso confirmou que a conectividade direta não era viável em uma configuração de rede privada.

A abordagem seguinte envolveu o uso do conector Databricks da Segment com a configuração padrão.

Configuração padrão do conector

Em seguida, experimentamos o conector Databricks da Segment com configuração padrão. De imediato, nos deparamos com dois obstáculos:

Incompatibilidade de OAuth: A Segment esperava um fluxo de autenticação específico (credenciais básicas/do cliente), enquanto o Databricks exigia um processo completo de autenticação OAuth, com o qual o conector atual ainda não estava preparado para lidar.

O filtro de nome do host: o driver do Databricks é exigente. Ele usa uma verificação strings.Contains para procurar azuredatabricks.net no nome do host. Se não estiver lá, ele nem tentará estabelecer comunicação.

Visando agilizar o processo, a introdução de uma camada externa de proxy foi identificada como a abordagem mais prática.

Mapeamento personalizado de nome de host e DNS

Para atender aos requisitos de validação do conector, foi introduzido um nome de host personalizado que incluía azuredatabricks.net.

Exemplo de padrão:

• dev.staging.azuredatabricks.net.<custom-domain>

Esse nome de host foi mapeado para o IP público do Gateway de Aplicativo do Azure.

Essa abordagem garantiu:

• Resolução DNS bem-sucedida
• Compatibilidade com a validação do nome do host do conector

Além disso, o comportamento do driver do Databricks SQL foi considerado:

• O driver determina o contexto do provedor de nuvem com base na correspondência de nomes de host
• Como utiliza correspondência por substring (strings.Contains), seria possível construir um nome de host compatível e, ainda assim, direcionar o tráfego por meio de uma infraestrutura personalizada

No entanto, essa abordagem por si só não foi suficiente porque:

• Não havia lógica de back-end para processar solicitações
• O tratamento da autenticação não havia sido implementado
• Não havia lógica de roteamento ou transformação das requisições

Isso confirmou que o alinhamento do DNS era necessário para a validação, mas não era suficiente para a integração.

Abordagem apenas do gateway de aplicativos

Adicionamos um Gateway de Aplicativo do Azure para gerenciar a entrada de tráfego público. Isso resolveu o problema de "visibilidade", mas o Gateway não é um componente inteligente, ele não conseguia lidar com a complexa troca de tokens necessária para atender aos requisitos do Databricks.

Gateway de Aplicativo fornecido com sucesso:

• Entrada de tráfego público
• Encerramento de TLS
• Roteamento de requisições

No entanto, essa abordagem falhou porque:

• Não foi possível realizar a troca de token OAuth
• Não foi possível expor endpoints de autenticação
• Não foi possível lidar com transformações no nível da requisição

Isso confirmou que o roteamento por si só não era suficiente para permitir a integração.

Autenticação e roteamento via camada de proxy

Um serviço de proxy personalizado foi implementado para preencher gaps de autenticação e conectividade entre a Segment e o Databricks.

O proxy foi projetado para se alinhar às expectativas da Segment enquanto interage com segurança com o Databricks.

Camada de autenticação

• Expõe endpoints compatíveis com OIDC:
• /oidc/v1/token
• /oidc/.well-known/oauth-authorization-server
• /oidc/jwks.json
• Aceita autenticação básica da Segment
• Emite tokens JWT assinados (RS256)
• Valida os tokens JWT recebidos utilizando pares de chaves públicas e privadas
• Gerencia o ciclo de vida dos tokens por meio de identificadores únicos (jti)

Troca de token com Databricks

• Recupera tokens de acesso do Databricks usando o fluxo client_credentials
• Armazena tokens para minimizar chamadas de autenticação repetidas
• Substitui os tokens emitidos pelo proxy recebidos por tokens OAuth válidos do Databricks

Camada de encaminhamento de requisição

• Encaminha requisições para endpoints do Databricks (/api, /sql)
• Normaliza e remove cabeçalhos conflitantes antes de encaminhar
• Preserva a compatibilidade com APIs do Databricks SQL

Recursos operacionais

• Endpoint de saúde (/health) para monitoramento
• Suporte TLS para comunicação segura
• Rastreamento de requisições com visibilidade da latência (tempo do proxy versus tempo do serviço upstream)

Isso resolveu:

• Problemas de validação do conector
• Incompatibilidade de autenticação
• Falhas de execução de consulta

O proxy atuou efetivamente como uma camada de tradução de autenticação e um mecanismo de controle de roteamento.

A inovação: o proxy de "troca de identidade"

Para vencer, precisávamos de mais do que um simples canal de comunicação; precisávamos de um tradutor. Desenvolvemos um serviço de proxy personalizado para atuar entre o Gateway e o Databricks.

O tempero secreto

Nosso proxy realizou um pouco de "mágica" técnica para manter ambos os lados satisfeitos:

• A máscara DNS: Damos ao proxy um nome de host personalizado, como dev.staging.azuredatabricks.net.custom-domain.com. Por conter a "string mágica", o driver do Databricks aceitou a conexão.
• A troca de tokens: O proxy disponibiliza endpoints compatíveis com OIDC. Ele recebe as credenciais da Segment, conecta-se ao Databricks para obter um token OAuth "real", armazena esse token em cache para obter velocidade e o injeta na requisição.
• Limpeza do cabeçalho: O proxy limpa e normaliza os cabeçalhos em tempo real, garantindo que, ao chegar ao Databricks, a requisição tenha um formato perfeitamente compatível com o padrão nativo da plataforma.

A arquitetura final

Fluxo de requisição: