Resposta curta: A IA não substituirá completamente os engenheiros de dados; ela automatizará tarefas repetitivas, como elaboração de SQL, estruturação de pipelines, testes e documentação. Se sua função envolve principalmente tarefas com pouca responsabilidade e baseadas em chamados, a IA estará mais exposta; se você é responsável por confiabilidade, definições, governança e resposta a incidentes, a IA principalmente tornará seu trabalho mais rápido.
Principais conclusões:
Responsabilidade : Priorize a responsabilidade pelos resultados, e não apenas a produção rápida de código.
Qualidade : Implementar testes, observabilidade e contratos para que os pipelines permaneçam confiáveis.
Governança : Mantenha a privacidade, o controle de acesso, a retenção e os registros de auditoria sob responsabilidade humana.
Resistência ao uso indevido : Trate os resultados da IA como rascunhos; revise-os para evitar conclusões precipitadas.
Mudança de função : Dedique menos tempo a digitar textos repetitivos e mais tempo a projetar sistemas duradouros.

Se você passou mais de cinco minutos perto de equipes de dados, com certeza já ouviu o refrão — às vezes sussurrado, às vezes lançado em uma reunião como uma reviravolta na trama: A IA substituirá os Engenheiros de Dados?
E… eu entendo. A IA consegue gerar SQL, construir pipelines, explicar rastreamentos de pilha, elaborar modelos dbt e até sugerir esquemas de data warehouse com uma confiança perturbadora. GitHub Copilot para SQL Sobre modelos dbt GitHub Copilot
É como ver uma empilhadeira aprendendo a fazer malabarismos. Impressionante, um pouco alarmante, e você não tem muita certeza do que isso significa para o seu trabalho 😅
Mas a verdade é menos simples do que a manchete sugere. A IA está mudando completamente a engenharia de dados. Está automatizando as tarefas tediosas e repetitivas. Está acelerando aqueles momentos de "sei o que quero, mas não me lembro da sintaxe". E também está gerando novos tipos de caos.
Então vamos analisar a situação como ela é, sem otimismo superficial ou pânico desenfreado.
Artigos que você pode gostar de ler depois deste:
🔗 Será que a IA substituirá os radiologistas?
Como a IA em imagens transforma o fluxo de trabalho, a precisão e os papéis futuros.
🔗 Será que a IA substituirá os contabilistas?
Veja quais tarefas contábeis a IA automatiza e quais permanecem sob intervenção humana.
🔗 Será que a IA substituirá os banqueiros de investimento?
Entenda o impacto da IA em negociações, pesquisas e relacionamento com clientes.
🔗 Será que a IA substituirá os agentes de seguros?
Descubra como a IA transforma a subscrição de seguros, as vendas e o apoio ao cliente.
Por que a pergunta “IA substitui Engenheiros de Dados” continua ressurgindo? 😬
O medo vem de um lugar muito específico: a engenharia de dados envolve muito trabalho repetitivo .
-
Escrita e refatoração de SQL
-
Criação de scripts de ingestão
-
Mapeamento de campos de um esquema para outro
-
Criação de testes e documentação básica
-
Depurando falhas em pipelines que são… meio previsíveis
A IA é excepcionalmente boa em identificar padrões repetíveis. E uma boa parte da engenharia de dados consiste exatamente nisso: padrões sobrepostos a padrões. Sugestões de código do GitHub Copilot
Além disso, o ecossistema de ferramentas já está "escondendo" a complexidade:
-
Conectores ELT gerenciados - Documentação da Fivetran
-
Computação sem servidor AWS Lambda (computação sem servidor)
-
Provisionamento de armazém com um clique
-
Orquestração de escalonamento automático - Documentação do Apache Airflow
-
Estruturas de transformação declarativa. O que é DBT?
Então, quando a IA aparece, pode parecer que é a última peça que falta. Se a arquitetura já está abstraída e a IA pode escrever o código de integração… o que resta? 🤷
Mas eis o que as pessoas ignoram: engenharia de dados não se resume a digitar . Digitar é a parte fácil. A parte difícil é fazer com que a realidade empresarial, complexa, política e em constante mudança, se comporte como um sistema confiável.
E a IA ainda enfrenta dificuldades com essa complexidade. As pessoas também enfrentam dificuldades – elas apenas improvisam melhor.
O que os engenheiros de dados realmente fazem o dia todo (a verdade nada glamorosa) 🧱
Sejamos francos: o título do cargo de "Engenheiro de Dados" soa como se você estivesse construindo motores de foguete usando matemática pura. Na prática, você está construindo confiança .
Um dia típico envolve menos "inventar novos algoritmos" e mais:
-
Negociar com as equipes upstream sobre definições de dados (doloroso, mas necessário)
-
Investigando por que uma métrica mudou (e se essa mudança é real)
-
Lidando com desvios de esquema e surpresas do tipo "alguém adicionou uma coluna à meia-noite"
-
Garantir que os pipelines sejam idempotentes, recuperáveis e observáveis
-
Criar mecanismos de proteção para que os analistas subsequentes não criem acidentalmente painéis de controle sem sentido
-
Gerenciando custos para que seu armazém não se transforme em um verdadeiro ralo de dinheiro 🔥
-
Garantir o acesso, auditoria, conformidade, políticas de retenção, princípios do RGPD (Comissão Europeia), limitação de armazenamento (ICO)
-
Criando produtos de dados que as pessoas realmente possam usar sem precisar te mandar mensagem direta. 20 perguntas
Grande parte do trabalho é de natureza social e operacional:
-
“De quem é esta mesa?”
-
“Essa definição ainda é válida?”
-
“Por que o CRM está exportando duplicados?”
-
"Será que podemos apresentar essa métrica aos executivos sem constrangimento?" 😭
A IA pode ajudar em algumas partes disso, com certeza. Mas substituí-la completamente é... difícil de alcançar.
O que caracteriza uma função de engenharia de dados de alta qualidade? ✅
Esta seção é importante porque geralmente se fala em substituição de engenheiros de dados partindo do pressuposto de que eles são principalmente "construtores de pipelines". Isso é como presumir que chefs de cozinha se dedicam principalmente a "picar legumes". Faz parte do trabalho, mas não é o trabalho em si.
Um bom engenheiro de dados geralmente é capaz de realizar a maioria destas tarefas:
-
Projetar para a mudança
. Os dados mudam. As equipes mudam. As ferramentas mudam. Um bom engenheiro constrói sistemas que não entram em colapso a cada imprevisto. 🤧 -
Defina contratos e expectativas.
O que significa "cliente"? O que significa "ativo"? O que acontece quando uma linha chega atrasada? Os contratos evitam o caos mais do que códigos sofisticados. Padrão de Contrato de Dados Abertos (ODCS) ODCS (GitHub) -
Incorpore a observabilidade em tudo.
Não apenas "executou?", mas "executou corretamente?". Atualização, anomalias de volume, explosões de valores nulos, mudanças na distribuição. Observabilidade de dados (Dynatrace). O que é observabilidade de dados? -
Faça concessões como um adulto:
velocidade versus precisão, custo versus latência, flexibilidade versus simplicidade. Não existe um pipeline perfeito, apenas pipelines com os quais você pode conviver. -
Transformar necessidades de negócios em sistemas duradouros.
As pessoas pedem métricas, mas o que elas realmente precisam é de um produto de dados. A IA pode elaborar o código, mas não consegue prever magicamente as armadilhas do negócio. -
Mantenha os dados em segredo.
O maior elogio que uma plataforma de dados pode receber é que ninguém fale sobre ela. Dados sem incidentes são bons dados. Como um encanamento. Você só percebe quando ele falha. 🚽
Se você está fazendo essas coisas, a pergunta "A IA substituirá os Engenheiros de Dados?" começa a soar... um pouco estranha. A IA pode substituir tarefas , não a responsabilidade .
Onde a IA já está ajudando os engenheiros de dados (e é realmente incrível) 🤖✨
A inteligência artificial não é apenas marketing. Quando bem utilizada, ela se torna um multiplicador de forças legítimo.
1) SQL e trabalho de transformação mais rápidos
-
Elaboração de junções complexas
-
Escrever funções de janela em que você preferiria não pensar
-
Transformando lógica em linguagem natural em esqueletos de consultas
-
Refatorando consultas complexas em CTEs legíveis: GitHub Copilot para SQL
Isso é muito importante porque reduz o efeito da "página em branco". Você ainda precisa validar, mas começa com 70% em vez de 0%.
2) Depuração e rastreamento da causa raiz
A IA é razoavelmente boa em:
-
Explicando mensagens de erro
-
Sugerindo onde procurar
-
Recomendar etapas do tipo "verificar incompatibilidade de esquema" no GitHub Copilot.
É como ter um engenheiro júnior incansável que nunca dorme e às vezes mente com convicção 😅
3) Enriquecimento da documentação e do catálogo de dados
Gerado automaticamente:
-
Descrição das colunas
-
Resumos de modelos
-
Explicações de linhagem
-
“Para que serve esta tabela?” rascunhos da documentação do dbt
Não é perfeito, mas quebra a maldição dos pipelines não documentados.
4) Testar e verificar os andaimes
A IA pode propor:
-
Testes nulos básicos
-
Verificações de unicidade
-
ideias de integridade referencial
-
Asserções do tipo "Esta métrica nunca deve diminuir" em testes de dados dbt. Grandes Expectativas: Expectativas
Repito: você ainda decide o que importa, mas isso agiliza as partes rotineiras.
5) Código de “cola” do pipeline
Modelos de configuração, estruturas YAML, rascunhos de DAGs de orquestração. Isso tudo é repetitivo e a IA devora repetição no café da manhã 🥣 DAGs do Apache Airflow
Onde a IA ainda enfrenta dificuldades (e este é o ponto crucial) 🧠🧩
Esta é a parte mais importante, porque responde à questão da substituição com textura real.
1) Ambiguidade e definições variáveis
A lógica empresarial raramente é clara. As pessoas mudam de ideia no meio da frase. "Usuário ativo" vira "usuário pagante ativo" vira "usuário pagante ativo, excluindo reembolsos, exceto em alguns casos"... você sabe como é.
A IA não consegue lidar com essa ambiguidade. Ela só pode fazer suposições.
2) Responsabilidade e risco
Quando um pipeline falha e o painel de controle executivo exibe informações sem sentido, alguém precisa:
-
triagem
-
comunicar o impacto
-
conserte
-
prevenir recorrência
-
Escreva a autópsia
-
decidir se a empresa ainda pode confiar nos números da semana passada
A IA pode ajudar, mas não pode ser responsabilizada de forma significativa. As organizações não funcionam com base em impressões, mas sim em responsabilidade.
3) Pensamento sistêmico
Plataformas de dados são ecossistemas: ingestão, armazenamento, transformações, orquestração, governança, controle de custos, SLAs. Uma mudança em uma camada se propaga por todo o sistema. Conceitos do Apache Airflow
A IA pode propor otimizações locais que criam problemas globais. É como consertar uma porta rangendo removendo a porta 😬
4) Segurança, privacidade, conformidade
É aqui que as fantasias de substituição vão morrer.
-
Controles de acesso
-
Segurança em nível de linha Políticas de acesso a linhas do Snowflake Segurança em nível de linha do BigQuery
-
Tratamento de informações pessoais identificáveis (PII) - Estrutura de Privacidade do NIST
-
Regras de retenção Limitação de armazenamento (ICO) Orientações da UE sobre retenção
-
Trilhas de auditoria NIST SP 800-92 (gerenciamento de logs) CIS Controle 8 (Gerenciamento de Logs de Auditoria)
-
Restrições de residência de dados
A IA pode elaborar políticas, mas implementá-las com segurança é uma verdadeira tarefa de engenharia.
5) Os “desconhecidos desconhecidos”
Incidentes com dados são frequentemente imprevisíveis:
-
Uma API de fornecedor altera silenciosamente a semântica
-
Uma inversão de fuso horário
-
Um preenchimento duplica uma partição
-
Um mecanismo de repetição causa gravações duplicadas
-
Uma nova funcionalidade do produto introduz novos padrões de eventos
A inteligência artificial é menos eficaz quando a situação não segue um padrão conhecido.
Tabela comparativa: o que está reduzindo o quê, na prática 🧾🤔
A seguir, uma visão prática. Não se trata de "ferramentas que substituem pessoas", mas sim de ferramentas e abordagens que simplificam determinadas tarefas.
| Ferramenta/abordagem | Público | Vibração de preço | Por que funciona |
|---|---|---|---|
| Copilotos de código de IA (ajudantes SQL + Python) GitHub Copilot | Engenheiros que escrevem muito código | Gratuito ou parcialmente pago | Excelente em estruturação, refatorações, sintaxe… às vezes arrogante de uma forma bem específica |
| Conectores ELT gerenciados Fivetran | Equipes cansadas de construir sistemas de ingestão | Assinatura-y | Elimina a dor da ingestão personalizada, mas quebra de maneiras novas e divertidas |
| Plataformas de observabilidade de dados Observabilidade de dados (Dynatrace) | Qualquer pessoa que possua SLAs | Empresas de médio a grande porte | Detecta anomalias precocemente - como alarmes de fumaça para oleodutos 🔔 |
| Estruturas de transformação (modelagem declarativa) dbt | Híbridos de análise e DE | Geralmente ferramenta + computação | Torna a lógica modular e testável, menos complexa e confusa |
| Catálogos de dados + camadas semânticas dbt Camada Semântica | Organizações com confusão métrica | Depende, na prática | Define "verdade" de uma vez por todas - reduzindo debates intermináveis sobre métricas |
| Orquestração com modelos Apache Airflow | Equipes com foco em plataforma | Custo de operação + abertura | Padroniza fluxos de trabalho; menos DAGs em formato de floco de neve |
| Geração de documentos DBT assistida por IA | Equipes que detestam escrever documentação | De baixo a moderado | Cria documentos "bons o suficiente" para que o conhecimento não desapareça |
| Políticas de governança automatizadas Estrutura de Privacidade do NIST | Ambientes regulamentados | Empresarial | Ajuda a fazer cumprir as regras, mas ainda precisa de humanos para elaborá-las |
Repare no que está faltando: uma linha que diz “pressione o botão para remover os engenheiros de dados”. Pois é… essa linha não existe 🙃
Então… a IA vai substituir os Engenheiros de Dados, ou apenas transformar a função deles? 🛠️
Eis a resposta nada dramática: a IA substituirá partes do fluxo de trabalho, não a profissão em si.
Mas isso vai reconfigurar o papel. E se você ignorar isso, vai sentir a pressão.
O que muda:
-
Menos tempo escrevendo textos padronizados
-
Menos tempo gasto procurando documentos
-
Mais tempo para revisar, validar e projetar
-
Mais tempo para definir contratos e expectativas de qualidade. Padrão de Contrato de Dados Abertos (ODCS)
-
Mais tempo dedicado à parceria com as áreas de produto, segurança e finanças
Essa é a mudança sutil: a engenharia de dados deixa de ser sobre "construir pipelines" e passa a ser sobre "construir um sistema de produtos de dados confiável"
E, numa reviravolta inesperada, isso se torna ainda mais valioso, e não menos.
Além disso — e vou dizer isso mesmo que soe dramático — a IA aumenta o número de pessoas que podem produzir artefatos de dados , o que aumenta a necessidade de alguém para manter tudo organizado. Mais produção significa mais potencial para confusão. GitHub Copilot
É como dar uma furadeira para todo mundo. Ótimo! Agora alguém precisa fazer cumprir a regra de "por favor, não fure o cano de água" 🪠
O novo conjunto de habilidades que continua valioso (mesmo com a IA em todos os lugares) 🧠⚙️
Se você deseja uma lista de verificação prática e "à prova de futuro", ela se parece com isto:
Mentalidade de projeto de sistemas
-
Modelagem de dados que sobrevive à mudança
-
Vantagens e desvantagens do processamento em lote versus processamento em fluxo contínuo
-
Pensamento em latência, custo e confiabilidade
Engenharia de qualidade de dados
-
Contratos, validações, detecção de anomalias, Padrão de Contrato de Dados Abertos (ODCS), observabilidade de dados (Dynatrace)
-
SLAs, SLOs, hábitos de resposta a incidentes
-
Análise da causa raiz com disciplina (e não com base em impressões)
Arquitetura de governança e confiança
-
Padrões de acesso
-
Auditabilidade NIST SP 800-92 (gerenciamento de logs)
-
Privacidade por design - Estrutura de Privacidade do NIST
-
Gestão do ciclo de vida dos dados: orientações da UE sobre retenção de dados.
Pensamento de plataforma
-
Modelos reutilizáveis, caminhos dourados
-
Padrões padronizados para ingestão, transformações e do Fivetran dbt.
-
Ferramentas de autosserviço que não derretem
Comunicação (sim, de verdade)
-
Escrever documentos claros
-
Alinhando definições
-
Dizer “não” educadamente, mas com firmeza
-
Explicando as vantagens e desvantagens sem parecer um robô 🤖
Se você conseguir fazer isso, a pergunta "A IA substituirá os Engenheiros de Dados?" se torna menos ameaçadora. A IA se torna seu exoesqueleto, não seu substituto.
Cenários realistas onde algumas funções de engenharia de dados diminuem 📉
Ok, vamos à realidade rapidinho, porque nem tudo são flores e emojis 🎉
Algumas funções são mais visíveis:
-
Funções de ingestão pura, onde tudo utiliza conectores padrão Fivetran.
-
Equipes que executam principalmente fluxos de trabalho de relatórios repetitivos com pouca nuance de domínio
-
Organizações onde a engenharia de dados é tratada como "macacos do SQL" (duro, mas verdade)
-
Cargos com pouca responsabilidade, onde o trabalho se resume a preencher formulários e copiar e colar
A inteligência artificial, aliada a ferramentas gerenciadas, pode reduzir essas necessidades.
Mas mesmo nesses casos, a substituição geralmente se parece com:
-
Menos pessoas realizando o mesmo trabalho repetitivo
-
Maior ênfase na propriedade e confiabilidade da plataforma
-
Uma mudança na direção de que “uma pessoa pode dar suporte a mais oleodutos”
Sim, os padrões de contratação podem mudar. As funções evoluem. Os títulos mudam. Essa parte é real.
Ainda assim, a versão do cargo com alto grau de propriedade e alta confiança permanece.
Resumo final 🧾✅
Será que a IA substituirá os Engenheiros de Dados? Não da forma simples e definitiva que as pessoas imaginam.
A IA irá:
-
automatizar tarefas repetitivas
-
Acelere a codificação, a depuração e a documentação. GitHub Copilot para SQL . Documentação do dbt.
-
reduzir o custo de produção de dutos
Mas a engenharia de dados trata fundamentalmente de:
-
responsabilidade
-
projeto de sistema
-
Confiança, qualidade e governança; Padrão de Contrato de Dados Abertos (ODCS); Estrutura de Privacidade do NIST
-
Traduzir a complexa realidade empresarial em produtos de dados confiáveis
A IA pode ajudar com isso... mas não é a "dona" disso.
Se você é um engenheiro de dados, a mudança é simples (não fácil, mas simples):
assuma a responsabilidade, priorize a qualidade, pense na plataforma e esforce-se para se comunicar. Deixe a IA lidar com as tarefas repetitivas enquanto você se concentra nas partes que realmente importam.
E sim, às vezes isso significa ser o adulto responsável na sala. Nada glamoroso. Mas silenciosamente poderoso 😄
A IA substituirá os Engenheiros de Dados?
Ela substituirá algumas tarefas, reorganizará a hierarquia e tornará os melhores engenheiros de dados ainda mais valiosos. Essa é a verdadeira questão.
Perguntas frequentes
Será que a IA substituirá completamente os engenheiros de dados?
Na maioria das organizações, é mais provável que a IA assuma tarefas específicas do que elimine completamente a função. Ela pode acelerar a elaboração de SQL, a estruturação de pipelines, as primeiras versões da documentação e a criação de testes básicos. Mas a engenharia de dados também envolve responsabilidade e prestação de contas, além do trabalho pouco glamoroso de fazer com que a complexa realidade dos negócios se comporte como um sistema confiável. Essas partes ainda precisam de humanos para decidir o que é "certo" e assumir a responsabilidade quando algo dá errado.
Que partes da engenharia de dados a IA já está automatizando?
A IA tem melhor desempenho em tarefas repetitivas: elaborar e refatorar SQL, gerar esqueletos de modelos dbt, explicar erros comuns e produzir esboços de documentação. Ela também pode criar testes, como verificações de nulos ou unicidade, e gerar código de "cola" para ferramentas de orquestração. A vantagem é o impulso inicial — você começa mais perto de uma solução funcional —, mas ainda precisa validar a correção e garantir que ela se adapte ao seu ambiente.
Se a IA consegue escrever SQL e pipelines, o que resta para os engenheiros de dados?
Muita coisa: definir contratos de dados, lidar com desvios de esquema e garantir que os pipelines sejam idempotentes, observáveis e recuperáveis. Os engenheiros de dados dedicam tempo a investigar mudanças nas métricas, criar mecanismos de proteção para usuários subsequentes e gerenciar o equilíbrio entre custo e confiabilidade. O trabalho geralmente se resume a construir confiança e manter a plataforma de dados "silenciosa", ou seja, estável o suficiente para que ninguém precise se preocupar com ela no dia a dia.
Como a IA muda o trabalho diário de um engenheiro de dados?
Normalmente, isso elimina o código repetitivo e o tempo gasto em pesquisas, permitindo que você dedique menos tempo à digitação e mais tempo à revisão, validação e design. Essa mudança direciona o papel para a definição de expectativas, padrões de qualidade e modelos reutilizáveis, em vez de codificar tudo manualmente. Na prática, você provavelmente trabalhará mais em parceria com as equipes de produto, segurança e finanças, pois o resultado técnico se torna mais fácil de criar, mas mais difícil de gerenciar.
Por que a IA tem dificuldades com definições de negócios ambíguas como "usuário ativo"?
Porque a lógica de negócios não é estática nem precisa — ela muda no meio do projeto e varia de acordo com as partes interessadas. A IA pode elaborar uma interpretação, mas não pode tomar a decisão final quando as definições evoluem ou surgem conflitos. A engenharia de dados frequentemente exige negociação, documentação de premissas e a transformação de requisitos imprecisos em contratos sólidos. Esse trabalho de "alinhamento humano" é um dos principais motivos pelos quais a função não desaparece, mesmo com a melhoria das ferramentas.
Será que a IA consegue lidar com segurança com a governança de dados, a privacidade e a conformidade?
A IA pode ajudar a elaborar políticas ou sugerir abordagens, mas a implementação segura ainda exige engenharia de verdade e supervisão cuidadosa. A governança envolve controles de acesso, tratamento de informações pessoais identificáveis (PII), regras de retenção, trilhas de auditoria e, às vezes, restrições de residência. Essas são áreas de alto risco em que "quase certo" não é aceitável. Os humanos devem elaborar as regras, verificar sua aplicação e permanecer responsáveis pelos resultados de conformidade.
Quais habilidades continuam sendo valiosas para engenheiros de dados à medida que a IA melhora?
Habilidades que tornam os sistemas resilientes: pensamento de design de sistemas, engenharia de qualidade de dados e padronização orientada a plataformas. Contratos, observabilidade, práticas de resposta a incidentes e análise disciplinada da causa raiz tornam-se ainda mais importantes quando mais pessoas conseguem gerar artefatos de dados rapidamente. A comunicação também se torna um diferencial — alinhar definições, escrever documentação clara e explicar as compensações sem drama é fundamental para manter a confiabilidade dos dados.
Quais funções de engenharia de dados estão mais ameaçadas pela IA e pelas ferramentas gerenciadas?
Funções focadas estritamente em ingestão repetitiva ou em fluxos de trabalho de geração de relatórios padrão ficam mais vulneráveis, especialmente quando conectores ELT gerenciados abrangem a maioria das fontes. Tarefas com baixa responsabilidade e baseadas em tickets podem diminuir, pois a IA e a abstração reduzem o esforço por fluxo de trabalho. Mas isso geralmente se traduz em menos pessoas realizando tarefas repetitivas, não necessariamente na ausência de engenheiros de dados. Funções com alta responsabilidade, centradas em confiabilidade, qualidade e confiança, permanecem estáveis.
Como devo usar ferramentas como o GitHub Copilot ou o dbt com IA sem causar caos?
Considere os resultados da IA como um rascunho, não como uma decisão. Use-os para gerar esqueletos de consultas, melhorar a legibilidade ou estruturar testes e documentação do dbt, validando-os em seguida com dados reais e casos extremos. Combine-os com convenções sólidas: contratos, padrões de nomenclatura, verificações de observabilidade e práticas de revisão. O objetivo é uma entrega mais rápida sem sacrificar a confiabilidade, o controle de custos ou a governança.
Referências
-
Comissão Europeia - Proteção de dados explicada: princípios do RGPD - commission.europa.eu
-
Escritório do Comissário de Informação (ICO) - Limitação de armazenamento - ico.org.uk
-
Comissão Europeia - Por quanto tempo os dados podem ser mantidos e é necessário atualizá-los? - commission.europa.eu
-
Instituto Nacional de Padrões e Tecnologia (NIST) - Estrutura de Privacidade - nist.gov
-
Centro de Recursos de Segurança de Computadores do NIST (CSRC) - SP 800-92: Guia para Gerenciamento de Logs de Segurança de Computadores - csrc.nist.gov
-
Centro para Segurança na Internet (CIS) - Gerenciamento de Logs de Auditoria (Controles CIS) - cisecurity.org
-
Documentação do Snowflake - Políticas de acesso a linhas - docs.snowflake.com
-
Documentação do Google Cloud - Segurança em nível de linha do BigQuery - docs.cloud.google.com
-
BITOL - Padrão de Contrato de Dados Abertos (ODCS) v3.1.0 - bitol-io.github.io
-
BITOL (GitHub) - Padrão de Contrato de Dados Abertos - github.com
-
Apache Airflow - Documentação (versão estável) - airflow.apache.org
-
Apache Airflow - DAGs (conceitos básicos) - airflow.apache.org
-
Documentação do dbt Labs - O que é dbt? - docs.getdbt.com
-
Documentação do dbt Labs - Sobre os modelos dbt - docs.getdbt.com
-
Documentação do dbt Labs - Documentação - docs.getdbt.com
-
Documentação do dbt Labs - Testes de dados - docs.getdbt.com
-
Documentação do dbt Labs - Camada Semântica do dbt - docs.getdbt.com
-
Documentação do Fivetran - Primeiros passos - fivetran.com
-
Fivetran - Conectores - fivetran.com
-
Documentação da AWS - Guia do desenvolvedor do AWS Lambda - docs.aws.amazon.com
-
GitHub - GitHub Copilot - github.com
-
Documentação do GitHub - Obtendo sugestões de código em sua IDE com o GitHub Copilot - docs.github.com
-
Microsoft Learn - GitHub Copilot para SQL (extensão do VS Code) - learn.microsoft.com
-
Documentação do Dynatrace - Observabilidade de dados - docs.dynatrace.com
-
DataGalaxy - O que é observabilidade de dados? - datagalaxy.com
-
Documentação do Great Expectations - Visão geral do Expectations - docs.greatexpectations.io