kdb+ का भविष्य?

 (timestored.com)
1 पॉइंट द्वारा GN⁺ 2024-08-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वित्तीय क्षेत्र में kdb+ ऐतिहासिक market data analysis और real-time calculations के लिए एक ताकतवर tool रहा है, लेकिन अब हर use case के लिए पर्याप्त रूप से mature alternative technologies सामने आ चुकी हैं
  • कई users को kdb+ की top speed तक की जरूरत नहीं होती, और banks के internal platforms भी उसके performance को पूरी तरह extract नहीं कर पाते, इसलिए speed advantage कम निर्णायक हो गया है
  • local quant analysis पर Python ecosystem का प्रभावी तौर पर दबदबा है, और DuckDB·Polars जैसे free community tools सीखने और job switch करने के लिहाज से ज्यादा फायदेमंद हैं
  • real-time streaming और distributed computing अब भी kdb+ की strengths हैं, लेकिन setup की कठिनाई और Kafka·Flink·RisingWave की बढ़ती mindshare इसके प्रसार को मुश्किल बनाती है
  • लंबे समय तक टिके रहने के लिए kdb+ को free usage path, core product पर focus, learning curve में कमी, और finance sector से बाहर फैलने लायक mass appeal की जरूरत है

वित्तीय क्षेत्र में kdb+ की भूमिका

  • kdb+ का इस्तेमाल कई financial systems और analysis workflows में होता रहा है
    • historical market data storage और analysis: MS Horizon, Citi CloudKDB, UBS Krypton जैसे उदाहरण
    • local quant analysis: liquidity analysis, PnL analysis, customer-wise profitability analysis
    • real-time streaming calculation engine: Streaming VWAP, Streaming TCA
    • distributed computing: stock portfolio margin calculation और risk analysis जैसे काम, जहां data को बांटकर compute किया जाता है और फिर दोबारा merge किया जाता है

Historical market data: मौजूदा customers रह सकते हैं, लेकिन नया expansion मुश्किल है

  • कई users बड़े datasets को query करके minute bars बनाना चाहते हैं, और asof join या अधिक advanced time-series analysis करना चाहते हैं
  • competing options अब ClickHouse, QuestDB जैसे नए databases, BigQuery·Redshift जैसे cloud vendors, और Market Data as a Service तक फैल गए हैं
  • kdb+ का speed advantage अब पहले जितना निर्णायक नहीं रहा, इसकी तीन वजहें हैं
    • ज्यादातर users को kdb+ की “speed” तक की जरूरत नहीं होती
    • ज्यादातर bank internal platforms kdb+ की speed को पूरी तरह extract नहीं कर पाते
    • competing products अब पर्याप्त तेज हो गए हैं
  • ClickBench benchmark को एक transparently published benchmark के रूप में बताया जाता है
  • kdb+ existing customers को बनाए रख सकता है, लेकिन tier-2 companies cloud-native या दूसरे विकल्प चाहती हैं, इसलिए नए customers हासिल करना आसान नहीं है
  • मौजूदा बड़े customers को अपने platforms बनाने में भारी investment करनी पड़ी थी, और kdb cloud platform में अभी भी और polish की जरूरत है

Local quant analysis: Python ecosystem आगे है

  • local quant analysis के alternatives ज्यादातर Python-centric हैं
    • Python + DuckDB
    • Python + Polars
    • Python + PyKX
    • Python + dataframe, Modin आदि
  • इस क्षेत्र में Python पहले ही जीत चुका है, और बाकी सवाल लगभग यही है कि तेज extra tools कौन देता है
  • DuckDB और Polars के मजबूत candidates होने की वजह उनका free होना है
    • university से शुरू करने वाले users free tools से सीखते हैं और बाद में भी उन्हें बदलने की संभावना कम होती है
    • किसी company में quant भी ऐसे free tools पसंद करता है जिनसे वह अगली job में भी similar analysis जारी रख सके
    • केवल kdb+ पर निर्भर रहने से, kdb+ न रखने वाली company में जाने पर skillset का बड़ा हिस्सा खो सकता है
  • kdb+ finance से बाहर ज्यादा नहीं फैला हुआ niche product है, और high starting cost व unfamiliar syntax इसकी कमजोरियां हैं

Real-time streaming और distributed computing: strengths हैं, लेकिन winner unclear है

  • real-time streaming और distributed computing हमेशा kdb+ में कम popular use cases रहे हैं, और contracts जीतने का मुख्य कारण भी नहीं थे
  • real-time data और historical data को एक model में combine करने की क्षमता kdb+ की सबसे बड़ी strengths में गिनी जाती है
  • real deployments में अक्सर बहुत skilled लोगों की जरूरत पड़ती थी, वरना system गड़बड़ हो जाता था
    • ऐसी failure cases company के अन्य departments में kdb+ को दूसरे use cases के लिए अपनाने पर भी negative असर डालती हैं
  • इस क्षेत्र का अंतिम winner अभी निश्चित नहीं है, लेकिन kdb+ होने की संभावना कम लगती है
  • Kafka पहले ही large-scale deployments और mindshare हासिल कर चुका है, और Flink व RisingWave जैसी technologies भी उभर रही हैं

Open source और standardization kdb+ की खूबियां absorb कर रहे हैं

  • kdb+ बेहतरीन technology है, लेकिन जब यह करीब 15 साल पहले जैसी ही उत्कृष्टता के स्तर पर ठहरा रहा, आसपास का ecosystem तेजी से बदल गया
  • अच्छी open source companies ने kdb+ के core ideas अपना लिए
    • Parquet/Iceberg optimized column storage के लिए kdb+ disk format जैसे हैं
    • Apache Arrow का in-memory format kdb+ के in-memory column format जैसा है
    • Kafka के log/replay/ksql concepts को भी कुछ angles से tplog जैसा देखा जा सकता है
    • QuestDB, DuckDB, ClickHouse सभी asof join support करते हैं
  • competitors ने kdb+ की strengths सिर्फ सीखी नहीं, उन्हें standardize भी किया
    • Snowflake, Dremio, Confluent, Databricks ने Apache Iceberg और Parquet support करना शुरू किया
    • QuestDB, DuckDB, Python ने Parquet को natively support करना शुरू किया
  • अगर data Parquet में है, तो कई tools उसी data पर run कर सकते हैं
  • comparison अब KX बनाम किसी एक competitor का नहीं, बल्कि KX बनाम competitors के पूरे समूह का हो गया है

KX को क्या बदलना होगा

  • KX बदल रहा है, लेकिन यह पर्याप्त तेजी से नहीं बदल रहा—ऐसा आकलन है
  • जरूरी बदलाव चार बिंदुओं में समझे जा सकते हैं
    • कई use cases में इस्तेमाल हो सकने वाला free version देना होगा, और कम budget वाले customers के लिए भी आसानी से अपनाने योग्य reasonable licensing तैयार करनी होगी
    • core product को शानदार बनाने पर focus करना होगा
    • MongoDB और InfluxDB ऐसे contrasting examples हैं जिन्होंने केवल अच्छे database के दम पर भी बड़े contracts जीते
    • Delta, kdb.ai जैसे peripheral products की तुलना में core product की maturity ज्यादा महत्वपूर्ण है
  • kdb+ के steep learning curve को भी कम करना होगा
    • जरूरत पड़ने पर इसमें language और technology को ही बदलने जैसे तरीके भी शामिल हो सकते हैं
  • अगर यह ज्यादा mainstream नहीं बन पाया, तो slow decline हो सकता है
  • core technology product के साथ-साथ AI, बड़े marketing spends जैसे बड़े costs और initiatives समेत company-level पर व्यापक बदलावों पर भी विचार करना होगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-04
Hacker News की राय

  • मैं TimescaleDB को भी उम्मीदवारों में रखना चाहूँगा। यह PostgreSQL extension है, इसलिए replication और authentication जैसे SQL से जुड़े पहलू वैसे ही बने रहते हैं
    column storage के साथ compression भी support करता है और बहुत तेज़ है। कुछ finance applications में इसे इस्तेमाल किया है, और भारी मात्रा में tick data लगभग hardware जितनी अनुमति देता था, उतनी अधिकतम speed से applications तक आ रहा था
    support भी अच्छा है और Slack पर response भी तेज़ मिलता है। kdb भी इस्तेमाल किया है, लेकिन इसका बड़ा नुकसान महँगा होना है, और Q language कभी-कभी code golf की तरह मज़े के लिए अच्छी लगती है, पर अंत में एहसास होता है कि single characters उतने expressive नहीं हैं जितना सोचा था
    अगर मकसद तुरंत quant analysis करना है, तो REPL में दिन भर छोटी strings डालकर पैसे कमाने लायक चीज़ें ढूँढने के लिए kdb सही हो सकता है। लेकिन बहुत-से काम असल में cron jobs जैसे होते हैं, इसलिए अगर तय queries को schedule पर चलाना है, तो उन्हें ऐसे readable रूप में बनाना बेहतर है जिसे अगला व्यक्ति समझ और maintain कर सके

    • TimescaleDB की एक और ताकत यह है कि यह दूसरे PostgreSQL extensions के साथ अच्छी तरह चलता है। PostGIS के साथ इस्तेमाल करने का अनुभव बहुत अच्छा रहा
      “sensors को map पर दिखाना और हर sensor के values graph दिखाना” जैसे scenario को एक single query से तेज़ और साफ़ तरीके से handle किया जा सकता है
    • काम पर TimescaleDB इस्तेमाल कर रहा हूँ और यह काफ़ी पसंद है। अगर data structure अच्छी तरह तय हो, तो यह सचमुच सुविधाजनक है
      हालांकि मेरा data थोड़ा pathological है, क्योंकि source side structure को मनमाने ढंग से बदल सकती है और मुझे उसे accept करना पड़ता है। अगर InfluxDB की pricing पूरी तरह पागलपन जैसी नहीं होती, तो सच कहूँ तो शायद सीधे InfluxDB ही इस्तेमाल करता

  • मैंने kdb+ इस्तेमाल करने वाली quant trading नौकरी 2 हफ्तों में छोड़ दी थी। इस्तेमाल तो कर सकता था, लेकिन experience बहुत खराब था
    language design या debugging को भयानक बताकर शिकायत की जा सकती है, लेकिन सबसे ज्यादा frustrate करने वाली बात coding rules का होना या न होना जैसा तरीका था, और इसमें language व community की बड़ी भूमिका मानता हूँ। company culture ने भी भूमिका निभाई; जब पूछा कि documentation इतनी खराब क्यों है, तो जवाब मिला, “समय के साथ हम समझ जाएंगे, और ऐसा करने से दूसरी teams हमारे ideas इस्तेमाल नहीं कर पाएंगी”
    पूरा stack भी पुराना था, और Q जैसे tool से बहुत-से interesting काम करना मुश्किल था। उदाहरण के लिए, qStudio से Excel में data copy करके graph बनाते थे
    अकेली अच्छी बात यह थी कि उन्होंने Docker/Kubernetes trend नहीं अपनाया और servers पर सीधे deploy किया। यह बात समझ आती है कि quant को production में तेजी से fix कर पाने की जरूरत होती है, लेकिन मुझे लगता है कि web app developers को भी production में changes का परिणाम देखने के लिए 10-10 मिनट इंतजार नहीं करना चाहिए
    मेरे पास एक theory है कि quants kdb को क्यों पसंद करते हैं। kdb एक अच्छा हथियार है। कुछ purposes के लिए सही है, लेकिन इसे बनाना उबाऊ है, इसलिए इसे tool कहना मुश्किल है। लोगों को यह पसंद है कि यह तुरंत काम करता है। लेकिन चाकू से कील ठोकी जा सकती है, इसका मतलब यह नहीं कि वही चाकू का purpose है
    उस theory को आगे बढ़ाएँ तो LISP, खासकर Racket, सबसे अच्छा tool हो सकता है। शुरुआत में यह सबसे powerful language नहीं है, लेकिन language को ही बदलने की capability के कारण इससे बहुत-सी abstractions बनाई जा सकती हैं। C++ और Python अच्छे software बनाने के लिए शानदार programming languages हैं, और Python काफ़ी अच्छा हथियार भी है
    Q यह भ्रम दे सकता है कि यह quant data explore करने की सबसे अच्छी language है, लेकिन ऐसा इसलिए है क्योंकि quants अच्छे software बनाने और अच्छे tools इस्तेमाल करने में पर्याप्त निवेश नहीं करते। अगर Python IDE को सही से सीख लिया जाए, तो किसी भी Q programmer से ज्यादा productive हुआ जा सकता है
    performance की बात तो शुरू भी नहीं करूँगा। linked article भले कमजोर हो, लेकिन वह इस हिस्से को cover करता है

    • लेख में Python और DuckDB को संभावित successor बताया गया है
      पहले Kdb+ ने मुझ पर काफ़ी गहरा असर डाला था। Chicago meetup में भी गया था, जहाँ बड़ी queries लगभग तुरंत चल गईं, और APL जैसी syntax math background वाले लोगों के ही समझ आने वाले जादुई मंत्र जैसी दिखती थी। sales rep ने कहा था कि Kdb इतना optimized है कि उस समय के processor के L1 cache में fit हो जाता है
      10 साल बाद, अब मैं Parquet files के ऊपर Python, DuckDB और Jupyter से वही काम कर रहा हूँ। DuckDB parallelization के साथ-साथ vectorization भी करता है। kdb+ से benchmark करने पर क्या नतीजा होगा, नहीं पता, लेकिन बड़े datasets पर DuckDB की responsiveness कम से कम kdb+ जितनी तेज़ महसूस होती है। बेशक kdb+ शायद बहुत ज्यादा optimized होगा, लेकिन फर्क यह है कि DuckDB free है
    • kdb की वजह से quant finance role में 2 हफ्ते भी न टिक पाना, और फिर यह कहना कि सब कुछ LISP में दोबारा लिखना चाहिए, अब तक देखी गई काफी HN-टाइप repeat-offender comment लगती है
    • 2 हफ्तों में Q सीखकर यह निष्कर्ष निकालने की योग्यता मिल गई कि Python IDE अच्छे से इस्तेमाल करने वाला व्यक्ति दशकों के अनुभव वाले quant developer से ज्यादा productive है—ऐसा मानना मुश्किल है
      ज्यादा संभावना यह लगती है कि code समझ न आने से frustrate होकर नौकरी छोड़ दी
      अगर वे skilled quant developer होते और position अच्छी होती, तो ऐसे contract terms के तहत 2 हफ्तों में छोड़ना अगली job move manage करने के लिए disaster होता
    • pykx integration कई gaps को काफी हद तक भर रहा है। इनमें charts, machine learning/statsmodels, HTML processing और web scraping जैसे areas शामिल हैं
      उदाहरण के लिए, Jupyter Notebook खोलकर ऐसा कर सकते हैं
      import pykx as kx
      df = kx.q(“select from foo where bar”)
      plt.plot(df[“x”], df[“y”])
      यह सचमुच smooth और powerful integration है। दोनों worlds की खूबियाँ मिल जाती हैं, और यह अगले 10 साल तक इस product को जिंदा रखने वाला feature भी हो सकता है

  • यहाँ kdb+/Q की एक आकर्षक क्षमता, जिसे स्पष्ट रूप से नहीं छुआ गया, vertical integration है। आम तौर पर जहाँ पूरे stack के use case के लिए कई ready-made technologies जोड़नी पड़ती हैं, वहाँ इसे एक ही technology से संभाला जा सकता है
    Q language, data serialization की built-in सुविधाएँ, और inter-process communication capabilities की वजह से अनुभवी programmer ज़रूरी system को एक ही language में बिल्कुल tailor-made बना सकता है, और codebase भी अक्सर सैकड़ों या हज़ारों पन्नों के बजाय कुछ पन्नों के documents में समा जाता है
    अगर कोई संगठन पहले ही ऐसे कुछ roles को दूसरे software, protocols, formats से संभालने का फैसला कर चुका है, तो development flow और overall performance में vertical integration के फायदे कम हो जाते हैं। kdb+ खुद proprietary है और महंगा भी, इसलिए नए projects में इसे पूरी तरह अपनाने को justify करना मुश्किल है, यह समझ आता है। technology अपने-आप में gem जैसी है, इसलिए वाकई अफसोस होता है

    • kdb+/Q की vertical integration क्षमता सचमुच कमाल की है, लेकिन Kx इसका सही फायदा क्यों नहीं उठाता, यह समझना मुश्किल है। Kx Platform ज्यादातर Java में लिखा हुआ लगता है, और Q से call किए जा सकने वाले APIs की documentation भी बहुत अच्छी नहीं है
      dashboard product इस्तेमाल में मुश्किल है, और मध्यम complexity वाले dashboards में भी editor अक्सर crash होने वाला गंभीर bug है। Q feature-rich है, इसलिए उससे web applications लिखना सचमुच मजेदार हो सकता था, लेकिन users को कुछ देने के लिए drag-and-drop editor इस्तेमाल करना ही पड़ता है
      अगर Shakti में load balancing, user permissions, SSO जैसे आम enterprise use cases को संभालने वाली libraries शामिल हों, तो वह Kx का वास्तविक competitor बन सकता है। कोई अनुभवी K programmer शायद 1–2 हफ्तों में बना दे, लेकिन बड़ी कंपनियाँ अक्सर product adoption तभी allow करती हैं जब ये features पहले से implemented हों
    • message queue, stream processor, database, query engine आदि को assemble किए बिना use case हल करने वाला एक code लिख पाना बड़ा फायदा है
      Kafka, Flink, Postgres, Iceberg जैसी open source technologies के ऊपर SQL से ऐसा integration layer बनाने और time-series processing को SQL में अधिक सुविधाजनक बनाने के लिए syntactic sugar जोड़ने का idea experiment कर रहा हूँ
      https://github.com/DataSQRL/sqrl/
      लक्ष्य है SQL को transform करना, computation DAG बनाना, फिर cost-based optimizer से DAG को काटकर underlying data technologies पर deploy करना, ताकि kdb+ की ताकत open source technologies और SQL के integrated package के रूप में दी जा सके

  • कई उपयोगों के लिए काम आने वाला free version निकालना चाहिए था
    मेरे हिसाब से kdb+ को एक शानदार technology और product के रूप में मान्यता मिलने और developer community में बढ़ने में सबसे बड़ी रुकावट यही थी
    finance sector में वर्षों तक kdb+ का काफी इस्तेमाल करके मैं इसका fan बन गया। design और simplicity में Unix philosophy में जड़ी हुई-सी elegance है। finance sector छोड़ने और kdb+ इस्तेमाल करने वाली company में काम न करने के बाद भी, इधर-उधर छोटे projects में kdb+ इस्तेमाल करने की इच्छा अक्सर होती थी
    यह बात खलती थी कि अब इसे इस्तेमाल नहीं कर सकता, और colleagues को यह कम-ज्ञात niche tool दिखाकर यह geek out भी नहीं कर सकता कि कुछ tasks और computations में यह कितना simple और efficient है

    • क्या कोई free version जैसा कुछ नहीं था?
      पहले मुझे kdb को data भेजने वाला C++ code और उनका wire protocol decoder लिखना पड़ा था, और दोनों के लिए testing वाला kdb binary जरूर था
      सिर्फ testing की जरूरत थी। शायद Kx ने development license दिया था, लेकिन यह काफी पुरानी बात है
    • ngn/k या Kerf जैसे open source versions काम के नहीं थे, यह जानना चाहूँगा

  • इस लेख की बातों से कुल मिलाकर सहमत हूँ। अगर नया बनाना हो, तो data को Parquet में store करके Polars या DuckDB से access किया जा सकता है
    q/kdb+ इतना नापसंद था कि time-series analysis के लिए अपनी language बना ली, लेकिन कई वर्षों से winner तो Python ही रहा है

  • kdb+ से एक हद तक सफल startup बनाया था। यह वह technology थी जिसे मैं जानता था, और इसने मजबूत product जल्दी बनाने में मदद की। लेकिन scale बढ़ने पर team expand करने के लिए इसे open source software में दोबारा लिखना पड़ा
    recommendations से काफी हद तक सहमत हूँ, लेकिन मुझे लगता है Kx को platform open source के रूप में release करना चाहिए। तब यह ecosystem में improvements और tools contribute करना चाहने वाले developer type को आकर्षित कर सकेगा

    • वह startup क्या था, और किस open source software पर migrate किया, यह जानना चाहूँगा

  • Kdb+ सचमुच शानदार दिखता है और APL के साथ इसे मजे के लिए थोड़ा सीखा था। मेरी industry में भी कई uses के लिए यह काफी fit लगता है, लेकिन price बिल्कुल बेतुकी है
    finance sector के banks जैसे प्रति CPU 100,000 डॉलर नहीं दे सकते। इसलिए असल में इसने बहुत बड़े potential customer base को ignore कर दिया

    • उन्होंने innovative product के लिए वह price दे सकने वाला niche market ढूँढ लिया। मुझे लगता है यह सही choice थी। क्योंकि यह शुरुआत से ही दुनिया की हर problem solve करने वाला product नहीं था
      दूसरे लोग उनकी techniques सीखकर दूसरे domains और languages में वही काम कर सकते हैं

  • लेख में कुछ corrections चाहिए

    1. ClickHouse कोई नई technology नहीं है। यह 2016 से open source है और 2009 से develop हो रहा है
    2. ClickHouse तीनों use cases संभाल सकता है। historical data और real-time data, distributed processing और local processing—सब संभव है। clickhouse-local और chdb देखें
    3. ClickHouse 2019 में अपने main product में ASOF JOIN देने वाला पहला SQL database था। kdb+ उससे पहले था, लेकिन SQL नहीं था
    • मैं ClickHouse पर काफी focused data consulting company चलाता हूँ। KDB को ClickHouse से replace करने में बहुत interest है। migration पर विचार कर रही companies से शायद 10 बार बात की होगी
      हालांकि अभी तक किसी ने सच में migration execute नहीं किया है। KDB से निकले कई integrations को देखते हुए शायद यह बड़ा फैसला है। फिर भी यह साफ तौर पर spiritual successor जैसा लगता है
    • point 3 ऐसी चीज है जिसे Q और उससे जुड़े tools को financial calculations में इस्तेमाल करने वाले लोग आसानी से miss कर सकते हैं। उन्होंने kdb+ चुना था तो उसकी वजह थी, और वह वजह database नहीं थी। लेख का core भी मैंने उसी तरह समझा

  • सोचता हूँ कि क्या अभी भी scratch से सीखकर kdb+ development में बहुत पैसा कमाया जा सकता है। कुछ साल पहले सालाना करीब 1 million dollars देने वाली job posting देखी थी, याद है; हैरानी हुई थी

  • अफसोस है कि kdb+ में DeWitt clause है, इसलिए लेख में आए दूसरे databases के साथ कोई benchmark नहीं कर सकता
    यह भी जानना चाहूँगा कि किसी third party ने public benchmark किया है या नहीं