[번역] 노션이 데이터 레이크를 구축하고 확장한 방법

How Notion build and grew our data lake to keep up with rapid growth

위의 포스트를 번역하고 정리했습니다.

 

노션의 데이터 모델과 성장

노션에서 볼 수 있는 모든 텍스트, 이미지, Headings, 리스트, 데이터베이스 , 페이지 등등 프론트엔드에서의 표현과 작동 방식은 다를지라도 모두 "block" entity 로써 백엔드에서 모델되었습니다.

그리고 이 데이터들은 Postgres 데이터베이스에 저장되어있죠.

(참고, 노션의 데이터 모델 : The data model behind Notion's flexibility) 

노션의 모든 항목들은 block입니다. 이 블록들은 어마어마하게 많은 데이터를 만들죠.

 

이런 모든 블록 데이터는 6~12개월 사이에 2배씩 데이터가 늘어났으며 3년사이에 10배 증가했습니다.

2021년부터 200억개의 block row가 Postgres에 저장되었고, 현재는 2000억개 이상입니다.

we’ve strategically expanded our database infrastructure from one Postgres instance to a more complex sharded architecture.

We began in 2021 by horizontally sharding our Postgres database into 32 physical instances, each comprising 15 logical shards, and continued in 2023 by increasing the number of physical instances to 96, with five logical shards per instance.

 

Notion의 Postgres 인스턴스 및 샤딩 변경 점

 

 

노션의 데이터 웨어하우스 아키텍처 2021

Fivetran을 사용하여 Postgres WAL에서 Snowflake로 데이터를 수집하는 간단한 ELT 파이프라인으로 전용 데이터 인프라를 시작했다고 합니다.

 

Scaling Challenges

운영

480개의 Fivetran connector를 관리하고 모니터링 하는 것에 오버헤드가 있었다고 합니다.

또한, Postgres의 re-shariding, upgrade 그리고 유지보수 기간에도 re-sync를 해줘야하여 그런 작업들은 극단적으로 높고 중요한 on-call 업무 부담을 팀 멤버들에게 주었죠.

 

속도, 데이터의 최신성 그리고 가격

Notion의 유니크한 update-heavy workload 때문에 Snowflake에 데이터를 수집하는 과정은 더 느려지고 비싸졌습니다.

유저가 새로운 데이터를 생성하는것보다 기존의 문서(text, heading, 제목, bullet list, 데이터베이스) 를 업데이트 하는 작업이 많아졌습니다. 

이런 변경은 block data를 update-heavy 한 workload로 만들었습니다. (Notion 유저의 upsert중 90%가 update였습니다.)

Snowflake를 포함한 대부분의 데이터 웨어하우스는 insert-heavy workload에 최적화 되어 있었어서 최적화에 Challenge가 있었습니다.

 

Use-case support

Data transformation 로직은 점점 더 복잡하고 무거워졌고, 기존의 데이터 웨어하우스에서 제공하는 표준 SQL 인터페이스의 기능을 넘어섰습니다.

한 가지 중요한 사례는 AI 및 검색에 관련된 Notion의 블록데이터에 대한 비정규화된 보기를 구성하는것입니다.

예를 들어 권한 데이터는 올바른 사용자만 접근이 가능하게 되는데 이 권한은 연결된 Postgres에 저장되지 않고 값비싼 트리 순회 계산을 통해서 매번 구성됩니다.

Permission 데이터를 만들기 위해서 각 블록은 모든 ancestor tree를 순회 해야 합니다.

예를 들면 위의 구성에서 block_1, block_2 그리고 block_3은 parent로 부터 상속받은 권한을 가지고 있습니다.

이런 블록 권한을 제공하기 우리가 구성한 트리의 root까지 순회를 해야합니다.

수천억개의 블록을 가진 ancestor와 수백의 depth를 가진 구조에서는 이런 계산은 상당히 비싸고 Snowflake에 대해서 timeout을 발생시키게 됩니다.

 

Notion의 in-house data lake를 만들고 scaling 하기

in-house datalake 구축의 목표는 아래와 같습니다.

1. raw데이터와 processed 데이터 모두 저장하고 scale 할 수 있는 data 저장소 만들기

2. 빠르고, Scalable하고, Operable하고, 비용 효율적인 data ingestion 그리고 Notion의 update-heavy block data와 같은 workload를 지원할 수 있는 computation을 가능하게 한다.

3. 비정규화된 데이터가 필요한 AI, 검색, 그리고 다른 product를 가능하게 한다.

 

다만, 이 과정에서 의도하지 않은 작업을 명확히 하는것도 중요합니다.

 

1. Snowflake를 완전히 대체하는것은 하지 않습니다.

Notion팀은 대부분의 삽입이 많고 대규모 비정규화된 트리 순회가 필요하지 않는 워크로드에 Snowflake로부터 운영 및 에코시스템의 용이성을 지속적으로 활용할 생각입니다.

 

2. Fivetran을 완전히 대체하는 것은 하지 않습니다.

Notion팀은 Fivetran의 non-update heavy tables, 작은 데이터 수집, 그리고 다양한 third-party 데이터 소스 및 destination을 계속 활용할 생각입니다.

 

3. Second-level 혹은 더 엄격한 latency를 필요로 하는 Online use-case를 support합니다.

노션의 데이터레이크는 주로 몇분에서 몇시간의 지연시간을 견딜 수 있는 오프라인 워크로드에 중점을 두게됩니다.

 

Notion의 Data lake의 High-level design

2022년부터 아래와 같은 데이터레이크 아키텍처를 사용했다고합니다.

Debezium CDC 커넥터를 이용해서 Postgres에서 Kafka로 업데이트된 데이터를 수집 한 다음

Apache hudi를 사용해서 그 데이터를 Kafka에서 S3로 옮겼습니다.

그런 다음 이 원시 데이터를 사용하여 변환, 비정규화 (e.g. 각 블록에 대한 트리 순회 및 권한 데이터 구성) 을 수행 한 다음 처리된 데이터를 S3에 다시 저장하거나 다운스트림 시스템에 저장하여 분석 및 보고 요구사항은 물론 AI, 검색 등의 요구사항을 충족 할 수 있습니다.

 

디자인 결정 1. 데이터 저장소와 데이터 레이크 선택 - S3 사용

1. S3를 데이터 저장소와 레이크로 결정했습니다.

모든 raw 데이터와 정제된 데이터들을 저장했습니다. 

그리고 데이터 웨어하우스나 제품 대면 데이터 저장소(e.g. elastic search, vector DB)를 다운스트림으로 배치했습니다.

 

그 이유는 아래와 같습니다.

1. Notion의 AWS 테크 스택과 aligned 되어있습니다.

Notion의 데이터베이스는 AWS RDS를 사용하고 이것의 S3로의 export 기능을 통해서 S3에서 테이블을 쉽게 부트스트랩 할 수 있습니다.

 

2. S3는 수많은 데이터를 저장할 능력과 다양한 데이터 processing engine을 낮은 가격에 지원할 수 있는 것을 증명했습니다.

 

디자인 결정 2. Notion의 Processing Engine에 대한 결정

Notion은 Spark를 데이터 processing engine으로 결정했습니다.

네 가지 주요 이득이 있었습니다.

1. Spark는 다양한 built-in 함수가 있고 SQL의 범위를 넘는 위에서 언급한 tree 순회와 block 데이터 비정규화 같은 로직을 할 수 있는 User Defined Functions가 있습니다.

2. 유저 친화적인 PySpark framework를 지원하고 더 높으 성능과 Heavy processing을 제공하는 Scala Spark를 지원합니다.

3. 많은 수의 데이터를 분산된 형태 그리고 극한의 설정으로 처리할 수 있습니다. 즉, over partitioning, data skewness, 그리고 resource allocation을 가능하게 합니다. 이에 따라서, 복잡한 Job들을 더 작은 task 단위로 쪼갤 수 있고 각 task의 자원을 최적화 할수도 있습니다.

4. Spark의 오픈소스 환경은 비용 효율적입니다.

 

디자인 결정 3. Snapshot dump 수집보다 증분 수집에 대한 선호

1. 일반적인 operation 중에서는, 증분 방식으로 수집 (incrementally ingest) 하고 지속적으로 Postgres 데이터를 S3로 전달합니다.

2. 예외의 케이스에서는 Postgres의 전체 데이터 스냅샷을 한번에 S3로 옮깁니다.

 

증분 수집은 새로운 데이터 전달을 낮은 가격와 낮은 deplay를 보장합니다.

전체 데이터 스냅샷은 반면 10시간 소모와 2배정도의 코스트를 요구합니다.

따라서, 자주 하지는 않고 S3에 새로운 테이블을 bootstrap할때만 사용합니다.

 

디자인 결정 4. 증분 수집을 간소화

1. Kafka CDC Connector for postgres -> Kafka

Postgres의 증분 수집 데이터를 kafka에 전달하기 위해서 Kafka Debezium CDC (Change Data Capture) connector를 사용합니다. Kafka의 Scalability, 쉬운 셋업, 현재 인프라와의 긴밀한 통합을 위해 선택했습니다.

2. Hudi for Kafka -> S3

Apache Hudi, Apache Iceberg, Databricks Delta Lake 등을 고려했지만 Notion의 update-heavy workload의 성능 최적화와 Debezium CDC와의 native integration을 위해서 Hudi를 선택했습니다.

Iceberg와 Delta lake는 22년 당시 Notion의 update-heavy workload와는 맞지 않았습니다.

 

디자인 결정 5. 프로세싱 전에 raw data를 수집

Single Source of truth와 전체 data pipeline에 대한 debugging을 간소화 하기 위해서 이런 결정을 했습니다.

 

데이터 레이크 확장 및 운영

1. CDC 커넥터 및 Kafka 설정: Postgres 호스트당 하나의 Debezium CDC 커넥터를 설정하고 AWS EKS 클러스터에 배포했습니다.

2. Hudi 설정: Apache Hudi Deltastreamer를 사용하여 Kafka 메시지를 사용하고 S3에서 Postgres 테이블의 상태를 복제했습니다.

3. Spark 데이터 처리 설정: 대부분의 데이터 처리 작업에 PySpark를 활용하고, 트리 순회 및 비정규화와 같은 더 복잡한 작업의 경우 Spark의 우수한 성능을 활용했습니다.

4. 부트스트랩 설정: Debezium Connector를 설정하여 Postgres 변경 사항을 Kafka로 수집하고, AWS RDS 제공 S3로 내보내기 작업을 사용하여 Postgres 테이블의 최신 스냅샷을 S3에 저장한 다음, Spark 작업을 생성하여 S3에서 해당 데이터를 읽고 Hudi 테이블 형식으로 썼습니다.

 

결과

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

 

참고

How Notion build and grew our data lake to keep up with rapid growth

Notion이 급격한 성장에 맞춰 데이터 레이크를 구축하고 확장한 방법 | GeekNews