Cách Notion xây dựng và mở rộng data lake để theo kịp tăng trưởng bùng nổ

xguru · 2024-07-15T10:31:01+09:00

Trong 3 năm qua, dữ liệu của Notion đã tăng gấp 10 lần do số lượng người dùng và nội dung tăng lên, và cứ mỗi 6–12 tháng lại tăng gấp đôi Để quản lý tốc độ tăng trưởng bùng nổ này đồng thời đáp ứng các yêu cầu dữ liệu cho những trường hợp sử dụng sản phẩm và phân tích quan trọng, bao gồm cả các tính năng Notion AI gần đây, Notion đã xây dựng và mở rộng data lake của mình Mô hình dữ liệu và tăng trưởng của Notion Mọi thứ bạn nhìn thấy trong Notion đều được mô hình hóa thành thực thể "block" và được lưu trong cơ sở dữ liệu Postgres với cấu trúc, schema và metadata liên quan nhất quán Dữ liệu block này tăng gấp đôi sau mỗi 6–12 tháng; vào đầu năm 2021 đã có hơn 20 tỷ hàng block, và hiện nay đã có hơn 200 tỷ block Kiến trúc data warehouse của Notion năm 2021 Notion khởi đầu hạ tầng dữ liệu chuyên dụng bằng một pipeline ELT đơn giản dùng Fivetran để thu thập dữ liệu từ Postgres WAL sang Snowflake Họ thiết lập 480 connector chạy theo giờ cho 480 shard để ghi vào 480 bảng Snowflake thô, rồi hợp nhất các bảng này thành một bảng lớn phục vụ các trường hợp sử dụng phân tích, báo cáo và machine learning Những thách thức khi mở rộng Khi dữ liệu Postgres tăng lên, họ phải đối mặt với nhiều vấn đề Khả năng vận hành: chi phí quản lý và giám sát 480 connector Fivetran trở nên rất cao Tốc độ, độ tươi của dữ liệu và chi phí: do đặc thù workload thiên về cập nhật của Notion, việc thu thập dữ liệu vào Snowflake trở nên chậm hơn và tốn kém hơn Hỗ trợ use case: logic chuyển đổi dữ liệu trở nên phức tạp và nặng hơn, vượt quá khả năng của giao diện SQL tiêu chuẩn mà data warehouse thông thường cung cấp Xây dựng và mở rộng data lake in-house của Notion Mục tiêu của data lake nội bộ Thiết lập một kho lưu trữ dữ liệu có thể lưu dữ liệu thô và dữ liệu đã xử lý ở quy mô lớn Cho phép thu thập và tính toán dữ liệu nhanh, có thể mở rộng, dễ vận hành và hiệu quả về chi phí cho mọi workload, đặc biệt là dữ liệu block thiên về cập nhật của Notion Hỗ trợ các use case cho AI, tìm kiếm và các sản phẩm khác cần dữ liệu phi chuẩn hóa Không nhằm thay thế hoàn toàn Snowflake và Fivetran, cũng không nhằm hỗ trợ các use case online đòi hỏi độ trễ nghiêm ngặt Thiết kế cấp cao của data lake Sử dụng connector CDC của Debezium để thu thập dữ liệu cập nhật gia tăng từ Postgres vào Kafka, sau đó dùng Apache Hudi để ghi các bản cập nhật này từ Kafka vào S3 Từ dữ liệu thô này, họ thực hiện chuyển đổi, phi chuẩn hóa và làm giàu dữ liệu, sau đó lưu dữ liệu đã xử lý trở lại S3 hoặc vào các hệ thống downstream để đáp ứng nhu cầu phân tích, báo cáo cũng như nhu cầu sản phẩm như AI, tìm kiếm và các sản phẩm khác Các quyết định thiết kế Lựa chọn kho dữ liệu và lake: dùng S3 làm nơi lưu trữ dữ liệu và data lake để chứa toàn bộ dữ liệu thô và dữ liệu đã xử lý, còn data warehouse và các kho dữ liệu hướng sản phẩm khác được đặt ở downstream Lựa chọn engine xử lý: chọn Spark, một framework mã nguồn mở, làm engine xử lý dữ liệu chính Ưu tiên thu thập gia tăng hơn dump snapshot: trong vận hành bình thường, thu thập dữ liệu Postgres đã thay đổi theo kiểu gia tăng và liên tục áp dụng vào S3; trong những trường hợp hiếm, tạo một snapshot đầy đủ của Postgres một lần để bootstrap bảng trên S3 Đơn giản hóa thu thập gia tăng: dùng connector CDC Kafka Debezium để publish dữ liệu Postgres đã thay đổi gia tăng lên Kafka, và dùng Hudi để thu thập dữ liệu gia tăng từ Kafka vào S3 Thu thập dữ liệu thô trước khi xử lý: thu thập dữ liệu Postgres thô vào S3 mà không xử lý on-the-fly để thiết lập một nguồn chân lý duy nhất và đơn giản hóa việc debug trên toàn bộ pipeline dữ liệu Mở rộng và vận hành data lake Thiết lập CDC connector và Kafka: cấu hình một connector CDC Debezium cho mỗi host Postgres và triển khai trên cụm AWS EKS Thiết lập Hudi: dùng Apache Hudi Deltastreamer để tiêu thụ message Kafka và sao chép trạng thái của các bảng Postgres trên S3 Thiết lập xử lý dữ liệu bằng Spark: tận dụng PySpark cho hầu hết các tác vụ xử lý dữ liệu, và với các tác vụ phức tạp hơn như duyệt cây và phi chuẩn hóa, khai thác hiệu năng vượt trội của Spark Thiết lập bootstrap: cấu hình Debezium Connector để thu thập thay đổi từ Postgres vào Kafka, dùng tác vụ export sang S3 do AWS RDS cung cấp để lưu snapshot mới nhất của các bảng Postgres lên S3, rồi tạo job Spark để đọc dữ liệu đó từ S3 và ghi dưới định dạng bảng Hudi Kết quả Bắt đầu phát triển hạ tầng data lake vào mùa xuân năm 2022 và hoàn thành vào mùa thu cùng năm Tiết kiệm ròng hơn 1 triệu USD trong năm 2022, và mức tiết kiệm trong năm 2023 và 2024 còn cao hơn tương ứng Thời gian thu thập end-to-end từ Postgres sang S3 và Snowflake giảm từ hơn một ngày xuống còn vài phút đối với bảng nhỏ, và tối đa vài giờ đối với bảng lớn Data lake đã giúp Notion triển khai thành công các tính năng Notion AI trong năm 2023 và 2024

(notion.so)

21 điểm bởi xguru 2024-07-15 | 2 bình luận | Chia sẻ qua WhatsApp

Trong 3 năm qua, dữ liệu của Notion đã tăng gấp 10 lần do số lượng người dùng và nội dung tăng lên, và cứ mỗi 6–12 tháng lại tăng gấp đôi
Để quản lý tốc độ tăng trưởng bùng nổ này đồng thời đáp ứng các yêu cầu dữ liệu cho những trường hợp sử dụng sản phẩm và phân tích quan trọng, bao gồm cả các tính năng Notion AI gần đây, Notion đã xây dựng và mở rộng data lake của mình

Mô hình dữ liệu và tăng trưởng của Notion

Mọi thứ bạn nhìn thấy trong Notion đều được mô hình hóa thành thực thể "block" và được lưu trong cơ sở dữ liệu Postgres với cấu trúc, schema và metadata liên quan nhất quán
Dữ liệu block này tăng gấp đôi sau mỗi 6–12 tháng; vào đầu năm 2021 đã có hơn 20 tỷ hàng block, và hiện nay đã có hơn 200 tỷ block

Kiến trúc data warehouse của Notion năm 2021

Notion khởi đầu hạ tầng dữ liệu chuyên dụng bằng một pipeline ELT đơn giản dùng Fivetran để thu thập dữ liệu từ Postgres WAL sang Snowflake
Họ thiết lập 480 connector chạy theo giờ cho 480 shard để ghi vào 480 bảng Snowflake thô, rồi hợp nhất các bảng này thành một bảng lớn phục vụ các trường hợp sử dụng phân tích, báo cáo và machine learning

Những thách thức khi mở rộng

Khi dữ liệu Postgres tăng lên, họ phải đối mặt với nhiều vấn đề
Khả năng vận hành: chi phí quản lý và giám sát 480 connector Fivetran trở nên rất cao
Tốc độ, độ tươi của dữ liệu và chi phí: do đặc thù workload thiên về cập nhật của Notion, việc thu thập dữ liệu vào Snowflake trở nên chậm hơn và tốn kém hơn
Hỗ trợ use case: logic chuyển đổi dữ liệu trở nên phức tạp và nặng hơn, vượt quá khả năng của giao diện SQL tiêu chuẩn mà data warehouse thông thường cung cấp

Xây dựng và mở rộng data lake in-house của Notion

Mục tiêu của data lake nội bộ
- Thiết lập một kho lưu trữ dữ liệu có thể lưu dữ liệu thô và dữ liệu đã xử lý ở quy mô lớn
- Cho phép thu thập và tính toán dữ liệu nhanh, có thể mở rộng, dễ vận hành và hiệu quả về chi phí cho mọi workload, đặc biệt là dữ liệu block thiên về cập nhật của Notion
- Hỗ trợ các use case cho AI, tìm kiếm và các sản phẩm khác cần dữ liệu phi chuẩn hóa
Không nhằm thay thế hoàn toàn Snowflake và Fivetran, cũng không nhằm hỗ trợ các use case online đòi hỏi độ trễ nghiêm ngặt

Thiết kế cấp cao của data lake

Sử dụng connector CDC của Debezium để thu thập dữ liệu cập nhật gia tăng từ Postgres vào Kafka, sau đó dùng Apache Hudi để ghi các bản cập nhật này từ Kafka vào S3
Từ dữ liệu thô này, họ thực hiện chuyển đổi, phi chuẩn hóa và làm giàu dữ liệu, sau đó lưu dữ liệu đã xử lý trở lại S3 hoặc vào các hệ thống downstream để đáp ứng nhu cầu phân tích, báo cáo cũng như nhu cầu sản phẩm như AI, tìm kiếm và các sản phẩm khác

Các quyết định thiết kế

Lựa chọn kho dữ liệu và lake: dùng S3 làm nơi lưu trữ dữ liệu và data lake để chứa toàn bộ dữ liệu thô và dữ liệu đã xử lý, còn data warehouse và các kho dữ liệu hướng sản phẩm khác được đặt ở downstream
Lựa chọn engine xử lý: chọn Spark, một framework mã nguồn mở, làm engine xử lý dữ liệu chính
Ưu tiên thu thập gia tăng hơn dump snapshot: trong vận hành bình thường, thu thập dữ liệu Postgres đã thay đổi theo kiểu gia tăng và liên tục áp dụng vào S3; trong những trường hợp hiếm, tạo một snapshot đầy đủ của Postgres một lần để bootstrap bảng trên S3
Đơn giản hóa thu thập gia tăng: dùng connector CDC Kafka Debezium để publish dữ liệu Postgres đã thay đổi gia tăng lên Kafka, và dùng Hudi để thu thập dữ liệu gia tăng từ Kafka vào S3
Thu thập dữ liệu thô trước khi xử lý: thu thập dữ liệu Postgres thô vào S3 mà không xử lý on-the-fly để thiết lập một nguồn chân lý duy nhất và đơn giản hóa việc debug trên toàn bộ pipeline dữ liệu

Mở rộng và vận hành data lake

Thiết lập CDC connector và Kafka: cấu hình một connector CDC Debezium cho mỗi host Postgres và triển khai trên cụm AWS EKS
Thiết lập Hudi: dùng Apache Hudi Deltastreamer để tiêu thụ message Kafka và sao chép trạng thái của các bảng Postgres trên S3
Thiết lập xử lý dữ liệu bằng Spark: tận dụng PySpark cho hầu hết các tác vụ xử lý dữ liệu, và với các tác vụ phức tạp hơn như duyệt cây và phi chuẩn hóa, khai thác hiệu năng vượt trội của Spark
Thiết lập bootstrap: cấu hình Debezium Connector để thu thập thay đổi từ Postgres vào Kafka, dùng tác vụ export sang S3 do AWS RDS cung cấp để lưu snapshot mới nhất của các bảng Postgres lên S3, rồi tạo job Spark để đọc dữ liệu đó từ S3 và ghi dưới định dạng bảng Hudi

Kết quả

Bắt đầu phát triển hạ tầng data lake vào mùa xuân năm 2022 và hoàn thành vào mùa thu cùng năm
Tiết kiệm ròng hơn 1 triệu USD trong năm 2022, và mức tiết kiệm trong năm 2023 và 2024 còn cao hơn tương ứng
Thời gian thu thập end-to-end từ Postgres sang S3 và Snowflake giảm từ hơn một ngày xuống còn vài phút đối với bảng nhỏ, và tối đa vài giờ đối với bảng lớn
Data lake đã giúp Notion triển khai thành công các tính năng Notion AI trong năm 2023 và 2024

2 bình luận

befree 2024-07-16

Bạn có thể cho biết tài liệu hoặc các tài liệu tham khảo liên quan đến nội dung trên được không?