Cara Notion membangun dan menskalakan data lake untuk mengikuti pertumbuhan pesat

• Selama 3 tahun terakhir, data Notion meningkat 10 kali lipat karena pertumbuhan pengguna dan konten, serta berlipat dua setiap 6~12 bulan
• Untuk mengelola pertumbuhan pesat ini sambil memenuhi kebutuhan data untuk kasus penggunaan produk dan analitik utama, termasuk fitur Notion AI terbaru, Notion membangun dan menskalakan data lake-nya

Model data dan pertumbuhan Notion

• Semua yang terlihat di Notion dimodelkan sebagai entitas "block" dan disimpan di database Postgres dengan struktur, skema, dan metadata terkait yang konsisten
• Data block ini berlipat dua setiap 6~12 bulan; pada awal 2021 ada lebih dari 20 miliar baris block, dan kini ada lebih dari 200 miliar block

Arsitektur data warehouse Notion pada 2021

• Infrastruktur data khusus dimulai dengan pipeline ELT sederhana yang menggunakan Fivetran untuk mengumpulkan data dari Postgres WAL ke Snowflake
• Mereka menyiapkan 480 connector yang berjalan setiap jam untuk 480 shard guna menulis ke 480 tabel Snowflake mentah, lalu menggabungkan tabel-tabel ini menjadi satu tabel besar untuk analitik, pelaporan, dan kasus penggunaan machine learning

Tantangan saat melakukan scaling

• Seiring pertumbuhan data Postgres, mereka menghadapi berbagai masalah
• Operasional: overhead untuk memantau dan mengelola 480 connector Fivetran menjadi sangat tinggi
• Kecepatan, kesegaran data, dan biaya: beban kerja Notion yang unik dan berfokus pada pembaruan membuat pengumpulan data ke Snowflake menjadi lambat dan lebih mahal
• Dukungan use case: logika transformasi data menjadi lebih kompleks dan berat, melampaui kemampuan antarmuka SQL standar yang disediakan data warehouse standar

Membangun dan menskalakan data lake in-house Notion

• Tujuan data lake internal
  • Mendirikan penyimpanan data yang mampu menyimpan data mentah dan data terproses dalam skala besar
  • Memungkinkan pengumpulan dan komputasi data yang cepat, skalabel, mudah dioperasikan, dan efisien biaya untuk semua workload, terutama untuk data block Notion yang berfokus pada pembaruan
  • Mendukung use case untuk AI, pencarian, dan produk lain yang memerlukan data terdenormalisasi
• Ini tidak dimaksudkan untuk sepenuhnya menggantikan Snowflake dan Fivetran atau mendukung use case online yang menuntut latensi ketat

Desain high-level data lake

• Menggunakan connector CDC Debezium untuk mengumpulkan data pembaruan inkremental dari Postgres ke Kafka, lalu menggunakan Apache Hudi untuk menulis pembaruan ini dari Kafka ke S3
• Data mentah ini kemudian digunakan untuk melakukan transformasi, denormalisasi, dan enrichment, lalu data terproses disimpan kembali ke S3 atau ke sistem downstream untuk memenuhi kebutuhan analitik dan pelaporan serta kebutuhan produk AI, pencarian, dan lainnya

Keputusan desain

1. Pemilihan penyimpanan data dan lake: menggunakan S3 sebagai penyimpanan data dan lake untuk menyimpan semua data mentah dan terproses, lalu menempatkan data warehouse dan penyimpanan data lain yang menghadap produk di downstream
2. Pemilihan engine pemrosesan: memilih Spark, framework open source, sebagai engine pemrosesan data utama
3. Lebih memilih pengumpulan inkremental daripada snapshot dump: selama operasi normal, perubahan data Postgres dikumpulkan secara inkremental dan terus diterapkan ke S3; dalam kasus yang jarang, satu full snapshot Postgres dibuat untuk bootstrap tabel di S3
4. Menyederhanakan pengumpulan inkremental: menggunakan connector CDC Kafka Debezium untuk memublikasikan perubahan inkremental data Postgres ke Kafka, lalu menggunakan Hudi untuk mengumpulkan data inkremental dari Kafka ke S3
5. Mengumpulkan data mentah sebelum pemrosesan: untuk menetapkan single source of truth dan menyederhanakan debugging di seluruh pipeline data, data Postgres mentah dikumpulkan ke S3 tanpa pemrosesan on-the-fly

Ekspansi dan operasi data lake

• Pengaturan connector CDC dan Kafka: menyiapkan satu connector CDC Debezium per host Postgres dan men-deploy-nya ke cluster AWS EKS
• Pengaturan Hudi: menggunakan Apache Hudi Deltastreamer untuk mengonsumsi pesan Kafka dan mereplikasi status tabel Postgres di S3
• Pengaturan pemrosesan data Spark: memanfaatkan PySpark untuk sebagian besar pekerjaan pemrosesan data, dan untuk pekerjaan yang lebih kompleks seperti tree traversal dan denormalisasi, memanfaatkan performa Spark yang unggul
• Pengaturan bootstrap: menyiapkan Debezium Connector untuk mengumpulkan perubahan Postgres ke Kafka, menggunakan pekerjaan ekspor ke S3 yang disediakan AWS RDS untuk menyimpan snapshot terbaru tabel Postgres ke S3, lalu membuat job Spark untuk membaca data tersebut dari S3 dan menuliskannya dalam format tabel Hudi

Hasil

• Pengembangan infrastruktur data lake dimulai pada musim semi 2022 dan selesai pada musim gugur tahun itu
• Pada 2022 terdapat penghematan bersih lebih dari US$1 juta, dan pada 2023 serta 2024 penghematannya meningkat secara proporsional
• Waktu pengumpulan end-to-end dari Postgres ke S3 dan Snowflake berkurang dari lebih dari satu hari menjadi beberapa menit untuk tabel kecil, dan maksimal beberapa jam untuk tabel besar
• Data lake memungkinkan peluncuran fitur Notion AI dengan sukses pada 2023 dan 2024

[befree]

Apakah Anda bisa memberi tahu dokumen atau referensi yang terkait dengan isi di atas dan yang dijadikan rujukan?

[befree]

Saya yang salah tulis, hahaha
Sudah ketemu~~~