O Domínio 4 do conteúdo oficial do DP-900 inclui "Descrever considerações para ingestão e processamento de dados". A análise começa reunindo os dados, então a diferença entre ETL e ELT, os pipelines e componentes do Azure Data Factory e as formas de levar dados ao Microsoft Fabric aparecem com frequência. São especialmente comuns as perguntas que pedem para diferenciar componentes com nomes parecidos, como serviços vinculados, conjuntos de dados e runtimes de integração.
Este post é um complemento de Serviços de análise em larga escala da nossa série de estudos do DP-900. Partindo da introdução a ETL, ELT e Data Factory feita lá, ele mostra como escolher entre as duas abordagens, o que faz cada componente do Data Factory, como o Fabric e o Databricks fazem a ingestão de dados e o HDInsight, que ainda aparece com frequência em materiais antigos e em questões de prática.
---
O que é ingestão de dados? ETL e ELT revisitados
Imagine um centro de distribuição de encomendas. Os pacotes são coletados no país inteiro (extração), separados por tamanho e região (transformação) e colocados nas prateleiras do armazém (carga). Se a separação acontece antes de os pacotes entrarem no armazém, é ETL; se tudo entra primeiro no armazém e é separado lá dentro, é ELT.
| Aspecto | ETL (extrair → transformar → carregar) | ELT (extrair → carregar → transformar) | |------|------|------| | Onde a transformação acontece | Antes da carga, em um mecanismo de processamento separado | Depois da carga, dentro do armazenamento analítico | | Dados brutos | Muitas vezes só o resultado transformado é armazenado | Os dados brutos são mantidos como estão e transformados quando necessário | | Armazenamento indicado | Um data warehouse relacional com esquema fixo | Armazenamentos com bastante poder de computação, como data lakes e lakehouses | | Vantagem | Só entram dados limpos | Rápido com grandes volumes; os dados podem ser transformados de outro jeito depois | | Exemplo | Limpar os dados com fluxos de dados do Data Factory e carregá-los no SQL Database | Copiar arquivos brutos para um lakehouse e depois transformá-los com Spark ou SQL |
A transformação normalmente roda em paralelo em sistemas distribuídos formados por vários nós. O lugar onde ficam os resultados intermediários durante a transformação se chama área de preparação (staging ou tabela de staging) e permite validar e limpar os dados sem sobrecarregar o sistema de origem. A ingestão abrange tanto o processamento em lote de dados estáticos reunidos quanto o processamento em streaming de eventos conforme chegam.
Dica de prova: "Copiar os dados primeiro para o armazenamento analítico e depois transformá-los com a computação do armazenamento" → ELT. "Limpar os dados e ajustar o formato antes de carregar" → ETL.
---
Os componentes do Azure Data Factory
O Azure Data Factory é um serviço de integração de dados (ETL) na nuvem para criar fluxos de trabalho de movimentação e transformação de dados e executá-los em um agendamento. Os nomes dos componentes são parecidos o bastante para confundir na prova, então use o diagrama e a tabela para separar as funções.
!Componentes de um pipeline do Azure Data Factory
| Componente | Função | Analogia | |------|------|------| | Pipeline | Agrupamento lógico de atividades que juntas realizam uma unidade de trabalho | Uma ficha de receita | | Atividade | Uma etapa de processamento dentro de um pipeline | Cada passo da receita | | Conjunto de dados (dataset) | Estrutura e local dos dados que uma atividade usa como entrada ou saída | A lista de ingredientes | | Serviço vinculado | Informações de conexão com um armazenamento de dados ou serviço de computação (parecido com uma cadeia de conexão) | O endereço e o crachá do mercado | | Runtime de integração (integration runtime) | O ambiente de computação onde as atividades rodam; a ponte entre atividades e serviços vinculados | A cozinha onde se cozinha | | Gatilho (trigger) | A condição que inicia uma execução do pipeline | A hora em que você começa a cozinhar | | Fluxo de dados de mapeamento | Lógica de transformação desenhada visualmente sem código, executada automaticamente em clusters Spark | Uma receita ilustrada |
Um serviço vinculado responde a "onde e como eu me conecto?", enquanto um conjunto de dados responde a "quais dados lá dentro?". Por exemplo, a cadeia de conexão de uma conta de armazenamento fica em um serviço vinculado, e um contêiner e uma pasta específicos dessa conta ficam em um conjunto de dados.
Três tipos de atividades
Atividades de movimentação de dados: a atividade Copy copia dados entre armazenamentos locais e na nuvem. Atividades de transformação de dados: processam dados com fluxos de dados de mapeamento, notebooks do Databricks, procedimentos armazenados, consultas Hive do HDInsight e mais. Atividades de controle: controlam o fluxo encadeando etapas em sequência, ramificando com If Condition, repetindo com ForEach ou executando outro pipeline.
Runtimes de integração e gatilhos
| Runtime de integração | Uso | |------|------| | Azure | Mover dados entre armazenamentos na nuvem e executar fluxos de dados | | Auto-hospedado | Acessar dados locais ou dentro de uma rede privada | | Azure-SSIS | Executar como estão pacotes SSIS (SQL Server Integration Services) existentes |
| Gatilho | Quando o pipeline roda | |------|------| | Agendamento | Em horários e intervalos definidos (por exemplo, todo dia às 2h) | | Janela em cascata (tumbling window) | Intervalos fixos sem sobreposição; janelas passadas podem ser reexecutadas | | Evento de armazenamento | Quando um blob é criado ou excluído | | Evento personalizado | Quando chega um evento personalizado pelo Event Grid |
Você também pode executar um pipeline manualmente (sob demanda), sem gatilho. Os pipelines podem ser implantados via CI/CD com Azure DevOps ou GitHub, e seus sucessos e falhas são monitorados com o Azure Monitor.
Dica de prova: "Copiar dados de um SQL Server local com o Data Factory" → runtime de integração auto-hospedado. "O componente que guarda as informações de conexão" → serviço vinculado. "Executar um pipeline sempre que um arquivo for enviado" → gatilho de evento de armazenamento.
---
Formas de levar dados ao Microsoft Fabric
O Fabric oferece várias formas de levar dados ao OneLake. Se os dados são de fato copiados, e se continuam sincronizados, é o que define qual usar.
| Método | O que faz | Copia dados | Escolha quando | |------|------|------|------| | Pipelines do Fabric Data Factory | Orquestram movimentação e transformação em várias etapas, em sequência ou em paralelo | Sim | ETL ou ELT em lote típico | | Dataflow Gen2 | Transformação sem código criada com Power Query | Sim | Transformações reutilizáveis sem código | | Atalhos do OneLake | Referenciam ADLS Gen2, Amazon S3, Google Cloud Storage e outros sem movê-los | Não | Os dados precisam ficar no local original | | Espelhamento (mirroring) | Replica de forma contínua e quase em tempo real Azure SQL Database, Cosmos DB, Snowflake e outros | Sim (automático) | Bancos operacionais prontos para análise sem pipelines | | Eventstream | Ingere em tempo real eventos do Event Hubs, Kafka e IoT Hub | Sim | Dados de streaming | | Notebooks | Ingestão e transformação diretas com código PySpark, Python ou SQL | Sim | Não há conector ou a lógica é complexa |
O Fabric Data Factory é a próxima geração do Azure Data Factory e usa o mesmo modelo de pipelines, então seu conhecimento continua valendo. A diferença é que, onde o Azure Data Factory usa serviços vinculados, o Fabric usa conexões. Se o destino é um serviço fora do Fabric, como o Azure SQL Database, ou você trabalha em um ambiente híbrido sem Fabric, use o serviço independente Azure Data Factory.
Dica de prova: "Consultar dados do Amazon S3 a partir de um lakehouse do Fabric sem copiá-los" → atalho do OneLake. "Continuar replicando um Azure SQL Database de produção no OneLake sem pipelines" → espelhamento.
---
Ingestão e processamento no Azure Databricks e no HDInsight
Azure Databricks
No Azure Databricks, os pipelines do Lakeflow permitem declarar o que as tabelas de saída devem conter, e o Databricks cuida para você da ordem de execução, das dependências e do processamento incremental. Eles combinam com a ingestão de produção em lote e em streaming. Para ingestões exploratórias ou pontuais, notebooks de PySpark ou SQL leem de APIs REST, fontes JDBC e armazenamento em nuvem e gravam em tabelas Delta Lake.
Azure HDInsight
O HDInsight executa no Azure, como clusters gerenciados, frameworks de big data de código aberto como Apache Spark, Hive, LLAP, Kafka, HBase e Hadoop. Ele não aparece no conteúdo atual da prova, mas materiais de estudo antigos e questões o trazem com frequência em cenários como "levar para a nuvem, como está, um ecossistema Hadoop existente".
| Serviço | Características | Escolha quando | |------|------|------| | Azure Data Factory | Pipelines sem código, muitos conectores integrados, conectividade híbrida | Integração de dados fora do Fabric, fontes locais | | Fabric Data Factory | Pipelines e Dataflow Gen2 dentro do Fabric | Levar dados ao OneLake para análise no Fabric | | Azure Databricks | Baseado em Spark, pipelines do Lakeflow e notebooks | Processamento em larga escala centrado em código, Delta Lake | | Azure HDInsight | Clusters gerenciados para frameworks de código aberto | Levar como estão trabalhos existentes de Hadoop, Hive ou Kafka |
Dica de prova: "Executar trabalhos existentes de Hadoop e Hive em clusters gerenciados do Azure com mudanças mínimas" → HDInsight. "Copiar e transformar dados de muitas fontes em um agendamento, sem código" → Data Factory.
---
Pratique com cenários
Decida sua resposta primeiro e depois confira as colunas da direita.
| Situação | Resposta | Por quê | |------|------|------| | Colocar primeiro todos os logs brutos no lake e transformá-los com Spark quando necessário | ELT | Transformaç