Decidir a arquitetura para processamento dos dados é mais um caso no mundo tech onde não há bala de prata. A escolha entre Kappa e Lambda pode partir de duas questões, uma acerca da origem e outra do destino:
- A fonte dos dados é puramente um stream? Ou seja, o único meio de recuperar dados históricos é conectando ao stream?
- No destino, o dado proveniente do stream deve se unir a dados do mesmo contexto com outra fonte?
Respondidas as perguntas fica mais clara a decisão, sendo a Kappa a mais ligada aos “streams puros”, que não se mostra necessidade de obter dados históricos, nem se deve importar com dados pre-existentes na tabelas.
Um outro meio de se pensar arquitetura quando trabalhando em streaming, é observando o desenho dado para a organização do seu destino, a arquitetura de dados. Partindo dos conceitos da Databricks de Medallion Architecture, podem se criar cenários em que apenas as três camadas Bronze, Silver e Gold não são suficientes. Isso se dá pois além de pensar o lakehouse como um aliado à governança, devemos levar em conta a importância da separação de responsabilidade de cada stream, possibilitando maior controle da configuração computacional e facilitando manutenções.
Exemplo de arquitetura
Tratando de um contexto muito semelhante a um que tive experiência, no qual streams tratam dados vindos do Kafka e formatados em Avro, na tabela seguinte exemplifico uma arquitetura pensada em divisão de responsabilidade e controle de acesso:
| Ordem | Origem | Responsabilidade | Output mode | Camada/Destino | Tipo de maquina |
|---|---|---|---|---|---|
| 1 | Stream Kafka | Leitura do kafka e armazenamento de dados brutos | Append | Bronze I | Priorização de memória |
| 2 | Stream 1 | Tratamento de schema avro | Append | Bronze II | Priorização de memória |
| 3 | Stream 2 | Correções de schema e schema enforcement | Merge | Silver I | Priorização de CPU |
| 4 | Stream 3 | Mascaramento / PII | Merge | Silver II | Priorização de CPU |
| * | Histórico | Restauração de dados históricos e união do stream (processo de início ou recuperação) | Merge | Silver I & II | * |
Tal escolha de arquitetura nos faz pensar sobre diversos trade-offs, como a replicação de dados, pois temos a mesma informação sendo escrita quatro vezes no data lake, sendo um ponto negativo para os custos de armazenamento e processamento; por um outro lado temos meios para facilitar a reprodução de cada sub-camada, facilitando manutenções. Essa separação pode ser ideal para a governança de dados, em que se permita o acesso público apenas à camada Silver II, um de maior controle na Silver I para a reprodução de tabelas na camada gold sem mascaramento/anonimização; o acesso da camada bronze fica preferivelmente privado.
A complexidade desse cenário de CDC é incrementada quando se trata da recuperação de dados: a dificuldade de unir dados históricos a tabelas em streaming controlando o paralelismo de escrita pode se tornar mais difícil do que construir os próprios streams. As possibilidades apresentadas devem estar sempre muito bem alinhadas à analises de gastos e retorno do investimento.