Data Lake x Data Warehouse: diferenças, custos, governança e critérios para escolher a arquitetura de dados de uma solução de Business Intelligence.
Confira!
Data Lake e Data Warehouse são arquiteturas de armazenamento e organização de dados utilizadas em soluções analíticas, mas não têm a mesma função. Um Data Lake permite conservar dados de formatos variados, inclusive arquivos, eventos e registros sem um modelo único de consumo prévio; um Data Warehouse organiza dados estruturados e modelos voltados a consultas e indicadores consistentes. A comparação deve considerar objetivos, governança, custo, desempenho, tratamento e necessidade de reprocessamento, não tratar uma abordagem como substituta universal da outra.
Em Business Intelligence, as fontes podem incluir vendas, estoque, sensores industriais, BMS, eventos do VMS, dados de vídeo e registros de manutenção. O ambiente de armazenamento é apenas uma parte da solução: integração, qualidade, catálogo, modelos de indicadores e dashboards determinam se esses registros se transformarão em informação confiável. É possível utilizar um Data Warehouse, um Data Lake ou combinação de camadas, conforme os requisitos e os produtos escolhidos.
Uma escolha correta começa pelas decisões que precisam ser tomadas. Se o objetivo é consolidar indicadores diários entre lojas, um repositório dimensional confiável pode ser mais útil que um grande acervo de dados brutos. Se há necessidade autorizada de conservar registros heterogêneos para novas transformações e auditorias, uma área de dados com governança e reprocessamento pode ser justificável. A solução precisa ser projetada conforme o cliente.
Data Lake: finalidade e características
Data Lake designa um ambiente capaz de armazenar dados de diferentes estruturas e formatos, como arquivos de sensores, documentos, registros de sistemas e eventos em grande volume. Em geral, permite preservar material em forma próxima à origem e organizar camadas posteriores de curadoria. Essa flexibilidade facilita reconstruir análises e incorporar novas fontes, mas não elimina necessidade de controle de acesso, catálogo, retenção e qualidade.
Um lago de dados sem regras de organização pode tornar-se um conjunto de arquivos cuja origem, versão e significado não são conhecidos. É necessário definir zonas lógicas, permissões, convenção de identificação, rastreabilidade, histórico e responsabilidades. A possibilidade de guardar informação não é motivo suficiente para copiá-la, sobretudo quando envolve dados pessoais e registros industriais sensíveis.
A documentação da AWS explica o papel do Data Lake na conservação de dados em diferentes estados e formas, enquanto outras plataformas implementam padrões semelhantes com recursos próprios. Não se deve presumir que o mesmo desenho físico, desempenho ou custo se aplique a qualquer provedor. A arquitetura precisa ser verificada diante das exigências do projeto.
Data Warehouse: finalidade e características
Data Warehouse é um ambiente orientado a consultas analíticas, com dados preparados e organizados para perguntas de negócio. Fatos, dimensões e regras semânticas permitem que diferentes áreas calculem indicadores de forma coerente. A arquitetura pode receber dados por ETL ou ELT, conforme tecnologia e desenho, e preservar histórico que facilite análises comparativas.
O diferencial não é apenas armazenar linhas estruturadas, mas oferecer modelos de significado e consulta adequados. Em uma rede de lojas, por exemplo, transações, fluxo estimado e calendário podem ser preparados em fatos e dimensões coerentes. Isso evita que um dashboard some a mesma venda diversas vezes por relacionar diretamente cada detecção de câmera a transações do mesmo período.
Produtos modernos de Data Warehouse variam em capacidade, processamento elástico, formatos e integração com outras camadas. A comparação deve ser feita com base em requisitos e testes, não em uma definição rígida de que todo Warehouse funciona apenas em infraestrutura tradicional ou possui custo fixo.
Diferenças práticas de Data Lake e Data Warehouse
O Data Lake tende a concentrar flexibilidade de armazenamento e conservação de dados heterogêneos. O Data Warehouse enfatiza organização para consulta, consistência de indicadores e modelagem. Ambas as arquiteturas exigem segurança e governança; nenhuma é intrinsecamente confiável apenas pelo nome. Um lago pode manter tabelas estruturadas, e um warehouse moderno pode trabalhar com dados semiestruturados, dependendo das funcionalidades contratadas.
| Critério | Data Lake | Data Warehouse |
| Finalidade predominante | Conservar e tratar dados variados | Consultar dados analíticos modelados |
| Modelo inicial | Pode receber dados ainda não harmonizados | Favorece organização e significado para consumo |
| Exemplos de fontes | Arquivos, eventos, registros e sensores | Fatos e dimensões de negócio |
| Risco principal | Acúmulo sem catálogo ou governança | Modelagem inadequada ou inflexível |
| Reprocessamento | Facilitado se a origem é retida | Depende de histórico e arquitetura |
| Escolha | Flexibilidade e necessidade de novas análises | Consultas confiáveis e indicadores compartilhados |
A tabela sintetiza intenções arquiteturais e não substitui a avaliação das capacidades de plataformas específicas. O nome comercial de um serviço não garante que ele atenda integralmente aos critérios de retenção, qualidade, segurança, desempenho e rastreabilidade exigidos.
Quando o Business Intelligence precisa de um ou de outro
Uma empresa que deseja comparar faturamento, atendimento e operação por unidade pode necessitar de métricas compartilhadas e atualização periódica. Um Data Warehouse com modelo dimensional pode ser suficiente se as fontes são conhecidas, o histórico necessário está disponível e o processamento atende aos requisitos. Adotar um Data Lake apenas por sua flexibilidade poderia acrescentar manutenção sem valor ao caso.
Outra organização pode lidar com eventos de sensores, vários formatos de logs, bases em mudança e necessidade de reprocessar registros conforme novas regras. Nesse cenário, conservar uma zona de ingestão de dados autorizados pode facilitar investigações e evolução do modelo. Ainda será preciso construir camadas confiáveis de consumo; apontar um dashboard diretamente para registros brutos não resolve diferenças de significado.
A decisão entre armazenamentos e transformações precisa considerar fontes existentes, requisitos de retenção e os indicadores que a organização deseja construir. Um diagnóstico de arquitetura ajuda a evitar complexidade e cópias de dados sem finalidade comprovada.
O desenho também pode ser combinado. Dados entram em uma área controlada de origem, passam por validação e harmonização e alimentam tabelas analíticas. O importante é explicitar a responsabilidade de cada camada, evitando replicar dados pessoais ou criar múltiplos repositórios sem governança.
Exemplos de dados de vídeo e operação
Analíticos de vídeo podem produzir contagens, eventos de linha e informações de permanência conforme câmeras, algoritmos e licenças. O VMS organiza vídeo, alarmes e interfaces operacionais. Registros brutos ou exportações autorizadas podem ter formatos variados, mas a análise gerencial normalmente utiliza metadados e agregados que precisam ser contextualizados por zona, direção, unidade e período. O armazenamento de vídeo integral não é automaticamente necessário à solução de Business Intelligence.
Se o projeto pretende analisar tendência de movimento e vendas, os indicadores precisam de granularidade compatível. Passagens estimadas não são visitantes únicos; transações não são compradores únicos. Os registros devem ser tratados antes de compor qualquer razão gerencial. A presença de um Data Lake ou Warehouse não corrige um contador mal calibrado.
Em sistemas de manutenção, uma falha pode gerar numerosos alarmes, mas representar um incidente único. O tratamento analítico pode conservar registros de origem na área apropriada e construir fatos de falhas e ativos para consulta. A arquitetura de armazenamento deve preservar a capacidade de rastrear a relação entre eventos, ordens e resultados.
A relação com ETL e ELT
ETL e ELT descrevem onde a transformação acontece em relação à carga. Essas abordagens não correspondem rigidamente a Data Warehouse ou Data Lake. Um warehouse pode usar ELT com transformações em seu próprio ambiente; um lago pode receber dados tratados e não tratados; uma arquitetura híbrida pode filtrar ou minimizar atributos antes da ingestão e executar harmonização posterior.
O artigo sobre ETL e ELT em Business Intelligence detalha esses métodos. O requisito central é saber o que ocorre em cada estágio, quais registros são rejeitados, como mudanças são reproduzidas e quais controles impedem acesso indevido.
Uma escolha inadequada de ordem de processamento pode criar custos de reprocessamento, retenção excessiva ou necessidade de manter múltiplas cópias. O projeto deve comparar alternativas com volume representativo, teste de falhas e capacidade de reconstruir indicadores após correções retroativas.
Arquitetura de referência entre fontes e indicadores
A solução pode usar zonas de ingestão, tratamento, armazenamento e apresentação, independentemente do nome comercial da plataforma. O Data Lake pode conservar registros em formatos variados sob governança; um Data Warehouse pode organizar fatos e dimensões para análise. Quando os dois são utilizados, a finalidade de cada cópia e o ponto de aplicação de regras precisam estar claros.
O diagrama descreve um caminho lógico possível, não obriga o uso de dois produtos distintos. O ambiente deve ser dimensionado segundo volume, latência, custo e exigências de governança. Em algumas soluções, as zonas são implementadas em serviços de uma mesma plataforma; em outras, mantêm responsabilidades distribuídas entre fornecedores e equipes.
O resultado precisa preservar identificadores de origem, horários, transformações e versão das regras. Sem esses elementos, uma divergência nos painéis pode exigir reconstrução manual demorada ou tornar-se impossível de explicar.
A confiabilidade de qualquer repositório depende da integração: códigos de sistemas, horários, estados e versões precisam ser harmonizados com tratamento de falhas. Interfaces sem semântica consistente podem produzir dados abundantes, mas indicadores incorretos.
Modelagem dimensional e qualidade dos indicadores
Fatos e dimensões permitem descrever fenômenos operacionais e analisá-los com contexto. Fatos podem representar vendas, eventos de acesso, contagens de vídeo ou ordens de manutenção. Dimensões descrevem loja, data, área, ativo e tipo de evento. A orientação da Microsoft recomenda granularidade consistente nas tabelas de fatos e relacionamentos explícitos para evitar resultados multiplicados por consultas indevidas.
Um mesmo registro de origem pode participar de mais de uma análise, mas cada métrica precisa definir o que mede e como agrega as informações. O valor de fluxo por horário não é equivalente a número de visitantes distintos; um dado de ocupação pode ser estimado e requer cobertura compatível. Warehouse e Lake ajudam na organização e no processamento, mas a interpretação depende das regras.
O catálogo de indicadores deve registrar fórmula, unidade, fonte, periodicidade, filtros, limitações e responsável. O dashboard precisa declarar dados incompletos ou atualizações tardias. Um repositório de alta capacidade não garante confiabilidade sem essa disciplina.
Governança, segurança e dados pessoais
Um Data Lake pode preservar registros de origem que contêm identificadores pessoais, informações operacionais sensíveis e atributos não necessários a todas as finalidades. A arquitetura deve aplicar finalidade, necessidade, controle de acesso, segurança e retenção proporcionais conforme a LGPD e as obrigações aplicáveis. A flexibilidade de armazenamento não constitui autorização para conservar tudo indefinidamente.
O Warehouse também precisa de segregação por função, governança de modelos e controle de exportações. Uma medida agregada adequada à direção não necessariamente exige expor dados individuais utilizados na origem. Perfis administrativos, logs e cópias de desenvolvimento precisam ser considerados para que as permissões sejam efetivas.
Políticas de retenção podem variar entre dados brutos, registros tratados e indicadores. A organização deve definir por que cada camada mantém os dados, por quanto tempo, quem autoriza seu uso e como ocorre a eliminação. Sem esse vínculo, a arquitetura corre risco de acumular informação sem responsabilidade.
Custos, desempenho e critérios de escolha
A avaliação econômica precisa considerar ingestão, processamento, armazenamento, consultas, transferências, licenças, observabilidade, proteção e manutenção das regras. Um Data Lake aparentemente barato para armazenar arquivos pode exigir tratamento significativo para gerar indicadores; um Warehouse eficiente para consultas pode gerar custo elevado se modelos forem mal dimensionados ou consultas executarem processamento excessivo.
A comparação deve utilizar cenários representativos, incluindo crescimento de fontes, retenção, atualizações, correções e períodos de pico. A portabilidade importa: a troca de plataforma pode ser difícil quando todo o significado das métricas está distribuído em lógica proprietária sem documentação. Contratos devem esclarecer formatos, exportação, responsabilidades e continuidade.
Um piloto pode medir tempos de carga, consulta e reprocessamento, custo aproximado sob premissas documentadas e facilidade de recuperar falhas. A escolha não deve ser baseada apenas em capacidade anunciada pelo fornecedor, pois o resultado depende da configuração e do padrão de uso da organização.
Exemplo de decisão para uma rede de varejo
Considere uma rede com dados de vendas por transação, contagens de entradas por hora e alterações periódicas de cadastro de lojas. O objetivo é acompanhar tendência de demanda e resultado comercial. Uma solução pode armazenar os registros autorizados, harmonizar códigos e calendário e oferecer tabelas por unidade e período para indicadores de gestão. Não é necessário que cada usuário final tenha acesso aos dados brutos ou que todos os formatos sejam conservados sem prazo.
Se novas perguntas exigirem reconstruir cálculos ou investigar diferenças anteriores, manter dados de origem sob governança pode ser útil. Essa necessidade deve ser equilibrada com privacidade, custo e disponibilidade de informações na origem. A mesma análise pode ser feita com diferentes produtos; o requisito central é permitir que indicadores sejam reproduzidos e seus limites compreendidos.
Uma situação de erro comum seria relacionar cada passagem estimada a todas as vendas do período e duplicar valores. A camada semântica precisa definir fatos compatíveis e impedir interpretações que o dado não sustenta. A solução de Business Intelligence conecta o armazenamento à decisão, e não o contrário.
Validação e implantação em etapas
O aceite deve testar qualidade dos registros, regras de transformação, modelos e consultas em situações normais e de falha. É necessário verificar duplicações, valores ausentes, atraso, correções de origem, mudança de esquema, troca de unidade e restrições de acesso. A equipe do cliente precisa conseguir reproduzir indicadores a partir de amostras e compreender o que mudou após uma retificação.
| Critério | Evidência de aceite |
| Ingestão | Fonte, identificador e horário preservados |
| Tratamento | Regras, exceções e versões documentadas |
| Armazenamento | Retenção e permissão testadas |
| Modelagem | Fatos e dimensões sem duplicações |
| Dashboard | Fórmula, qualidade e origem verificáveis |
A implantação gradual começa por um caso de uso cuja decisão seja clara. A arquitetura pode ser simplificada quando as fontes são poucas e estáveis ou ampliada quando existem requisitos reais de histórico, heterogeneidade e reprocessamento. O sucesso não é adotar o nome mais recente de uma tecnologia, mas manter uma cadeia de informação útil ao cliente.
Em ambientes industriais, a definição da camada de dados não pode ignorar segurança OT, o papel dos sistemas de controle e a qualidade dos registros de sensores. O projeto de automação estabelece condições para coleta e uso apropriado das fontes técnicas.
Exemplo técnico: dados de vídeo, vendas e manutenção
Considere uma organização que deseja analisar fluxo estimado de pessoas em diferentes unidades, relacionando essas medidas a transações e indisponibilidade de equipamentos. Os analíticos de vídeo fornecem eventos ou agregados por zona; o ponto de venda entrega transações e ajustes; a manutenção registra ocorrências de ativos. A primeira atividade é definir a granularidade de cada informação e as perguntas de negócio que os dados podem sustentar. Um repositório de alta capacidade não corrige a divergência entre passagem estimada e visitante único nem a diferença entre abertura e encerramento de uma ordem.
Uma arquitetura possível preserva dados autorizados de origem em ambiente controlado para auditoria e reprocessamento. Depois harmoniza códigos de loja, horários, unidades e regras de qualidade, construindo fatos e dimensões que permitem consultar indicadores. O Data Lake pode cumprir papel relevante na conservação heterogênea, enquanto o Data Warehouse pode servir ao consumo analítico modelado. Isso não obriga dois serviços separados: uma plataforma pode oferecer mais de uma capacidade, conforme desenho e ferramentas.
Quando uma câmera muda de posição, o histórico de contagem pode perder comparabilidade. Se o processo de vendas passa a registrar cancelamentos de outra forma, o indicador comercial também muda. A retenção de dados de origem sob políticas adequadas pode facilitar reconstruir séries, mas somente se versões de regras e registros de configuração forem preservados. Um ambiente cheio de arquivos sem catálogo não resolve esse problema; a governança precisa acompanhar o dado desde a coleta.
Um teste de aceitação seleciona amostras e reproduz números após uma correção retroativa, verificando também se o usuário final recebe apenas dados autorizados. O projeto não termina quando o Data Lake ou Warehouse recebe informações. O resultado útil está em produzir métricas consistentes, permitir consulta com desempenho adequado e explicar diferenças diante de falhas ou mudanças na operação.
Escolha pela necessidade de reprocessamento e pelo custo
Uma pergunta recorrente é se a organização precisa preservar todos os registros detalhados ou apenas os resultados consolidados. A resposta depende da finalidade, do custo e da necessidade legítima de revisão. Quando uma métrica deriva de múltiplas fontes e suas regras mudam com frequência, conservar dados autorizados da origem pode facilitar auditoria e reprocessamento. Se a análise precisa somente de agregados históricos já confiáveis, um desenho mais enxuto pode ser suficiente. O nome da tecnologia não substitui a avaliação dessas condições.
Custos incluem volume armazenado, número de cópias, processamento, transferência entre serviços, consultas, backup, observabilidade e pessoal responsável. Uma arquitetura que conserva todos os dados e replica cada estágio em outra plataforma pode criar custo recorrente sem melhorar a decisão. O estudo deve comparar hipóteses de crescimento, período de retenção, frequência de consultas e necessidade de reprocessar históricos. As estimativas precisam estar vinculadas a preços e parâmetros concretos no momento da contratação, sem generalizações por marca.
A governança também afeta o custo de mudança. Fórmulas de indicadores escondidas em consultas não documentadas podem dificultar migração e manutenção. Catalogar os dados e manter transformações com versão permite reorganizar o processamento sem perder a interpretação das métricas. O custo de uma solução deve considerar sua capacidade de evoluir com o negócio e com a substituição de fornecedores.
Segurança, retenção e contratos de dados
Conservar dados em forma próxima à origem pode incluir informações pessoais, segredos operacionais ou elementos não necessários a todos os usuários. A política de retenção deve justificar cada classe, restringir acesso e prever eliminação quando apropriada. A existência de um lago de dados não autoriza copiar registros de vídeo, credenciais ou bases transacionais integralmente. A organização precisa escolher o conjunto mínimo adequado à finalidade e separar zonas técnicas de ambientes de consulta gerencial.
Contratos de dados definem campos, tipos, unidades, significado, identificadores, periodicidade e tratamento de exceções. Se uma origem mudar seu esquema ou sua forma de classificar eventos, a transformação precisa detectar a alteração antes que ela chegue silenciosamente ao dashboard. A mesma regra vale para APIs, arquivos e integrações por eventos. O projeto deve incluir monitoramento de completude, idade dos registros e falhas de ingestão, mantendo evidência dos dados rejeitados.
Em ambientes com múltiplas equipes, modelos analíticos devem oferecer permissões proporcionais à função. O usuário de gestão pode consultar totais por unidade e período sem acessar identificadores individuais preservados para outras finalidades legítimas. É necessário testar também exportações, cópias e perfis administrativos. Segurança não se limita a colocar autenticação na tela do dashboard: abrange as diversas camadas por onde os dados circulam.
Matriz de decisão para selecionar o repositório
Uma matriz útil começa por perguntas verificáveis. Quais formatos chegam das fontes? Com que frequência são atualizados? Qual histórico precisa ser reconstruído? Qual público consultará as medidas? Quais prazos de atualização, limites de privacidade e condições de portabilidade são necessários? O projeto registra requisitos, alternativas e testes, não uma preferência abstrata por um tipo de armazenamento.
Se a prioridade é fornecer indicadores corporativos consistentes em fontes estáveis, um modelo analítico em Warehouse pode atender bem. Se é essencial explorar dados heterogêneos e reprocessar registros autorizados com novas regras, uma camada de Lake pode ser pertinente. Em cenários combinados, a governança determina quais dados ficam em cada etapa e por quanto tempo. Uma ferramenta que reúne capacidades dos dois modelos deve ser avaliada pelos mesmos critérios, sem depender de marketing tecnológico.
Os ensaios devem medir consulta, carga, recuperação de falhas, segurança e rastreabilidade em escala representativa. Não basta executar um exemplo simples e extrapolar para um empreendimento com centenas de origens. Uma arquitetura adequada preserva a possibilidade de explicar indicadores, adaptar novas fontes e encerrar dados que não têm mais finalidade, mantendo custo e complexidade proporcionais ao valor gerencial.
Como testar portabilidade e recuperação de dados
A contratação de uma arquitetura analítica precisa considerar a capacidade de recuperar dados e definições quando uma plataforma é substituída. Exportar apenas os números finais do dashboard pode não ser suficiente para reconstruir indicadores, porque transformações, chaves e relações podem estar armazenadas em outros componentes. A solução deve documentar formatos de entrada, convenções de identificação, versões das regras, permissões e condições de retirada de dados do fornecedor. Essa documentação permite avaliar dependência tecnológica e planejar continuidade.
Um teste de portabilidade pode selecionar um conjunto limitado de registros autorizados e reproduzir a transformação e o indicador em ambiente controlado. A comparação deve observar integridade, preservação de horários, tipos de dados, valores nulos e critérios de agregação. Se resultados divergem após a migração, a equipe precisa conseguir localizar a diferença entre entrada, tratamento, modelo e consulta. Essa capacidade vale tanto para uma arquitetura baseada em Data Lake quanto para um Data Warehouse.
Recuperação após falha também precisa de critérios. Um conector pode retransmitir registros, o sistema de origem pode corrigir históricos e o repositório pode restaurar dados de uma cópia. A arquitetura deve manter procedimentos de reconciliação que evitem duplicação ou perda silenciosa. Um dashboard visualmente disponível não significa que seu período esteja completo. A governança da informação inclui transparência sobre qualidade, atualização e consistência depois de incidentes.
Responsabilidades e evolução do modelo analítico
Uma solução de Business Intelligence envolve equipes responsáveis pelas fontes, pela integração, pelo armazenamento, pelos indicadores e pela interpretação gerencial. O responsável pelo sistema de origem confirma significado e disponibilidade; a engenharia de dados controla transformações e qualidade; a equipe de negócio aprova fórmulas e limites; segurança e privacidade definem regras de acesso e retenção. Sem esse arranjo, divergências podem permanecer sem solução, mesmo quando a infraestrutura está tecnicamente disponível.
O projeto deve prever mudanças futuras. Novas fontes, alterações em APIs, reclassificação de eventos e expansão de unidades podem modificar o modelo. O Data Lake pode apoiar conservação autorizada de dados de origem para reprocessar, enquanto o Warehouse pode fornecer consultas estáveis para a gestão; essa divisão só agrega valor se cada camada possuir responsabilidade clara. A arquitetura pode ser mais simples quando a organização não precisa das duas capacidades em ambientes separados.
Na prática, o critério de evolução é a decisão que passou a ser necessária e a evidência que poderá sustentá-la. Novos registros não devem ser copiados indiscriminadamente só porque há capacidade de armazenamento. O planejamento deve avaliar qualidade, legitimidade, custo, latência e impacto das mudanças sobre indicadores já utilizados. Assim a escolha de tecnologia permanece vinculada à utilidade do Business Intelligence.
Considerações finais
Data Lake e Data Warehouse oferecem capacidades diferentes dentro de arquiteturas analíticas. A escolha depende de variedade de fontes, necessidade de conservação, tratamento, governança, desempenho e consultas; uma solução pode adotar uma ou combinar ambas conforme os requisitos.
Business Intelligence depende mais que armazenamento: precisa de qualidade, semântica, métricas, autorização de uso e dashboards adequados à decisão. Eventos de vídeo, sensores e registros corporativos só se tornam úteis quando seu significado é preservado.
A arquitetura ideal é a que permite explicar números, refazer cálculos e evoluir com o negócio sem criar cópias de dados desnecessárias. O planejamento deve começar pelas perguntas do cliente e pelos critérios de aceitação, não pela escolha antecipada do repositório.
Referências técnicas
[1] AMAZON WEB SERVICES. What is a data lake? AWS Cloud Computing Concepts. Disponível em: https://aws.amazon.com/what-is/data-lake/.
[2] AMAZON WEB SERVICES. What is a data warehouse? AWS Cloud Computing Concepts. Disponível em: https://aws.amazon.com/what-is/data-warehouse/.
[3] MICROSOFT. Understand star schema and the importance for Power BI. Disponível em: https://learn.microsoft.com/power-bi/guidance/star-schema.
[4] GOOGLE CLOUD. What is a data warehouse? Cloud Learning Resources. Disponível em: https://cloud.google.com/learn/what-is-a-data-warehouse.
[5] MICROSOFT. What is a data lake? Azure Architecture Center. Disponível em: https://learn.microsoft.com/azure/architecture/data-guide/scenarios/data-lake.
[6] BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm.
Perguntas frequentes
O Data Lake privilegia conservação de dados variados, enquanto o Data Warehouse enfatiza dados organizados para análise e indicadores, conforme as ferramentas.
Não universalmente. A arquitetura pode usar um, outro ou ambos de acordo com fontes, governança e consultas necessárias.
Depende de qualidade e semântica dos dados; ambientes analíticos modelados tendem a facilitar indicadores consistentes.
Não por padrão. A solução pode utilizar eventos e metadados autorizados sem conservar gravações integrais.
Alguns produtos modernos oferecem capacidades para formatos semiestruturados. É preciso conferir a plataforma e o projeto.
Não. ETL e ELT são métodos de tratamento e podem ser combinados conforme requisitos.
Quando houver finalidade legítima, governança, necessidade de reprocessamento e retenção justificada.
Não para análise confiável. Origem, significado, responsabilidade, qualidade e acesso precisam ser documentados.
Considere ingestão, armazenamento, consultas, transformação, licenças, segurança, reprocessamento e crescimento.
Defina finalidade, minimização, segregação, acesso e retenção proporcionais conforme a LGPD.
Não. Fórmulas, modelo semântico, granularidade e testes são necessários para evitar resultados incorretos.
Defina decisão, fontes e limites; teste arquitetura com dados representativos e critérios de aceite verificáveis.
