Este é um artigo traduzido originalmente publicado dia 19/03/2024 pelo Jack Vanlightly no post: "Tableflow: The Stream/Table, Kafka/Iceberg Duality". Siga o Jack no LinkedIn para se manter atualizado com novas publicações.
A Confluent acaba de anunciar o Tableflow, a materialização perfeita dos tópicos do Apache Kafka como tabelas do Apache Iceberg. Este anúncio deve ser o anúncio mais impactante que testemunhei no meu tempo na Confluent. Este post é sobre por que as tabelas Iceberg não são apenas mais um destino para sincronizar dados; elas mudam fundamentalmente o mundo do streaming. É também sobre as macrotendências que nos levaram a este ponto e porque o Iceberg (e os outros formatos de tabela) são tão importantes para o futuro do streaming.
O mundo está mudando
O mundo da infraestrutura de dados está passando por diversas mudanças de paradigma simultaneamente, todas impulsionadas pelo S3 e por outros serviços de object storage em nuvem (GCS, Azure Blob Storage). Embora as tendências que vemos agora estejam em formação há vários anos, parece que 2024 será o ano em que a mudança realmente ganhará ritmo. Como se costuma dizer, a mudança ocorre lentamente e depois de uma só vez.
Existem três mudanças principais de paradigma em andamento:
A ascensão do object storage como a principal camada de armazenamento para sistemas de dados baseados em nuvem.
Tabelas como uma primitiva de compartilhamento, possibilitada por formatos de tabela abertos, sendo o Apache Iceberg o líder de mercado.
Streaming como uma generalização de lote.
Mudança de paradigma #1 – Object Storage. No design de sistemas de dados, o custo é uma espécie de força imparável que reescreve as arquiteturas a cada década ou mais, e isso está acontecendo agora. AWS, GCP e Azure têm sido consistentes na redução dos custos e no aumento da confiabilidade de seus serviços de object storage ao longo do tempo. S3 et al são o únicos players e a forma mais barata de armazenamento; portanto, qualquer sistema tem que se basear nele e não pode ser realmente mais barato ou mais confiável. Você não pode competir com o S3 porque a AWS não fornece os primitivos na nuvem para reconstruí-lo. Sua única outra opção é conseguir algum espaço em um local e começar a armazenar seus próprios discos rígidos e unidades SSD. O S3 pode ou não ser a interface de armazenamento ideal para um conjunto diversificado de sistemas de dados do ponto de vista do design, mas em termos de economia, é imbatível e inevitável.
Mudança de paradigma #2 - Tabelas como primitiva de compartilhamento. Antes dos formatos de tabela aberta, como Apache Iceberg, a forma mais comum de mover dados entre o estado operacional (pense em microsserviços, sistemas back-end, bancos de dados OLTP, etc.) e o estado analítico (pense em data warehouses, OLAP, etc.) foram trabalhos do Apache Kafka e processos ETL. Os tópicos Kafka atuam como primitivos para o compartilhamento de dados entre sistemas e até mesmo entre organizações. Iceberg et al adicionaram outro ideal primitivo de compartilhamento sólido para o setor analítico com sua infinidade de mecanismos de consulta e ferramentas de BI que podem ler e gravar nessas tabelas. A primeira manifestação dessa nova primitiva de compartilhamento é a mercantilização do data lake e a ascensão da arquitetura de dados headless. Com armazenamento e computação desagregados, cada organização pode escolher os mecanismos de consulta/ferramentas de BI que atendem às suas necessidades, colocando mais poder nas mãos da organização para escolher onde colocar seus dados e como acessá-los. Fornecedores de data warehouse como a Snowflake também estão entrando na briga, adicionando a capacidade de consultar tabelas “externas” usando o formato de tabela Iceberg.
Mudança de paradigma #3 – streaming como uma generalização do lote. Até agora, vemos que o Iceberg é a ponte entre estas duas primeiras mudanças tecnológicas, mas também desempenha um papel fundamental na concretização da terceira. A frase “ lote é um caso especial de streaming ” foi cunhada há quase uma década, mas, na realidade, tem lutado para ser concretizada. Os dados ilimitados são um superconjunto de dados limitados, e os trabalhos em lote e os trabalhos de streaming têm janelas, sendo que os primeiros têm uma janela global. Embora logicamente correto, tem sido difícil conseguir isso quando a fonte histórica e a fonte em tempo real vêm de sistemas diferentes. Insira as tabelas Iceberg, que podem atuar tanto como tabelas quanto como fluxos servindo ambas as representações, trazendo essa mesma generalização de princípios presente na camada de processamento de fluxo, mas atuando na camada de armazenamento.
Uma coisa que percebemos é que para tornar o processamento de fluxo realmente poderoso, ele também deve abranger o conjunto de capacidades de um sistema de processamento em lote: a capacidade de gerenciar enormes tabelas de estado e a capacidade de reprocessar dados históricos massivos à medida que a lógica muda. A parte difícil foi combinar os dois modos sem uma mudança brusca de um modo para outro.
As coisas que podemos fazer com a dualidade stream-table
A dualidade stream-table é o conceito de que um stream pode ser projetado como uma tabela e as alterações aplicadas a uma tabela podem ser materializadas como um stream. O stream e a tabela são duas faces da mesma moeda. Iceberg traz outro nível para essa dualidade, pois pode representar o mesmo conjunto de dados como uma tabela e um stream. A coisa maravilhosa sobre como os metadados do Iceberg funcionam é que, controlando as referências de snapshots, podemos criar múltiplas representações dos mesmos dados subjacentes. É possível que um consumidor de dados trate uma tabela como um stream ilimitado enquanto outro vê uma tabela limitada em um momento específico ou até mesmo que um stream diverja com ambas as ramificações compartilhando um ancestral comum.
O que é realmente poderoso é a fusão do tópico Kafka e da tabela Iceberg em um conjunto de dados coerente. O estado operacional de microsserviços e bancos de dados OLTP pode continuar a produzir streams com a API Kafka, como acontece há muito tempo. Os consumidores de dados podem optar por consumir esse stream usando a API Kafka ou como uma tabela Iceberg usando SQL. Os consumidores na área operacional provavelmente continuarão com a API Kafka, enquanto as ferramentas na área analítica podem escolher a API Kafka para latência otimizada e o Iceberg para cargas de trabalho baseadas em SQL. Como os arquivos de dados da tabela Iceberg subjacentes são Parquet, agora temos “streams colunares”, onde o processador de stream só precisa ler as colunas necessárias, aumentando bastante a eficiência de trabalhos grandes. O Flink pode filtrar, transformar, agregar e juntar streams, gravando-os de volta em streams por meio da API Kafka ou materializando diretamente os resultados como tabelas Iceberg. Isso abre a possibilidade de reutilização de dados por ambos os lados da organização, quer prefiram a API Kafka ou o Iceberg.
Integrando o Iceberg ao próprio mecanismo de armazenamento Kora
A seguir, quero escrever sobre as motivações para integrar o Iceberg ao próprio mecanismo de armazenamento Kora, em vez de depender apenas de outro conector. É um ponto importante a ser entendido, pois não podemos simplesmente substituir todos os conectores por uma integração profunda no mecanismo de armazenamento. Então, por que incorporar o Iceberg no mecanismo de armazenamento, por que se tornar multimodal?
Usar um conector Iceberg tem seus limites e força você a escolher entre duas preocupações concorrentes:
Se você priorizar a latência, você gravará antecipadamente, o que significa muitos arquivos Parquet pequenos. Isso se torna ineficiente para leituras que agora precisam lidar com grandes quantidades de arquivos pequenos.
Se você priorizar a eficiência de leitura, acumulará dados até poder gravar em arquivos Parquet grandes, mas isso introduz uma latência muito maior.
O que realmente queremos fazer é otimizar a latência e a eficiência de leitura, sendo capazes de gravar arquivos pequenos e usar a compactação para mesclar esses arquivos pequenos em arquivos maiores com otimização de leitura em segundo plano. Se você leu meu artigo recente sobre ClickHouse , reconhecerá esse padrão. Escreva pequeno para latência e, em seguida, compacte para grande em segundo plano para eficiência de leitura.
Usar um conector Iceberg resolve apenas metade do problema, e a metade muito mais fácil. Isso também significa duplicar dados, já que o Kora já classifica agressivamente os dados para o object storage.
Ao integrar o Iceberg ao mecanismo de armazenamento como um primitivo de armazenamento de primeira classe, podemos fazer coisas incríveis. Em primeiro lugar, podemos substituir o formato de armazenamento em camadas nativo por arquivos Parquet e metadados Iceberg diretamente. Isso cria uma representação de armazenamento de cópia zero de um fluxo como um único conjunto de dados coerente entre corretores Kora e armazenamento de objetos. O mecanismo de armazenamento Kora lida com esse nível de armazenamento Iceberg/Parquet, compactação de arquivos de armazenamento de objetos, retenção, otimização de armazenamento e evolução de esquema entre esquemas de tópicos Kafka e tabelas Iceberg. Os consumidores de dados podem acessar os dados em camadas diretamente como tabelas Iceberg ou consumir todo o fluxo dos corretores Kora usando a API Kafka.
Há uma grande diferença entre ter um conector Iceberg e um mecanismo de armazenamento multimodal. Depois de ter esse mecanismo de armazenamento multimodal, você pode pensar no resto como “aplicativos” que ficam no topo.
Nesta plataforma modular em camadas, os “aplicativos” na parte superior obtêm apenas abstrações de fluxo e tabela.
Pensamentos finais
Os fornecedores de streaming de dados, como o Confluent, são fundamentalmente diferentes de muitos outros no setor de infraestrutura de dados. Os fornecedores de streaming não dependem da gravidade dos dados – os dados entram e saem novamente. A plataforma de streaming é uma plataforma de dados, mas é aberta por design. Ganha dinheiro ao permitir o compartilhamento de dados, abrindo-os para outros sistemas. Onde a mudança de paradigma da tabela compartilhada pode ameaçar alguma parte do setor de infraestrutura de dados, para streaming, ela representa apenas uma oportunidade.
Kafka tem essa posição única, onde é muito usado no estado operacional, mas também como uma forma de inserir dados no estado analítico. Streams multimodais que falam a linguagem de ambos os lados da organização aproximam os lados analítico e operacional. A princípio, os streams se materializarão como tabelas, mas mais tarde o Tableflow terá a capacidade de materializar tabelas Iceberg como tópicos Kafka. Verdadeira comunicação bidirecional entre as propriedades operacionais e analíticas.
Isso torna a reutilização trivialmente possível porque o caminho de menor atrito é simplesmente ativar o Iceberg em um tópico Kafka ou ativar o Kafka em uma tabela Iceberg. Sem ETL, sem duplicação de dados, mas com uma dualidade fluxo/tabela multimodal bidirecional.
Comments