Como a Junto Seguros utilizou o Iceberg com o Amazon Athena para simplificar o gerenciamento do Data Lake

Por Pedro Andriow, coordenador da área de Infraestrutura e Gestão de Dados na Junto Seguros e Eduardo Pereira, Arquiteto de Soluções na AWS.

Introdução

A Junto Seguros, com mais de três décadas de atuação no mercado, é uma empresa especializada em soluções inovadoras em seguros para empresas. Mantendo-se atenta às evoluções tecnológicas e estruturais, o conhecimento de mercado e solidez de negócios são alguns dos diferenciais da seguradora. Entre as suas principais ofertas, estão produtos como Seguro Garantia e Fiança Locatícia, que atendem a um leque de necessidades empresariais, cobrindo desde aluguéis e construção até a gestão de fluxo de caixa em processos judiciais e administrativos.

Com uma base de mais de 80 mil empresas atendidas, a Junto Seguros figura como uma das referências nacionais em inovação, alcançando a 14ª posição na lista das 100 empresas mais inovadoras do prêmio IT Forum, além de estar entre as cinco mais inovadoras do setor de seguros, segundo o Prêmio Valor Inovação 2024. Essas conquistas refletem o investimento contínuo da seguradora em inovação voltada para ganhos de eficiência, agilidade e impacto positivo nos clientes, parceiros e colaboradores.

Desafios

Para a Junto Seguros, a capacidade de tomar decisões informadas e rápidas é um diferencial competitivo no mercado de seguros, especialmente no segmento de seguro garantia. A crescente quantidade de dados gerada pelas operações diárias, considerando o aumento de emissão de documentos da casa de 100 mil documentos em 2019 para mais de 230 mil documentos em 2023, com isso também tiveram o aumento de todos os outros dados relativos à emissão dos documentos, como informações de clientes, sinistros e dados financeiros. Este aumento exponencial pode se tornar um desafio sem a infraestrutura e arquitetura adequada para o processamento de todas estas informações.

Com esse contexto, a Junto Seguros estabeleceu como estratégia a criação de um Data Lake, um repositório centralizado que permite que a empresa armazene e organize grandes volumes de dados de diferentes fontes, tanto estruturados (como planilhas e bancos de dados) quanto não estruturados (como e-mails e documentos digitais). Dessa forma, as equipes podem acessar informações relevantes de maneira rápida e eficiente, garantindo que todos os setores da empresa estejam trabalhando com dados precisos e atualizados.

A capacidade de processar grandes volumes de dados oferece uma vantagem estratégica significativa. Em um setor onde a agilidade é fundamental, o Data Lake permite que a empresa reaja rapidamente às mudanças no mercado, tome decisões baseadas em dados atualizados e mantenha a conformidade regulatória com mais facilidade. Além disso, a escalabilidade do Data Lake significa que, à medida que a empresa cresce, sua infraestrutura de dados pode crescer junto, suportando volumes ainda maiores de informações sem a necessidade de reconstruir sistemas do zero. Em suma, para a Junto, investir em um Data Lake não é apenas uma questão de organização, mas sim um fator estratégico, para garantir a longevidade e o sucesso da empresa no competitivo mercado de seguros garantia.

Modelagem de exemplo

Como exemplo, temos um modelo simplificado, que nos permitirá identificar o comportamento típico da arquitetura medalhão, com a camada ouro representada em uma modelagem estrela, utilizando fatos e dimensões com o objetivo de facilitar a construção das visualizações. O exemplo seguirá a premissa da camada bronze sendo uma cópia fiel do banco de dados do sistema contendo informações dos usuários como: altura, peso, sexo, idade, local de residência entre outros. A camada ouro deverá habilitar a criação de visões relacionadas ao IMC dos usuários na ferramenta de visualização, podendo ter aberturas por faixas de idade, sexo e estado.

Devido à essa necessidade da camada ouro, a camada prata será construída como uma View com origem na camada bronze filtrando apenas as colunas necessárias para a construção da camada ouro. Segue abaixo a modelagem do exemplo:

Arquitetura proposta

Além das camadas bronze, prata e ouro relacionadas à arquitetura medalhão, foi adicionada uma camada precedente LOG, que recebe os dados no formato de mensagem do Kafka.

A camada de aquisição dos dados possui como fonte os diversos bancos de dados que a companhia possui, sendo os principais o SQL Server, o PostgreSQL e o MongoDB. Todos eles possuem o CDC (Change Data Capture) ativo, o que habilita utilizar o conector Debezium para disponibilizar os logs de alteração para o Kafka.
Para a construção da camada LOG é utilizado o conector do Kafka S3Sink, que se comporta como um buffer, armazenando vários registros para salvar um único arquivo no bucket S3 utilizando o SchemaRegistry do próprio Kafka para salvar os dados no formato parquet, ajudando assim a controlar problemas gerados para gestão e acesso de arquivos pequenos em grande quantidade.
Na camada bronze, ficam armazenados os dados brutos exatamente como são recebidos das diversas fontes, sem qualquer tipo de processamento ou filtragem. Isso permite que se tenha acesso à versão original dos dados sempre que necessário, preservando a integridade das informações.
Na camada prata, os dados passam por uma etapa de limpeza e transformação, tornando-os mais organizados e prontos para análises mais detalhadas. Aqui, inconsistências são corrigidas e informações são enriquecidas para facilitar o uso.
Por fim, na camada ouro, encontramos os dados totalmente processados e prontos para serem consumidos pelos sistemas de inteligência de negócios, dashboards ou relatórios gerenciais.

Com a necessidade de construir um ambiente escalável, a primeira pipeline do Data Lake foi baseada em clusters de Amazon EMR (Elastic Map Reduce) para tratar os dados utilizando o Apache Spark, com arquivos no formato parquet, utilizando a seguinte arquitetura:

Esta arquitetura é adequada para o processamento de grandes volumes de dados, porém, no caso da Junto Seguros, ela veio acompanhada de alguns desafios:

Dificuldade de atualização de dados: Este processo requer clusters com mais memória e um elevado número de leituras e reescritas no serviço de armazenamento que implicam maiores custos.
Volume de dados processados: mesmo que as operações envolvam apenas parte dos dados, seja uma consulta ou atualização de um atributo, há um grande número de leituras dos dados.
Não há a possibilidade de múltiplas escritas simultâneas: como a estrutura de armazenamento tem como elemento mais granular os arquivos em formato bruto, não é possível ter transações do tipo ACID para registros, linhas, ou itens específicos.
Otimizar o custo do cluster com resiliência: O Amazon EMR tem como capacidade a substituição de nodes caso estes apresentem alguma falha, ou tornem-se indisponíveis, caso utilizem instâncias spot. Para tirar proveito desta característica é necessário que as aplicações estejam preparadas de modo que as informações não sejam perdidas durante o processamento, sendo capazes de continuar do ponto onde houve a interrupção.

Com este contexto, a Junto Seguros alterou a arquitetura do projeto, usando ferramentas que permitam criar um data lake adequado às suas necessidades. A alternativa que se mostrou mais eficiente foi a utilização do Apache Iceberg junto ao Amazon Athena com o Amazon Managed Workflows for Apache Airflow (Amazon MWAA) para orquestrar a movimentação dos dados entre as camadas do Data Lake.

O Apache Iceberg é um formato de tabela de dados distribuído e de código aberto que ajuda a simplificar o processamento de grandes conjuntos de dados em data lakes.

O Iceberg oferece integrações fáceis com estruturas de processamento de dados amplamente utilizadas, como Apache Spark, Apache Flink, Apache Hive e Presto. Usando o Iceberg, é possível criar um data lake transacional, onde não apenas os dados são armazenados em grande escala, mas também é oferecido suporte a operações transacionais, ou seja, seguem as características conhecidas como ACID (atomicidade, consistência, isolamento e durabilidade), além de permitir acompanhar as mudanças em seu conteúdo e estrutura ao longo do tempo (time-travel e schema evolution)

Aqui está um resumo dos principais benefícios de usar o Apache Iceberg para data lakes transacionais:

- - Familiaridade com SQL: O Apache Iceberg permite que qualquer pessoa que conheça SQL crie e gerencie data lakes, sem precisar aprender uma nova linguagem.

- - Consistência: O Iceberg garante a consistência de dados, para que todos os usuários visualizem os mesmos dados ao ler e gravar.

- - Evolução do esquema: O Iceberg permite facilmente adicionar, renomear ou remover colunas de tabelas de dados, sem comprometer os dados subjacentes.

- - Versionamento: O Iceberg oferece suporte para versionamento de dados, permitindo aos usuários acessarem e consultar versões históricas dos dados e analisar alterações.

- - Suporte multiplataforma: O Iceberg é compatível com diversos sistemas de armazenamento e mecanismos de consulta, como Apache Spark, Apache Hive e Presto.

- - Processamento incremental: O Iceberg permite processamento incremental, permitindo processar apenas os dados que foram alterados desde a última execução, melhorando a eficiência e o desempenho do processamento de dados.

Para mais informações sobre o Apache iceberg, visite o link.

A evolução desta arquitetura trouxe os seguintes benefícios em relação ao cenário anterior.

Transações ACID: Com a adoção do Apache Iceberg é possível ter acesso a transações ACID no Data Lake da companhia, pois o Apache Iceberg gerencia de forma autônoma esse tipo de transação.

Possibilidade de operações de Upsert (update e insert): O Apache Iceberg permite ações de upsert de forma simplificada, utilizando SQL, sem a necessidade de carregar todo o dado em memória para atualização de informações, como no exemplo abaixo.

Redução de custos: Utilizando o Amazon Athena aliado ao Apache Iceberg, que armazena os dados em arquivos no formato parquet, permitindo consultas e operações em colunas específicas, ou seja, somente os dados referenciados são acessados.
No modelo anterior era utilizado o Amazon EMR com uma configuração de 1 nó primário e 3 nós core da instância m5.8xlarge com 3 horas de execução diária, gerando um custo mensal de $98,55, na região de S.Paulo (sa-east-1). Utilizando o Amazon Athena com o Iceberg e uma média de 10.000 consultas diárias, processando uma média de 10MB por consulta, resulta um custo mensal de $26,11, ou seja, uma redução de 73,5%.

Possibilidade de navegação temporal nos arquivos: Como o Apache Iceberg fornece a funcionalidade de time-travel, é possível verificar como o dado estava em um determinado momento do tempo, sem a necessidade de uma estrutura complexa para armazenamento.
Um exemplo de utilização prática desta funcionalidade é o caso em que um cliente emitiu uma apólice que gerou sinistro. Com a funcionalidade de time-travel é possível voltarmos nos dados e verificarmos como estavam as variáveis deste cliente na data em que a apólice foi gerada, permitindo treinar nossos modelos de inteligência artificial de análise de risco com dados mais precisos.

Redução no tempo de manutenção: Com a utilização do Amazon Athena, foi reduzida a alocação do time para tarefas de monitoramento manutenção do cluster, permitindo-os concentrar seu tempo em tarefas mais importantes para o negócio, como aquisição de novas fontes de dados em processos para garantia de qualidade dos dados do Data Lake.

Otimização na velocidade de processamento: Como o Apache Iceberg indexa os dados armazenados, e o Amazon Athena só faz a leitura das colunas solicitadas, o tempo médio de busca de informações foi reduzido em aproximadamente 35% em relação a arquitetura anterior na qual era necessário trazer todo o dado para a memória do cluster para realizar as consultas. Considerando um contexto com mais de 1000 tabelas e uma média de mais de 5000 registros novos por tabela diariamente, o tempo de processamento diário na camada bronze foi reduzido de cerca de 3 horas para uma média de 1 hora e 50 minutos.

Exemplos de código

A Junto Seguros utiliza uma convenção de nomenclatura padrão para os tópicos do Debezium com CDC. O nome do tópico indica a origem do tópico (Debezium com CDC), o banco de dados monitorado, o tipo de snapshot configurado e a data de criação do tópico. Essa padronização tem o objetivo de facilitar a organização e o gerenciamento dos tópicos, mas pode ser ajustada conforme as necessidades específicas de cada caso.

Para essa operação também é criado um usuário “debezium” no banco de dados que terá o CDC ativo, com permissões necessárias.

{"name": "debezium-cdc-DATABASENAME-initial-20240511",
"config":{
"connector.class": "io.debezium.connector.sqlserver.SqlServerConnector",
"incremental.snapshot.chunk.size": "50000",
"tasks.max": "1",
"schema.history.internal.consumer.max.poll.records": "50000",
"schema.history.internal.consumer.sasl.jaas.config": "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"USER\" password=\"PASSWORD\";",
"topic.prefix": "cdc.DATABASENAME",
"decimal.handling.mode": "double",
"schema.history.internal.kafka.topic": "cdc-schema.history.DATABASENAME-initial-20240511",
"schema.history.internal.producer.security.protocol": "SASL_PLAINTEXT",
"signal.data.collection": "DATABASENAME.dbo.dbz_signal",
"snapshot.fetch.size": "50000",
"schema.history.internal.producer.sasl.mechanism": "PLAIN",
"database.encrypt": "true",
"database.user": "debezium",
"database.names": "DATABASENAME",
"time.precision.mode": "connect",
"schema.history.internal.kafka.bootstrap.servers": "kafka-1:PORT,kafka-2:PORT,kafka-3:PORT,kafka-4:PORT,kafka-5:PORT",
"snapshot.isolation.mode": "read_committed",
"database.port": "1234",
"schema.history.internal.kafka.recovery.poll.interval.ms": "10000",
"database.hostname": "rds-DATABASENAME.DOMAIN.com",
"database.password": "DATABASEPASSWORD",
"schema.history.internal.producer.sasl.jaas.config": "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"USER\" password=\"PASSWORD\";",
"schema.history.internal.consumer.sasl.mechanism": "PLAIN",
"database.trustServerCertificate": "true",
"table.include.list": "dbo.user,dbo.table2,dbo.table3",
"snapshot.mode": "initial",
"schema.history.internal.consumer.security.protocol": "SASL_PLAINTEXT"
}
}

Abaixo temos um exemplo do conteúdo do pacote inserido no Kafka pelo Debezium. Esse é um caso de uma inserção de um novo registro, como o campo before é null, podemos saber que o registro não existia anteriormente. Pelo S3sink o pacote contendo essa informação é transferido para o bucket da camada LOG no S3, onde podemos usar a external table para abrir o conteúdo utilizando o Athena.

Siga o link para mais exemplos usando o MSK Connect.

{
"before":null,
"after": {
"id":"1",
"nome":"New data",
"peso":”75”,
"altura": “179”,
"idade": “30”,
"sexo": "New Value",
"cidade": "New Value",
"estado": "New Value",
"endereco": "New Value",
"documento": "New Value",
"telefone": "New Value",
"email": "New Value"
},

"source": {
...
"snapshot":"incremental"
},
"op":"r",
"ts_ms":"1620393591654",
"ts_us":"1620393591654547",
"ts_ns":"1620393591654547920",
"transaction":null
}

Para configuração do conector do Debezium com o SQL Server, vá para o link.

Para que seja possível executar consultas usando o Amazon Athena sobre os dados da camada LOG, é necessário registrar a estrutura de dados desta camada como uma tabela do AWS Glue Data Catalog:

CREATE EXTERNAL TABLE log.example_user(
`before` struct<
id:int,
nome: string,
peso: double,
altura: double,
idade: int,
sexo: string,
cidade: string,
estado: string,
endereco: string,
documento: string,
telefone: string,
email: string >,
`after` struct<
id:int,
nome: string,
peso: double,
altura: double,
idade: int,
sexo: string,
cidade: string,
estado: string,
endereco: string,
documento: string,
telefone: string,
email: string>,
`source` struct<
version:string,
connector:string,
name:string,
ts_ms:bigint,
snapshot:string,
db:string,
sequence:string,
schema:string,
table:string,
change_lsn:string,
commit_lsn:string >,
`op` string,
`ts_ms` bigint,
`transaction` struct<
id:string,
total_order:bigint,
data_collection_order:bigint >
)

PARTITIONED BY (year string, month string, day string)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION 's3://bucket-log-example/kafka/user-example/'
TBLPROPERTIES (
'parquet.compression'='SNAPPY'
);

Após criar a tabela com a instrução acima, é necessário carregar as partições existentes no bucket to S3 que foi especificado. A forma mais simples de fazer isso é através do comando MSCK REPAIR TABLE log.example_user.

Com a tabela da camada LOG mapeada, é necessário criar uma tabela temporária apenas com os últimos estados coletados do tópico Kafka.

Como no CDC, são retornados os dados de todas as operações que geram mudanças nos dados na ordem que elas ocorrem, o evento mais recente representa o estado corrente do dado na origem, desta forma, podemos considerar apenas este último evento para atualizar os dados no Data Lake, com o objetivo de reduzir a quantidade de operações realizadas.

Para criar essa tabela temporária apenas com os últimos estados dos registros, pode ser utilizado o seguinte script:

CREATE TABLE log.temp_user_example
WITH (format = 'PARQUET', write_compression = 'SNAPPY') AS
SELECT DISTINCT
x.row_data.*
, x.op
FROM (
SELECT COALESCE(after, before) AS row_data, source, op
FROM log.user
JOIN (
SELECT c.tupla.id,
MAX(c.source.commit_lsn) AS max_commit_lsn,
COALESCE(MAX(c.source.change_lsn), '0') AS max_change_lsn
FROM (
SELECT COALESCE(after, before) AS tupla, source, op
FROM log.user
) c
GROUP BY c.tupla.id
) grouped_cdc ON source.commit_lsn = grouped_cdc.max_commit_lsn
AND COALESCE(source.change_lsn, '0') = grouped_cdc.max_change_lsn
AND COALESCE(after.id, before.id) = grouped_cdc.id
) x ORDER BY "id"

Com isso feito, temos a camada LOG pronta com os eventos devidamente filtrados, podemos começar a construção da camada bronze. O primeiro passo é criar a tabela na camada bronze:

CREATE TABLE bronze.user-example(
id:int,
nome: string,
peso: double,
altura: double,
idade: int,
sexo: string,
cidade: string,
estado: string,
endereco string,
documento string,
telefone string,
email string)
LOCATION 's3://example-bucket-bronze/database/users-example'
TBLPROPERTIES (
'table_type'='iceberg',
'vacuum_max_snapshot_age_seconds'='172800',
'write_compression'='SNAPPY',
'format'='PARQUET',
'optimize_rewrite_delete_file_threshold'='2',
'optimize_rewrite_data_file_threshold'='10',
'vacuum_min_snapshots_to_keep'='1'
);

Considerando o DDL acima da tabela bronze.user-example, foram utilizados os seguintes parâmetros:

“table_type=’iceberg'” define que essa é uma tabela Iceberg.
“vacuum_max_snapshot_age_seconds=’172800′” especifica que os snapshots da tabela mais antigos que 48 horas (172.800 segundos) podem ser removidos durante a compactação (vacuum) da tabela.
“write_compression=’SNAPPY'” define que os dados serão armazenados em formato Parquet com compressão Snappy. Isso reduz o tamanho dos arquivos, melhorando a eficiência de armazenamento.
“format=’PARQUET'” indica que a tabela usará o formato de arquivo Parquet, um formato colunar otimizado para desempenho e compressão.
“optimize_rewrite_delete_file_threshold=’2′” determina o número mínimo de arquivos de exclusão (delete files) que precisam existir antes que a tabela seja reescrita durante o processo de otimização. Isso significa que se houver 2 ou mais arquivos de exclusão, o Iceberg irá reescrevê-los em um único arquivo, tornando a tabela mais compacta e eficiente.
“optimize_rewrite_data_file_threshold=’10′” define o número mínimo de arquivos de dados (data files) que precisam existir antes que a tabela seja reescrita durante a otimização. Assim, se houver 10 ou mais arquivos de dados, o Iceberg irá reescrevê-los em um menor número de arquivos, também melhorando a compactação e a eficiência da tabela.
Finalmente, o “vacuum_min_snapshots_to_keep=’1′” garante que pelo menos um snapshot da tabela seja mantido, mesmo após a compactação, preservando o histórico de alterações.

Para boas praticas de otimização de workloads Iceberg, vá para o link.

Para fazer a operação de Upsert utilizamos a função de MERGE do Amazon Athena com o Iceberg, da seguinte maneira:

MERGE INTO bronze.user-example destino
USING (SELECT * FROM log.temp_user_example) origem
ON destino."id" = origem."id"
WHEN MATCHED AND op != 'd' THEN UPDATE SET
"id"        = origem."id",
"nome"      = origem."nome",
"peso"      = origem."peso",
"altura"    = origem."altura",
"idade"     = origem."idade",
"sexo"      = origem."sexo",
"cidade"    = origem."cidade",
"estado"    = origem."estado",
"endereco"  = origem."endereco",
"documento" = origem."documento",
"telefone"  = origem."telefone",
"email"     = origem."email"
WHEN NOT MATCHED AND op != 'd' THEN INSERT (
"id", "nome", "peso", "altura", "idade", "sexo", "cidade", "estado", "endereco", "documento", "telefone", "email"
) VALUES (
origem."id", origem."nome", origem."peso", origem."altura", origem."idade", origem."sexo", origem."cidade", origem."estado", origem."endereco", origem."documento", origem."telefone", origem."email"
);

Nesse caso quando encontra um determinado ID na base da camada bronze, ele atualiza todos os campos e quando não encontra, cria um registro na camada bronze.

Essa estratégia de Upsert não comtempla as operações de exclusão. As operações de exclusões são identificadas na mensagem do CDC no Kafka através do campo “op”, que nesse caso recebe o caracter “d” como indicação da exclusão de um determinado registro.

Para operacionalizar a exclusão na camada bronze deve ser executado um segundo passo com o script que trate apenas das exclusões:

MERGE INTO bronze.user-example destino
USING (SELECT * FROM log.temp_user_example) origem
ON destino."id" = origem."id"
WHEN MATCHED AND op = 'd' THEN DELETE

Com a camada bronze finalizada, é possível começar a construção das demais camadas do data lake, como por exemplo a prata sendo criada com views:

CREATE OR REPLACE VIEW "prata.user-example" AS
SELECT
id,
nome,
peso,
altura,
idade,
sexo,
estado)
FROM bronze.user-example

Trabalhar com views na camada prata, aliada ao formato Iceberg, pode proporcionar otimização de custos ao construir a camada ouro, pois só serão carregados os dados nas colunas utilizadas nesta camada.

Resultados

Com a implementação de uma arquitetura serverless baseada no Amazon Athena e Apache Iceberg, a Junto Seguros eliminou a necessidade de monitoramento e manutenção contínua do ambiente de Data Lake, o que trouxe maior agilidade na gestão de dados. A mudança para a estrutura serverless também resultou em uma redução de 35% no tempo de processamento e uma economia de 73,5% nos custos, quando comparada ao uso de um cluster dedicado.

Sob o aspecto técnico, a migração para essa arquitetura reduziu significativamente a complexidade do código necessário para construir o Data Lake. O que antes demandava processos manuais e códigos longos e complexos, passou a ser gerido automaticamente pelo Apache Iceberg, permitindo o desenvolvimento de códigos mais simples e enxutos, utilizando apenas SQL. Essa simplificação tem impacto direto na produtividade da empresa, permitindo que a equipe concentre esforços em tarefas de maior valor agregado.

A confiabilidade do sistema também foi aprimorada ao implementar um orquestrador, eliminando completamente as falhas nos processamentos realizados no Data Lake.

Como próximos passos, a Junto Seguros planeja criar a uma camada de acesso simplificada aos dados processados e armazenados na camada ouro. Isso permitirá que os dados calculados no ambiente do Data Lake sejam acessíveis em canais de ampla visualização, como a plataforma do corretor de seguros. Para viabilizar essa expansão, a companhia considera implementar o Amazon Redshift permitindo a replicação da camada ouro com a escala necessária para atender às demandas operacionais da Junto Seguros.

Autores

	Pedro Andriow é coordenador da área de Infraestrutura e Gestão de Dados na Junto Seguros. Com formação em Engenharia da Computação pela Universidade Positivo e pós-graduações em Big Data pela Universidade da Califórnia e em Liderança e Gestão de pessoas pela FIA-SP. Com mais de 15 anos de experiência, tem uma trajetória sólida nas áreas de Engenharia e Ciência de Dados.
	Eduardo Pereira é Arquiteto de Soluções. Atua ajudando clientes Enterprise, na indústria de FSI, durante a sua jornada na nuvem da AWS. Tem grande interesse na área de Analytics, observabilidade e serverless.

Revisores

Edir Santana é Arquiteto de Soluções. Atua com clientes Enterprise de diferentes indústrias em suas jornadas de migração e adoção de serviços em nuvem na AWS em diversas áreas, principalmente em Dados e Analytics.

Lucas Rehem de Azevedo é Arquiteto de Soluções do time de Enterprise para Setor Financeiro. Possui mais de 14 anos de experiência na área de tecnologia e atua apoiando os clientes nas decisões em torno de computação na nuvem. Especialista em Analytics, hoje atua como Arquiteto de Soluções, apoiando os clientes nos seus desafios, buscando as melhores soluções para as suas necessidades.

O blog da AWS