- पिछले 3 वर्षों में, users और content की वृद्धि के कारण Notion का data 10 गुना बढ़ गया, और हर 6–12 महीनों में 2 गुना होता गया
- हाल में Notion AI features सहित प्रमुख product और analytics use cases की data requirements को पूरा करते हुए इस तेज़ growth को manage करने के लिए Notion ने अपना data lake बनाया और scale किया
Notion का data model और growth
- Notion में दिखाई देने वाली हर चीज़ को "block" entity के रूप में model किया जाता है और Postgres database में एक consistent structure, schema और संबंधित metadata के साथ store किया जाता है
- यह block data हर 6–12 महीनों में 2 गुना बढ़ा; 2021 की शुरुआत में 20 अरब से अधिक block rows थीं, और अब 200 अरब से अधिक blocks हैं
2021 में Notion का data warehouse architecture
- Postgres WAL से Snowflake में data ingest करने वाली एक simple ELT pipeline के लिए Fivetran का उपयोग कर dedicated data infrastructure की शुरुआत की गई
- 480 raw Snowflake tables में लिखने के लिए 480 shards पर हर घंटे चलने वाले 480 connectors सेट किए गए, और analytics, reporting तथा machine learning use cases के लिए इन tables को merge करके एक बड़ी table बनाई गई
Scaling के दौरान चुनौतियाँ
- Postgres data बढ़ने के साथ कई समस्याओं का सामना करना पड़ा
- Operability: 480 Fivetran connectors को monitor और manage करने का overhead बहुत बढ़ गया
- Speed, data freshness और cost: Notion के unique update-centric workload के कारण Snowflake में data ingest करने की गति धीमी हुई और लागत बढ़ी
- Use case support: data transformation logic और अधिक complex और heavy हो गया, जिससे standard data warehouse द्वारा दिए जाने वाले standard SQL interface की क्षमता पीछे छूट गई
Notion का in-house data lake बनाना और scale करना
- Internal data lake के लक्ष्य
- large scale पर raw data और processed data store कर सकने वाला data storage स्थापित करना
- खास तौर पर Notion के update-centric block data के लिए, सभी workloads में तेज़, scalable, operable और cost-efficient data ingestion और computation सक्षम करना
- AI, search और denormalized data की आवश्यकता वाले अन्य products के use cases को support करना
- इसका उद्देश्य Snowflake और Fivetran को पूरी तरह replace करना या सख्त latency की मांग वाले online use cases को support करना नहीं था
Data lake का high-level design
- Debezium CDC connector का उपयोग करके Postgres से Kafka में incrementally updated data ingest किया गया, फिर Apache Hudi का उपयोग करके इन updates को Kafka से S3 में लिखा गया
- इस raw data का उपयोग transform, denormalize और enrich करने के लिए किया गया, फिर processed data को वापस S3 या downstream systems में store किया गया ताकि analytics और reporting requirements के साथ-साथ AI, search और अन्य product requirements पूरी की जा सकें
Design decisions
- Data storage और lake का चयन: सभी raw और processed data को store करने के लिए S3 को data storage और lake के रूप में इस्तेमाल किया गया, और data warehouse तथा अन्य product-facing data stores को downstream में रखा गया
- Processing engine का चयन: मुख्य data processing engine के रूप में open source framework Spark को चुना गया
- Snapshot dump की बजाय incremental ingestion को प्राथमिकता: सामान्य संचालन के दौरान बदले हुए Postgres data को incremental रूप से ingest करके लगातार S3 पर apply किया गया, और विरले मामलों में S3 पर table bootstrap करने के लिए एक बार full Postgres snapshot बनाया गया
- Incremental ingestion को सरल बनाना: Kafka Debezium CDC connector का उपयोग करके incrementally changed Postgres data को Kafka पर publish किया गया, और Hudi का उपयोग करके Kafka से S3 में incremental data ingest किया गया
- Processing से पहले raw data ingestion: single source of truth स्थापित करने और पूरे data pipeline में debugging को सरल बनाने के लिए, बिना on-the-fly processing के raw Postgres data को S3 में ingest किया गया
Data lake का विस्तार और संचालन
- CDC connector और Kafka setup: हर Postgres host के लिए एक Debezium CDC connector सेट किया गया और उसे AWS EKS cluster पर deploy किया गया
- Hudi setup: Apache Hudi Deltastreamer का उपयोग करके Kafka messages consume किए गए और S3 पर Postgres tables की state को replicate किया गया
- Spark data processing setup: अधिकांश data processing tasks के लिए PySpark का उपयोग किया गया, और tree traversal तथा denormalization जैसे अधिक complex tasks के लिए Spark की बेहतर performance का लाभ उठाया गया
- Bootstrap setup: Debezium Connector को इस तरह configure किया गया कि वह Postgres changes को Kafka में ingest करे, और AWS RDS के provided S3 export job का उपयोग करके Postgres tables का नवीनतम snapshot S3 में store किया जाए; इसके बाद एक Spark job बनाई गई जो S3 से उस data को पढ़कर Hudi table format में लिखे
परिणाम
- 2022 की वसंत ऋतु में data lake infrastructure का development शुरू हुआ और उसी वर्ष शरद ऋतु में पूरा हुआ
- 2022 में 10 लाख डॉलर से अधिक की net savings हुई, और 2023 तथा 2024 में अनुपातिक रूप से इससे भी अधिक savings हुई
- Postgres से S3 और Snowflake तक end-to-end ingestion समय एक दिन से अधिक से घटकर small tables के लिए कुछ मिनट और large tables के लिए अधिकतम कुछ घंटे रह गया
- Data lake की बदौलत 2023 और 2024 में Notion AI features को सफलतापूर्वक launch किया जा सका
2 टिप्पणियां
क्या आप कृपया बता सकते हैं कि ऊपर दी गई सामग्री से संबंधित कोई दस्तावेज़ या संदर्भ सामग्री है जिसे आपने देखा हो?
मुझसे गलती से गलत लिखा गया था हाहा
मिल गया~~~