Nạp 1 nghìn tỷ bản ghi dữ liệu thời tiết vào TimescaleDB

Xây dựng kho dữ liệu thời tiết, phần 1: Nạp 1 nghìn tỷ dòng dữ liệu thời tiết vào TimescaleDB

Ý nghĩa của công việc chúng ta đang làm

Vì sao xây dựng kho dữ liệu thời tiết

• Tác giả cho rằng sẽ rất hữu ích nếu thu thập và phân tích dữ liệu thời tiết lịch sử trên toàn thế giới để phân tích các dấu hiệu của biến đổi khí hậu
• Nếu có một kho dữ liệu thời tiết quy mô lớn, có thể xác định theo từng khu vực liệu Jakarta thực sự đã ấm lên hơn hay bão đã dữ dội hơn, Chile nói chung có nóng hơn hay nhiều mây hơn hay không
• Qua đó có thể xác định khu vực nào trên Trái Đất đã trải qua nhiều biến đổi khí hậu nhất và đã có những dạng thay đổi nào
• Để thực hiện kiểu phân tích này ở quy mô toàn cầu, cần tăng tốc độ truy vấn của kho dữ liệu và lượng dữ liệu là cực kỳ lớn
• Bước đầu tiên là nạp dữ liệu vào PostgreSQL. Việc dùng TimescaleDB để tăng tốc truy vấn chuỗi thời gian và PostGIS để tăng tốc truy vấn địa không gian có vẻ đầy hứa hẹn

Giới thiệu dữ liệu

• Sử dụng dữ liệu từ sản phẩm tái phân tích khí hậu ERA5 chứ không phải dữ liệu quan trắc thực tế
• ERA5 là kết quả chạy mô hình khí hậu có ràng buộc bởi dữ liệu quan trắc; ở nơi có nhiều quan trắc thì dữ liệu gần với quan trắc, còn ở nơi không có quan trắc thì dữ liệu vẫn nhất quán về mặt vật lý và phù hợp với thống kê khí hậu
• ERA5 cung cấp dữ liệu theo giờ cho toàn cầu từ năm 1940 với độ phân giải 0,25 độ. Với từng biến như nhiệt độ, lượng mưa, độ mây che phủ, tốc độ gió..., dữ liệu có hơn 750 triệu dòng
• Việc chèn nhanh lượng dữ liệu này vào cơ sở dữ liệu quan hệ không hề dễ

Các cách chèn dữ liệu

Câu lệnh insert từng dòng

• Đây là cách đơn giản nhất nhưng rất chậm. Với tốc độ 3.000 bản ghi mỗi giây, sẽ mất khoảng 8 năm để nạp toàn bộ dữ liệu
• Có quá nhiều overhead như phân tích cú pháp, kiểm tra bảng/cột, lập kế hoạch thực thi, khóa bảng, ghi bộ đệm, ghi đĩa, commit...

Insert nhiều giá trị

• Chèn nhiều dòng bằng một câu lệnh insert. Giảm overhead mạng, phân tích cú pháp và lập kế hoạch thực thi
• psycopg3 là nhanh nhất với 25.000~30.000 bản ghi mỗi giây
• Tuy vậy vẫn cần khoảng 10 tháng để nạp toàn bộ dữ liệu

Câu lệnh copy

• Đây là cách được tối ưu cho nạp dữ liệu khối lượng lớn. Có thể đọc trực tiếp từ tệp CSV hoặc nhị phân để tối ưu phân tích cú pháp, lập kế hoạch và việc sử dụng WAL
• Nếu đã có sẵn CSV thì có thể dùng câu lệnh copy rất đơn giản
• Tính năng copy của psycopg3 có thể chèn hơn 100.000 bản ghi mỗi giây. Tính cả overhead thì vẫn có thể nạp toàn bộ dữ liệu trong vòng 3 tháng
• Khi chèn tốc độ cao trong thời gian dài bằng copy, cần chú ý các điểm nghẽn có thể phát sinh

Copy song song

• Thực hiện nhiều tác vụ copy song song để tăng tốc độ
• Việc chèn vào một bảng duy nhất không thu được nhiều lợi ích từ song song hóa, nên trên 16 worker thì hầu như không còn cải thiện hiệu năng

Sử dụng công cụ bên ngoài

• Benchmark với pg_bulkload và timescaledb-parellel-copy
• pg_bulkload nhanh hơn nhưng mặc định bỏ qua WAL nên không an toàn
• timescaledb-parallel-copy có thể chèn an toàn hơn 300.000 bản ghi mỗi giây với nhiều worker

Điều chỉnh cấu hình PostgreSQL

• Có thể tắt fsync và full_page_writes để tránh ghi đĩa và tăng tốc, nhưng rất rủi ro
• Bảng unlogged cũng không dùng WAL nên nhanh hơn, nhưng có thể bị cắt cụt khi crash. Hypertable không thể là unlogged

Vậy cách tốt nhất là gì?

• Tốt nhất là dùng psycopg3 để copy trực tiếp vào hypertable. Nếu là tệp CSV thì dùng timescaledb-parallel-copy
• Mức song song hóa phù hợp là khoảng 12~16 worker
• Nếu nới lỏng các quy tắc thì có thể đạt tới 460.000 bản ghi mỗi giây, nhưng đi kèm rủi ro
• Có thể đạt tốc độ cao hơn nữa nếu nâng cấp phần cứng
• ClickHouse có thể nhanh hơn, nhưng tác giả chọn TimescaleDB vì muốn học PostgreSQL
• Với 460.000 bản ghi mỗi giây, có thể nạp toàn bộ dữ liệu trong vòng 20 ngày

Ý kiến của GN⁺

• Nỗ lực đưa dữ liệu ERA5 vào cơ sở dữ liệu quan hệ để phân tích khá thú vị. Trước đây, việc phân tích trực tiếp dữ liệu NetCDF bằng xarray hoặc dask là phổ biến hơn, nhưng nếu xây dựng kho dữ liệu thì có thể thực hiện những truy vấn phức tạp hơn.
• Điều gây ấn tượng là phần cứng của tác giả đã 5 năm tuổi mà vẫn có thể nạp 460.000 bản ghi mỗi giây. Với phần cứng hiện đại hơn, có lẽ đạt 1 triệu bản ghi mỗi giây cũng khả thi. Tuy nhiên, việc tắt fsync và full_page_writes có thể làm tổn hại tính toàn vẹn của DB nên cần cẩn trọng.
• Có vẻ tính năng xử lý song song của PostgreSQL không giúp được nhiều với một bảng đơn lẻ. Nếu kết hợp xử lý song song với phân vùng, có thể đạt hiệu năng cao hơn. Cũng đáng cân nhắc các giải pháp mở rộng theo chiều ngang cho Postgres như Citus.
• Việc ERA5 có thể được dùng cho phân tích biến đổi khí hậu là một điểm thú vị. Điều này cho phép phân tích khí hậu lịch sử ở những khu vực thiếu dữ liệu quan trắc. Tuy nhiên, ERA5 suy cho cùng vẫn là đầu ra của mô hình. Dù đã được hiệu chỉnh bằng dữ liệu quan trắc, vẫn cần tính đến mức độ bất định.
• Với nền tảng phân tích, việc dùng các kho dữ liệu đám mây như Snowflake hay BigQuery là phổ biến hơn. Nhưng như tác giả, tự vận hành phần cứng để học hỏi cũng rất có ý nghĩa. Đặc biệt, dữ liệu khí hậu có dung lượng lớn nên không dễ chuyển hết lên cloud. Có thể kỳ vọng vào các kết quả phân tích thực tế trong tương lai.

[jangsc0000]

Ý kiến trên GN+ đang dùng kính ngữ à..?

[GN⁺]

Ý kiến trên Hacker News

Tóm tắt như sau:

• Khi phân tích dữ liệu địa không gian, việc hiểu hệ tọa độ (CRS) và phép chiếu bản đồ là rất quan trọng. Với các tác vụ địa không gian quy mô lớn, Google BigQuery là lựa chọn tốt nhất.

• Việc cơ sở dữ liệu quan hệ có phù hợp với dữ liệu thời tiết dạng lưới hay không cần được kiểm chứng bằng thực nghiệm.

• Lý do Hypertable trên Timescale chậm có thể là do chỉ mục cột timestamp được tạo mặc định. Nên bỏ qua việc tạo chỉ mục bằng tùy chọn create_default_indexes=>false hoặc tạo chỉ mục sau khi nạp dữ liệu.

• Phân tích về lợi ích của việc chuyển dữ liệu thời tiết sang RDBMS vẫn còn thiếu. Dùng serverless + object storage cũng có thể đạt tốc độ phản hồi rất nhanh.

• Hầu hết các bộ dữ liệu thời tiết/khí hậu như ERA5 đều được cấu thành từ lưới vĩ độ-kinh độ đều đặn, nên không nên phá vỡ hoàn toàn cấu trúc đó. Tốt hơn là tận dụng các phiên bản được tối ưu cho đám mây như ARCO-ERA5.

• Trong PostgreSQL, tắt WAL và chạy định kỳ lệnh VACUUM FREEZE có thể giúp tăng thêm hiệu năng khi nạp lượng dữ liệu lớn.

• Nếu không thể dùng COPY, một cách hay khác là mã hóa các hàng thành chuỗi JSON, gửi chúng như một tham số truy vấn duy nhất và dùng json_to_recordset.