Data Lake e Lakehouse não são sinônimos. Data Lake designa uma arquitetura de armazenamento capaz de conservar dados de formatos diversos, incluindo arquivos e registros próximos d
Confira!
Data Lake e Lakehouse não são sinônimos. Data Lake designa uma arquitetura de armazenamento capaz de conservar dados de formatos diversos, incluindo arquivos e registros próximos da origem. Lakehouse acrescenta organização tabular, mecanismos de transação, versões e capacidades de consulta e governança para workloads analíticos sobre esse armazenamento, dependendo das tecnologias implementadas. A decisão não deve ser tomada apenas pela presença de arquivos Parquet ou pela marca de uma plataforma: é necessário examinar snapshots, evolução de schema, concorrência, processamento, catálogo, segurança e custo de manutenção. Este artigo compara o Lakehouse com um Data Lake convencional; a comparação entre Data Lake e Data Warehouse já possui um conteúdo próprio.
O que muda entre Data Lake e Lakehouse
Data Lake como ambiente de armazenamento
Data Lake é usado para manter dados heterogêneos, que podem incluir tabelas, logs, eventos, telemetria e arquivos autorizados. O armazenamento por objetos e a separação entre dados brutos e transformados permitem conservar informação de origem para auditoria ou reprocessamento. Entretanto, não há garantia de que um arquivo em uma pasta seja uma tabela transacional consistente. Metadados, políticas de acesso, catálogo, retenção e contratos entre produtores e consumidores continuam necessários. Um ambiente que apenas recebe arquivos sem ownership e convenções claras pode se tornar difícil de explorar e governar.
A forma de ingestão determina a utilidade do histórico. Exportações de ERP podem conter registros alterados depois da primeira carga; sensores podem produzir mensagens repetidas e fora de ordem. Guardar arquivos sem registrar período, versão e estado de processamento não assegura capacidade de reconstruir métricas. O Data Lake deve documentar camadas lógicas, formatos, chaves, fontes, horários e políticas de retenção. Em casos que exigem leitura analítica confiável por vários consumidores, pode ser necessário um formato de tabela que governe snapshots e atualizações; essa é uma das razões para considerar uma arquitetura Lakehouse.
Lakehouse e a camada de tabelas
Uma arquitetura Lakehouse combina armazenamento de dados com formatos ou serviços que administram tabelas analíticas, incluindo metadados, commits e versões consistentes quando suportados. Projetos como Delta Lake e Apache Iceberg implementam mecanismos específicos para acompanhar arquivos de dados como tabelas, permitindo operações de atualização, consulta histórica e evolução de schema conforme suas especificações. O formato de tabela não resolve sozinho a governança organizacional, a classificação da informação nem todas as regras de negócio. Ele fornece capacidades técnicas sobre as quais catálogos, permissões e processos podem ser construídos.
Um diretório de arquivos Parquet pode ser útil para consultas, mas alterações concorrentes podem exigir coordenação adicional. Formatos de tabela adicionam uma representação do estado confirmado e mecanismos para controlar alterações, dependendo da implementação. A arquitetura deve verificar isolamento, consistência, integração com motores de consulta, retenção de snapshots e custos de manutenção de metadados. Não se deve interpretar Time Travel como retenção infinita: políticas de expiração e limpeza de arquivos podem limitar versões disponíveis. A configuração efetiva precisa ser documentada e testada.
Não confundir Lakehouse com qualquer Data Warehouse
Data Warehouse é uma solução analítica organizada para consulta e medidas consistentes; Lakehouse descreve uma abordagem de arquitetura e armazenamento que pode executar trabalhos semelhantes e também acomodar dados de outros formatos. Um Lakehouse pode suportar SQL, modelos dimensionais e relatórios, mas a qualidade e o desempenho dependem do motor, das transformações, do formato e da governança. É inadequado prometer substituição automática de um Data Warehouse existente apenas porque a nova plataforma anuncia capacidade transacional ou processamento distribuído.
O comparativo deve observar workloads reais. Um ambiente destinado somente a indicadores estruturados estáveis pode ser atendido por um Warehouse existente. Um conjunto que recebe eventos volumosos, documentos e tabelas para diversos tipos de análise pode justificar uma abordagem Lakehouse. A arquitetura híbrida também é possível. O custo de duplicar dados, o esforço de operar catálogos e a dependência de ferramentas devem ser tratados como parte da decisão, não apenas o preço por gigabyte de armazenamento.
O aproveitamento de arquivos e eventos num Lakehouse depende de contratos de origem que explicitem versões, chaves, atualização e tratamento de correções. A escolha do formato tabular não substitui a engenharia necessária para receber dados coerentes.
Delta Lake e Apache Iceberg: o que os formatos oferecem
Snapshots e isolamento de transações
Apache Iceberg representa o estado de uma tabela por metadados e snapshots que apontam para arquivos ativos. Sua especificação descreve commits que substituem atomicamente uma referência de metadados e mecanismos de concorrência otimista. Delta Lake utiliza log de transações e oferece garantias ACID conforme a implementação. A existência de snapshots facilita leituras consistentes, mas não significa que todo motor, conector ou combinação de escrita implemente as mesmas operações e garantias. É necessário validar compatibilidade de versões e o comportamento efetivo da stack selecionada.
Um teste típico executa duas escritas concorrentes enquanto um consumidor consulta a mesma tabela. O resultado esperado deve ser especificado: o leitor não pode receber um estado parcialmente confirmado e o escritor em conflito deve falhar ou ser tratado segundo regras de concorrência. A verificação deve incluir atualização e exclusão, não apenas append. Também deve identificar qual versão da tabela foi utilizada por um relatório. Um snapshot consistente não garante que os dados representam o fechamento do negócio, mas permite controlar tecnicamente o estado consultado.
Schema evolution e mudanças compatíveis
A evolução de schema inclui adicionar, renomear, remover ou alterar tipos de colunas, além de lidar com campos aninhados. A especificação Iceberg utiliza identificadores de coluna para proteger relações entre nomes e dados durante mudanças, enquanto Delta Lake oferece mecanismos próprios de enforcement e evolução de schema. As operações disponíveis e os requisitos variam conforme versão e motor. O projeto deve testar mudança de coluna, compatibilidade de consumidores e impacto das regras de negócio, em vez de presumir que qualquer alteração passa a ser segura pelo uso de formato aberto.
Uma alteração de schema também pode preservar estrutura e modificar significado. Um campo status pode passar a representar outra etapa do processo sem mudar nome ou tipo. Nenhum formato de tabela identifica automaticamente esse desvio sem contrato semântico e governança. É preciso definir responsável, versão, janela de migração e testes de consumidores. Alterações em campos essenciais exigem tratamento diferente de novos atributos opcionais. Catálogo e Data Lineage ajudam a identificar quais dashboards e APIs dependem de determinada tabela antes que a mudança seja implantada.
Time Travel, retenção e evolução de partições
Time Travel permite consultar snapshots históricos quando disponíveis, ajudando auditoria, reprocessamento e investigação. Porém, os dados e metadados associados podem ser removidos conforme política de retenção e manutenção, de modo que uma consulta histórica só é possível se a versão necessária foi preservada. A organização precisa definir quais decisões exigem reconstrução e por quanto tempo. Não se deve confundir versionamento de arquivos ou tabela com arquivo documental aprovado de uma decisão, que pode exigir evidências próprias de entrega e assinatura.
A evolução de particionamento também pode reduzir custos sem obrigar consumidores a conhecer os caminhos físicos dos arquivos, conforme capacidades da plataforma. Entretanto, o planejamento precisa considerar distribuição de dados, volume de arquivos pequenos, frequência de compactação e padrão de consultas. Uma tabela com muitos arquivos diminutos pode exigir operações de manutenção e consumir recursos desnecessários. A engenharia deve medir latência, custo e efeito da reorganização antes de aplicar alterações em produção. A otimização precisa preservar snapshots e resultados esperados.
Camadas, pipelines e governança
Bronze, Silver e Gold como organização lógica
Algumas arquiteturas Lakehouse utilizam camadas Bronze, Silver e Gold. Bronze costuma conservar registros próximos da origem, Silver introduz limpeza e padronização e Gold disponibiliza conjuntos prontos para consumo. Essa organização é uma convenção útil, não um requisito universal. O desenho deve declarar o que cada camada garante e como uma falha impede publicação. Uma tabela Gold não é automaticamente confiável: precisa de definição de medidas, Quality Gates, Data Owner e reconciliação com referências apropriadas.
Os pipelines devem manter contratos, versões e estados de processamento. Se uma origem envia eventos duplicados, a camada de tratamento precisa demonstrar como identifica repetição. Se um campo financeiro muda retroativamente, a transformação deve reconhecer e republicar períodos afetados conforme política. O Lakehouse pode suportar processamento batch e streaming, mas a escolha e as garantias dependem dos motores e conectores. Uma ingestão de baixa latência pode ampliar a complexidade sem melhorar decisões quando o processo de origem fecha dados apenas diariamente.
Catálogo, metadados e controle de acesso
Um catálogo permite descobrir tabelas e relacionar propriedade, classificação, schema, origem e condições de consumo. A governança precisa distinguir autorização para consultar metadados de permissão para acessar registros. Um produto de dados pode combinar informações de clientes, transações e manutenção, criando risco de exposição que não existia em uma origem isolada. O Lakehouse precisa de políticas de acesso, minimização, retenção e segregação entre ambientes, incluindo arquivos temporários, resultados exportados e backups.
Formato aberto não equivale a acesso livre ou ausência de dependência de fornecedor. Um arquivo pode estar armazenado em padrão suportado, mas rotinas de catálogo, políticas de segurança, jobs e recursos de consulta dependerem de serviços específicos. A avaliação deve incluir capacidade de exportar tabelas e metadados, além de documentação que permita reconstruir transformações. Em contextos com dados pessoais, a finalidade e as responsabilidades precisam atender à legislação aplicável, sem afirmar que uma arquitetura Lakehouse garante conformidade automaticamente.
Qualidade, observabilidade e recuperação
A observabilidade acompanha quantidade de registros, atraso, schema, falhas de execução, qualidade de dados e saúde das tabelas. Data Lineage conecta fontes, transformações e consumidores. Um snapshot tecnicamente válido pode estar incompleto em relação à origem; por isso, a publicação precisa de reconciliação e critérios de cobertura. A equipe deve reconhecer estados normal, provisório e indisponível, informando aos consumidores quando as medidas não estão aptas para decisão. A integridade de transações não substitui a integridade do significado do KPI.
A decisão de adotar Lakehouse precisa ser sustentada por testes de concorrência, desempenho, portabilidade e custo no workload real. Uma avaliação técnica pode estabelecer critérios verificáveis antes da migração de um repositório já utilizado pela organização.
Um runbook precisa detalhar como recuperar falha de origem, execução parcial e alteração inesperada de schema. Em um teste, a operação pode interromper um Job entre escrita de arquivos e commit, depois verificar que leitores continuam acessando apenas versões confirmadas. O replay deve tratar duplicação de eventos e conservar versão de transformação. Também é necessário verificar políticas de limpeza: arquivos de versões antigas não podem ser removidos antes de cumprida a retenção exigida pelo processo. A recuperação completa inclui reconciliação e explicação de resultados, não apenas retorno da plataforma.
Comparação de custos, desempenho e interoperabilidade
Armazenamento barato não representa custo total
O custo de um Data Lake pode parecer baixo quando avaliado somente pelo volume armazenado, mas operações de leitura, transformação, movimentação de arquivos, catálogos e monitoramento também consomem recursos. Lakehouse acrescenta necessidades de manutenção de metadados, compactação, retenção de snapshots, governança e coordenação de motores. A análise de custo deve modelar cargas reais, concorrência e volume de arquivos, inclusive durante recuperação de backlog. Comparações por tabela de preços precisam declarar hipóteses e limites para não converter uma estimativa em promessa de economia.
Uma arquitetura pode optar por preservar dados brutos em armazenamento econômico e publicar subconjuntos curados para análises específicas. Isso pode reduzir repetição de processamento, mas exige controle de versões entre as camadas. A existência de mais de um formato ou motor pode aumentar compatibilidade e também aumentar complexidade. A decisão precisa considerar recursos da equipe, documentação, licenças, SLA e capacidade de substituir fornecedores. A escolha por Lakehouse deve demonstrar benefício sobre o ambiente existente, e não apenas adotar uma categoria tecnológica.
Workloads e consultas reais
Uma prova de conceito deve incluir consultas com filtros, joins, agrupamentos e acesso simultâneo, além da carga de dados. Não basta ler poucos arquivos em laboratório; é necessário simular volume representativo, alterações concorrentes e condições de pico. Métricas incluem latência de consulta, custo por execução, freshness, duração de transformação e impacto sobre outras tarefas. Uma consulta SQL que atende relatório mensal pode comportar-se de modo diferente quando usada por centenas de usuários ou por um modelo de IA em paralelo.
É relevante medir o número e o tamanho de arquivos, a política de organização das tabelas e o efeito de particionamento. Alguns motores podem consultar uma mesma tabela com recursos diferentes; compatibilidade declarada deve ser confirmada em versões específicas. Resultados de benchmark de fornecedor não substituem testes no contexto do cliente. A homologação precisa reproduzir totais e indicadores entre o ambiente anterior e o novo, identificando diferenças por semântica, atraso ou mudança de calendário. Desempenho não compensa resultado incorreto.
Migração e coexistência com Data Warehouse
Um Lakehouse pode alimentar um Data Warehouse, consumir dados deste ou substituí-lo parcialmente, dependendo do cenário. A migração deve começar por inventário de tabelas, workloads, medidas e integrações, reconhecendo dependências de relatórios e contratos. Uma fase em paralelo permite comparar outputs, latência, permissões e custos. A organização precisa definir quando uma fonte passa a ser autoritativa e como reverter a mudança caso o novo ambiente não atenda aos critérios de aceite.
Quando a migração envolve SCD tipo 2 e dimensões históricas, copiar tabelas sem preservar chaves e vigência pode alterar análises passadas. Os contratos precisam conservar a capacidade de reconstruir medidas oficiais. A portabilidade deve ser testada com leitura por motor alternativo quando esse requisito fizer parte da estratégia. Uma plataforma pode oferecer formato aberto e ainda exigir ferramentas proprietárias para administrar certas políticas; esse risco deve ser documentado. O resultado desejado é uma arquitetura sustentável, não a eliminação de componentes antes de comprovar equivalência.
| Critério | Data Lake convencional | Lakehouse com formato de tabela |
|---|---|---|
| Estado da tabela | Depende da organização e do motor | Snapshots e metadados sob contrato |
| Escritas concorrentes | Exigem mecanismos adicionais | Controle segundo formato e implementação |
| Schema e evolução | Regras frequentemente externas | Capacidades específicas de evolução |
| Consulta histórica | Requer estratégia de versionamento | Time Travel conforme retenção |
| Governança | Depende de catálogo e políticas | Também depende de catálogo e políticas |
| Custo | Armazenamento, processamento e operação | Acrescenta manutenção de tabelas e metadados |
Ensaio técnico de Lakehouse com dados corporativos
Simulação de alterações de origem
Considere um Data Lake que recebe diariamente exportações do ERP e arquivos de telemetria. Um projeto Lakehouse pretende publicar tabelas com histórico e atualização incremental. O ensaio inicial seleciona documentos fiscais com cancelamento, alteração de classificação e correção tardia. A equipe registra chaves, período e valores esperados, produz o primeiro snapshot e verifica se todos os registros elegíveis estão presentes. Depois, simula duas alterações concorrentes para testar consistência, política de conflito e tratamento de duplicações. A validação deve utilizar um motor e versão especificados.
Uma correção do ERP chega após o fechamento e exige reprocessamento. A nova versão precisa demonstrar diferenças explicáveis entre snapshots, permitindo identificar resultados anteriormente publicados. O consumidor deve acessar somente estados confirmados, com qualidade e temporalidade adequadas. O Time Travel ajuda a investigar a versão anterior, mas a política de retenção precisa assegurar que ela exista durante o período de auditoria. O aceite inclui logs, catálogo, testes de permissões e resultado da reconciliação, e não apenas o sucesso do comando de escrita.
Falha de job, arquivos pequenos e schema
Outro cenário interrompe o Job depois de gravar arquivos, mas antes de confirmar alteração na tabela. O comportamento esperado é que leitores não recebam atualização parcial e que a operação possa identificar e limpar arquivos temporários conforme regras seguras. Em seguida, uma carga com milhares de pequenos arquivos é comparada a uma organização otimizada para avaliar consulta e custo. A equipe mede consumo de processamento, tempo de compactação e impacto nos snapshots, sem pressupor melhoria igual para todos os padrões de consulta.
Quando classificações, cadastros e aprovações chegam inconsistentes às camadas analíticas, mais versões de tabela não resolvem a origem do problema. Examinar os processos e responsabilidades ajuda a definir o que deve ser corrigido antes da ampliação da plataforma.
Por fim, uma propriedade de produto é renomeada e um consumidor antigo continua ativo. O teste verifica se a evolução de schema é suportada pela versão escolhida e se o significado permanece correto. Uma mudança de nome tecnicamente segura não protege contra alteração semântica, portanto o contrato e a aprovação do Data Owner são necessários. O pacote final contém arquitetura, formato, configuração, registro de versões, testes de concorrência, qualidade, custos e procedimentos de continuidade. Sem essas evidências, a expressão Lakehouse descreve intenção arquitetural, mas não uma entrega comprovada.
Ensaio comparativo de formatos e governança de snapshots
Um ensaio de Lakehouse deve selecionar duas ou mais cargas que representem necessidades reais de escrita e leitura. O conjunto inicial pode incluir registros transacionais com alterações retroativas, uma série de telemetria com eventos duplicados e metadados de equipamento. Os responsáveis definem a versão do motor e do formato, os parâmetros de retenção, o catálogo e as credenciais usadas. O primeiro cenário escreve uma tabela e publica um snapshot confirmado; em seguida, executa consulta enquanto outra tarefa tenta aplicar atualização concorrente. A evidência precisa identificar a versão lida, o comportamento do escritor em conflito e o resultado final, sem presumir que todos os motores implementem exatamente a mesma semântica.
Depois, uma alteração de schema adiciona uma propriedade, renomeia outra e modifica uma classificação de negócio sem alterar estrutura. As duas primeiras mudanças podem ser cobertas por recursos do formato escolhido, conforme versão; a terceira requer governança de significado. O ensaio precisa demonstrar que consumidores anteriores não confundem valores após a mudança. Um contrato de dados aprovado registra versão de campo, significado e critérios de compatibilidade. A equipe deve consultar catálogos e logs para identificar quais relatórios e pipelines dependem dessa informação. A ausência de erro de leitura não comprova correção semântica e não encerra a homologação.
Uma falha é introduzida entre a gravação de arquivos e a confirmação dos metadados da tabela. O comportamento esperado é que o leitor não veja estado parcialmente confirmado, segundo as garantias da arquitetura implementada. A recuperação deve identificar arquivos não referenciados e executar limpeza segura, sem afetar snapshots ainda necessários para auditoria. Em seguida, um replay controlado verifica idempotência e compara os totais com a fonte. A prova de Time Travel precisa utilizar versão anterior ainda disponível, demonstrando que a política de expiração e retenção é suficiente para o uso acordado. Esse procedimento deve ser repetível, não apenas um comando apresentado na demonstração.
A análise econômica deve comparar manutenção de metadados, compactação, armazenamento, processamento e custo de consulta no mesmo workload. O relatório de benchmark deve incluir tamanho e número de arquivos, duração das operações, consultas concorrentes e impacto da limpeza de versões. Um motor pode apresentar desempenho superior em agregações e inferior em atualização de tabelas pequenas; a escolha deve considerar o perfil de uso do cliente. Não é adequado extrapolar economia para produção sem verificar volume, retenção e dependências. A engenharia precisa registrar alternativas e trade-offs que possam ser revisitados quando as necessidades mudarem.
Por fim, a equipe tenta ler uma amostra com consumidor alternativo quando a portabilidade fizer parte dos requisitos. O teste verifica acesso aos metadados, compatibilidade de tipos, comportamento de leitura e políticas de autorização. Uma plataforma pode utilizar formato aberto, mas conservar catálogos, automações e regras de segurança específicos do fornecedor. A decisão arquitetural deve registrar quais componentes podem ser migrados diretamente e quais exigem reconstrução. O aceite final inclui arquitetura, snapshots, regras de Quality Gate, custo observado, mecanismos de recuperação e um plano de evolução que não interrompa serviços já homologados.
Governança de versões e encerramento de ciclos de dados
Snapshots de uma tabela não substituem a política documental da empresa. Um conjunto de dados pode ser atualizado várias vezes para corrigir falhas e conter versões técnicas que não correspondem a uma revisão aprovada de relatório. A governança deve definir que snapshot foi utilizado para produzir cada indicador e se aquela versão poderá ser consultada durante o período de retenção contratado. Quando é necessário apagar dados por obrigação aplicável, a equipe precisa avaliar como a limpeza afeta o histórico de versões. O formato da tabela pode permitir operações de exclusão, mas o processo de privacidade precisa considerar arquivos antigos, backups e consumidores externos.
Um projeto Lakehouse também precisa definir como serão promovidos modelos entre desenvolvimento, homologação e produção. Uma transformação nova não deve atualizar tabelas curadas enquanto consumidores dependem da versão anterior sem um plano de migração. O ensaio pode executar comparações lado a lado com snapshots identificados, medindo alterações no resultado e no custo. Se a organização pretende utilizar múltiplos motores, a política de mudança deve especificar combinações de versões suportadas e requisitos de compatibilidade. O objetivo é preservar a liberdade de evolução sem transformar a plataforma em conjunto de formatos cuja integridade ninguém consegue comprovar.
Uma consideração adicional é a diferença entre manter snapshots tecnicamente acessíveis e assegurar uma política de preservação auditável. A equipe deve registrar o período pelo qual versões antigas permanecerão disponíveis, quais ações de manutenção podem eliminá-las e como usuários serão informados de revisões de dados. Em casos de informações sensíveis, a retenção de snapshots deve ser conciliada com necessidades de minimização, exclusão e controles de acesso sobre cópias e backups. Esses requisitos não são resolvidos somente pela escolha de Delta Lake ou Iceberg: exigem acordo entre responsáveis técnicos, proprietários de dados, segurança e processos de negócio. O aceite precisa incluir uma consulta a versão histórica, uma execução de limpeza controlada e a verificação de que indicadores oficiais continuam reproduzíveis pelo prazo acordado.
Considerações finais
A diferença relevante entre um Data Lake convencional e um Lakehouse está nas capacidades para organizar, versionar e processar tabelas analíticas sobre o armazenamento, conforme formatos, catálogos e motores selecionados. Delta Lake e Apache Iceberg oferecem mecanismos técnicos de snapshots, transações e evolução de schema, mas esses recursos não eliminam necessidade de políticas, contratos de dados e validação de indicadores. Um Lakehouse não é automaticamente mais econômico, seguro ou adequado a todo workload; a escolha exige testes com dados e consultas representativos.
Um projeto deve avaliar concorrência, Time Travel efetivamente retido, segurança, qualidade, custos, recuperação e portabilidade, além da coexistência com sistemas existentes. A homologação precisa demonstrar que versões confirmadas são consistentes e que correções tardias podem ser reconstruídas e comunicadas. O objetivo não é substituir um Data Lake ou Data Warehouse apenas pelo nome da tecnologia, mas entregar condições confiáveis de consulta e evolução com evidências técnicas.
Referências técnicas
[1] DELTA LAKE. Welcome to the Delta Lake documentation. Disponível em: https://docs.delta.io/
[2] APACHE SOFTWARE FOUNDATION. Apache Iceberg: Table Spec. Disponível em: https://iceberg.apache.org/spec/
[3] APACHE SOFTWARE FOUNDATION. Apache Iceberg: Evolution. Documentação do projeto. Disponível em: https://iceberg.apache.org/docs/latest/evolution/
[4] MICROSOFT CORPORATION. Understand star schema and the importance for Power BI. Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/power-bi/guidance/star-schema
Perguntas frequentes
É uma abordagem de armazenamento para dados de diferentes formatos, que exige catálogo, segurança, organização e política de consumo.
É uma arquitetura que acrescenta recursos de tabelas analíticas, transação e versionamento sobre armazenamento de dados, conforme a implementação.
A camada de tabelas e metadados que administra estados confirmados, alterações e consultas, além da governança necessária.
Não necessariamente; a decisão depende de workloads, modelos, segurança, desempenho e custo real.
Projeto de código aberto que adiciona transações ACID e recursos de versionamento sobre armazenamento de dados.
Formato de tabela analítica com snapshots, metadados e mecanismos de evolução e concorrência definidos em especificação.
É a capacidade de consultar versões históricas de tabela que ainda estejam disponíveis segundo a política de retenção.
Não por si só. É necessário avaliar a organização transacional, catálogo e serviços envolvidos.
Não. São uma convenção de camadas de processamento que pode ser adequada ou não ao projeto.
Não. Qualidade e significado dependem de contratos, regras, Data Owners e reconciliação com a origem.
Com testes de workload, concorrência, qualidade, permissões, histórico, custo e capacidade de recuperação.
Não integralmente; catálogos, políticas, processamento e operações ainda podem depender de serviços específicos.
