TimescaleDB'ye 1 trilyon hava durumu verisi yükleme

Hava durumu veri ambarı kurmak Bölüm 1: TimescaleDB'ye 1 trilyon satır hava durumu verisi yüklemek

Yaptığımız işin anlamı

Neden bir hava durumu veri ambarı kuruyoruz?

• İklim değişikliğinin işaretlerini analiz etmek için dünyanın dört bir yanındaki geçmiş hava durumu verilerini toplayıp incelemenin iyi bir fikir olduğunu düşündük
• Büyük ölçekli bir hava durumu veri ambarı olursa, Jakarta'nın gerçekten daha sıcak hale gelip gelmediğini ya da fırtınaların şiddetlenip şiddetlenmediğini, Şili'nin genel olarak daha sıcak veya daha bulutlu hale gelip gelmediğini bölge bazında görebiliriz
• Böylece dünyanın hangi bölgelerinin en fazla iklim değişikliği yaşadığını ve ne tür değişimler olduğunu tespit etmek mümkün olur
• Bu analizi küresel ölçekte yapmak için veri ambarı sorgularını hızlandırmak gerekiyor ve veri miktarı son derece büyük
• İlk adım verileri PostgreSQL'e yüklemek. Zaman serisi sorgularını TimescaleDB ile, coğrafi uzamsal sorguları da PostGIS ile hızlandırmak umut verici görünüyor

Veri hakkında

• Gerçek gözlem verileri yerine ERA5 iklim yeniden analiz (climate reanalysis) ürün verileri kullanılıyor
• ERA5, gözlem verileriyle kısıtlanan bir iklim modelinin çalıştırılması sonucu elde ediliyor; gözlemin çok olduğu yerlerde gözlemlere benziyor, gözlemin olmadığı yerlerde ise fiziksel olarak tutarlı kalıyor ve iklim istatistikleriyle uyumlu oluyor
• ERA5, 1940'tan itibaren tüm dünyayı 0,25 derece çözünürlükte saatlik verilerle kapsıyor. Sıcaklık, yağış, bulutluluk, rüzgar hızı gibi her değişken için 750 milyondan fazla satır veri var
• Bu veriyi ilişkisel bir veritabanına hızlıca eklemek kolay değil

Veri ekleme yöntemleri

Tek satırlı insert ifadesi

• En basit yöntem ama çok yavaş. Saniyede 3000 ekleme hızında tüm veriyi yüklemek yaklaşık 8 yıl sürüyor
• Söz dizimi ayrıştırma, tablo/sütun doğrulama, yürütme planı, tablo kilidi, tampon yazımı, disk yazımı, commit gibi ek yükler fazla

Çoklu değerli insert

• Tek bir insert ifadesiyle birden fazla satır ekleniyor. Ağ, söz dizimi ayrıştırma ve yürütme planı ek yükü azalıyor
• psycopg3 saniyede 25.000~30.000 kayıtla en hızlı seçenek
• Ancak yine de tüm veriyi yüklemek yaklaşık 10 ay sürüyor

copy ifadesi

• Büyük hacimli veri yükleme için optimize edilmiş yöntem. CSV veya ikili dosyalardan doğrudan okuyarak ayrıştırma, planlama ve WAL kullanımını optimize ediyor
• Elinizde zaten CSV varsa doğrudan copy ifadesi kullanmak kolay
• psycopg3'ün copy özelliği saniyede 100 binden fazla kayıt ekleyebiliyor. Ek yük hesaba katılsa bile tüm veriyi 3 ay içinde yüklemek mümkün
• copy ile uzun süre yüksek hızda ekleme yaparken darboğazlara dikkat etmek gerekiyor

Paralel copy

• Birden fazla copy işini paralel çalıştırarak hız artırılıyor
• Tek tabloya ekleme yapıldığında paralelleştirmenin etkisi büyük olmuyor; 16 worker'ın üstünde performans artışı görülmüyor

Harici araç kullanımı

• pg_bulkload ve timescaledb-parellel-copy için benchmark yapılmış
• pg_bulkload daha hızlı ama varsayılan olarak WAL'ı atladığı için güvenli değil
• timescaledb-parallel-copy, birden fazla worker ile saniyede 300 binden fazla kaydı güvenli şekilde ekleyebiliyor

PostgreSQL ayarlarını değiştirme

• fsync ve full_page_writes kapatılırsa disk yazımı azaltılarak daha yüksek hız elde edilebilir, ancak bu riskli
• unlogged tablolar da WAL kullanmadığı için hızlı, fakat çökme durumunda kırpılıyor. hypertable'lar unlogged olamıyor

En iyi yöntem ne?

• Veriyi doğrudan hypertable'a psycopg3 ile copy etmek en iyi seçenek. CSV dosyaları içinse timescaledb-parallel-copy kullanılmalı
• Paralelleştirme için 12~16 worker uygun
• Kurallar gevşetilirse saniyede 460 bin kayda kadar çıkılabiliyor ama bu riskli
• Donanım yükseltmesiyle daha da yüksek hızlar mümkün
• ClickHouse daha hızlı olabilir ama PostgreSQL öğrenmek istediği için TimescaleDB tercih edilmiş
• Saniyede 460 bin kayıtla tüm veri 20 gün içinde yüklenebilir

GN⁺ görüşü

• ERA5 verisini ilişkisel bir veritabanına koyup analiz etmeye çalışmaları ilgi çekici. Şimdiye kadar xarray veya dask ile NetCDF verisini doğrudan analiz etmek daha yaygındı, ancak bir veri ambarı kurulursa daha karmaşık sorgular çalıştırmak mümkün olabilir.
• Yazarın donanım özellikleri 5 yıl öncesine ait olmasına rağmen saniyede 460 bin kayıt ekleyebilmesi etkileyici. Güncel donanımla saniyede 1 milyon kayıt da mümkün olabilir. Ancak fsync ve full_page_writes ayarlarını kapatmak veritabanı bütünlüğünü bozabileceği için dikkatli olmak gerekir.
• PostgreSQL'in paralel işleme özellikleri tek bir tablo üzerinde çok yardımcı olmuyor gibi görünüyor. Paralel işleme ile partitioning birleştirilirse daha yüksek performans elde edilebilir. Citus gibi PostgreSQL'in yatay ölçekleme çözümleri de değerlendirilebilir.
• ERA5 verisinin iklim değişikliği analizinde kullanılabilmesi ilgi çekici. Gözlem verisinin yetersiz olduğu bölgelerin geçmiş iklimini incelemek mümkün olabilir. Ancak ERA5'in nihayetinde bir model çıktısı olduğu unutulmamalı. Gözlem verileriyle düzeltilmiş olsa da belirsizlik içerdiği hesaba katılmalı.
• Analiz platformu olarak genelde Snowflake veya BigQuery gibi bulut veri ambarları kullanılıyor. Ancak yazarın yaptığı gibi kendi donanımıyla uğraşıp öğrenmek de oldukça değerli. Özellikle iklim verisi çok büyük olduğu için bunu buluta taşımak kolay değil. Bundan sonra ortaya çıkacak gerçek analiz sonuçları merak uyandırıyor.

[jangsc0000]

GN+ yorumları resmî hitapla yazılmış gibi duruyor..?

[GN⁺]

Hacker News görüşü

Özetle şöyle:

• Coğrafi uzamsal veri analizi yaparken koordinat sistemi (CRS) ve harita projeksiyonlarını anlamak önemlidir. Büyük ölçekli coğrafi uzamsal işler için Google BigQuery en iyisidir.

• İlişkisel veritabanlarının ızgara tabanlı hava durumu verileri için uygun olup olmadığı deneylerle anlaşılmalıdır.

• Timescale'de Hypertable'ın yavaş olmasının nedeni, varsayılan olarak oluşturulan timestamp sütun indeksi olabilir. create_default_indexes=>false seçeneğiyle indeks oluşturmayı atlamak veya veriyi girdikten sonra indeks oluşturmak daha iyidir.

• Hava durumu verilerini RDBMS'e taşımanın ne gibi avantajlar sağladığına dair analiz yetersizdir. Serverless + nesne depolama ile de çok hızlı yanıt süreleri elde edilebilir.

• ERA5 gibi çoğu hava durumu/iklim veri kümesi düzenli enlem-boylam ızgaralarından oluşur; bu yüzden yapıyı tamamen bozmak iyi bir fikir değildir. ARCO-ERA5 gibi buluta optimize edilmiş sürümleri kullanmak daha iyidir.

• PostgreSQL'de WAL'ı kapatıp VACUUM FREEZE komutunu periyodik olarak çalıştırmak, büyük veri yüklemelerinde performansı daha da artırabilir.

• COPY kullanılamıyorsa, satırları JSON dizgeleri olarak kodlayıp tek bir sorgu parametresiyle göndermek ve json_to_recordset kullanmak da iyi bir yöntemdir.