Memuat 1 Triliun Data Cuaca ke TimescaleDB

Membangun gudang data cuaca bagian 1: Memuat 1 triliun baris data cuaca ke TimescaleDB

Arti dari apa yang kami lakukan

Mengapa membangun gudang data cuaca

• Terpikir bahwa akan baik untuk mengumpulkan dan menganalisis data cuaca historis dari seluruh dunia guna menganalisis tanda-tanda perubahan iklim
• Jika ada gudang data cuaca berskala besar, kita bisa mengetahui per wilayah apakah Jakarta benar-benar menjadi lebih hangat atau badai makin parah, atau apakah Chile secara umum menjadi lebih panas atau lebih berawan
• Dengan ini, kita dapat mengetahui wilayah mana di Bumi yang mengalami perubahan iklim paling besar, serta jenis perubahan apa yang terjadi
• Untuk melakukan analisis seperti ini secara global, kecepatan kueri gudang data harus ditingkatkan, dan jumlah datanya sangat besar
• Langkah pertama adalah memuat data ke PostgreSQL. Menggunakan TimescaleDB untuk meningkatkan kecepatan kueri deret waktu dan PostGIS untuk meningkatkan kecepatan kueri geospasial tampak menjanjikan

Pengenalan data

• Menggunakan data produk reanalisis iklim ERA5, bukan data observasi nyata
• ERA5 adalah hasil eksekusi model iklim yang dibatasi oleh data observasi; di tempat yang banyak observasinya hasilnya mirip observasi, sedangkan di tempat tanpa observasi hasilnya tetap konsisten secara fisik dan sesuai dengan statistik iklim
• ERA5 menyediakan data per jam untuk seluruh Bumi sejak 1940 dengan resolusi 0,25 derajat. Untuk tiap variabel seperti suhu, curah hujan, tutupan awan, kecepatan angin, dan lain-lain, ada lebih dari 750 juta baris data
• Menyisipkan data ini dengan cepat ke DB relasional bukan hal yang mudah

Metode penyisipan data

Pernyataan insert satu baris

• Metode paling sederhana, tetapi sangat lambat. Dengan 3.000 penyisipan per detik, memuat seluruh data akan memakan waktu sekitar 8 tahun
• Overhead besar berasal dari parsing sintaks, validasi tabel/kolom, rencana eksekusi, penguncian tabel, penulisan buffer, penulisan disk, commit, dan sebagainya

Insert multi-nilai

• Menyisipkan beberapa baris dengan satu pernyataan insert. Overhead jaringan, parsing sintaks, dan rencana eksekusi berkurang
• psycopg3 adalah yang tercepat dengan 25.000~30.000 penyisipan per detik
• Namun tetap memerlukan sekitar 10 bulan untuk memuat seluruh data

Pernyataan copy

• Metode yang dioptimalkan untuk pemuatan data massal. Membaca langsung dari file CSV atau biner sehingga parsing, perencanaan, dan penggunaan WAL lebih optimal
• Jika sudah ada CSV, cukup mudah menggunakan pernyataan copy
• copy di psycopg3 dapat menyisipkan lebih dari 100 ribu baris per detik. Bahkan dengan overhead, seluruh data bisa dimuat dalam kurang dari 3 bulan
• Saat melakukan penyisipan copy berkecepatan tinggi dalam waktu lama, perlu waspada terhadap bottleneck

Copy paralel

• Menjalankan beberapa pekerjaan copy secara paralel untuk meningkatkan kecepatan
• Penyisipan ke satu tabel tidak terlalu diuntungkan oleh paralelisasi, sehingga di atas 16 worker tidak ada peningkatan kinerja berarti

Menggunakan alat eksternal

• Benchmark pg_bulkload dan timescaledb-parellel-copy
• pg_bulkload lebih cepat, tetapi pada dasarnya tidak menggunakan WAL sehingga tidak aman
• timescaledb-parallel-copy dapat menyisipkan lebih dari 300 ribu baris per detik dengan aman menggunakan banyak worker

Menyesuaikan pengaturan PostgreSQL

• Menonaktifkan fsync dan full_page_writes dapat menghindari penulisan disk dan membuatnya lebih cepat, tetapi berisiko
• Tabel unlogged juga tidak menggunakan WAL sehingga cepat, tetapi akan terpotong saat crash. hypertable tidak bisa menjadi unlogged

Metode terbaik?

• Cara terbaik adalah melakukan copy langsung ke hypertable dengan psycopg3. Untuk file CSV, gunakan timescaledb-parallel-copy
• Paralelisasi yang sesuai adalah 12~16 worker
• Jika aturan keselamatan dinonaktifkan, bisa mencapai 460 ribu baris per detik, tetapi berisiko
• Kecepatan lebih tinggi dimungkinkan dengan upgrade hardware
• ClickHouse mungkin lebih cepat, tetapi TimescaleDB dipilih karena ingin mempelajari PostgreSQL
• Dengan 460 ribu baris per detik, seluruh data dapat dimuat dalam 20 hari

Pendapat GN⁺

• Upaya memasukkan data ERA5 ke DB relasional untuk dianalisis cukup menarik. Selama ini biasanya data NetCDF dianalisis langsung dengan xarray atau dask, tetapi dengan membangun gudang data, kueri yang lebih kompleks bisa dijalankan.
• Mengesankan bahwa dengan spesifikasi hardware penulis yang sudah berusia 5 tahun pun bisa memasukkan 460 ribu baris per detik. Dengan hardware terbaru, mungkin 1 juta baris per detik juga memungkinkan. Namun, menonaktifkan fsync dan full_page_writes bisa merusak integritas DB, jadi perlu hati-hati.
• Fitur pemrosesan paralel PostgreSQL tampaknya tidak terlalu membantu untuk satu tabel. Jika paralelisasi digabungkan dengan partisi, kinerja yang lebih tinggi mungkin bisa dicapai. Solusi scale-out horizontal Postgres seperti Citus juga layak dipertimbangkan.
• Menarik bahwa data ERA5 dapat dimanfaatkan untuk analisis perubahan iklim. Ini memungkinkan analisis iklim masa lalu di wilayah yang kekurangan data observasi. Namun, ERA5 pada akhirnya tetap merupakan hasil model. Walau sudah dikoreksi dengan data observasi, keterbatasan berupa ketidakpastian tetap perlu diperhitungkan.
• Sebagai platform analisis, biasanya digunakan gudang data cloud seperti Snowflake atau BigQuery. Namun, belajar sambil menangani hardware sendiri seperti penulis juga sangat bermakna. Terutama karena data iklim berukuran besar, memindahkannya ke cloud tidak mudah. Hasil analisis aktualnya layak dinantikan.

[jangsc0000]

Komentar GN+ menggunakan bahasa formal, ya..?

[GN⁺]

Opini Hacker News

Ringkasnya sebagai berikut:

• Saat menganalisis data geospasial, penting untuk memahami sistem koordinat (CRS) dan metode proyeksi peta. Untuk pekerjaan geospasial skala besar, Google BigQuery adalah yang paling unggul.

• Apakah DB relasional cocok untuk data cuaca berbasis grid perlu dibuktikan lewat eksperimen.

• Alasan Hypertable di Timescale lambat bisa jadi karena indeks kolom timestamp yang dibuat secara default. Sebaiknya lewati pembuatan indeks dengan opsi create_default_indexes=>false, atau buat indeks setelah data dimasukkan.

• Kurang ada analisis tentang keuntungan memindahkan data cuaca ke RDBMS. Dengan serverless + object storage pun bisa mendapatkan waktu respons yang sangat cepat.

• Sebagian besar dataset cuaca/iklim seperti ERA5 terdiri dari grid lintang-bujur yang teratur, jadi tidak baik jika strukturnya dihancurkan sepenuhnya. Lebih baik memanfaatkan versi yang dioptimalkan untuk cloud seperti ARCO-ERA5.

• Di PostgreSQL, mematikan WAL dan menjalankan perintah VACUUM FREEZE secara berkala dapat lebih meningkatkan performa saat memuat data dalam jumlah besar.

• Jika tidak bisa menggunakan COPY, mengenkode baris sebagai string JSON lalu mengirimkannya sebagai satu parameter kueri dan menggunakan json_to_recordset juga merupakan cara yang baik.