PostHog rời bỏ DuckDB: bài học đắt giá khi mở rộng kho dữ liệu lên 2 PB

Cách đây 5 tháng, PostHog đã gây chú ý khi xây dựng lại kho dữ liệu của mình trên DuckDB thay vì ClickHouse. Giờ đây, khi khối lượng dữ liệu chạm ngưỡng 2 PB, công ty quyết định thay đổi lần nữa — lần này là chuyển sang Trino cùng định dạng bảng mở do chính họ phát triển, HogLake.

DuckDB tuyệt vời trên một máy, nhưng khó sống ở quy mô lớn

DuckDB được đánh giá cao nhờ khả năng phân tích khối lượng dữ liệu lớn trên một máy đơn lẻ — thậm chí là trên laptop cá nhân. Nó ổn định, gần như luôn hoàn thành truy vấn và tự động ghi ra đĩa khi hết bộ nhớ RAM.

Tuy nhiên, chính những ưu điểm này lại trở thành điểm yếu khi đưa lên đám mây. PostHog nhận ra khách hàng chạy những truy vấn phức tạp hơn nhiều so với dự đoán, buộc họ phải cấp các instance có cấu hình rất lớn.

• Phải định cỡ worker trước khi truy vấn đến, trong khi rất khó dự đoán nhu cầu CPU và bộ nhớ của từng truy vấn.
• Thêm dung lượng đĩa là một lựa chọn, nhưng truy vấn sẽ quá chậm và tốn kém để khả thi.
• Việc lấy dữ liệu lớn từ S3 gặp nút thắt do thiếu cơ chế tải bất đồng bộ — tính năng mà DuckDB chỉ mới bổ sung gần đây.

Quan điểm của đội ngũ kỹ thuật rất rõ ràng: người dùng không nên phải bận tâm đến việc truy vấn của mình cần bao nhiêu tài nguyên. Trách nhiệm của nhà cung cấp là xử lý phần còn lại.

DuckLake được thiết kế để tương thích, không phải để mở rộng

Để biến DuckDB thành một kho dữ liệu đầy đủ, PostHog cài đặt mặc định tiện ích mở rộng DuckLake — định dạng lakehouse mới từ cùng nhóm tác giả. Triết lý vẫn là giữ mọi thứ đơn giản và chạy được trên gần như mọi thiết lập.

Nhưng ở quy mô của PostHog, vấn đề bắt đầu xuất hiện:

• Lược đồ catalog của DuckLake phải duy trì tính di động giữa nhiều cơ sở dữ liệu SQL khác nhau, hạn chế các tối ưu riêng cho engine.
• Một thao tác ghi bảng đơn lẻ có thể mất hơn 3 phút, do mỗi lần commit đều phải đọc lại số liệu thống kê của toàn bộ catalog.
• Hơn 99% dòng thống kê trong catalog thuộc về các bảng đã không còn tồn tại. Dọn dẹp giúp ghi nhanh hơn 30–50 lần, nhưng chúng lại sinh sôi trở lại.
• Số lượng kết nối mà DuckLake mở tới cơ sở dữ liệu metadata gây tốn kém trên các instance Postgres dùng chung.

Quy mô 1.000 tỷ dòng là thách thức thực sự

PostHog không thử nghiệm từ từ mà đưa toàn bộ hệ thống lên DuckLake ngay, trở thành khách hàng đầu tiên của chính mình. Khi rời bỏ, kho dữ liệu chứa khoảng 2 PB, tương đương 1.000 tỷ dòng và 15,3 triệu bản chụp trạng thái.

Minh họa kho dữ liệu quy mô lớn

Hệ thống hỏng theo nhiều cách khó có thể khắc phục trong phạm vi của DuckLake. Đội ngũ muốn đóng góp cho cộng đồng mã nguồn mở, nhưng tốc độ tung ra thay đổi không đáp ứng được nhu cầu — cuối cùng họ phải tự duy trì một bản fork chứa các bản vá riêng, đi ngược lại một trong những lợi ích cốt lõi của việc dùng DuckLake.

Nói chuyện được với Postgres khó hơn tưởng tượng

Cung cấp kết nối Postgres trực tiếp qua cổng 5432 nghe có vẻ hấp dẫn, nhưng thực tế khó mở rộng hơn nhiều so với HTTP.

Việc thiếu cơ chế tự kết nối lại, quản lý TTL và kết nối nhàn rỗi ở quy mô lớn là rất khó khăn, trong khi kết nối chạy dài lại tốn kém.

Công cụ cân bằng tải cho pgwire cũng khan hiếm so với HTTP — có thể so sánh sự khác biệt giữa AWS NLB và ALB. Thêm vào đó, danh sách các thư viện client Postgres là vô tận, mỗi thư viện lại kỳ vọng một hành vi riêng. PostHog đã dành nhiều thời gian để vá lỗi cho khách hàng nhưng độ phủ không bao giờ đủ tốt.

Xây dựng lại trên Trino với HogLake

Bài học lớn nhất: đừng thần tượng hóa công nghệ đằng sau một kho dữ liệu — điều quan trọng là trải nghiệm mà nó mang lại.

Đội ngũ kỹ thuật xây dựng hệ thống mới

PostHog đang xây dựng lại toàn bộ hệ thống quanh một phiên bản Trino riêng và tự phát triển định dạng bảng mở HogLake. Họ kiểm thử ở quy mô petabyte của chính mình trước khi bàn giao cho các đối tác thiết kế.

Với người dùng Việt Nam đang cân nhắc lựa chọn giữa DuckDB, ClickHouse hay các giải pháp lakehouse, câu chuyện của PostHog là lời nhắc nhở: công cụ phân tích đơn máy rất tốt cho khối lượng dữ liệu vừa phải, nhưng khi bước vào vùng petabyte, kiến trúc phân tán được thiết kế từ đầu vẫn là yếu tố không thể thay thế.

Công ty cũng cho biết đang tìm kiếm thêm đối tác thiết kế, đặc biệt là những ai có khối lượng dữ liệu lớn cần truy vấn.