Este é um artigo traduzido originalmente publicado dia 21/7/2022 no blog do Kai Waehner: "Best Practices for Building a Cloud-Native Data Warehouse or Data Lake". 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 5: Práticas recomendadas para criar um data warehouse ou data lake nativo da nuvem.
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 5: Práticas recomendadas para criar um data warehouse ou data lake nativo da nuvem.
Série do Blog: Data Warehouse vs. Data Lake vs. Data Streaming
Esta série de blogs explora conceitos, recursos e compensações de uma pilha de dados moderna usando data warehouse, data lake e streaming de dados juntos:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, um pouco dos dois? (post original: Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?)
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 (post original: Data Warehouse and Data Lake Modernization: From Legacy On-Premise to Cloud-Native Infrastructure)
Estudos de caso: streaming de dados nativo da nuvem para modernização do data warehouse (post original: Case Studies: Cloud-native Data Streaming for Data Warehouse Modernization)
ESTE POST: Práticas recomendadas para criar um data Warehouse ou Data Lake nativo da nuvem
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).
Práticas recomendadas para criar um data warehouse ou data lake nativo da nuvem
Vamos explorar as seguintes lições aprendidas com a criação de infraestrutura de análise de dados nativa da nuvem com data warehouses, data lakes, streaming de dados e lakehouses:
Lição 1: Processe e armazene dados no lugar certo.
Lição 2: Não projete dados em repouso para revertê-los.
Lição 3: Não há necessidade de uma arquitetura lambda para separar cargas de trabalho em lote e em tempo real
Lição 4: entenda as vantagens e desvantagens entre o compartilhamento de dados em repouso e uma troca de dados de streaming.
Lição 5: A malha de dados não é um único produto ou tecnologia.
Vamos começar…
Lição 1: Processe e armazene dados no lugar certo.
Pergunte a si mesmo: qual é o caso de uso para seus dados?
Aqui estão alguns exemplos de casos de uso para dados e ferramentas exemplares para implementar o caso de negócios:
Relatórios recorrentes para gerenciamento => Data warehouse e suas ferramentas de relatórios prontas para uso
Análise interativa de dados estruturados e não estruturados => Ferramentas de business intelligence como Tableau, Power BI, Qlik ou TIBCO Spotfire em cima do data warehouse ou outro armazenamento de dados
Cargas de trabalho de negócios transacionais => Aplicativo Java personalizado executado em um ambiente Kubernetes ou infraestrutura de nuvem sem servidor
Análise avançada para encontrar insights em dados históricos => Conjuntos de dados brutos armazenados em um data lake para aplicar algoritmos poderosos com tecnologias de IA / Machine Learning, como TensorFlow
Ações em tempo real em novos eventos => Aplicativos de streaming para processar e correlacionar dados continuamente enquanto são relevantes
Computação em tempo real ou em lote na plataforma certa, conforme necessário
As cargas de trabalho em lote funcionam melhor em uma infraestrutura criada para isso. Por exemplo, Hadoop ou Apache Spark. As cargas de trabalho em tempo real funcionam melhor em uma infraestrutura criada para isso. Por exemplo, Apache Kafka.
No entanto, às vezes, ambas as plataformas podem ser usadas. Entenda a infraestrutura subjacente para aproveitá-la da melhor maneira. Apache Kafka pode substituir um banco de dados! No entanto, isso deve ser feito apenas nos poucos cenários em que faz sentido (ou seja, simplifica a arquitetura ou agrega valor ao negócio).
Por exemplo, a reprodutibilidade como uma sequência de eventos (com ordenação garantida com carimbos de data/hora) é incorporada ao log imutável do Kafka. A reprodução e o reprocessamento de dados históricos do Kafka são simples e um caso de uso perfeito para muitos cenários , incluindo:
Novo aplicativo do consumidor
Manipulação de erros
Conformidade / processamento regulatório
Consultar e analisar eventos existentes
Alterações de esquema na plataforma de análise
Treinamento de modelo
Por outro lado, se você precisar fazer análises complexas, como redução de mapa ou embaralhamento, consultas SQL com dezenas de JOINs, uma análise robusta de séries temporais de eventos de sensores, um índice de pesquisa baseado em informações de log ingeridas e assim por diante. Então é melhor você escolher Spark, Rockset, Apache Druid ou Elasticsearch para esse caso de uso .
Armazenamento em camadas com armazenamento de objetos nativo da nuvem para economia
Uma única infraestrutura de armazenamento não pode resolver todos esses problemas , mesmo que os “fornecedores da casa do lago” digam isso. Portanto, a ingestão de todos os dados em um único sistema não será bem-sucedida nos casos de uso acima. Escolha a melhor abordagem com as ferramentas certas para o trabalho.
Os sistemas modernos e nativos da nuvem dissociam o armazenamento e a computação . Isso vale para plataformas de streaming de dados como Apache Kafka e plataformas de análise como Apache Spark, Snowflake ou Google BigQuery. As soluções SaaS implementam soluções inovadoras de armazenamento em camadas (nos bastidores para que você não as veja) para uma separação econômica entre armazenamento e computação .
Até mesmo os serviços modernos de streaming de dados aproveitam o armazenamento em camadas:
Lição 2: Não projete dados em repouso para revertê-los.
Pergunte a si mesmo: há algum valor comercial agregado se você processar os dados agora em vez de mais tarde (o que quer que signifique mais tarde)?
Se sim, não armazene os dados em um banco de dados ou data lake ou data warehouse como a primeira etapa. Os dados são armazenados em repouso e não estão mais disponíveis para processamento em tempo real . Uma plataforma de streaming de dados como o Apache Kafka é a escolha certa se os dados em tempo real superarem os dados lentos no seu caso de uso!
Acho incrível quantas pessoas colocam todos os seus dados brutos no armazenamento de dados apenas para descobrir que poderiam aproveitar os dados em tempo real mais tarde. As ferramentas de ETL reverso são ativadas para acessar os dados no lakehouse novamente por meio da captura de dados de alteração (CDC) ou abordagens semelhantes. Ou se você usa o Spark Structured Streaming (= “tempo real”), mas a primeira coisa a obter os dados para “processamento de fluxo em tempo real” é lê-los de um armazenamento de objetos S3 (= “em repouso e muito tarde”) é impróprio.
O ETL reverso NÃO é a abordagem certa para casos de uso em tempo real…
Se você armazenar dados em um data warehouse ou data lake, não poderá mais processá-los em tempo real, pois já estão armazenados em repouso. Esses armazenamentos de dados são criados para indexação, pesquisa, processamento em lote, relatório, treinamento de modelo e outros casos de uso que fazem sentido no sistema de armazenamento. Mas você não pode consumir os dados em tempo real em movimento do armazenamento em repouso :
… o streaming de dados foi desenvolvido para processar dados continuamente em tempo real
É aí que o streaming de eventos entra em ação. Plataformas como Apache Kafka permitem o processamento de dados em movimento em tempo real para cargas de trabalho transacionais e analíticas .
O ETL reverso não é necessário na arquitetura moderna orientada a eventos! Ele é “embutido” na arquitetura fora da caixa. Cada consumidor consome diretamente os dados em tempo real, se apropriado e tecnicamente viável. E data warehouses ou data lakes ainda o consomem em seu próprio ritmo, quase em tempo real ou em lote:
Novamente, isso não significa que você não deve colocar os dados em repouso em seu data warehouse ou data lake. Mas só faça isso se precisar analisar os dados posteriormente. O armazenamento de dados em repouso NÃO é apropriado para cargas de trabalho em tempo real .
Saiba mais sobre esse tópico no meu post no blog “ Quando usar o ETL reverso e quando é um antipadrão ”.
Lição 3: Não há necessidade de uma arquitetura lambda para separar cargas de trabalho em lote e em tempo real
Pergunte a si mesmo: qual é a maneira mais fácil de consumir e processar dados recebidos com minha tecnologia de análise de dados favorita?
Dados em tempo real superam dados lentos, mas nem sempre!
Pense em seu setor, unidades de negócios, problemas que você resolve e novos aplicativos inovadores que você cria. Dados em tempo real superam dados lentos . Esta afirmação é quase sempre verdadeira. Seja para aumentar a receita, reduzir custos, reduzir riscos ou melhorar a experiência do cliente.
Dados em repouso significam armazenar dados em um banco de dados, data warehouse ou data lake . Dessa forma, os dados são processados tarde demais em muitos casos de uso – mesmo se um componente de streaming em tempo real (como Kafka) ingerir os dados. O processamento de dados ainda é uma chamada de serviço da Web, consulta SQL ou processo em lote de redução de mapa longe de fornecer um resultado para seu problema.
Não me entenda mal. Dados em repouso não são uma coisa ruim . Vários casos de uso, como relatórios (inteligência de negócios), análises (processamento em lote) e treinamento de modelo (aprendizado de máquina) funcionam muito bem com essa abordagem . Mas o tempo real supera o lote em quase todos os outros casos de uso.
A arquitetura Kappa simplifica a infraestrutura para cargas de trabalho em lote E em tempo real
A arquitetura Kappa é uma arquitetura de software baseada em eventos que pode lidar com todos os dados em qualquer escala em tempo real para cargas de trabalho transacionais E analíticas .
A premissa central por trás da arquitetura Kappa é que você pode realizar processamento em tempo real e em lote com uma única pilha de tecnologia . Essa é uma abordagem muito diferente da conhecida arquitetura Lambda. O último separa cargas de trabalho em lote e em tempo real em infraestruturas e pilhas de tecnologia separadas.
O coração de uma infraestrutura Kappa é a arquitetura de streaming . Primeiro, o log da plataforma de streaming de eventos armazena os dados de entrada. A partir daí, um mecanismo de processamento de fluxo processa os dados continuamente em tempo real ou ingere os dados em qualquer outro banco de dados analítico ou aplicativo de negócios por meio de qualquer paradigma e velocidade de comunicação, incluindo tempo real, quase em tempo real, lote e solicitação-resposta .
Saiba mais sobre os benefícios e compensações da arquitetura Kappa em meu artigo “ Kappa Architecture is Mainstream Replaceing Lambda ”.
Lição 4: entenda as vantagens e desvantagens entre o compartilhamento de dados em repouso e uma troca de dados de streaming.
Pergunte a si mesmo: como preciso compartilhar dados com outras unidades de negócios internas ou organizações externas?
Casos de uso para replicação híbrida e multinuvem com streaming de dados, data lakes, data warehouses e lakehouses
Existem muitos bons motivos para replicar dados em data centers, regiões ou provedores de nuvem:
Recuperação de desastres e alta disponibilidade : crie um cluster de recuperação de desastres e failover durante uma interrupção.
Replicação global e em várias nuvens : Mova e agregue dados entre regiões e nuvens.
Compartilhamento de dados: compartilhe dados com outras equipes, linhas de negócios ou organizações.
Migração de dados : migre dados e cargas de trabalho de um cluster para outro (como de um data warehouse local legado para um data lakehouse nativo da nuvem).
A replicação de dados em tempo real supera o compartilhamento lento de dados
A história em torno do compartilhamento de dados internos ou externos não é diferente de outros aplicativos. A replicação em tempo real supera as trocas de dados lentas. Portanto, armazenar dados em repouso e depois replicá-los para outro data center, região ou provedor de nuvem é um antipadrão se as informações em tempo real agregarem valor aos negócios .
O exemplo a seguir mostra como as partes interessadas independentes (= domínios em diferentes empresas) usam uma troca de dados de streaming entre empresas:
A inovação não para na própria fronteira. A replicação de streaming é relevante para todos os casos de uso em que o tempo real é melhor do que dados lentos (válido para a maioria dos cenários). Alguns exemplos:
Otimização da cadeia de suprimentos de ponta a ponta, dos fornecedores ao fabricante, do intermediário ao pós-venda
Rastreie e rastreie entre países
Integração de serviços complementares de terceiros ao próprio produto digital
APIs abertas para incorporar e combinar serviços externos para criar um novo produto
Leia os detalhes sobre um “ Streaming Data Exchange with Kafka and a Data Mesh in Motion vs. Data Sharing in Rest in the Data Warehouse ou Data Lake ” para obter mais detalhes.
Além disso, entenda porque APIs (= REST/HTTP) e streaming de dados (= Apache Kafka) são complementares, não competitivos!
Lição 5: A malha de dados não é um único produto ou tecnologia.
Pergunte a si mesmo: como crio uma arquitetura corporativa flexível e ágil para inovar com mais eficiência e resolver meus problemas de negócios mais rapidamente?
Data Mesh é uma visão lógica, não física!
A malha de dados muda para um paradigma que se baseia na arquitetura distribuída moderna : considerar os domínios como a preocupação de primeira classe, aplicar o pensamento de plataforma para criar uma infraestrutura de dados de autoatendimento, tratar os dados como um produto e implementar a padronização aberta para permitir um ecossistema de produtos de dados distribuídos.
Aqui está um exemplo de uma malha de dados:
TL;DR: Data Mesh combina paradigmas existentes, incluindo Design orientado a domínio, Data Marts, Microservices e Event Streaming .
Um data warehouse ou data lake NÃO é e NÃO PODE SE TORNAR toda a malha de dados!
O coração de uma infraestrutura Data Mesh deve ser em tempo real, desacoplado, confiável e escalável . Kafka é uma plataforma de integração empresarial nativa da nuvem moderna (também chamada de iPaaS hoje) . Portanto, Kafka fornece todos os recursos para a fundação de um Data Mesh .
No entanto, nem todos os componentes podem ou devem ser baseados em Kafka. A beleza das arquiteturas de microsserviços é que cada aplicativo pode escolher as tecnologias certas . Um aplicativo pode ou não incluir bancos de dados, ferramentas analíticas ou outros componentes complementares. As portas de dados de entrada e saída do produto de dados devem ser independentes das soluções escolhidas:
Kafka pode ser um componente estratégico de uma malha de dados nativa da nuvem , nem mais nem menos. Mas mesmo que você não use streaming de dados e crie uma malha de dados apenas com dados em repouso, ainda não há uma solução mágica . Não tente construir uma malha de dados com um único produto, tecnologia ou fornecedor. Não importa se essa ferramenta se concentra em streaming de dados em tempo real, processamento e análise em lote ou interfaces baseadas em API. Ferramentas como Starburst – um mecanismo de consulta MPP baseado em SQL desenvolvido pelo Trino de código aberto (anteriormente Presto) – permitem análises sobre diferentes armazenamentos de dados.
As melhores práticas para um data warehouse nativo da nuvem vão além de um produto SaaS
Construir um data warehouse ou data lake nativo da nuvem é um projeto enorme. Requer ingestão de dados, integração de dados, conectividade com plataformas de análise, privacidade de dados e padrões de segurança e muito mais. Tudo isso é necessário antes que as tarefas reais, como relatórios ou análises, possam começar.
A arquitetura corporativa completa além do escopo do data warehouse ou data lake é ainda mais complexa. As melhores práticas devem ser aplicadas para construir uma infraestrutura de análise de dados resiliente, escalável, elástica e econômica . SLAs, latências e tempo de atividade têm requisitos muito diferentes entre os domínios de negócios. As melhores abordagens da raça escolhem a ferramenta certa para o trabalho. A verdadeira dissociação entre unidades de negócios e aplicativos permite focar na solução de problemas de negócios específicos.
Separação de armazenamento e computação, pipelines unificados em tempo real em vez de separar lote e tempo real, evitando antipatterns como ETL reverso e conceitos de compartilhamento de dados apropriados permitem uma jornada bem-sucedida para a análise de dados nativa da nuvem.
Para mais detalhes, navegue em outros posts desta série de blogs:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, um pouco dos dois? (post original: Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?)
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 (post original: Data Warehouse and Data Lake Modernization: From Legacy On-Premise to Cloud-Native Infrastructure)
Estudos de caso: streaming de dados nativo da nuvem para modernização do data warehouse (post original: Case Studies: Cloud-native Data Streaming for Data Warehouse Modernization)
ESTE POST: Práticas recomendadas para criar um data Warehouse ou Data Lake nativo da nuvem
Como você modernizou seu data warehouse ou data lake? Você concorda com as lições que aprendi? Que outras experiências você teve? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comentários