Gündeme dön

CPU mu GPU mu? Presto'da SQL'i 4 Kata Kadar Hızlandıran Velox ve cuDF Hamlesi

IBM Developer'da yayımlanan demo, açık kaynak Presto'yu Velox (C++ motor) ve NVIDIA cuDF ile GPU üzerinde koşarak 179 milyon satırlık IBM AML verisinde aynı sorguyu 6 saniyeden 1,6 saniyeye indirdiğini gösteriyor — tek fark Docker imajını gpu-nightly ile değiştirmek.

Nodesdaily’e aktarım: (UTC+03:00)
YouTube'da izle — KRmln6u9QNk
Okuma seçenekleri

Bu tarayıcıda cihazdan sesli okuma kullanılamıyor.

Kavram merceği

Bu görünümde geçen teknik kavramlardan birini seç. Genel tanımı, öğretici örneği ve haberdeki kullanımını birlikte oku.

Bu görünümde sözlüğümüzdeki kavramlardan biri bulunmadı. Sözlük henüz tüm terimleri kapsamıyor.

Her analitik ekibin bildiği darboğazla başlıyoruz: Presto, büyük veri için dağıtık SQL motoru olarak CPU'da doğdu ve veri büyüdükçe sorgu süresi şişiyor. Videoda Roy, William (NVIDIA) ile birlikte aynı derdin GPU ile nasıl kırıldığını gösteriyor. İş birliği IBM, NVIDIA ve Presto topluluğundan geliyor; hedef, mevcut veri ambarını taşımadan üzerine GPU hızlandırmalı bir motor eklemek. Vaat basit: Java tabanlı Presto yerine Velox adlı C++ tabanlı yürütme katmanıyla çalışan Presto, aynı SQL'i paralel donanımda koşsun. Tıpkı tek şeritli yolu sekiz şeritli otoyola çevirmek gibi — araç aynı, yolun şerit sayısı artıyor.

Presto nedir sorusunu kısaca netleştirelim. Facebook'ta 2012'de doğan Presto, depolama ile hesaplamayı ayıran, coordinator ve worker'larla ölçeklenen açık kaynak bir dağıtık SQL motoru. 2019'da topluluk PrestoDB ve Trino olarak ikiye ayrıldı; Linux Foundation altındaki PrestoDB bugün prestodb/presto ve Presto Foundation çatısında yaşıyor. Klasik Presto Java'da koşar. Velox ise Meta'nın geliştirdiği vektörel, sütunsal (columnar) C++ yürütme kütüphanesi (Presto C++ / Presto Native'in kalbi). Velox, JVM yükünü atıp veriyi vektörler halinde işleyerek aynı sorgu planını daha yakın donanıma çevirir. cuDF ile buluştuğunda ise bu plan GPU çekirdeklerine dağılır. Analoji: Java orkestrası yerine C++'ın doğrudan sahneye çıkan küçük ve hızlı ekibi.

GPU tarafındaki sihir NVIDIA cuDF ve onun yeni uzantısı cuDF-X üzerinden geliyor. cuDF, RAPIDS (artık NVIDIA CUDA-X) ailesinde GPU DataFrame kütüphanesi — altında libcudf ve pylibcudf var, join, aggregate, filter ve sort gibi işlemleri binlerce CUDA çekirdeğinde paralel koşar. Videodaki anlatıyla birebir örtüşüyor: veri çerçevesini al, birleştir, grupla, hesapla — bunların hepsi GPU'da hızlanır. Darboğaz ise veriyi GPU belleğine (VRAM) taşımak. William'ın altını çizdiği nokta kritik: 100 satırlık sorguyu GPU'ya taşımak anlamsız, taşıma maliyeti kazancı yutar; ama 179 milyon satırda grupla ve sırala gibi toplu işlemler paralelleşince kazanç belirginleşiyor. 2026'daki GB200 NVL72 ve DGX B200 testleri de aynı içgörüyü doğruluyor — NVLink ile operatörler arası veri GPU belleğinden çıkmadan aktarılabilirse gecikme düşüyor.

Videodaki pratik kurulum üç defterden (notebook) oluşuyor ve hepsi Presto Foundation'ın Prestorials deposunda duruyor. İlk defter Docker Compose ile Presto Native kümesini ayağa kaldırıyor. Adımlar net: host üzerinde metastore ve warehouse dizinlerini oluştur, Presto için config dosyalarını yaz, sonra docker compose ile coordinator ve worker'ı başlat. Doğrulama hücresi iki bileşenin de Running olduğunu gösteriyor — biri CPU coordinator, diğeri CPU worker. Ardından birkaç basit sorgu ile kümenin sağlıklı olduğu teyit ediliyor. Bu, veri ambarını sıfırdan kurmak yerine var olan host verisi üzerinde çalışan minimal bir Presto kümesi — altyapı ekiplerinin sevdiği, tek komutla ayağa kalkan laboratuvar düzeni.

İkinci defter büyük veriyi ekliyor. Kullanılan küme IBM'in kara para aklamayı önleme (AML) için ürettiği sentetik işlem verisi. Kaynak Kaggle'da "IBM Transactions for Anti Money Laundering" ve Hugging Face'te de aynısı var; satır sayısı ölçeğe göre değişiyor, büyük ölçekte yaklaşık 176 milyon satır. Veri, banka transferleri, alışverişler ve kredi kartı işlemlerini taklit eden finansal işlem satırlarından oluşuyor — GNN ve foundation model araştırmalarında da sık kullanılıyor. Defter bu veriyi warehouse'a yükleyip yine doğrulama hücresiyle kümenin ayakta olduğunu ve basit sorguların döndüğünü gösteriyor. Bu adım, benchmark'ın gerçekçi hacmini kuruyor; sentetik de olsa hacim ve şema prod benzeri analitik yükü temsil ediyor.

Üçüncü defter asıl yeniliği getiriyor: mevcut ambarı kopyalayıp üzerine GPU hızlandırmalı motoru eklemek. Ekranda Explorer'da duran config ve metadata'nın birebir kopyası oluşturuluyor, ardından GPU için birkaç ek özellik ekleniyor ve GPU kümesi başlatılıyor. Başlatma hızlı görünüyor ama ilk doğrulamada State hâlâ Starting, ikinci denemede Running oluyor. Sonra küçük bir duman testi: select star limit 1. William özellikle not ediyor, ilk sorgu VRAM'deki ikili dosyaları ayağa kaldırdığı için bir saniye kadar sürüyor — bu ısınma maliyeti normal. Ardından kritik tasarım kararı geliyor: GPU tarafı bilerek salt okunur (read-only) ayarlanmış. Gerekçe, aynı veriye iki yazma akışı çarpışıp dosyayı bozmasın; halihazırda rapor ve işler CPU kümesinde koşarken GPU motoru sadece okusun isteniyor. Yalnızca GPU motoru koşacaksa bu kısıt kaldırılabilir.

Ve kafa kafaya test. Aynı sorgu — çok ağır değil ama tüm satırlar üzerinde gruplama ve sıralama yapıp 10 satır döndüren bir analitik sorgu — hem CPU hem GPU motoruna sırayla gönderiliyor. Kod, CPU ve GPU için ayrı bağlantı ve imleç (connection/cursor) açan bir döngü kuruyor, her sorguyu zamanlayarak koşuyor. Sonuç ekranda net: CPU yaklaşık 6 saniye, GPU 1,6 saniye. Hesapla 3,75 kat hız, videoda yuvarlatılarak dört ila beş kat olarak anılıyor. Docker tarafındaki fark da bir o kadar minimal: coordinator imajı prestodb/presto:latest yerine gpu-nightly, worker prestodb/presto-native:latest yerine gpu-nightly; Jupyter'de yan yana konan açık tema karşılaştırma hücresi bu iki satırlık farkı vurguluyor. Yani var olan ambarı kopyala, imaj etiketini değiştir, birkaç GPU özelliği ekle — hız kazancı bu kadar yakın.

Genel resme çekildiğimizde tablo birleşiyor. Prestorials deposundaki üç defter, üretimdeki bir veri ambarının yanına ikinci bir hız katmanı koymayı gösteriyor; veriyi taşımadan, aynı SQL'i koruyarak. IBM ve NVIDIA'nın Velox + cuDF entegrasyonu, Mart 2026'da arXiv'e konan VLDB çalıştay bildirisinde de anlatıldığı gibi, depolamadan GPU operatörlerine veri taşıma ve operatörler arası alışverişi GPU belleğinde tutma gibi iki kritik zorluğu çözmeye odaklanıyor. İlk değerlendirmede TPC-H türevi sorgularda maliyet/performansta 6 kata varan iyileşme raporlanıyor. Video, laboratuvar ölçeğinde 179 milyon satırda 6'ya karşı 1,6 saniyelik somut kanıtı veriyor. Son mesaj pratik: GPU hızlandırmalı Presto'yu denemek isterseniz Prestorials'ı klonlayıp aynı defterleri koşabilir, yorumlarda kendi hız kazancınızı paylaşabilirsiniz.

Görsel: nodesdaily AI
PlatformSüreHız Faktörü
CPU (Presto Native)6,0 sn1×
GPU (Presto + Velox/cuDF)1,6 sn3,8×

AI yorumu

"Benim gözümde bu video, veri ambarı ekiplerinin en sevdiği cümleyi doğruluyor: donanımı değil, yürütme motorunu değiştirerek hız kazanabilirsiniz. 176 milyon satırda 3,75 kat hız, gece sürümü imajla gelen iki satırlık config farkı için oldukça cömert — ama VRAM'a ilk yüklemenin bedelini ve küçük sorgularda CPU'nun hâlâ mantıklı olduğunu unutmamak gerekiyor."

AI değerlendirmesi

Karşıt görüşü en güçlü haliyle kurarsak, CPU hâlâ birçok işte rasyonel seçim. 100 satırlık filtre veya tekil nokta sorgusunda veriyi VRAM'a taşıma maliyeti kazancı siler; küçük boyutlu, sık ve etkileşimli sorgular ile yazma ağırlıklı iş yüklerinde JVM tabanlı Presto ve hatta Postgres benzeri sistemler daha basit ve ucuz kalır. Mevcut pipeline'ı, izleme ve güvenlik sertifikasyonlarını GPU nightly imajına taşımak da operasyonel risk taşır — nightly etiketi stabilite sözünü vermez.

Sınırlar ve yöntem notları da net. Video tek bir node üzerinde, aynı Docker host'ta çalışan iki kümeyi karşılaştırıyor; network shuffle ve çok node'lu dağıtık değişim ölçülmüyor. İlk sorgunun VRAM ısınma maliyeti raporda ayrı kalem değil; ikinci ve sonraki sorgular daha iyi görünür. VRAM kapasitesi —GB200'de bile 13,5 TB HBM3e / 17 TB LPDDR5X ile sınırlı— veriyi aşan tablolarda spill veya parçalama gerekir. Ayrıca IBM AML verisi sentetik; gerçek prod çarpıklığı, null oranı ve kardinalite farkları planlayıcıyı başka yola sokabilir.

Kimin iddiası ve ne doğrulanmalı? Hız iddiası videodaki 6'ya karşı 1,6 saniyelik ölçüm ve IBM-NVIDIA'nın arXiv 2606.24647 bildirisindeki 6 kata varan maliyet/performans vurgusuna dayanıyor. Bağımsız tekrar için Prestorials defterleri açık, TPC-H türevi sorgularla aynı veri hacminde ve aynı instance tipinde ölçüm tekrarlanmalı; GB200 NVL72 blogundaki DGX B200 sonuçları ise farklı donanım sınıfı olduğu için doğrudan kıyas değil, ölçek referansı olarak okunmalı. NVIDIA CUDA-X / cuDF belgeleri ve Prestodb dokümantasyonu sürüm ve nightly etiketlerinin ne içerdiğini teyit için birincil kaynak.

Pratik çıkarım: tekrarlayan büyük analitik taramalar, gece raporları ve özellik çıkarımı gibi 100 milyon satır üzeri, toplu aggregate/sort içeren işlerde GPU katmanı cazip — özellikle zaten Velox tabanlı Presto Native kullanıyorsanız geçiş iki satırlık config farkı. Etkileşimli küçük sorgular, sık yazma ve maliyet hassasiyeti yüksek ekipler için CPU'da kalmak veya Trino/Spark gibi alternatiflerin kendi hızlandırma yollarını (ör. Spark RAPIDS) değerlendirmek daha sağlıklı. Karar, sorgu boyut dağılımınızı ve VRAM bütçenizi ölçmeden verilmemeli.

Kaynaklar

11 bağlantı; bunları kullanan başka yayımlanmış haber yok. Aynı bağlantıyı paylaşan haberler birbirini doğrulamış sayılmaz; kaynağın kökeni bağlantı sayısından çıkarılmaz.

presto · velox · gpu · nvidia cudf · sql · docker · ibm

Konuyu takip et

Bu haberden önce

Aynı olayla editör tarafından ilişkilendirilmiş önceki haberlerden kısa bir okuma sırası.

Kanıt ve kaynaklar

İzinli kaynak metnini, sürümünü ve köken bilgisini incele.

KAYNAKLARLA OKU

Bu haberi açalım.

Hesap kontrol ediliyor…