Este é um artigo traduzido originalmente publicado dia 27/6/2022 no blog do Kai Waehner: "Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?". Assine a newsletter do Kai para se manter atualizado com novas publicações.
Os conceitos e arquiteturas de um data warehouse, um data lake e streaming de dados são complementares para resolver problemas de negócios. Infelizmente, as tecnologias subjacentes são muitas vezes incompreendidas, usadas em excesso para arquiteturas monolíticas e inflexíveis e apresentadas para casos de uso errados pelos fornecedores. Vamos explorar esse dilema em uma série de blogs. Esta é a parte 1: Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, ou um pouco dos dois?
Os conceitos e arquiteturas de data warehouse, data lake e streaming de dados são complementares para resolver problemas de negócios . Armazenar dados em repouso para relatórios e análises requer recursos e SLAs diferentes do processamento contínuo de dados em movimento para cargas de trabalho em tempo real. Existem muitas estruturas de código aberto, produtos comerciais e serviços de nuvem SaaS. Infelizmente, as tecnologias subjacentes são muitas vezes incompreendidas, usadas em excesso para arquiteturas monolíticas e inflexíveis e apresentadas para casos de uso errados pelos fornecedores. Vamos explorar esse dilema em uma série de blogs. Saiba como criar uma pilha de dados moderna com tecnologias nativas da nuvem . Esta é a parte 1: Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, Inimigos?
Data Warehouse x Data Lake x Data Streaming
Esta série de blogs explora conceitos, recursos e compensações de uma stack de dados moderna usando um data warehouse, data lake e streaming de dados juntos:
ESTE POST: Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, ou um pouco dos dois?
Streaming de dados para ingestão de dados no Data Warehouse e Data Lake (post original: Data Streaming for Data Ingestion into the Data Warehouse and Data Lake)
Modernização do Data Warehouse: De Legado On-Premise a Infraestrutura Nativa em Nuvem (versão traduzida em breve, post original: Data Warehouse Modernization: From Legacy On-Premise to Cloud-Native Infrastructure)
Estudos de caso: streaming de dados nativo da nuvem para modernização do data warehouse (versão traduzida em breve, post original:Case Studies: Cloud-native Data Streaming for Data Warehouse Modernization)
Lições aprendidas com a criação de um data warehouse nativo da nuvem (versão traduzida em breve, post original: Lessons Learned from Building a Cloud-Native Data Warehouse)
Fique atento para uma postagem de blog dedicada para cada tópico como parte desta série de blogs. Vou linkar os blogs aqui assim que estiverem disponíveis (nas próximas semanas). Assine minha newsletter para receber um e-mail após cada publicação (sem spam ou anúncios).
O valor dos dados: cargas de trabalho transacionais versus analíticas
A última década ofereceu muitos artigos, blogs e apresentações sobre dados se tornando o novo petróleo. Hoje, ninguém questiona que os processos de negócios orientados por dados mudam o mundo e permitem a inovação em todos os setores .
Os processos de negócios orientados a dados exigem processamento de dados em tempo real e processamento em lote . Pense no seguinte fluxo de eventos entre aplicativos, domínios e organizações:
Um evento é uma informação comercial ou informação técnica. Eventos acontecem o tempo todo. Um processo de negócios no mundo real requer a correlação de vários eventos.
Quão crítico é um evento?
A criticidade de um evento define o resultado. Os impactos potenciais podem ser aumento de receita, redução de risco, redução de custo ou melhoria da experiência do cliente.
Transação comercial : Idealmente, zero tempo de inatividade e zero perda de dados. Exemplo: Os pagamentos precisam ser processados exatamente uma vez.
Análise crítica : Idealmente, tempo de inatividade zero. A perda de dados de um único evento de sensor pode ser aceitável. Alertar sobre a agregação de eventos é mais crítico. Exemplo: monitoramento contínuo de dados do sensor de IoT e um alerta de falha de máquina (preditivo).
Análise não crítica : o tempo de inatividade e a perda de dados não são bons, mas não matam todo o negócio. É um acidente, mas não um desastre. Exemplo: Relatórios e inteligência de negócios para previsão de demanda.
Quando processar um evento?
Tempo real geralmente significa processamento de ponta a ponta em milissegundos ou segundos. Se você não precisar de decisões em tempo real, o processamento em lote (ou seja, após minutos, horas, dias) ou sob demanda (ou seja, solicitação-resposta) é suficiente.
As transações comerciais geralmente são em tempo real: uma transação como um pagamento geralmente requer processamento em tempo real (por exemplo, antes que o cliente saia da loja; antes de enviar o item; antes de sair do carro).
A análise crítica geralmente é em tempo real: a análise crítica geralmente requer processamento em tempo real (por exemplo, detectar a fraude antes que ela aconteça; prever uma falha de máquina antes que ela quebre; vender para um cliente antes que ele saia da loja).
A análise não crítica geralmente não é em tempo real: encontrar insights em dados históricos geralmente é feito em um processo em lote usando paradigmas como consultas SQL complexas, redução de mapa ou algoritmos complexos (por exemplo, relatórios; treinamento de modelo com algoritmos de aprendizado de máquina; previsão ).
Com esses conceitos básicos sobre o processamento de eventos, vamos entender por que armazenar todos os eventos em um único data lake central não é a solução para todos os problemas.
Flexibilidade através da descentralização e o melhor da categoria
A abordagem tradicional de data warehouse e data lake consiste em ingerir todos os dados de todas as fontes em um sistema de armazenamento central para propriedade de dados centralizada . O céu (e seu orçamento) é o limite com as tecnologias atuais de big data e nuvem.
No entanto, conceitos de arquitetura como design orientado a domínio, microsserviços e malha de dados mostram que a propriedade descentralizada é a escolha certa para a arquitetura empresarial moderna :
Sem problemas. O data warehouse e o data lake não estão mortos, mas mais relevantes do que nunca em um mundo orientado a dados. Ambos fazem sentido para muitos casos de uso. Mesmo em um desses domínios, as organizações maiores não usam um único data warehouse ou data lake. Selecionar a ferramenta certa para o trabalho (em seu domínio ou unidade de negócios) é a melhor maneira de resolver o problema de negócios.
Há boas razões pelas quais as pessoas estão satisfeitas com o Databricks para ETL em lote, aprendizado de máquina e agora até mesmo data warehouse, mas ainda preferem um banco de dados SQL em nuvem leve, como AWS RDS (PostgreSQL totalmente gerenciado) para alguns casos de uso.
Há boas razões para os usuários felizes do Splunk também ingerirem alguns dados no Elasticsearch. E por que Cribl está ganhando cada vez mais tração neste espaço também.
Há boas razões para alguns projetos utilizarem o Apache Kafka como banco de dados . Armazenar dados a longo prazo no Kafka só faz sentido para alguns casos de uso específicos (como tópicos compactados, consultas de chave/valor, análise de streaming). Kafka não substitui outros bancos de dados ou data lakes.
Escolha a ferramenta certa para o trabalho com propriedade de dados descentralizada!
Com isso em mente, vamos explorar os casos de uso e o valor agregado de um data warehouse moderno (e como ele se relaciona com os data lakes e o novo buzz lakehouse).
Data warehouse: relatórios e inteligência de negócios com dados em repouso
Um data warehouse (DWH) fornece recursos para geração de relatórios e análise de dados. É considerado um componente central da inteligência de negócios.
Casos de uso para dados em repouso
Não importa se você usa um produto chamado data warehouse, data lake ou lakehouse. Os dados são armazenados em repouso para processamento adicional:
Relatórios e Business Intelligence : Disponibilidade rápida e flexível de relatórios, estatísticas e números-chave, por exemplo, para identificar correlações entre o mercado e a oferta de serviços
Engenharia de dados : integração de dados de conjuntos de dados estruturados e distribuídos de forma diferente para permitir a identificação de relacionamentos ocultos entre os dados
Big Data Analytics e AI / Machine Learning : visão global dos dados de origem e, portanto, avaliações abrangentes para encontrar insights desconhecidos para melhorar os processos de negócios e os inter-relacionamentos.
Alguns leitores podem dizer: apenas o primeiro é um caso de uso para um data warehouse e os outros dois são para um data lake ou lakehouse! Tudo depende da definição.
Arquitetura de armazenamento de dados
Os DWHs são repositórios centrais de dados integrados de fontes diferentes. Eles armazenam dados históricos em um sistema de armazenamento . Os dados são armazenados em repouso, ou seja, salvos para posterior análise e processamento. Os usuários de negócios analisam os dados para encontrar insights.
Os dados são carregados de sistemas operacionais, como dados de IoT, ERP, CRM e muitos outros aplicativos. A limpeza de dados e a garantia de qualidade de dados são peças cruciais no pipeline do DWH. Extract, Transform, Load (ETL) ou Extract, Load, Transform (ELT) são as duas principais abordagens para construir um sistema de data warehouse. Os data marts ajudam a focar em um único assunto ou linha de negócios dentro do ecossistema de data warehouse.
A relação do data warehouse com o data lake e o lakehouse
O foco de um data warehouse é a geração de relatórios e inteligência de negócios usando dados estruturados. Por outro lado, o data lake é sinônimo de armazenamento e processamento de big data bruto. Um data lake foi construído com tecnologias como Hadoop, HDFS e Hive no passado. Hoje, o data warehouse e o data lake se fundiram em uma única solução. Um DWH nativo da nuvem oferece suporte a big data. Da mesma forma, um data lake nativo da nuvem precisa de inteligência de negócios com ferramentas tradicionais .
Databricks: A evolução do data lake para o data warehouse
Isso é verdade para quase todos os fornecedores. Por exemplo, veja a história de um dos principais fornecedores de big data: Databricks, conhecido por ser a empresa Apache Spark . A empresa começou como um fornecedor comercial por trás do Apache Spark, uma plataforma de processamento em lote de big data. A plataforma foi aprimorada com (algumas) cargas de trabalho em tempo real usando micro-lote. Alguns marcos depois, a Databricks é uma empresa totalmente diferente hoje, com foco em nuvem, análise de dados e armazenamento de dados. A estratégia da Databricks mudou de:
código aberto para a nuvem
software autogerenciado para ofertas sem servidor totalmente gerenciadas
concentre-se no Apache Spark para AI / Machine Learning e recursos de armazenamento de dados adicionados posteriormente
um único produto para um vasto portfólio de produtos em análise de dados, incluindo formatos de dados padronizados (“Delta Lake”), governança, ferramentas ETL (Delta Live Tables) e muito mais,
Fornecedores como Databricks e AWS também criaram uma nova palavra de ordem para essa fusão de data lake, data warehouse, business intelligence e recursos em tempo real: The Lakehouse .
O Lakehouse (às vezes chamado de Data Lakehouse) não é novidade. Ele combina características de plataformas separadas . Escrevi um artigo sobre como criar um lakehouse sem servidor nativo da nuvem na AWS usando o Kafka em conjunto com as plataformas de análise da AWS .
Snowflake: A evolução do data warehouse para o data lake
Floco de neve veio da outra direção. Foi o primeiro data warehouse genuinamente nativo da nuvem disponível em todas as principais nuvens . Hoje, o Snowflake oferece muito mais recursos além do espectro tradicional de business intelligence . Por exemplo, engenheiros de dados e software têm recursos para interagir com o data lake do Snowflake por meio de outras tecnologias e APIs. O engenheiro de dados requer uma interface Python para analisar dados históricos, enquanto o engenheiro de software prefere ingestão e análise de dados em tempo real em qualquer escala.
Não importa se você cria um data warehouse, data lake ou lakehouse: o ponto crucial é entender a diferença entre dados em movimento e dados em repouso para encontrar a arquitetura corporativa e os componentes certos para sua solução . As seções a seguir exploram por que uma boa arquitetura de data warehouse requer ambos e como eles se complementam muito bem.
As cargas de trabalho transacionais em tempo real não devem ser executadas no data warehouse ou no data lake! A separação de interesses é fundamental devido a diferentes SLAs de tempo de atividade, leis regulatórias e de conformidade e requisitos de latência.
Streaming de dados: complementando o data warehouse moderno com dados em movimento
Vamos esclarecer: streaming de dados NÃO é o mesmo que ingestão de dados! Você pode usar uma tecnologia de streaming de dados como o Apache Kafka para ingestão de dados em um data warehouse ou data lake. A maioria das empresas faz isso. Fino e valioso.
MAS: Uma plataforma de streaming de dados como o Apache Kafka é muito mais do que apenas uma camada de ingestão. Portanto, ele difere significativamente de mecanismos de ingestão como AWS Kinesis, Google Pub/Sub e ferramentas semelhantes .
O streaming de dados NÃO é o mesmo que a ingestão de dados
O streaming de dados fornece recursos de mensagens, persistência, integração e processamento . Alta escalabilidade para milhões de mensagens por segundo, alta disponibilidade, incluindo compatibilidade com versões anteriores e atualizações contínuas para cargas de trabalho de missão crítica, e recursos nativos da nuvem são alguns dos recursos integrados.
O padrão de fato para streaming de dados é o Apache Kafka . Portanto, uso principalmente o Kafka para arquiteturas de streaming de dados e casos de uso.
Casos de uso transacionais e analíticos para streaming de dados com o Apache Kafka
O número de diferentes casos de uso para streaming de dados é quase infinito. Lembre-se de que o fluxo de dados NÃO é apenas uma fila de mensagens para ingestão de dados ! Embora a ingestão de dados em um data lake tenha sido o primeiro caso de uso proeminente, isso implica em menos de 5% das implantações reais do Kafka. Aplicativos de negócios, middleware ETL de streaming, análises em tempo real e cenários de borda/híbridos são alguns dos outros exemplos:
A camada de persistência do Kafka permite arquiteturas de microsserviços descentralizadas para aplicativos ágeis e verdadeiramente desacoplados .
Lembre-se de que o Apache Kafka oferece suporte a cargas de trabalho transacionais e analíticas (post original: Analytics vs. Transactions in Data Streaming with Apache Kafka). Ambos geralmente têm SLAs de tempo de atividade, latência e perda de dados muito diferentes. Confira esta postagem e a apresentação de slides para saber mais sobre casos de uso de streaming de dados em todos os setores com tecnologia Apache Kafka (post traduzido em breve, post original: Use Cases and Architectures for Apache Kafka across Industries).
A próxima postagem desta série de blogs explora por que o streaming de dados com ferramentas como o Apache Kafka é a tecnologia predominante para ingestão de dados em data warehouses e data lakes .
Não (tente) usar o data warehouse ou data lake para streaming de dados
Esta postagem de blog explorou a diferença entre dados em repouso e dados em movimento:
Um data warehouse é excelente para relatórios e inteligência de negócios .
Um data lake é perfeito para análise de big data e IA/Aprendizado de máquina .
O streaming de dados permite casos de uso em tempo real.
Uma arquitetura empresarial descentralizada e flexível é necessária para construir uma pilha de dados moderna em torno de microsserviços e malha de dados.
Nenhuma das tecnologias é uma bala de prata. Escolha a ferramenta certa para o problema. As arquiteturas monolíticas não resolvem os problemas de negócios atuais . Armazenar todos os dados apenas em repouso não ajuda com a demanda por casos de uso em tempo real.
A arquitetura Kappa é uma abordagem moderna para cargas de trabalho em tempo real e em lote para evitar uma infraestrutura muito mais complexa usando a arquitetura Lambda . O streaming de dados complementa o data warehouse e o data lake . A conectividade entre esses sistemas está disponível imediatamente se você escolher os fornecedores certos (que geralmente são parceiros estratégicos, não concorrentes, como algumas pessoas pensam).
Para mais detalhes, navegue até outras postagens desta série de blogs:
ESTE POST: Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, ou um pouco dos dois?
Streaming de dados para ingestão de dados no Data Warehouse e Data Lake (post original: Data Streaming for Data Ingestion into the Data Warehouse and Data Lake)
Modernização do Data Warehouse: De Legado On-Premise a Infraestrutura Nativa em Nuvem (versão traduzida em breve, post original: Data Warehouse Modernization: From Legacy On-Premise to Cloud-Native Infrastructure)
Estudos de caso: streaming de dados nativo da nuvem para modernização do data warehouse (versão traduzida em breve, post original:Case Studies: Cloud-native Data Streaming for Data Warehouse Modernization)
Lições aprendidas com a criação de um data warehouse nativo da nuvem (versão traduzida em breve, post original: Lessons Learned from Building a Cloud-Native Data Warehouse)
Como você combina data warehouse e streaming de dados hoje? O Kafka é apenas sua camada de ingestão no data lake? Você já aproveita o streaming de dados para casos de uso adicionais em tempo real? Ou o Kafka já é o componente estratégico na arquitetura corporativa para microsserviços desacoplados e uma malha de dados? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comments