- Nos últimos 3 anos, os dados da Notion cresceram 10x devido ao aumento de usuários e conteúdo, dobrando a cada 6 a 12 meses
- A Notion construiu e escalou seu data lake para gerenciar esse crescimento acelerado enquanto atendia aos requisitos de dados de casos de uso importantes de produto e análise, incluindo recursos recentes do Notion AI
Modelo de dados e crescimento da Notion
- Tudo o que aparece na Notion é modelado como a entidade "bloco" e armazenado no banco de dados Postgres com uma estrutura, esquema e metadados relacionados consistentes
- Esses dados de blocos dobraram a cada 6 a 12 meses: no início de 2021, havia mais de 20 bilhões de linhas de blocos, e hoje há mais de 200 bilhões de blocos
Arquitetura do data warehouse da Notion em 2021
- A empresa iniciou sua infraestrutura de dados dedicada com um pipeline ELT simples usando o Fivetran para ingerir dados do Postgres WAL para o Snowflake
- Foram configurados 480 conectores, executados a cada hora para 480 shards, para gravar em 480 tabelas brutas no Snowflake, e essas tabelas eram mescladas em uma grande tabela para casos de uso de análise, relatórios e machine learning
Desafios ao escalar
- Com o crescimento dos dados no Postgres, vários problemas surgiram
- Operabilidade: o overhead de monitorar e gerenciar 480 conectores do Fivetran ficou muito alto
- Velocidade, atualização dos dados e custo: devido à carga de trabalho única da Notion, focada em atualizações, a ingestão de dados no Snowflake ficou mais lenta e mais cara
- Suporte a casos de uso: a lógica de transformação de dados ficou mais complexa e pesada, superando as capacidades da interface SQL padrão oferecida por um data warehouse tradicional
Construindo e escalando o data lake interno da Notion
- Objetivos do data lake interno
- Estabelecer um repositório de dados capaz de armazenar dados brutos e processados em larga escala
- Possibilitar ingestão e processamento de dados rápidos, escaláveis, operáveis e com boa eficiência de custo para todas as cargas de trabalho, especialmente para os dados de blocos da Notion, centrados em atualizações
- Dar suporte a casos de uso para AI, busca e outros produtos que exigem dados desnormalizados
- Não havia a intenção de substituir completamente o Snowflake e o Fivetran nem de dar suporte a casos de uso online que exigem latência rígida
Design de alto nível do data lake
- Usando conectores CDC do Debezium, a empresa ingeriu dados atualizados incrementalmente do Postgres para o Kafka e depois gravou essas atualizações do Kafka no S3 com Apache Hudi
- Esses dados brutos foram usados para realizar transformações, desnormalização e enriquecimento, e depois os dados processados foram salvos novamente no S3 ou em sistemas downstream para atender às necessidades de análise e relatórios, além de AI, busca e outros requisitos de produto
Decisões de design
- Escolha do armazenamento de dados e do lake: usar o S3 como armazenamento e lake de dados para guardar todos os dados brutos e processados, deixando o data warehouse e outros armazenamentos de dados voltados a produtos como camadas downstream
- Escolha do motor de processamento: selecionar o Spark, um framework open source, como principal motor de processamento de dados
- Preferência por ingestão incremental em vez de dumps de snapshot: durante a operação normal, ingerir incrementalmente os dados alterados do Postgres e aplicá-los continuamente ao S3; em casos raros, gerar um snapshot completo do Postgres apenas uma vez para fazer o bootstrap das tabelas no S3
- Simplificação da ingestão incremental: usar conectores CDC Kafka Debezium para publicar no Kafka os dados alterados incrementalmente do Postgres e usar o Hudi para ingerir os dados incrementais do Kafka para o S3
- Ingestão de dados brutos antes do processamento: ingerir os dados brutos do Postgres no S3 sem processamento on-the-fly para estabelecer uma única fonte da verdade e simplificar o debugging em todo o pipeline de dados
Escalando e operando o data lake
- Configuração dos conectores CDC e do Kafka: foi configurado um conector CDC Debezium por host Postgres e implantado em um cluster AWS EKS
- Configuração do Hudi: o Apache Hudi Deltastreamer foi usado para consumir mensagens do Kafka e replicar no S3 o estado das tabelas do Postgres
- Configuração do processamento de dados com Spark: o PySpark foi utilizado na maioria dos trabalhos de processamento de dados e, para tarefas mais complexas, como travessia de árvores e desnormalização, foi aproveitado o forte desempenho do Spark
- Configuração de bootstrap: o conector Debezium foi configurado para coletar alterações do Postgres para o Kafka, depois um job de exportação para o S3 fornecido pelo AWS RDS foi usado para salvar no S3 o snapshot mais recente das tabelas do Postgres, e então foi criado um job Spark para ler esses dados do S3 e gravá-los no formato de tabela Hudi
Resultados
- O desenvolvimento da infraestrutura do data lake começou na primavera de 2022 e foi concluído no outono do mesmo ano
- Houve uma economia líquida de mais de US$ 1 milhão em 2022, com economias proporcionalmente maiores em 2023 e 2024
- O tempo de ingestão end-to-end do Postgres para S3 e Snowflake caiu de mais de um dia para alguns minutos em tabelas pequenas e até algumas horas em tabelas grandes
- O data lake permitiu lançar com sucesso os recursos do Notion AI em 2023 e 2024
2 comentários
Você poderia informar quais documentos ou referências relacionados ao conteúdo acima foram usados?
Eu escrevi besteira hahaha
Encontrei~~~