Büyük veri işleme yükleri, özellikle bulut üzerinde çalışanlar, genellikle veri kaynağı olarak nesne depolama hizmetlerinden (S3, Google Cloud Storage, Azure Blob Storage vb.) yararlanır. Nesne depolama hizmetleri, devasa miktarda veriyi saklayıp sunabilme kapasitesine sahiptir; fakat en iyi performansı elde etmek için yükünüzü, uzak nesne depolarının davranışlarına uygun hale getirmeniz gerekebilir. Bu yazı, RAPIDS kullanıcılarının nesne depolama ile veri okuma veya yazma işlemlerini mümkün olan en hızlı şekilde yapmalarına yardımcı olmak amacıyla hazırlanmıştır, böylece IO aşamasında darboğaz yaşanmaz.
Yerel dosya sistemlerinin nasıl davrandığına dair bazı bilgilere sahip olmanız, uzaktaki nesne depoları için de geçerlidir; ancak bu ikisi temelde farklıdır. Belki de en büyük fark, en azından veri analizi iş yükleri açısından, nesne depolama üzerindeki okuma ve yazma işlemlerinin daha yüksek ve değişken gecikmelere sahip olmasıdır. Her depolama hizmetinin kendine özgü en iyi uygulamalar ve performans kılavuzları bulunmaktadır (AWS, Azure). Burada, veri analizi iş yüklerine odaklanarak bazı genel yönergeler vereceğiz.
Konum
Hesaplama düğümlerinizi depolama hizmetine yakın bir konumda (ideal olarak aynı bulut bölgesinde) yerleştirmeniz, iş yükünüzü yürüten makineler ile verileri sunan makineler arasındaki ağa en hızlı ve en güvenilir bağlantıyı sağlayacaktır. Nihayetinde, veri transferi ışık hızı ile sınırlı olduğu için fiziksel mesafeyi minimumda tutmak her zaman faydalıdır.
Dosya Formatı
“Bulut yerel” dosya formatları, nesne depolama ile uyumlu çalışacak şekilde geliştirilmiştir. Bu dosya formatları, meta verilere (sütun adları veya veri türleri gibi yüksek seviye bilgilere ve dosyada belirli veri alt kümelerinin nerede bulunduğu gibi düşük seviye bilgilere) hızlı ve kolay erişim sunar. Apache Parquet, Zarr ve Cloud Optimized GeoTIFF gibi formatlar, çeşitli veri türleri için bulut yerel dosya formatlarına örnektir.
Nesne depolama hizmetleri genellikle aralık istekleri gibi yöntemleri desteklediğinden, istemciler (örneğin, cuDF) meta verileri okuyabilir ve ardından yalnızca ihtiyaç duyduğu veriyi indirebilir. Örneğin, cuDF, birçok sütun içeren bir Parquet dosyasından yalnızca birkaç sütunu okuyabilir veya bir Zarr istemcisi, büyük bir n-boyutlu dizinin tek bir parçasını okuyabilir. Bu okuma işlemleri yalnızca birkaç HTTP isteği ile gerçekleştirilir ve gereksiz verilerin indirilmesi, filtrelenmesi gerekmeksizin yapılır.
Dosya Boyutu
Her okuma işleminin (en az) bir HTTP isteği gerektirmesi nedeniyle, her HTTP isteğinden kaynaklanan yükü makul sayıda bayt üzerinde yaymayı tercih ederiz. Verileri yazma sürecini kontrol ediyorsanız, dosyaların yeterince büyük olmasını sağlamalısınız; böylece sonraki işleme işlemleri iyi bir performans elde edebilir. Optimal değer, iş yükünüze bağlıdır; ancak Parquet dosyaları için birkaç düzine ile düşük yüzlerce MB arası boyutlar yaygındır.
Bununla birlikte, dosya boyutunun bir sonraki araç olan eşzamanlılıkla nasıl etkileşime girdiğine dikkat etmeniz gerekir.
Eşzamanlılık
Birçok blob’u (veya tek bir blob’un birden fazla parçasını) aynı anda indirmek için eşzamanlılık kullanmak, uzak bir depolama hizmetinden iyi performans elde etmenin kritik bir unsuru haline gelir. Çünkü bu bir uzak hizmet olduğundan, süreciniz, HTTP isteğinin gönderilmesi ile yanıtın alınması arasında bir miktar (belki de çok zaman) boş beklemek zorunda kalacaktır. Bu bekleme süresi, ağın isteği iletmesi, depolama hizmetinin isteği işleyip yanıtı göndermesi ve ağın (muhtemelen büyük) yanıtı iletmesi için gereklidir. Bu istek/yanıt döngüsünün bazı bölümleri, veri miktarı ile ölçeklenebilirken, diğer kısımlar sabit yükten ibarettir.
Nesne depolama hizmetleri, birçok eşzamanlı isteği işlemek üzere tasarlanmıştır. Bekleme süresini değerlendirerek, toplam çıktı oranını artırmak için çok sayıda eşzamanlı istek yapabiliriz. Python’da bu genellikle bir iş parçacığı havuzu kullanılarak yapılır:
pool = concurrent.futures.ThreadPoolExecutor()
futures = pool.map(request_chunk, chunks)
Ya da asyncio kullanarak:
tasks = [request_chunk_async(chunk) for chunk in chunks]
await asyncio.gather(*tasks)
Birçok okuma isteğinin en aynı anda beklemesi, toplam çıktı oranımızı artırmaktadır. Her iş parçacığı/görev çoğunlukla hiçbir şey yapmadığı için, optimum yükünüz için çekirdek sayınızdan daha fazla iş parçacığı/görev olması sorun değil. Yeterli sayıda eşzamanlı istek varsa, nihayetinde depolama hizmetinizi doyurabilirsiniz; çünkü bu hizmet, karşılamaya çalıştığı bazı istek sayısı ve bant genişliği hedeflerine sahiptir. Ancak bu hedefler oldukça yüksektir; genellikle yüklemenizi doyurmak için birçok makineye ihtiyacınız olabilir ve çok yüksek çıkış oranları elde etmelisiniz.
Kütüphaneler
Yukarıda belirtilen her şey, nesne depolama hizmetinden uzak IO yapan hemen hemen tüm kütüphaneler için geçerlidir. RAPIDS bağlamında, NVIDIA KvikIO dikkat çekicidir çünkü:
- Geniş okuma isteklerini otomatik olarak birçok daha küçük isteğe böler ve bu istekleri eşzamanlı olarak gerçekleştirir.
- Veri veya cihaz belleğine verimli bir biçimde okuyabilir, özellikle GPU Direct Storage etkinleştirildiğinde.
- Hızlıdır.
RAPIDS 24.12 sürüm duyurusunda belirtildiği gibi, KvikIO, S3’ten okuma işlemi yaparken etkileyici bir bant genişliği elde edebilir. Şimdi, bu performans testlerine bir göz atalım.
Performans Testleri
KvikIO bir dosya okumak istediğinde, bu okuma işlemini kvikio.defaults.task_size baytlık daha küçük okumalara böler. Bu okuma isteklerini, kvikio.defaults.num_threads iş parçacığı ile bir thread havuzu kullanarak paralel bir şekilde gerçekleştirir. Bu değerler, ortam değişkenleri KVIKIO_TASK_SIZE ve KVIKIO_NTHREADS ile veya Python üzerinden şöyle kontrol edilebilir:
with kvikio.defaults.set_num_threads(num_threads), kvikio.defaults.set_task_size(size):
...
Runtime Settings‘e göz atabilirsiniz.
Aşağıdaki grafik, 1 GB’lık bir blob’un S3‘ten, aynı bölgede bulunan bir g4dn EC2 örneğine aktarımının, thread havuzundaki çeşitli boyutlar için megabit cinsinden sağladığı bant genişliğini göstermektedir (daha yüksek değerler daha iyidir).
kvikio.defaults.num_threads değerleri ile sağladığı bant genişliği. Bant genişliği, thread sayısını artırdıkça artmaktadır.Daha az thread (dörtten az) daha düşük bant genişliği elde eder ve dosyanın okunması daha uzun sürmektedir. Daha fazla thread (64, 128, 256) depolama hizmetine paralel olarak sunulan istekleri artırarak daha yüksek bant genişliği elde eder. Depolama hizmetinin, ağın veya sisteminizdeki diğer darboğazların sınırlarına ulaşıldığında azalan ve hatta negatif getiriler gözlemlenebilir.
Uzak IO’da her thread, yanıtı bekleyen nispeten uzun bir süre boyunca atıl durumda kalır; buna bağlı olarak, iş yükünüze göre, çekirdek sayınıza göre daha fazla thread (ihtimallerin üstünde) kullanmak uygun olabilir. Bu durumda, en yüksek bant genişliği genellikle 64 ile 128 thread arasında elde edilir.
Aşağıdaki grafik, görev boyutunun maksimum bant genişliğini nasıl etkilediğini göstermektedir.
Görev boyutu çok küçük (yaklaşık ya da 4 MiB altında) veya çok büyük (yaklaşık ya da 128 MiB üzerinde) olmamak şartıyla, 10 Gbps seviyelerinde bant genişliği elde edebiliriz. Görev boyutu küçük olduğunda, çok sayıda HTTP isteği yapılmasının aşırı yüklenmesi bant genişliğini azaltır. Görev boyutu büyük olduğunda, yeterli eşzamanlılık elde edemediğimiz için bant genişliği sınırlıdır.
KvikIO, bu iş yükünde, boto3 ile karşılaştırıldığında daha yüksek bir bant genişliği sağlamaktadır, hatta boto3 kullanılarak thread havuzunda istekler eşzamanlı olarak gerçekleştirildiğinde bile.
Biraz daha gerçekçi bir iş yükü olarak, toplam yaklaşık 46 GB olan 360 adet Parquet dosyasının okunma performansını karşılaştırıyoruz. Bu dosyaların her biri yaklaşık 128 MB boyutundadır ve işlem g4dn.12xlarge bir AWS örneğinde gerçekleştirilmiştir, bu örneğin 4 NVIDIA T4 GPU’su ve 48 sanal işlemci içermektedir.
KvikIO etkinleştirildiğinde, dört Dask işçi süreci, toplamda neredeyse 20 Gbps bant genişliğinde S3’ten veri alabilmektedir.
Sonuç
Eğer RAPIDS diğer bölümlerde hızlandırmalar yaparken IO, bir darboğaza dönüşebilir. Eğer nesne depolama kullanıyorsanız ve verilerinizi yüklerken beklemekten sıkılmadıysanız; bu yazıdaki bazı önerileri deneyebilirsiniz. KvikIO ile deneyimleriniz hakkında bilgi almak için GitHub‘da bize ulaşın. Ayrıca GPU hızlandırmalı veri işleme ile alakalı olarak RAPIDS Slack topluluğuna katılarak 3,500’den fazla üye ile de iletişime geçebilirsiniz.
