Como exportar dados de Warehouse para Lakehouse em Microsoft Fabric: passo a passo
Este guia mostra como exportar dados de um Warehouse para um Lakehouse em Microsoft Fabric de forma controlada, mantendo o esquema e aplicando transformações ligeiras. Esta tarefa é útil quando precisa de consolidar dados num Lakehouse para análises em Power BI, reduzir custos de armazenamento do Warehouse ou preparar dados para pipelines ETL posteriores. O objetivo é ter um processo fiável que preserve tipos, permissões e permita validação simples após a cópia.
Pré-requisitos
- Conta com acesso a um workspace no Microsoft Fabric e permissões de leitura no Warehouse e escrita no Lakehouse. Idealmente a identidade usada tem permissões RBAC mínimas para segurança.
- Um Warehouse com uma tabela de exemplo disponível (por exemplo, 1M linhas, ~500 MB) para testar antes de cargas maiores.
- Um Lakehouse criado com espaço suficiente e permissões de escrita; verifique quotas do espaço OneLake (por exemplo, 100 GB livre para testes) e o caminho abfss onde os ficheiros Parquet serão guardados.
- Noções básicas de SQL/T-SQL e acesso ao SQL Editor do Warehouse ou Notebooks T-SQL para executar queries e scripts de carga.
Passo 1: Planear o mapeamento de esquema
Antes de copiar os dados, compare o esquema da tabela no Warehouse com a tabela alvo no Lakehouse. Faça um pequeno inventário: nomes de colunas, tipos (BIGINT vs INT, VARCHAR vs NVARCHAR), nullability e tipos de dados com precisão decimal. Decida se vai manter o mesmo nome de colunas, alterar tipos para compatibilidade (por exemplo, converter FLOAT para DECIMAL(18,4)), ou acrescentar colunas de auditoria como load_timestamp, source_system ou batch_id. Para tabelas grandes, pense em particionar por data (por exemplo, partition_date) para ficheiros Parquet menores e consultas mais rápidas.
Passo 2: Criar a tabela alvo no Lakehouse
Crie a tabela no Lakehouse com o esquema desejado. No Microsoft Fabric, use o SQL Editor do Warehouse (ou um Notebook T-SQL) apontando para o OneLake path do Lakehouse. Um método simples é criar uma tabela externa apontando para um diretório do Lakehouse. Se prevê cargas incrementais, planeie particionamento por uma coluna como load_date para reduzir ficheiros e melhorar leitura em Power BI.
-- Exemplo T-SQL para criar uma tabela externa parquet no Lakehouse
CREATE EXTERNAL TABLE lakehouse_schema.target_table (
id BIGINT,
name VARCHAR(200),
amount DECIMAL(18,2),
load_timestamp DATETIME2
)
WITH (
LOCATION = 'abfss://@.dfs.core.windows.net/lakehouse/path/target_table/',
FILE_FORMAT = (TYPE = PARQUET)
);
Passo 3: Extrair e transformar dados do Warehouse
Execute uma query no Warehouse para seleccionar e transformar os dados. Aqui pode filtrar (por exemplo, is_active = 1), agregar ou converter tipos para compatibilidade com o Lakehouse. Adicione uma coluna de auditoria se necessário. Para volumes médios (100k–1M linhas) a transformação em memória é rápida; para dezenas de milhões considere transformar por lotes (batch) para reduzir uso de memória. Exemplos de transformações práticas: normalizar texto com UPPER/LOWER, arredondar decimais e converter fusos horários para UTC.
-- Exemplo de SELECT transformador no Warehouse
SELECT
id,
UPPER(name) AS name,
CAST(amount AS DECIMAL(18,2)) AS amount,
SYSUTCDATETIME() AS load_timestamp
FROM schema.source_table
WHERE is_active = 1;
Passo 4: Exportar os dados para o Lakehouse
Existem duas formas comuns: (A) copiar diretamente com INSERT INTO ... SELECT apontando para a tabela externa do Lakehouse; (B) exportar para ficheiro Parquet e escrever no caminho do Lakehouse usando utilitários. O método A é direto e simples para cargas únicas ou recorrentes simples. Para cargas incrementais, considere INSERT INTO por partição ou usar INSERT OVERWRITE em conjuntos particionados. Para grandes volumes, é recomendável testar com lotes de 100k–500k linhas e verificar o tamanho médio dos ficheiros Parquet (idealmente 64–256 MB para bom equilíbrio entre I/O e paralelismo).
-- Método A: Inserir diretamente na tabela externa do Lakehouse
INSERT INTO lakehouse_schema.target_table
SELECT
id,
UPPER(name) AS name,
CAST(amount AS DECIMAL(18,2)) AS amount,
SYSUTCDATETIME() AS load_timestamp
FROM schema.source_table
WHERE is_active = 1;
Passo 5: Validar escrita e gerir permissões
Após a inserção, verifique se os ficheiros Parquet foram escritos no caminho do Lakehouse e ajuste permissões se necessário. Garanta que as identidades (managed identity, service principal ou utilizador) têm acesso ao OneLake/Storage com as permissões necessárias (Write/List). Valide integridade com contagens: SELECT COUNT(*) na tabela fonte vs tabela do Lakehouse e, se necessário, amostras com CHECKSUM das colunas críticas para detectar perdas ou truncamentos. Para cargas de produção, registe a identidade usada e crie alertas para erros de permissão ou quotas.
-- Consulta de validação simples na tabela do Lakehouse
SELECT TOP 10 * FROM lakehouse_schema.target_table ORDER BY load_timestamp DESC;
Verificar o resultado
Confirme que: (1) o número de linhas na tabela alvo corresponde ao esperado (por exemplo, 1.000.000 linhas); (2) os tipos e formatos estão corretos (decimais, datas em UTC); (3) os ficheiros Parquet aparecem no diretório do Lakehouse com tamanhos razoáveis; (4) aplicações como Power BI conseguem ler a tabela e responder a queries em tempo aceitável. Execute contagens por partição e amostras de valores críticos. Uma verificação prática: SELECT COUNT(*), MIN(load_timestamp), MAX(load_timestamp) para validar janela temporal.
Conclusão
Agora já tem um processo simples e replicável para exportar dados de um Warehouse para um Lakehouse em Microsoft Fabric mantendo esquema e aplicando transformações ligeiras. Próximos passos: automatizar com Pipelines no Data Factory do Fabric, criar snapshots com Time Travel ou implementar cargas incrementais com watermarking. Dica prática: registe sempre a identidade usada para escrita, defina limites de lote para grandes cargas e verifique quotas antes de cargas massivas para evitar interrupções.