Este é um artigo traduzido originalmente publicado no blog do Kai Waehner: "The Shift Left Architecture – From Batch and Lakehouse to Real-Time Data Products with Data Streaming". Assine a newsletter do Kai para se manter atualizado com novas publicações.
A integração de dados é um desafio difícil em todas as empresas. O processamento em lote e o ETL reverso são práticas comuns em um data warehouse, data lake ou lakehouse. Inconsistência de dados, alto custo computacional e informações obsoletas são as consequências. Este post apresenta um novo padrão de design para resolver esses problemas: A arquitetura Shift Left permite um data mesh com produtos de dados em tempo real para unificar cargas de trabalho transacionais e analíticas com Apache Kafka, Flink e Iceberg. Informações consistentes são tratadas com processamento de streaming ou ingeridas em Snowflake, Databricks, Google BigQuery ou qualquer outra plataforma analítica/IA para aumentar a flexibilidade, reduzir custos e permitir uma cultura empresarial orientada por dados com time to market mais rápido, criando sistemas inovadores.
Produtos de dados – a base de um data mesh
Um produto de dados é um conceito crucial no contexto de um data mesh que representa uma mudança da gestão de dados centralizada tradicional para uma abordagem descentralizada.
A McKinsey conclui que “quando as empresas gerenciam dados como um produto de consumo — seja ele digital ou físico — elas podem obter valor no curto prazo com seus investimentos em dados e preparar o caminho para obter rapidamente mais valor amanhã. A criação de produtos e padrões de dados reutilizáveis para reunir tecnologias de dados permite que as empresas obtenham valor dos dados hoje e amanhã”:
De acordo com a McKinsey, os benefícios da abordagem de produto de dados podem ser significativos:
Novos casos de uso de negócios podem ser entregues até 90% mais rápido.
O custo total de propriedade, incluindo tecnologia, desenvolvimento e manutenção, pode diminuir em 30%.
O risco e a carga da governação de dados podem ser reduzidos.
Produto de dados de uma perspectiva técnica
Aqui está o que um produto de dados envolve em um data mesh do ponto de vista técnico:
Propriedade descentralizada : cada produto de dados pertence a uma equipe de domínio específica. Os aplicativos são verdadeiramente dissociados.
Obtidos de sistemas operacionais e analíticos : os produtos de dados incluem informações de qualquer fonte de dados, incluindo os sistemas mais críticos e plataformas de análise/relatórios.
Autônomo e detectável : um produto de dados inclui não apenas os dados brutos, mas também os metadados, documentação e APIs associados.
Interfaces padronizadas : os produtos de dados aderem a interfaces e protocolos padronizados, garantindo que possam ser facilmente acessados e utilizados por outros produtos de dados e consumidores dentro da malha de dados.
Qualidade de dados : a maioria dos casos de uso se beneficia de dados em tempo real. Um produto de dados garante a consistência dos dados em aplicativos em tempo real e em lote.
Orientado para o valor : A criação e manutenção de produtos de dados são impulsionadas pelo valor do negócio.
Em essência, um produto de dados em uma estrutura de data mesh transforma os dados em um ativo gerenciado e de alta qualidade que é facilmente acessível e utilizável em toda a organização, promovendo um ecossistema de dados mais ágil e escalável.
Anti-pattern: Processamento em lote e ETL reverso
A stack de dados “moderna” aproveita ferramentas tradicionais de ETL ou streaming de dados para ingestão em um data lake, data warehouse ou lakehouse. A consequência é uma arquitetura espaguete com diversas ferramentas de integração para cargas de trabalho em lote e em tempo real, misturando tecnologias analíticas e operacionais:
O ETL reverso é necessário para transferir informações do data lake para aplicativos operacionais e outras ferramentas analíticas. Como escrevi sobre isso anteriormente, a combinação de data lakes e Reverse ETL é um antipadrão para a arquitetura corporativa, em grande parte devido às ineficiências econômicas e organizacionais que o ETL reverso cria . Os produtos de dados orientados a eventos permitem uma arquitetura muito mais simples e econômica.
Um dos principais motivos para a necessidade de processamento em lote e padrões de ETL reverso é o uso comum da arquitetura Lambda : uma arquitetura de processamento de dados que lida com o processamento em tempo real e em lote separadamente, usando diferentes camadas . Isso ainda existe amplamente em arquiteturas corporativas. Não apenas para casos de uso de big data, como Hadoop/Spark e Kafka, mas também para integração com sistemas transacionais, como monólitos legados baseados em arquivos ou bancos de dados Oracle.
Ao contrário, a Arquitetura Kappa lida com processamento em tempo real e em lote usando uma única pilha de tecnologia . Saiba mais sobre “ Kappa substituindo a arquitetura Lambda ”. TL/DR: A arquitetura Kappa é possível trazendo até mesmo tecnologias legadas para uma arquitetura orientada a eventos usando uma plataforma de streaming de dados. Change Data Capture (CDC) é um dos auxiliares mais comuns para isso.
ELT tradicional no Data Lake, Data Warehouse, Lakehouse
Parece que ninguém mais faz data warehouse hoje. Todo mundo fala sobre um lakehouse que combina data warehouse e data lake. Qualquer que seja o termo que você use ou prefira… O processo de integração hoje em dia é parecido com o seguinte:
Apenas ingerir todos os dados brutos em um data warehouse/data lake/lakehouse apresenta vários desafios:
Atualizações mais lentas : quanto mais longo o pipeline de dados e mais ferramentas forem usadas, mais lenta será a atualização do produto de dados.
Time to market mais longo : os esforços de desenvolvimento são repetidos porque cada unidade de negócios precisa executar as mesmas etapas de processamento ou etapas de processamento semelhantes novamente, em vez de consumir um produto de dados selecionado.
Custo aumentado : a fonte de renda das plataformas de análise cobrada é a computação, não o armazenamento. Quanto mais suas unidades de negócios usarem DBT, melhor para o provedor de SaaS analítico.
Esforços repetidos : a maioria das empresas possui múltiplas plataformas analíticas, incluindo diferentes data warehouses, data lakes e plataformas de IA. ELT significa fazer o mesmo processamento de novo, de novo e de novo.
Inconsistência de dados : ETL reverso, ETL zero e outros padrões de integração garantem que seus aplicativos analíticos e especialmente operacionais vejam informações inconsistentes. Você não pode conectar um consumidor em tempo real ou uma API de aplicativo móvel a uma camada em lote e esperar resultados consistentes.
Integração de dados, Zero ETL e Reverse ETL com Kafka, Snowflake, Databricks, BigQuery, etc.
Essas desvantagens são reais! Não conheci um único cliente nos últimos meses que discordasse e me dissesse que esses desafios não existem. Para saber mais, confira minha série de blog sobre streaming de dados com Apache Kafka e análises com Snowflake:
A série de blogs pode ser aplicada a qualquer outro mecanismo de análise. Vale a pena ler, não importa se você usa Snowflake, Databricks, Google BigQuery ou uma combinação de várias plataformas analíticas e de IA.
A solução para essa confusão de dados que cria inconsistência de dados, informações desatualizadas e custos cada vez maiores é a Arquitetura Shift Left …
Shift left para o streaming de dados para produtos de dados operacionais E analíticos
A arquitetura Shift Left permite informações consistentes de produtos de dados confiáveis e escaláveis, reduz o custo de computação e permite um time to market muito mais rápido para aplicativos operacionais e analíticos com qualquer tipo de tecnologia (Java, Python, iPaaS, Lakehouse, SaaS, “ você escolhe”) e paradigma de comunicação (em tempo real, em lote, ou request-response):
Mudar o processamento de dados para a plataforma de streaming de dados permite:
Capture e transmita dados continuamente quando o evento for criado
Crie contratos de dados para compatibilidade downstream e promoção de confiança com qualquer aplicativo ou plataforma analítica/IA
Limpe, selecione e verifique a qualidade continuamente dos dados upstream com contratos de dados e aplicação de políticas
Moldar dados em vários contextos dinamicamente para maximizar a reutilização (e ainda permitir que os consumidores downstream escolham entre produtos de dados brutos e refinados)
Crie produtos de dados confiáveis que sejam instantaneamente valiosos, reutilizáveis e consistentes para qualquer consumidor transacional e analítico (não importa se consumidos em tempo real ou posteriormente por meio de lote ou request-response)
Ao mudar para a esquerda com algumas cargas de trabalho, é crucial entender que os desenvolvedores/engenheiros de dados/cientistas de dados geralmente ainda podem usar sua interface favorita, como SQL, ou uma linguagem de programação, como Java ou Python.
Arquitetura Shift Left com Apache Kafka, Flink e Iceberg
O streaming de dados é o fundamento principal da arquitetura Shift Left para permitir produtos de dados confiáveis, escalonáveis e em tempo real com boa qualidade de dados . A arquitetura a seguir mostra como Apache Kafka e Flink conectam qualquer fonte de dados, selecionam conjuntos de dados (também conhecidos como processamento de fluxo/Streaming ETL) e compartilham os eventos processados com qualquer coletor de dados operacionais ou analíticos:
A arquitetura mostra uma tabela Apache Iceberg como consumidor alternativo. Apache Iceberg é um formato de tabela aberto projetado para gerenciar conjuntos de dados em grande escala de maneira confiável e de alto desempenho , fornecendo transações ACID, evolução de esquema e recursos de particionamento. Ele otimiza o armazenamento de dados e o desempenho de consultas, tornando-o ideal para data lakes e fluxos de trabalho analíticos complexos. O Iceberg evolui para o padrão de fato com o suporte da maioria dos principais fornecedores na nuvem e no espaço de gerenciamento de dados, incluindo AWS, Azure, GCP, Snowflake, Confluent e muitos outros (como Databricks após a aquisição da Tabular).
Do ponto de vista do streaming de dados, a tabela Iceberg está a apenas um clique de distância do tópico Kafka e seu esquema (usando o Tableflow do Confluent – tenho certeza que outros fornecedores seguirão em breve com soluções próprias). A grande vantagem do Iceberg é que os dados precisam ser armazenados apenas uma vez (normalmente em um object storage econômico e escalável como o Amazon S3). Cada aplicativo downstream pode consumir os dados com sua própria tecnologia, sem qualquer necessidade de codificação ou conectores adicionais . Isso inclui data lakehouses como Snowflake ou Databricks E mecanismos de streaming de dados como Apache Flink.
Vídeo: Arquitetura Shift Left
Resumi as arquiteturas e exemplos acima para a Arquitetura Shift Left em um pequeno vídeo de dez minutos, se você preferir ouvir o conteúdo:
Apache Iceberg – O novo padrão de fato para formato de tabela Lakehouse?
Apache Iceberg é um tópico enorme e uma verdadeira virada de jogo para arquiteturas corporativas, usuários finais e fornecedores de nuvem. Escreverei outro blog dedicado, incluindo tópicos interessantes como:
Estratégia de produto da Confluent para incorporar tabelas Iceberg em sua plataforma de streaming de dados
Projeto Iceberg de código aberto do Snowflake Polaris
Aquisição da Tabular pela Databricks (a empresa por trás do Apache Iceberg) e a relação com Delta Lake e código aberto de seu Catálogo Unity
O futuro (esperado) da padronização de formatos de tabelas , guerras de catálogos e outras soluções adicionais como Apache Hudi ou Apache XTable para interoperabilidade omnidirecional em formatos de tabelas lakehouse.
Valor comercial da arquitetura Shift Left
Apache Kafka é o padrão de fato para streaming de dados construindo uma arquitetura Kappa. O cenário de streaming de dados mostra várias tecnologias de código aberto e fornecedores de nuvem. Data Streaming é uma nova categoria de software . A Forrester publicou “ The Forrester Wave™: Plataformas de streaming de dados, quarto trimestre de 2023 ”. Os líderes são Microsoft, Google e Confluent , seguidos por Oracle, Amazon, Cloudera e alguns outros.
Construir produtos de dados mais a esquerda na arquitetura corporativa com uma plataforma de streaming de dados e tecnologias como Kafka e Flink cria um enorme valor comercial:
Redução de custos : Redução do custo de computação em uma ou mesmo múltiplas plataformas de dados (data lake, data warehouse, lakehouse, plataforma de IA, etc.).
Menos esforço de desenvolvimento : Streaming ETL, curadoria de dados e controle de qualidade de dados já executados instantaneamente (e apenas uma vez) após a criação do evento.
Time to market mais rápido : concentre-se em uma nova lógica de negócios em vez de realizar trabalhos ETL repetidos.
Flexibilidade : A melhor abordagem para escolher a melhor e/ou mais econômica tecnologia por caso de uso.
Inovação : as unidades de negócios podem escolher qualquer linguagem de programação, ferramenta ou SaaS para fazer consumo em tempo real ou em lote de produtos de dados para tentar falhar ou escalar rapidamente.
A unificação de cargas de trabalho transacionais e analíticas é finalmente possível para permitir boa qualidade de dados, tempo de lançamento mais rápido no mercado para inovação e custo reduzido de todo o pipeline de dados. A consistência dos dados é importante em todos os aplicativos e bancos de dados… Um tópico Kafka com um contrato de dados (= Esquema com políticas) traz a consistência dos dados pronta para uso!
Como está sua arquitetura de dados hoje? A Arquitetura Shift Left faz sentido para você? Qual é a sua estratégia para chegar lá? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Kommentare