21P by xguru 3달전 | favorite | 댓글 2개
  • 지난 3년 동안 Notion의 데이터는 사용자 및 콘텐츠 증가로 인해 10배 증가했으며, 6~12개월마다 2배씩 증가함
  • 최근 Notion AI 기능을 비롯한 주요 제품 및 분석 사용 사례에 대한 데이터 요구 사항을 충족하면서 이러한 급격한 성장을 관리하기 위해 Notion의 데이터 레이크를 구축하고 확장

Notion의 데이터 모델과 성장

  • Notion에서 보이는 모든 것은 "블록" 엔터티로 모델링되어 Postgres 데이터베이스에 일관된 구조, 스키마 및 관련 메타데이터로 저장됨
  • 이 블록 데이터는 6~12개월마다 2배씩 증가하여 2021년 초에는 200억 개 이상의 블록 행이 있었고, 현재는 2,000억 개 이상의 블록이 있음

2021년 Notion의 데이터 웨어하우스 아키텍처

  • Fivetran을 사용하여 Postgres WAL에서 Snowflake로 데이터를 수집하는 간단한 ELT 파이프라인으로 전용 데이터 인프라를 시작함
  • 480개의 원시 Snowflake 테이블에 쓰기 위해 480개의 샤드에 대해 매시간 실행되는 480개의 커넥터를 설정하고, 이 테이블을 분석, 보고 및 기계 학습 사용 사례를 위한 하나의 큰 테이블로 병합함

스케일링시의 도전 과제들

  • Postgres 데이터 증가에 따라 여러 문제에 직면함
  • 운영 가능성: 480개의 Fivetran 커넥터 모니터링 및 관리에 대한 오버헤드가 매우 높아짐
  • 속도, 데이터 신선도 및 비용: Notion의 고유한 업데이트 중심 워크로드로 인해 Snowflake로 데이터를 수집하는 속도가 느려지고 비용이 증가함
  • 유스케이스 지원: 데이터 변환 로직이 더 복잡해지고 무거워져 표준 데이터 웨어하우스에서 제공하는 표준 SQL 인터페이스의 기능을 능가함

Notion 인하우스 데이터 레이크 구축 및 확장하기

  • 내부 데이터 레이크의 목표
    • 원시 데이터와 처리된 데이터를 대규모로 저장할 수 있는 데이터 저장소 설립
    • 특히 Notion의 업데이트 중심 블록 데이터에 대해 모든 워크로드에 대해 빠르고 확장 가능하며 운영 가능하고 비용 효율적인 데이터 수집 및 계산 가능
    • AI, 검색 및 비정규화된 데이터가 필요한 기타 제품에 대한 유스케이스 지원
  • Snowflake와 Fivetran을 완전히 대체하거나 엄격한 지연 시간을 요구하는 온라인 사용 사례를 지원하는 것을 의도하지는 않음

데이터 레이크의 하이레벨 디자인

  • Debezium CDC 커넥터를 사용하여 Postgres에서 Kafka로 증분 업데이트된 데이터를 수집한 다음 Apache Hudi를 사용하여 이러한 업데이트를 Kafka에서 S3로 씀
  • 이 원시 데이터를 사용하여 변환, 비정규화 및 보강을 수행한 다음 처리된 데이터를 S3에 다시 저장하거나 다운스트림 시스템에 저장하여 분석 및 보고 요구 사항과 AI, 검색 및 기타 제품 요구 사항을 충족함

디자인 결정

  1. 데이터 저장소 및 레이크 선택: S3를 데이터 저장소 및 레이크로 사용하여 모든 원시 및 처리된 데이터를 저장하고 데이터 웨어하우스 및 기타 제품 대면 데이터 저장소를 다운스트림으로 배치
  2. 처리 엔진 선택: 오픈 소스 프레임워크인 Spark를 주요 데이터 처리 엔진으로 선택
  3. 스냅샷 덤프보다 증분 수집 선호: 정상 작동 중에는 변경된 Postgres 데이터를 증분 수집하여 지속적으로 S3에 적용하고, 드문 경우에는 S3에서 테이블을 부트스트랩하기 위해 전체 Postgres 스냅샷을 한 번 생성
  4. 증분 수집 간소화: Kafka Debezium CDC 커넥터를 사용하여 증분 변경된 Postgres 데이터를 Kafka에 게시하고, Hudi를 사용하여 Kafka에서 S3로 증분 데이터를 수집
  5. 처리 전에 원시 데이터 수집: 단일 진실 소스를 설정하고 전체 데이터 파이프라인에서 디버깅을 단순화하기 위해 온더플라이 처리 없이 원시 Postgres 데이터를 S3에 수집

데이터 레이크 확장 및 운영

  • CDC 커넥터 및 Kafka 설정: Postgres 호스트당 하나의 Debezium CDC 커넥터를 설정하고 AWS EKS 클러스터에 배포
  • Hudi 설정: Apache Hudi Deltastreamer를 사용하여 Kafka 메시지를 사용하고 S3에서 Postgres 테이블의 상태를 복제
  • Spark 데이터 처리 설정: 대부분의 데이터 처리 작업에 PySpark를 활용하고, 트리 순회 및 비정규화와 같은 더 복잡한 작업의 경우 Spark의 우수한 성능을 활용
  • 부트스트랩 설정: Debezium Connector를 설정하여 Postgres 변경 사항을 Kafka로 수집하고, AWS RDS 제공 S3로 내보내기 작업을 사용하여 Postgres 테이블의 최신 스냅샷을 S3에 저장한 다음, Spark 작업을 생성하여 S3에서 해당 데이터를 읽고 Hudi 테이블 형식으로 씀

결과

  • 2022년 봄에 데이터 레이크 인프라 개발을 시작하여 그해 가을에 완료
  • 2022년에 100만 달러 이상의 순 절감 효과가 있었으며 2023년과 2024년에는 비례적으로 더 높은 절감 효과가 발생
  • Postgres에서 S3 및 Snowflake로의 엔드투엔드 수집 시간이 하루 이상에서 작은 테이블의 경우 몇 분, 큰 테이블의 경우 최대 몇 시간으로 단축됨
  • 데이터 레이크를 통해 2023년과 2024년에 Notion AI 기능을 성공적으로 출시할 수 있었음

혹시 위 내용과 관련된 문서나 참조한 문서를 알려주실 수 있으실지요?

제가 헛썼네요 ㅎㅎㅎ
찾았습니다~~~