@kapa.ai source, destinations e connections são que tipos de recurso?

No Airbyte, sources, destinations e connections são os conceitos centrais para mover dados: • Source (Fonte): É o banco de dados, API ou outro sistema de onde você sincroniza os dados. [Sources, destinations, and connectors] • Destination (Destino): É o data warehouse, data lake, banco de dados ou outro sistema para onde você sincroniza os dados. [Sources, destinations, and connectors] • Connection (Conexão): É o relacionamento entre um conector de source e um conector de destination. Ao criar uma connection, você cria um pipeline de dados automatizado que sincroniza dados da source para a destination. As connections definem coisas como: quais dados replicar, como ler e gravar os dados, quando iniciar uma sincronização, onde gravar os dados replicados e como lidar com mudanças de schema. [Connections and streams] Esses recursos utilizam connectors — os componentes que o Airbyte usa para se conectar e interagir com suas sources e destinations. O Airbyte disponibiliza mais de 600 connectors, quase todos open source. [Sources, destinations, and connectors] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai como esses 3 conceitos se relacionam com o k8s?

No Airbyte, sources, destinations e connections se relacionam com o Kubernetes da seguinte forma: Connectors rodam como pods no Kubernetes Cada operação de conector é executada como um workload — um pod no Kubernetes que encapsula a invocação de um ou mais métodos de interface do conector (READ, WRITE, CHECK, DISCOVER, SPEC). [Architecture overview] Existem dois tipos principais de pods: • Replication (SYNC) pods: Criados quando uma connection executa uma sincronização. Chamam READ no conector de source e WRITE no conector de destination — ambos rodando no mesmo pod. [Workloads & Jobs] • Connector Job pods (CHECK, DISCOVER, SPEC): Criados para operações pontuais em um conector de source ou destination, como verificar credenciais ou descobrir o schema. [Workloads & Jobs] Os pods só existem durante a execução Os pods de source e destination são lançados apenas quando uma connection está em execução. Com o autoscaling do cluster Kubernetes, é possível reduzir custos quando não há sincronizações ativas. [Forum: Isolation and Combination] Quem gerencia os pods? O componente Launcher (

airbyte-workload-launcher

) é responsável por consumir eventos da Workload API e interagir com o Kubernetes para lançar os pods. Ele também controla a criação de jobs com base nos recursos disponíveis, minimizando situações de deadlock. [Architecture overview; Workloads & Jobs] Em resumo: cada vez que uma connection dispara uma sincronização, o Airbyte cria pods no Kubernetes para executar os conectores de source e destination configurados naquela connection. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.