Notion สร้างและขยาย Data Lake อย่างไรให้ทันกับการเติบโตแบบก้าวกระโดด

• ในช่วง 3 ปีที่ผ่านมา ข้อมูลของ Notion เพิ่มขึ้น 10 เท่า จากการเติบโตของผู้ใช้และคอนเทนต์ และเพิ่มเป็น 2 เท่าทุก ๆ 6–12 เดือน
• เพื่อรับมือกับการเติบโตอย่างรวดเร็วนี้ พร้อมตอบโจทย์ความต้องการด้านข้อมูลของกรณีใช้งานสำคัญทั้งผลิตภัณฑ์และการวิเคราะห์ รวมถึงฟีเจอร์ Notion AI ล่าสุด Notion จึงสร้างและขยาย data lake ของตน

โมเดลข้อมูลและการเติบโตของ Notion

• ทุกสิ่งที่เห็นใน Notion ถูกโมเดลเป็นเอนทิตี "block" และถูกจัดเก็บในฐานข้อมูล Postgres ด้วยโครงสร้าง สคีมา และเมตาดาตาที่เกี่ยวข้องอย่างสม่ำเสมอ
• ข้อมูล block นี้เพิ่มขึ้นเป็น 2 เท่าทุก ๆ 6–12 เดือน โดยในต้นปี 2021 มี block row มากกว่า 20 พันล้านรายการ และปัจจุบันมี block มากกว่า 200 พันล้านรายการ

สถาปัตยกรรม data warehouse ของ Notion ในปี 2021

• เริ่มต้นโครงสร้างพื้นฐานข้อมูลเฉพาะด้วย ELT pipeline แบบเรียบง่ายที่ใช้ Fivetran เพื่อนำเข้าข้อมูลจาก Postgres WAL ไปยัง Snowflake
• ตั้งค่า connector 480 ตัวที่รันทุกชั่วโมงสำหรับ 480 shard เพื่อเขียนลงตาราง Snowflake ดิบ 480 ตาราง แล้วรวมตารางเหล่านี้เป็นตารางขนาดใหญ่เพียงตารางเดียวสำหรับกรณีใช้งานด้านการวิเคราะห์ รายงาน และ machine learning

ความท้าทายเมื่อสเกลระบบ

• เมื่อข้อมูลใน Postgres เพิ่มขึ้น ก็พบกับปัญหาหลายด้าน
• การปฏิบัติการ: ภาระในการมอนิเตอร์และจัดการ Fivetran connector ทั้ง 480 ตัวสูงมาก
• ความเร็ว ความสดใหม่ของข้อมูล และต้นทุน: เวิร์กโหลดแบบเน้นการอัปเดตที่เป็นเอกลักษณ์ของ Notion ทำให้การนำเข้าข้อมูลไปยัง Snowflake ช้าลงและมีต้นทุนเพิ่มขึ้น
• การรองรับ use case: ลอจิกการแปลงข้อมูลซับซ้อนและหนักขึ้น จนเกินขีดความสามารถของ SQL interface มาตรฐานที่ data warehouse ทั่วไปมีให้

การสร้างและขยาย data lake ภายในของ Notion

• เป้าหมายของ data lake ภายใน
  • สร้างที่เก็บข้อมูลที่สามารถจัดเก็บทั้งข้อมูลดิบและข้อมูลที่ประมวลผลแล้วได้ในสเกลใหญ่
  • รองรับการนำเข้าข้อมูลและการคำนวณที่รวดเร็ว ขยายได้ จัดการได้ในเชิงปฏิบัติการ และคุ้มต้นทุนสำหรับทุกเวิร์กโหลด โดยเฉพาะข้อมูล block ของ Notion ที่เน้นการอัปเดต
  • รองรับ use case สำหรับ AI, การค้นหา และผลิตภัณฑ์อื่น ๆ ที่ต้องใช้ข้อมูลแบบ de-normalized
• ไม่ได้มีเป้าหมายจะแทนที่ Snowflake และ Fivetran ทั้งหมด หรือรองรับ use case แบบออนไลน์ที่ต้องการ latency เข้มงวด

การออกแบบระดับสูงของ data lake

• ใช้ Debezium CDC connector เพื่อนำเข้าข้อมูลที่อัปเดตแบบ incremental จาก Postgres ไปยัง Kafka จากนั้นใช้ Apache Hudi เขียนข้อมูลอัปเดตเหล่านี้จาก Kafka ไปยัง S3
• จากข้อมูลดิบนี้จึงทำการแปลงข้อมูล ทำ de-normalization และ enrichment แล้วบันทึกข้อมูลที่ประมวลผลแล้วกลับไปยัง S3 หรือเก็บไว้ในระบบปลายน้ำ เพื่อรองรับทั้งความต้องการด้านการวิเคราะห์และรายงาน รวมถึงความต้องการของ AI, การค้นหา และผลิตภัณฑ์อื่น ๆ

การตัดสินใจด้านการออกแบบ

1. การเลือก data store และ lake: ใช้ S3 เป็นทั้ง data store และ lake สำหรับเก็บข้อมูลดิบและข้อมูลที่ประมวลผลแล้วทั้งหมด และวาง data warehouse กับ data store สำหรับผลิตภัณฑ์อื่น ๆ ไว้เป็นระบบปลายน้ำ
2. การเลือก processing engine: เลือก Spark ซึ่งเป็นเฟรมเวิร์กโอเพนซอร์ส เป็น processing engine หลัก
3. เลือก incremental ingestion มากกว่าการ dump snapshot: ระหว่างการทำงานปกติ จะนำเข้าข้อมูล Postgres ที่เปลี่ยนแปลงแบบ incremental แล้วเขียนต่อเนื่องลง S3 และในกรณีที่เกิดขึ้นไม่บ่อย จะสร้าง full Postgres snapshot เพียงครั้งเดียวเพื่อ bootstrap ตารางบน S3
4. ทำ incremental ingestion ให้ง่ายขึ้น: ใช้ Kafka Debezium CDC connector เพื่อเผยแพร่ข้อมูล Postgres ที่เปลี่ยนแปลงแบบ incremental ไปยัง Kafka และใช้ Hudi เพื่อนำเข้าข้อมูล incremental จาก Kafka ไปยัง S3
5. นำเข้าข้อมูลดิบก่อนประมวลผล: นำเข้าข้อมูล Postgres ดิบไปยัง S3 โดยไม่ประมวลผลระหว่างทาง เพื่อสร้าง single source of truth และทำให้การดีบักตลอดทั้ง data pipeline ง่ายขึ้น

การขยายและปฏิบัติการ data lake

• การตั้งค่า CDC connector และ Kafka: ตั้งค่า Debezium CDC connector หนึ่งตัวต่อ Postgres host และ deploy บนคลัสเตอร์ AWS EKS
• การตั้งค่า Hudi: ใช้ Apache Hudi Deltastreamer เพื่อใช้ข้อความจาก Kafka และจำลองสถานะของตาราง Postgres บน S3
• การตั้งค่า Spark data processing: ใช้ PySpark กับงานประมวลผลข้อมูลส่วนใหญ่ และสำหรับงานที่ซับซ้อนกว่า เช่น tree traversal และ de-normalization ก็ใช้ประโยชน์จากประสิทธิภาพที่ยอดเยี่ยมของ Spark
• การตั้งค่า bootstrap: ตั้งค่า Debezium Connector เพื่อเก็บการเปลี่ยนแปลงของ Postgres ไปยัง Kafka จากนั้นใช้ export job ไปยัง S3 ที่ AWS RDS มีให้ เพื่อบันทึก snapshot ล่าสุดของตาราง Postgres ลง S3 แล้วสร้างงาน Spark ให้อ่านข้อมูลนั้นจาก S3 และเขียนในรูปแบบตาราง Hudi

ผลลัพธ์

• เริ่มพัฒนาโครงสร้างพื้นฐาน data lake ในฤดูใบไม้ผลิปี 2022 และเสร็จสมบูรณ์ในฤดูใบไม้ร่วงปีเดียวกัน
• ในปี 2022 ประหยัดต้นทุนสุทธิได้มากกว่า 1 ล้านดอลลาร์ และในปี 2023 กับ 2024 ก็ประหยัดได้สูงขึ้นตามสัดส่วน
• เวลาในการนำเข้าข้อมูลแบบ end-to-end จาก Postgres ไปยัง S3 และ Snowflake ลดลงจากมากกว่า 1 วัน เหลือเพียงไม่กี่นาทีสำหรับตารางขนาดเล็ก และสูงสุดเพียงไม่กี่ชั่วโมงสำหรับตารางขนาดใหญ่
• data lake นี้ช่วยให้ Notion เปิดตัวฟีเจอร์ Notion AI ได้สำเร็จในปี 2023 และ 2024

[befree]

ขอรบกวนช่วยแนะนำเอกสารหรือแหล่งอ้างอิงที่เกี่ยวข้องกับเนื้อหาข้างต้นได้ไหมครับ?

[befree]

ผมพิมพ์ผิดเองครับ 555
เจอแล้ว~~~