kdb+’ın geleceği?
(timestored.com)- Finans sektöründe kdb+, geçmiş piyasa verisi analizi ve gerçek zamanlı hesaplamalar için güçlü bir araçtı; ancak artık her kullanım alanında yeterince olgun alternatif teknolojiler ortaya çıktı
- Birçok kullanıcı kdb+’ın sunduğu en yüksek hıza ihtiyaç duymuyor ve banka içi platformlar da bu performansı tam olarak ortaya çıkaramadığı için hız avantajı daha az belirleyici hale geldi
- Yerel quant analizi fiilen Python ekosistemi tarafından domine ediliyor ve DuckDB ile Polars gibi ücretsiz topluluk araçları öğrenme ve iş değiştirme açısından daha avantajlı
- Gerçek zamanlı streaming ve dağıtık hesaplama hâlâ kdb+’ın güçlü yönleri olsa da, kurulum zorluğu ile Kafka, Flink ve RisingWave’in yarattığı mindshare yaygınlaşmayı zorlaştırıyor
- kdb+’ın uzun vadede ayakta kalabilmesi için ücretsiz bir kullanım yolu, çekirdek ürüne odaklanma, öğrenme eğrisini azaltma ve finans dışına açılabilecek daha geniş bir çekicilik gerekiyor
Finans sektöründe kdb+’ın üstlendiği rol
- kdb+, çeşitli finans sistemlerinde ve analiz işlerinde kullanıldı
- Geçmiş piyasa verisinin depolanması ve analizi: MS Horizon, Citi CloudKDB, UBS Krypton gibi örnekler
- Yerel quant analizi: likidite analizi, PnL analizi, müşteri bazında kârlılık analizi
- Gerçek zamanlı streaming hesaplama motoru: Streaming VWAP, Streaming TCA
- Dağıtık hesaplama: hisse portföyü marjin hesaplaması, risk analizi gibi veriyi bölüp hesapladıktan sonra yeniden birleştiren işler
Geçmiş piyasa verisi: mevcut müşteriler kalır ama yeni genişleme zor
- Birçok kullanıcı büyük hacimli veriyi sorgulayıp minute bar üretmek, asof join yapmak veya daha gelişmiş zaman serisi analizi gerçekleştirmek istiyor
- Rakip seçenekler ClickHouse ve QuestDB gibi yeni veritabanlarından, BigQuery ve Redshift gibi bulut sağlayıcılarına ve Market Data as a Service çözümlerine kadar genişledi
- kdb+’ın hız avantajının eskisi kadar belirleyici olmamasının üç nedeni var
- Kullanıcıların çoğu kdb+ düzeyindeki “hıza” ihtiyaç duymuyor
- Banka içi platformların çoğu kdb+’ın hızını tam olarak kullanamıyor
- Rakip ürünler artık yeterince hızlı hale geldi
- ClickBench benchmarkı, şeffaf biçimde yayımlanan bir benchmark olarak anılıyor
- kdb+ mevcut müşterileri koruyabilir; ancak ikinci kademe şirketler bulut-native ya da başka seçenekler istediği için yeni müşteri kazanmak kolay değil
- Mevcut büyük müşteriler kendi platformlarını kurmak için ciddi yatırım yapmak zorunda kaldı ve kdb cloud platformunun da hâlâ olgunlaştırılması gereken yönleri var
Yerel quant analizi: Python ekosistemi önde
- Yerel quant analizindeki alternatifler çoğunlukla Python merkezli biçimde şekilleniyor
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe, Modin vb.
- Bu alanda Python zaten kazandı; geriye kalan soru daha çok kimin ek hızlı araçlar sunduğu
- DuckDB ve Polars’ın güçlü aday olmasının nedeni ücretsiz olmaları
- Üniversitede başlayan kullanıcılar ücretsiz araçlarla öğreniyor ve sonrasında da değiştirmeme ihtimalleri yüksek
- Şirketlerde çalışan quant’lar da bir sonraki işlerinde benzer analizi sürdürebilecekleri ücretsiz araçları tercih ediyor
- Yalnızca kdb+’a bağımlı kalmak, kdb+ kullanmayan bir şirkete geçildiğinde yetkinlik setinin büyük bir kısmını kaybetmek anlamına gelebilir
- kdb+, finans dışına büyük ölçüde yayılamamış niş bir ürün; başlangıç maliyeti yüksek ve sözdizimi de yabancı geliyor
Gerçek zamanlı streaming ve dağıtık hesaplama: güçlü yönler var ama kazanan belirsiz
- Gerçek zamanlı streaming ve dağıtık hesaplama, kdb+ içinde her zaman daha az popüler kullanım alanlarıydı ve sözleşme kazanmanın ana nedeni de değildi
- Gerçek zamanlı veri ile geçmiş veriyi tek bir modelde birleştirebilme yeteneği, kdb+’ın en büyük gücü olarak görülüyor
- Gerçek kurulumlarda ya çok yetkin insanlar gerekiyordu ya da sistemin karmaşaya dönüştüğü durumlar yaşanıyordu
- Bu tür başarısız örnekler, şirket içindeki diğer ekiplerin kdb+’ı farklı amaçlarla benimsemesini de olumsuz etkiliyor
- Bu alanın nihai kazananı hâlâ net değil; ancak bunun kdb+ olma ihtimali düşük görünüyor
- Kafka zaten geniş ölçekli dağıtımlar ve mindshare kazandı; Flink ve RisingWave gibi teknolojiler de yükselişte
Açık kaynak ve standardizasyon, kdb+’ın avantajlarını içine alıyor
- kdb+ etkileyici bir teknoloji olsa da, yaklaşık 15 yıl önceki kadar etkileyici bir seviyede kalırken çevresindeki ekosistem çok hızlı değişti
- İyi açık kaynak şirketleri kdb+’ın temel fikirlerini aldı
- Parquet/Iceberg, optimize edilmiş kolon bazlı depolama için kdb+’ın disk formatına benziyor
- Apache Arrow’un in-memory formatı, kdb+’ın bellek içi kolon formatına benziyor
- Kafka’nın log/replay/ksql kavramları da bazı açılardan tplog’a benzetilebilir
- QuestDB, DuckDB ve ClickHouse’un hepsi asof join destekliyor
- Rakipler yalnızca kdb+’ın avantajlarını öğrenmekle kalmadı, bunları standardize de etti
- Snowflake, Dremio, Confluent ve Databricks artık Apache Iceberg ile Parquet destekliyor
- QuestDB, DuckDB ve Python artık Parquet’i native olarak destekliyor
- Veri Parquet olduğunda, birden fazla araç aynı veri üzerinde çalışabiliyor
- Karşılaştırma artık KX’e karşı tek bir rakip değil, KX’e karşı tüm rakipler ekosistemi haline geldi
KX’in değiştirmesi gerekenler
- KX değişiyor, ancak bunun yeterince hızlı olmadığı yönünde değerlendirmeler var
- Gerekli değişimler dört başlıkta toplanıyor
- Birden çok amaçla kullanılabilecek bir ücretsiz sürüm sunmalı ve bütçesi sınırlı müşterilerin de kolayca kullanabileceği makul bir lisans modeli hazırlamalı
- Çekirdek ürünü mükemmelleştirmeye odaklanmalı
- MongoDB ve InfluxDB, yalnızca iyi bir veritabanıyla bile büyük sözleşmeler kazanılabildiğini gösteren karşı örnekler
- Delta ve kdb.ai gibi çevresel ürünlerden çok, çekirdek ürünün olgunluğu daha önemli
- kdb+’ın dik öğrenme eğrisi de azaltılmalı
- Gerekirse bu, dilin ve teknolojinin kendisini değiştirmeyi de kapsayabilir
- Daha kitlesel hale gelemezse, yavaş bir gerileme yaşanabilir
- Yalnızca çekirdek teknoloji ürünü değil; yapay zeka, büyük ölçekli pazarlama harcamaları gibi maliyetli girişimler dâhil şirket düzeyinde daha geniş değişiklikler de düşünülmeli
1 yorum
Hacker News yorumları
TimescaleDB’yi de adaylar arasına koymak isterim. PostgreSQL eklentisi olduğu için replikasyon, kimlik doğrulama gibi SQL tarafındaki unsurlar aynen korunuyor.
Sütun bazlı depolama biçiminde sıkıştırmayı da destekliyor ve çok hızlı. Birkaç finans uygulamasında kullandım; muazzam miktarda tick verisi, donanımın izin verdiği neredeyse en yüksek hızda uygulamaya kadar ulaştı.
Desteği de iyi, Slack’te hızlı yanıt veriyorlar. kdb’yi de kullandım ama pahalı olması büyük bir dezavantaj; Q dili de ara sıra code golf gibi eğlenmek için iyi, ama sonunda tek karakterlerin sanıldığı kadar ifade gücü yüksek olmadığını fark ediyorsunuz.
Amaç anlık kantitatif analiz ise, REPL’e bütün gün kısa dizgiler girip para kazandıracak şeyler aradığınız kdb doğru seçenek olabilir. Ama pek çok iş aslında cron job’a daha yakın; belirli sorguları takvime göre çalıştıracaksanız, sonraki kişinin anlayıp bakımını yapabileceği okunur bir biçime sokmak daha iyi.
“Sensörleri haritada gösterip her sensörün değer grafiğini göstermek” gibi senaryoları tek bir sorguyla hızlı ve temiz biçimde halledebiliyor.
Yine de benim verim biraz patolojik; kaynak taraf yapıyı istediği gibi değiştirebiliyor ve benim bunu kabul etmem gerekiyor. InfluxDB’nin fiyatı tamamen çılgın olmasaydı, açıkçası doğrudan InfluxDB kullanırdım sanırım.
kdb+ kullanılan bir kantitatif trading işinden 2 hafta içinde ayrıldığım oldu. Kullanabiliyordum ama deneyim çok kötüydü.
Dil tasarımından ya da debug etmenin berbatlığından şikâyet edebilirim, ama en sinir bozucu olan kodlama kurallarının var olma ya da olmama biçimiydi; bunda dilin ve topluluğun büyük rol oynadığını düşünüyorum. Şirket kültürünün de payı vardı: Dokümantasyonun neden bu kadar kötü olduğunu sorduğumda “Zaman geçince biz anlıyoruz; ayrıca böyle olmalı ki diğer ekipler fikirlerimizi kullanamasın” cevabını aldım.
Tüm stack de eskimişti ve Q gibi araçlarla çok sayıda ilginç iş yapmak da zordu. Örneğin qStudio’dan Excel’e veri kopyalayıp grafik çiziyorduk.
Tek iyi yanı, Docker/Kubernetes modasına kapılmayıp doğrudan sunuculara dağıtım yapmalarıydı. Kantitatif analistin prod ortamında hızlıca düzeltme yapabilmesi mantıklı; ama web uygulaması geliştiricilerinin de prod’da değişikliğin sonucunu görmek için 10 dakika beklememesi gerektiğini düşünüyorum.
Kantçıların kdb’yi neden sevdiğine dair bir teorim var. kdb iyi bir silah. Bazı amaçlara uygun, ama bir şeyler yapmak sıkıcı olduğu için ona araç demek zor. Hemen çalışmasını seviyorlar. Ama bıçakla çivi çakabiliyor olmanız, bıçağın amacının bu olduğu anlamına gelmez.
Bu teoriyi sürdürürsek LISP, özellikle Racket, en iyi araç olabilir. Baştan en güçlü dil olduğu için değil; dilin kendisini değiştirme yeteneğiyle çok sayıda soyutlama oluşturabildiği için. C++ ve Python iyi yazılımlar geliştirmeyi sağlayan harika programlama dilleri; Python aynı zamanda oldukça iyi bir silah da.
Q, kant verilerini keşfetmek için en iyi dilmiş gibi bir yanılsama yaratabilir; ama bunun nedeni kantçıların iyi yazılım geliştirmeye ve iyi araçlar kullanmaya yeterince yatırım yapmaması. Python IDE’sini düzgünce öğrenirseniz herhangi bir Q programcısından daha üretken olabilirsiniz.
Performans konusuna hiç girmeyeceğim. Bağlantı verilen yazı pek iyi olmasa da o kısmı ele alıyor.
Eskiden Kdb+ bende epey iz bırakmıştı. Chicago buluşmasına da gitmiştim; büyük bir sorgu neredeyse anında çalışmıştı ve APL benzeri sözdizimi, sanki sadece matematikçilerin bildiği büyülü sözler gibi görünüyordu. Satış temsilcisi, Kdb’nin o kadar optimize olduğunu ve o dönemin işlemcilerinin L1 önbelleğine sığdığını söylemişti.
10 yıl sonra bugün aynı işi Parquet dosyaları üzerinde Python, DuckDB ve Jupyter ile yapıyorum. DuckDB yalnızca paralelleştirme değil, vektörleştirme de yapıyor. kdb+ ile benchmark edilse sonuç ne olur bilmiyorum; ama büyük veri kümelerinde DuckDB’nin tepkiselliği en az kdb+ kadar hızlı hissettiriyor. Elbette kdb+ muhtemelen çok daha fazla optimize edilmiştir; fakat fark, DuckDB’nin ücretsiz olması.
Daha olası olan, kodu anlayamadığı için hayal kırıklığı yaşayıp ayrılmış olması.
Deneyimli bir kant geliştiricisi olsaydı ve iyi bir pozisyon olsaydı, böyle bir sözleşme koşulunda 2 hafta içinde ayrılmak sonraki iş değişikliğini yönetmek açısından felaket olurdu.
Örneğin Jupyter Notebook açıp şöyle yapmanız yeterli:
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])Gerçekten pürüzsüz ve güçlü bir entegrasyon. İki dünyanın da en iyi yanlarını alabiliyorsunuz ve bu ürünü önümüzdeki 10 yıl boyunca yaşatacak özellik olabilir.
Burada açıkça ele alınmayan kdb+/Q’nun çekici özelliklerinden biri dikey entegrasyon. Normalde birden çok hazır teknolojiyi seçip birbirine bağlamayı gerektiren tüm yığın kullanım senaryolarını tek bir teknolojiyle ele alabiliyorsunuz.
Q dili, yerleşik veri serileştirme özellikleri ve süreçler arası iletişim işlevleri sayesinde deneyimli bir programcı, ihtiyaç duyulan sistemi tek bir dilde tam istenen şekilde özel olarak kurabiliyor; kod tabanı da çoğu zaman yüzlerce ya da binlerce sayfa yerine birkaç sayfalık bir belgeye sığacak kadar küçük oluyor.
Bir kuruluş bu rollerin bir kısmını zaten başka yazılımlar, protokoller ve formatlarla çözmeye karar verdiyse, dikey entegrasyonun geliştirme akışı ve genel performans açısından faydaları azalır. kdb+’nın kendisi de tescilli ve üstelik pahalı olduğundan, yeni bir projede baştan sona benimsenmesini gerekçelendirmekte zorlanılmasını anlıyorum. Teknolojinin kendisi mücevher gibi; gerçekten yazık.
Dashboard ürünü kullanması zor; orta karmaşıklıktaki dashboard’larda bile editörün sık sık çökmesine neden olan ciddi hatalar var. Q o kadar zengin özellikli ki onunla web uygulaması yazmak gerçekten eğlenceli olurdu, ama kullanıcılara bir şey sunmak için sürükle-bırak editörünü kullanmak zorundasınız.
Shakti; yük dengeleme, kullanıcı yetkileri, SSO gibi yaygın kurumsal kullanım senaryolarını ele alan kütüphaneler içerirse Kx’in gerçek bir rakibi olabilir bence. Deneyimli bir K programcısı bunları 1-2 haftada yapabilir, ama büyük şirketler çoğu zaman bu işlevler uygulanmış olmadan ürünün benimsenmesine izin vermiyordu.
Kafka, Flink, Postgres, Iceberg gibi açık kaynak teknolojilerin üzerine SQL ile böyle bir entegrasyon katmanı kurma ve zaman serisi işlemeyi SQL’de daha rahat hale getiren sözdizimsel kolaylıklar ekleme fikrini deniyoruz.
https://github.com/DataSQRL/sqrl/
Hedef; SQL’i dönüştürüp bir hesaplama DAG’ı oluşturmak, ardından maliyet tabanlı bir iyileştiriciyle DAG’ı bölerek alttaki veri teknolojilerine yerleştirmek ve böylece kdb+’nın gücünü açık kaynak teknolojiler ve SQL’i birleştiren bir paket olarak sunmak.
Birçok amaç için kullanılabilecek ücretsiz bir sürüm çıkarmaları gerekirdi.
kdb+’nın harika bir teknoloji ve ürün olarak kabul görüp geliştirici topluluğunda büyümesinin önündeki en büyük engelin bu olduğunu düşünüyorum.
Finans sektöründe yıllarca kdb+’yı yoğun kullandım ve hayranı oldum. Tasarımında ve sadeliğinde Unix felsefesine dayanıyor gibi görünen bir zarafet var. Finans sektöründen ayrılıp kdb+ kullanan bir şirkette çalışmamaya başladıktan sonra bile, küçük projelerde burada burada kdb+ kullanma isteği sık sık içimde doğdu.
Artık kullanamamak ve meslektaşlarıma bu az bilinen niş aracı gösterip belirli işler ve hesaplamalarda ne kadar basit ve verimli olduğunu anlatırken geek out yapamamak sinir bozucuydu.
Eskiden kdb’ye veri gönderen C++ kodu ve onların wire protocol decoder’ını yazmam gerekmişti; ikisi için de test amaçlı bir kdb binary’si kesinlikle vardı.
Sadece test etmem gerekiyordu. Kx geliştirme lisansı vermiş de olabilir; ama epey eski bir olay.
Bu yazının içeriğine genel olarak katılıyorum. Baştan yapılacaksa veriyi Parquet’te saklayıp Polars veya DuckDB ile erişmek yeterli.
q/kdb+’dan o kadar nefret ettim ki zaman serisi analizi için kendi dilimi yaptım, ama zaten yıllardır kazanan Python’du.
kdb+ ile belli ölçüde başarılı bir startup kurdum. Bildiğim teknolojiydi ve sağlam bir ürünü hızlıca geliştirmeme yardımcı oldu. Ama ölçek büyüdükçe ekibi genişletebilmek için açık kaynak yazılımla yeniden yazmak zorunda kaldık.
Önerilere genel olarak katılıyorum, ancak Kx’in platformu açık kaynak olarak yayımlaması gerektiğini düşünüyorum. Böylece ekosisteme iyileştirme ve araç katkısı yapmak isteyecek türden geliştiricileri çekebilir.
Kdb+ gerçekten harika görünüyor; APL ile birlikte eğlence olsun diye biraz öğrenmiştim. Benim sektörümde de çeşitli kullanımlara oldukça uygun gibi duruyor, ama fiyatı akıl almaz.
Finans bankalarının ödediği gibi CPU başına 100 bin dolar ödeyemeyiz. Bu yüzden fiilen devasa bir potansiyel müşteri kitlesini yok saymış oldular.
Başkaları onların tekniklerini öğrenip başka alanlara ve dillere uyarlayarak aynı işi yapabilir.
Yazıyla ilgili birkaç düzeltme gerekiyor.
clickhouse-localvechdbye bakın.Ancak henüz gerçekten geçişi uygulayan olmadı. KDB’den çıkan çok sayıdaki entegrasyonu düşününce büyük bir karar olduğu anlaşılıyor. Yine de ruhani halefi gibi hissettirdiği kesin.
Hâlâ sıfırdan öğrenip kdb+ geliştirme ile büyük para kazanmanın mümkün olup olmadığını merak ediyorum. Birkaç yıl önce yılda yaklaşık 1 milyon dolar veren bir ilan gördüğümü hatırlıyorum; şaşırtıcıydı.
kdb+’da DeWitt maddesi olduğu için yazıda geçen diğer veritabanlarıyla kimsenin benchmark yapamaması üzücü.
Üçüncü taraflarca yapılmış herkese açık benchmark olup olmadığını da merak ediyorum.