How we built our Internal Data Warehouse at ClickHouse: A year later

ClickHouse · 2024 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Phần 2, viết một năm sau ClickHouse 2023. Bài của nhà cung cấp về chính sản phẩm của họ; các nhận định ưu thế là theo ClickHouse.

Bối cảnh

• Năm 2024 DWH có 19 nguồn nạp theo giờ hoặc theo ngày; mỗi ngày ghi khoảng 6 tỉ dòng, 50 TB chưa nén; đang lưu 470 TB đã nén của hai năm, tăng 23% trong 30 ngày; khoảng 70 user chạy SELECT mỗi tuần (2023: 13 TB nén, 10 nguồn).
• DWH thành hệ "business-critical" cho lãnh đạo, product, sales, finance. Môi trường preprod còn được dùng làm canary cho bản ClickHouse open source trước khi nâng cấp rộng trên ClickHouse Cloud.

Thay đổi chính

• dbt cho batch reporting: cách dồn logic transform vào Airflow không scale khi thêm nguồn và metric phức tạp hơn (window function, so sánh chênh lệch, điều kiện từ bảng ngoài). dbt gom logic transform về một chỗ, theo dõi phụ thuộc, tự sinh lineage; xử lý được việc các nguồn đến lúc khác nhau (7:26, 10:01) nhưng cùng một mốc giờ logic để join.
• Tách DAG khổng lồ: lúc đầu chỉ có một job "hourly load" làm hết; khi thêm nguồn và mô hình, job chạy quá lâu và một lỗi làm hỏng việc nạp mọi dữ liệu vì các mô hình phụ thuộc nhau. Sau khi có dbt, tách thành 9 tiến trình, độ tin cậy tốt hơn (đây chính là "một DAG chính lớn" mà phần 1 chọn).
• Dữ liệu gần thời gian thực: nạp thêm nguồn khối lượng lớn, schema lỏng: một bảng nhận khoảng 4 tỉ dòng/ngày, gần nghìn tỉ dòng tổng; event Google Analytics dạng mảng lồng; bản đổ từ DB NoSQL của control plane dạng JSON. Đưa ra cả dạng thô (user tự trích trường JSON bằng SQL) lẫn dạng tổng hợp (dbt tính khi dữ liệu đến; cũng làm được bằng materialized view), rồi join với báo cáo batch, ví dụ "số khách có query lỗi".
• Thêm lối truy cập: SQL client của Superset hay lỗi nên mở SQL console của ClickHouse Cloud (quyền vẫn qua Google Groups); Growthbook truy vấn thẳng để phân tích A/B test; xuất dữ liệu sang Salesforce qua S3 vì Salesforce không gọi được từ IP tĩnh.
• Hướng tới: hầu hết job vẫn chạy mỗi giờ nên service phải chạy 24/7. Định dùng compute-compute separation (nhiều nhóm compute chung một kho dữ liệu): một service chỉ đọc cho BI, một service đọc-ghi 24/7 cho ETL quan trọng, một service đọc-ghi khác cho ETL ít quan trọng (cập nhật mỗi ngày) có thể tắt khi rảnh để tiết kiệm.

Vì sao

• Logic nghiệp vụ tăng nhanh hơn số nguồn; khi logic nằm rải trong các task của bộ điều phối thì thêm nguồn là thêm phụ thuộc chéo. Công cụ chuyên cho transform (dbt) tách "khi nào chạy" (Airflow) khỏi "tính gì" (Pipeline dữ liệu và analytics).
• Khi dữ liệu nằm chung một kho, tách compute theo workload cho phép mỗi workload co giãn và tắt riêng (Tách compute khỏi storage).

Bài học cho SWE

• Một DAG lớn đơn giản lúc đầu, nhưng là một miền lỗi duy nhất; tách theo mô hình dữ liệu khi một lỗi bắt đầu chặn mọi thứ.
• Giữ dữ liệu thô bên cạnh dữ liệu tổng hợp: người dùng tự khám phá được, và còn bản gốc khi cần điều tra sâu.
• DWH nội bộ của nhà làm DB có thể làm canary cho chính DB đó.
• So hai phần: giả định "theo giờ là đủ, không cần CDC" của 2023 vẫn đứng; giả định "hai tầng là đủ" và "một DAG" thì không.

Liên quan

• ClickHouse 2023 · Shopify 2022 · Snowflake 2026 · Netflix 2022
• Pipeline dữ liệu và analytics · Tách compute khỏi storage