Masa depan kdb+?
(timestored.com)- Di sektor keuangan, kdb+ telah menjadi alat yang kuat untuk analisis data pasar historis dan komputasi real-time, tetapi kini telah muncul teknologi pengganti yang cukup matang untuk masing-masing kasus penggunaan
- Banyak pengguna tidak memerlukan kecepatan maksimum kdb+, dan platform internal bank juga tidak mampu sepenuhnya memaksimalkan performa tersebut, sehingga keunggulan kecepatan menjadi kurang menentukan
- Untuk analisis kuantitatif lokal, ekosistem Python pada praktiknya sudah mendominasi, dan alat komunitas gratis seperti DuckDB dan Polars lebih menguntungkan dari sisi pembelajaran dan perpindahan kerja
- Streaming real-time dan komputasi terdistribusi masih menjadi kekuatan kdb+, tetapi tingkat kesulitan implementasi serta meluasnya mindshare Kafka, Flink, dan RisingWave membuat ekspansi menjadi sulit
- Agar kdb+ bisa bertahan dalam jangka panjang, dibutuhkan jalur penggunaan gratis, fokus pada produk inti, pengurangan kurva pembelajaran, dan daya tarik yang cukup luas untuk berekspansi ke luar sektor keuangan
Peran yang selama ini diemban kdb+ di sektor keuangan
- kdb+ telah digunakan dalam berbagai sistem dan pekerjaan analitik di sektor keuangan
- Penyimpanan dan analisis data pasar historis: contoh seperti MS Horizon, Citi CloudKDB, dan UBS Krypton
- Analisis kuantitatif lokal: analisis likuiditas, analisis PnL, analisis profitabilitas per pelanggan
- Mesin komputasi streaming real-time: Streaming VWAP, Streaming TCA
- Komputasi terdistribusi: pekerjaan seperti perhitungan margin portofolio saham dan analisis risiko, yang membagi data, menghitungnya, lalu menggabungkannya kembali
Data pasar historis: pelanggan lama bertahan, tetapi ekspansi baru sulit
- Banyak pengguna ingin melakukan kueri terhadap data berskala besar untuk membuat minute bar, melakukan asof join, atau menjalankan analisis deret waktu yang lebih canggih
- Pilihan pesaing kini meluas ke basis data baru seperti ClickHouse dan QuestDB, vendor cloud seperti BigQuery dan Redshift, hingga Market Data as a Service
- Ada tiga alasan mengapa keunggulan kecepatan kdb+ tidak lagi sedeterminatif dulu
- Sebagian besar pengguna tidak membutuhkan “kecepatan” setingkat kdb+
- Sebagian besar platform internal bank tidak mampu sepenuhnya memaksimalkan kecepatan kdb+
- Produk pesaing kini sudah cukup cepat
- Benchmark ClickBench disebut sebagai benchmark yang dipublikasikan secara transparan
- kdb+ mungkin masih bisa mempertahankan pelanggan lama, tetapi perusahaan tier-2 menginginkan opsi cloud-native atau pilihan lain, sehingga sulit mendapatkan pelanggan baru
- Pelanggan utama yang sudah ada harus berinvestasi besar untuk membangun platform internal mereka sendiri, dan platform kdb cloud masih menyisakan bagian yang perlu disempurnakan
Analisis kuantitatif lokal: ekosistem Python lebih unggul
- Alternatif untuk analisis kuantitatif lokal sebagian besar terpusat pada Python
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe, Modin, dan lain-lain
- Di area ini Python pada dasarnya sudah menang, dan pertanyaan yang tersisa lebih mendekati siapa yang menyediakan alat tambahan tercepat
- Alasan DuckDB dan Polars dianggap kuat adalah karena keduanya gratis
- Pengguna yang memulai dari universitas akan belajar dengan alat gratis dan kemungkinan besar tidak akan berganti sesudahnya
- Quant yang bekerja di perusahaan juga lebih memilih alat gratis yang bisa terus dipakai untuk analisis serupa di pekerjaan berikutnya
- Jika hanya bergantung pada kdb+, mereka bisa kehilangan bagian besar dari skill set mereka saat pindah ke perusahaan yang tidak menggunakan kdb+
- kdb+ adalah produk niche yang tidak berhasil meluas jauh ke luar dunia keuangan, dengan kelemahan berupa biaya awal yang tinggi dan sintaks yang terasa asing
Streaming real-time dan komputasi terdistribusi: punya kekuatan, tetapi pemenangnya belum jelas
- Streaming real-time dan komputasi terdistribusi selalu menjadi kasus penggunaan yang kurang populer untuk kdb+, dan juga bukan alasan utama untuk memenangkan kontrak
- Kemampuan menggabungkan data real-time dan data historis dalam satu model disebut sebagai kekuatan terbesar kdb+
- Dalam implementasi nyata, sering kali dibutuhkan orang yang sangat terampil, atau sistem justru berakhir berantakan
- Contoh kegagalan seperti ini juga berdampak negatif pada adopsi kdb+ untuk penggunaan lain di bagian perusahaan yang berbeda
- Pemenang akhir di area ini masih belum pasti, tetapi kecil kemungkinan itu adalah kdb+
- Kafka sudah memiliki deployment skala besar dan mindshare, sementara teknologi seperti Flink dan RisingWave juga sedang naik daun
Open source dan standardisasi menyerap keunggulan kdb+
- kdb+ adalah teknologi yang luar biasa, tetapi sementara ia tetap luar biasa pada level yang mirip dengan 15 tahun lalu, ekosistem di sekitarnya berubah sangat cepat
- Perusahaan open source yang bagus telah mengambil ide-ide inti dari kdb+
- Parquet/Iceberg mirip dengan format disk kdb+ untuk penyimpanan kolumnar yang dioptimalkan
- Format in-memory Apache Arrow mirip dengan format kolumnar in-memory milik kdb+
- Konsep log/replay/ksql pada Kafka juga, dari sudut pandang tertentu, dapat dianggap mirip dengan tplog
- QuestDB, DuckDB, dan ClickHouse semuanya mendukung asof join
- Para pesaing bukan hanya mempelajari keunggulan kdb+, tetapi juga menstandarkannya
- Snowflake, Dremio, Confluent, dan Databricks kini mendukung Apache Iceberg dan Parquet
- QuestDB, DuckDB, dan Python kini mendukung Parquet secara native
- Jika data berada dalam format Parquet, banyak alat dapat dijalankan terhadap data yang sama
- Struktur persaingannya bukan lagi KX melawan satu pesaing, melainkan KX melawan keseluruhan banyak pesaing
Hal yang perlu diubah KX
- KX memang sedang berubah, tetapi dinilai tidak cukup cepat
- Perubahan yang dibutuhkan diringkas menjadi empat hal
- Perlu menyediakan versi gratis yang bisa dipakai untuk berbagai keperluan, serta lisensi yang masuk akal agar pelanggan dengan anggaran kecil juga mudah menggunakannya
- Harus fokus membuat produk inti menjadi sangat baik
- MongoDB dan InfluxDB adalah contoh pembanding yang berhasil memenangkan kontrak besar hanya dengan basis data yang baik
- Tingkat kematangan produk inti lebih penting daripada produk periferal seperti Delta dan kdb.ai
- Kurva pembelajaran kdb+ yang curam juga harus diturunkan
- Jika perlu, ini bahkan mencakup cara mengubah bahasa dan teknologinya sendiri
- Jika tidak bisa menjadi lebih populer, hal itu dapat berujung pada kemunduran yang lambat
- Perlu dipertimbangkan pula perubahan yang lebih luas di tingkat perusahaan, termasuk bukan hanya produk teknologi inti, tetapi juga biaya besar dan inisiatif seperti AI serta pengeluaran pemasaran berskala besar
1 komentar
Pendapat di Hacker News
Saya juga ingin memasukkan TimescaleDB sebagai kandidat. Karena ini ekstensi PostgreSQL, elemen terkait SQL seperti replikasi dan autentikasi tetap dipertahankan apa adanya.
Ia juga mendukung penyimpanan kolumnar dengan kompresi dan sangat cepat. Saya pernah memakainya di beberapa aplikasi finansial, dan volume data tick yang sangat besar masuk hingga ke aplikasi pada kecepatan yang hampir mencapai batas maksimum yang diizinkan perangkat keras.
Dukungannya juga bagus dan respons di Slack cepat. Saya juga pernah memakai kdb, tetapi kelemahan besarnya adalah mahal, dan bahasa Q memang sesekali menyenangkan untuk code golf, tetapi pada akhirnya Anda akan menyadari bahwa karakter-karakter tunggal itu tidak seekspresif yang dibayangkan.
Jika tujuannya adalah analisis kuantitatif ad hoc, kdb mungkin cocok: seharian mengetik string pendek di REPL untuk mencari sesuatu yang menghasilkan uang. Namun banyak pekerjaan sebenarnya lebih mirip cron job, jadi jika Anda akan menjalankan kueri yang sudah ditentukan sesuai jadwal, lebih baik membuatnya dalam bentuk yang mudah dibaca agar orang berikutnya dapat memahami dan memeliharanya.
Skenario seperti “menampilkan sensor di peta dan menunjukkan grafik nilai tiap sensor” bisa ditangani dengan satu kueri secara cepat dan rapi.
Namun data saya agak patologis: pihak sumber bisa mengubah struktur sesuka mereka dan saya harus menerimanya. Sejujurnya, kalau harga InfluxDB tidak benar-benar gila, saya mungkin langsung memakai InfluxDB.
Saya pernah berhenti setelah 2 minggu dari pekerjaan quant trading yang memakai kdb+. Saya bisa memakainya, tetapi pengalamannya sangat buruk.
Saya bisa saja mengeluhkan desain bahasa atau debugging yang mengerikan, tetapi yang paling membuat frustrasi adalah ada-tidaknya aturan coding dan cara penerapannya; menurut saya bahasa dan komunitas punya peran besar di sini. Budaya perusahaan juga ikut berperan: ketika saya bertanya mengapa dokumentasinya seburuk itu, jawabannya adalah, “Seiring waktu kami akan mengerti, dan harus seperti ini supaya tim lain tidak bisa memakai ide kami.”
Seluruh stack-nya juga sudah tua, dan dengan alat seperti Q sulit melakukan banyak hal menarik. Misalnya, kami menyalin data dari qStudio ke Excel untuk membuat grafik.
Satu-satunya hal yang saya sukai adalah mereka tidak ikut-ikutan tren Docker/Kubernetes dan melakukan deployment langsung ke server. Memang masuk akal bahwa quant harus bisa memperbaiki sesuatu dengan cepat di production, tetapi menurut saya developer web app pun seharusnya tidak perlu menunggu 10 menit untuk melihat hasil perubahan di production.
Saya punya teori tentang mengapa para quant menyukai kdb. kdb adalah senjata yang bagus. Ia cocok untuk tujuan tertentu, tetapi membangunnya membosankan, jadi sulit menyebutnya alat. Mereka menyukai fakta bahwa ia langsung bekerja. Namun hanya karena Anda bisa menancapkan paku dengan pisau, bukan berarti itu tujuan pisau.
Jika teori itu diteruskan, LISP, khususnya Racket, bisa menjadi alat terbaik. Bukan karena sejak awal ia bahasa paling kuat, tetapi karena kemampuannya mengubah bahasa itu sendiri memungkinkan banyak abstraksi dibuat. C++ dan Python adalah bahasa pemrograman hebat untuk membuat perangkat lunak yang baik, dan Python juga merupakan senjata yang cukup bagus.
Q bisa memberi ilusi seolah-olah ia bahasa terbaik untuk mengeksplorasi data quant, tetapi itu karena para quant tidak cukup berinvestasi dalam membuat perangkat lunak yang baik dan memakai alat yang baik. Jika Anda benar-benar menguasai IDE Python, Anda bisa lebih produktif daripada programmer Q mana pun.
Saya bahkan tidak akan mulai membahas performa. Walau tulisan yang ditautkan tidak terlalu bagus, bagian itu dibahas di sana.
Dulu saya cukup terkesan dengan Kdb+. Saya juga pergi ke pertemuan di Chicago; kueri besar berjalan hampir seketika, dan sintaks mirip APL tampak seperti mantra sihir yang hanya diketahui orang-orang matematika. Staf sales mengatakan Kdb begitu teroptimasi sehingga muat di cache L1 prosesor saat itu.
Sepuluh tahun kemudian, sekarang saya melakukan hal yang sama dengan Python, DuckDB, dan Jupyter di atas file Parquet. DuckDB tidak hanya melakukan paralelisasi, tetapi juga vektorisasi. Saya tidak tahu bagaimana hasil benchmark melawan kdb+, tetapi pada dataset besar, responsivitas DuckDB terasa setidaknya secepat kdb+. Tentu kdb+ mungkin jauh lebih teroptimasi, tetapi bedanya DuckDB gratis.
Yang jauh lebih mungkin adalah ia frustrasi karena tidak memahami kodenya lalu berhenti.
Jika ia quant developer yang terampil dan posisinya bagus, berhenti setelah 2 minggu dengan ketentuan kontrak seperti itu akan menjadi bencana untuk mengelola perpindahan kerja berikutnya.
Misalnya, cukup buka Jupyter Notebook dan lakukan seperti ini:
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])Integrasinya benar-benar mulus dan kuat. Anda bisa mendapatkan keunggulan dari kedua dunia, dan ini mungkin menjadi fitur yang membuat produk ini tetap hidup selama 10 tahun ke depan.
Salah satu fitur menarik kdb+/Q yang tidak dibahas secara eksplisit di sini adalah integrasi vertikal. Use case untuk keseluruhan stack, yang biasanya harus dirakit dari beberapa teknologi siap pakai, bisa ditangani dengan satu teknologi saja
Berkat bahasa Q, fitur bawaan serialisasi data, dan kemampuan komunikasi antarproses, programmer berpengalaman bisa membuat sistem yang dibutuhkan secara presisi dalam satu bahasa, dan codebase-nya sering kali cukup muat dalam dokumen beberapa halaman, bukan ratusan atau ribuan halaman
Jika sebuah organisasi sudah memutuskan untuk menangani sebagian peran ini dengan software, protokol, dan format lain, manfaat integrasi vertikal dalam alur pengembangan dan performa keseluruhan akan berkurang. Karena kdb+ sendiri proprietary dan juga mahal, bisa dimengerti mengapa sulit membenarkan adopsi penuh untuk proyek baru. Teknologinya sendiri seperti permata, jadi benar-benar disayangkan
Produk dashboard-nya sulit digunakan, dan ada bug parah yang membuat editor sering mati bahkan pada dashboard dengan kompleksitas sedang. Q kaya fitur, jadi menulis aplikasi web dengannya pasti sangat menyenangkan, tetapi untuk menyediakan sesuatu kepada pengguna, kita harus memakai editor drag-and-drop
Menurut saya, jika Shakti menyertakan library yang menangani use case enterprise umum seperti load balancing, hak akses pengguna, dan SSO, ia bisa menjadi pesaing nyata Kx. Programmer K yang berpengalaman mungkin bisa membuatnya dalam 1–2 minggu, tetapi perusahaan besar sering kali hanya mengizinkan adopsi produk jika fitur-fitur seperti ini sudah diimplementasikan
Saya sedang bereksperimen dengan ide membuat layer integrasi semacam ini dalam SQL di atas teknologi open source seperti Kafka, Flink, Postgres, dan Iceberg, lalu menambahkan syntactic sugar agar pemrosesan time-series lebih nyaman dilakukan di SQL
https://github.com/DataSQRL/sqrl/
Tujuannya adalah menerjemahkan SQL, membuat DAG komputasi, lalu memotong DAG dengan cost-based optimizer dan menempatkannya pada teknologi data dasar, sehingga kekuatan kdb+ bisa disediakan sebagai paket yang mengintegrasikan teknologi open source dan SQL
Seharusnya mereka merilis versi gratis yang bisa digunakan untuk berbagai keperluan
Menurut saya, inilah hambatan terbesar bagi kdb+ untuk diakui sebagai teknologi dan produk yang hebat serta berkembang di komunitas developer
Saya menjadi penggemarnya setelah memakai kdb+ cukup banyak selama bertahun-tahun di sektor keuangan. Ada keanggunan dalam desain dan kesederhanaannya yang terasa berakar pada filosofi Unix. Bahkan setelah meninggalkan sektor keuangan dan tidak lagi bekerja di perusahaan yang memakai kdb+, saya sering terdorong untuk memakai kdb+ pada berbagai proyek kecil
Menyebalkan karena saya tidak bisa lagi memakainya, dan tidak bisa geek out dengan menunjukkan tool niche yang kurang dikenal ini kepada rekan kerja serta memperlihatkan betapa sederhana dan efisiennya ia untuk tugas dan perhitungan tertentu
Dulu saya harus menulis kode C++ yang mengirim data ke kdb dan decoder untuk wire protocol mereka, dan saya cukup yakin ada binary kdb untuk pengujian keduanya
Saya hanya membutuhkannya untuk testing. Sepertinya Kx memberi lisensi pengembangan, tetapi itu sudah lama sekali
Secara umum saya setuju dengan isi tulisan ini. Kalau membangun sesuatu dari awal sekarang, cukup simpan data di Parquet dan akses dengan Polars atau DuckDB
Saya sangat tidak suka q/kdb+ sampai-sampai membuat bahasa sendiri untuk analisis time-series, tetapi selama bertahun-tahun pemenangnya sudah Python
Saya pernah membuat startup yang cukup sukses dengan kdb+. Itu teknologi yang saya kenal, dan membantu membuat produk yang solid dengan cepat. Namun ketika skalanya membesar, kami harus menulis ulang dengan software open source agar bisa memperbesar tim
Saya sebagian besar setuju dengan rekomendasinya, tetapi menurut saya Kx harus membuka platformnya sebagai open source. Dengan begitu mereka bisa menarik tipe developer yang ingin berkontribusi pada perbaikan dan tooling ekosistem
Kdb+ terlihat sangat keren, dan saya mempelajarinya sedikit bersama APL untuk bersenang-senang. Di industri saya pun sepertinya cukup cocok untuk berbagai keperluan, tetapi harganya tidak masuk akal
Kami tidak bisa membayar 100 ribu dolar per CPU seperti yang dibayar bank-bank di sektor keuangan. Jadi pada dasarnya mereka mengabaikan basis calon pelanggan yang sangat besar
Orang lain bisa mempelajari teknik mereka dan melakukan hal yang sama untuk domain dan bahasa lain
Ada beberapa koreksi yang perlu dibuat terhadap tulisan ini
clickhouse-localdanchdbNamun sejauh ini belum ada yang benar-benar menjalankan migrasi. Mengingat banyaknya integrasi yang bercabang dari KDB, tampaknya itu keputusan besar. Meski begitu, jelas terasa seperti penerus spiritualnya
Saya penasaran apakah sekarang pun masih bisa belajar dari nol dan menghasilkan banyak uang dari pengembangan kdb+. Saya ingat beberapa tahun lalu melihat lowongan yang membayar sekitar 1 juta dolar per tahun, dan itu mengejutkan
Sayang sekali kdb+ memiliki klausa DeWitt, sehingga tidak ada yang bisa melakukan benchmark terhadap database lain yang disebutkan dalam tulisan ini
Saya juga penasaran apakah ada benchmark publik yang dilakukan pihak ketiga