- 金融業界で kdb+ は、過去の市場データ分析とリアルタイム計算の強力なツールだったが、今では用途ごとに十分成熟した代替技術が登場している
- 多くのユーザーは kdb+ の最高速度までは必要としておらず、銀行の内部プラットフォームもその性能を完全には引き出せないため、速度面の優位性は以前ほど決定的ではなくなった
- ローカルでのクオンツ分析は Python エコシステムが事実上主導しており、DuckDB・Polars のような無料のコミュニティツールのほうが、学習や転職の面で有利
- リアルタイムストリーミングと分散計算は依然として kdb+ の強みだが、構築の難しさと Kafka・Flink・RisingWave のマインドシェア拡大が普及を難しくしている
- kdb+ が長期的に生き残るには、無料で使える導線、コア製品への集中、学習曲線の緩和、金融業界の外へ広げられる大衆性が必要
金融業界で kdb+ が担ってきた役割
- kdb+ は複数の金融システムや分析業務で使われてきた
- 過去の市場データの保存・分析: MS Horizon、Citi CloudKDB、UBS Krypton などの事例
- ローカルでのクオンツ分析: 流動性分析、PnL 分析、顧客別収益性分析
- リアルタイムストリーミング計算エンジン: Streaming VWAP、Streaming TCA
- 分散計算: 株式ポートフォリオのマージン計算、リスク分析のように、データを分割して計算し、その後再び結合する作業
過去の市場データ: 既存顧客は残っても新規拡大は難しい
- 多くのユーザーは大容量データをクエリして minute bar を作成し、asof join や、より高度な時系列分析を行おうとしている
- 競合の選択肢は、ClickHouse、QuestDB のような新しいデータベース、BigQuery・Redshift のようなクラウドベンダー、Market Data as a Serviceへと広がっている
- kdb+ の速度面の優位性が以前ほど決定的でない理由は3つある
- ほとんどのユーザーは kdb+ の「速度」までは必要としていない
- ほとんどの銀行の内部プラットフォームは kdb+ の速度を完全には引き出せない
- 競合製品が今では十分に高速になった
- ClickBench ベンチマークは、透明性高く公開されたベンチマークとして言及されている
- kdb+ は既存顧客を維持することはできるが、ティア2企業はクラウドネイティブや別の選択肢を求めており、新規獲得は容易ではない
- 既存の主要顧客は自社プラットフォーム構築に大きな投資をする必要があり、kdb cloud プラットフォームにはまだ磨き込むべき部分が残っている
ローカルでのクオンツ分析: Python エコシステムが優勢
- ローカルでのクオンツ分析の代替案は、ほとんどがPython 中心に整理される
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe、Modin など
- この領域では Python がすでに勝っており、残る問いは誰が高速な追加ツールを提供するかに近い
- DuckDB と Polars が有力な理由は、無料である点だ
- 大学で始めるユーザーは無料ツールで学び、その後も乗り換えない可能性が高い
- 企業にいるクオンツも、次の職場で同様の分析を続けられる無料ツールを好む
- kdb+ だけに依存すると、kdb+ のない企業へ移ったときにスキルセットの大きな部分を失う可能性がある
- kdb+ は金融以外に大きく広がっていないニッチ製品であり、導入コストが高く、文法も馴染みにくいという弱点がある
リアルタイムストリーミングと分散計算: 強みはあるが勝者は不透明
- リアルタイムストリーミングと分散計算は、kdb+ において常に人気の低い用途であり、契約を獲得する主な理由でもなかった
- リアルタイムデータと過去データを1つのモデルで結合する能力は、kdb+ の最大の強みとされる
- 実際の構築では、非常に熟練した人材が必要だったり、システムが混乱状態になったりすることがあった
- こうした失敗事例は、社内の別部門が kdb+ を別用途で採用する際にも悪影響を及ぼす
- この領域の最終的な勝者はまだはっきりしないが、kdb+ になる可能性は低そうだ
- Kafka はすでに大規模デプロイとマインドシェアを獲得しており、Flink や RisingWave のような技術も台頭している
オープンソースと標準化が kdb+ の強みを吸収
- kdb+ は優れた技術だが、15年前と同じような水準で優れたままでいる間に、周辺エコシステムは急速に変化した
- 優れたオープンソース企業は kdb+ の中核的なアイデアを取り入れた
- Parquet/Iceberg は、最適化されたカラムストレージのための kdb+ のディスクフォーマットに似ている
- Apache Arrow のインメモリフォーマットは、kdb+ のインメモリカラムフォーマットに似ている
- Kafka の log/replay/ksql の概念も、ある角度からは tplog に似ていると見なせる
- QuestDB、DuckDB、ClickHouse はいずれも asof join をサポートしている
- 競合は kdb+ の強みを学んだだけでなく、それを標準化した
- Snowflake、Dremio、Confluent、Databricks は Apache Iceberg と Parquet をサポートするようになった
- QuestDB、DuckDB、Python は Parquet をネイティブにサポートするようになった
- データが Parquet であれば、複数のツールが同じデータに対して実行できる
- 比較構図はもはや KX 対単一の競合ではなく、KX 対複数の競合全体になった
KX が変えるべきこと
- KX は変化しているが、十分に速くはないという評価がある
- 必要な変化は4つに整理される
- 複数の用途に使える無料版を提供し、予算の少ない顧客も容易に使える合理的なライセンスを用意すべき
- コア製品を優れたものにすることに集中すべき
- MongoDB と InfluxDB は、優れたデータベースだけでも大きな契約を獲得できることを示す比較事例である
- Delta、kdb.ai のような周辺製品よりも、コア製品の完成度のほうが重要
- kdb+ の急な学習曲線も緩和する必要がある
- 必要であれば、言語や技術そのものを変える方法まで含まれる
- より大衆的になれなければ、緩やかな衰退につながる可能性がある
- 中核となる技術製品だけでなく、AI、大規模なマーケティング支出のような大きなコストや取り組みを含め、会社全体としてより広い変化も検討すべき
1件のコメント
Hacker News の意見
TimescaleDBも候補に入れたい。PostgreSQLの拡張なので、レプリケーションや認証のようなSQL関連の要素がそのまま維持される
カラム型ストレージ方式で圧縮もサポートしており、非常に速い。いくつかの金融アプリケーションで使ったことがあるが、膨大な量のティックデータが、ハードウェアの許すほぼ最大速度でアプリケーションまで流れ込んできた
サポートも良く、Slackでの反応も速い。kdbも使ったことがあるが、高価という大きな欠点があり、Q言語はたまにコードゴルフのように楽しむには良いものの、結局は単一文字の並びが思ったほど表現力に優れていないことに気づく
即席のクオンツ分析が目的なら、REPLに短い文字列を一日中打ち込んで金になるものを探すkdbが合っているかもしれない。だが多くの作業は実際にはcronジョブに近いので、決まったクエリをスケジュールに沿って回すつもりなら、次の人が理解して保守できるよう、読みやすい形にしておく方がよい
「センサーを地図上に表示し、各センサーの値のグラフを見せる」といったシナリオを、単一のクエリで高速かつすっきり処理できる
ただし自分のデータは少し病的で、送信元側が構造を好き勝手に変えられ、こちらはそれを受け入れなければならない。InfluxDBの価格が完全に狂っていなければ、正直すぐにInfluxDBを使っていたと思う
kdb+を使うクオンツトレーディングの仕事を2週間で辞めたことがある。使えはしたが、体験はあまりにひどかった
言語設計やデバッグが最悪だと文句を言うこともできるが、いちばん苛立ったのはコーディング規約があるのかないのか分からないようなやり方で、そこには言語とコミュニティが大きく関わっていると思う。会社文化も一因で、ドキュメントがなぜこんなにひどいのかと聞いたら、「時間が経てば自分たちは理解できるし、こうしておけば他チームが自分たちのアイデアを使えない」と言われた
スタック全体も古びていて、Qのようなツールでは面白いことをあまり多くはできなかった。たとえばqStudioからExcelにデータをコピーしてグラフを描いていた
唯一良かったのは、Docker/Kubernetesの流行に乗らず、サーバーへ直接デプロイしていた点だ。クオンツが本番環境で素早く修正できるべきだというのは理にかなっているが、Webアプリ開発者であっても、本番で修正結果を見るために10分ずつ待たされないのが当然だと思う
クオンツがkdbを好む理由についての持論がある。kdbは良い武器だ。ある目的には合っているが、作るのが退屈なので道具と呼ぶのは難しい。すぐ動く点が好まれているのだ。だが、ナイフで釘を打てるからといって、それがナイフの目的ではない
その理論を続けるなら、LISP、とくにRacketが最高の道具になり得る。最初から最も強力な言語というわけではないが、言語自体を変える機能によって多くの抽象化を作れるからだ。C++とPythonは良いソフトウェアを作れる優れたプログラミング言語であり、Pythonはかなり良い武器でもある
Qはクオンツデータを探索する最高の言語であるかのような錯覚を与え得るが、それはクオンツたちが良いソフトウェアを作り、良い道具を使うことに十分投資していないからだ。Python IDEをきちんと習得すれば、どんなQプログラマーより生産的になれる
性能の話は始めるつもりもない。リンク先の記事は出来は良くないが、その点は扱っている
以前Kdb+にはかなり強い印象を受けた。Chicagoのミートアップにも行ったが、大きなクエリがほぼ即時に実行され、APLのような構文は数学系の人だけが知る魔法の呪文のように見えた。営業担当者は、Kdbは非常に最適化されていて、当時のプロセッサのL1キャッシュに収まると言っていた
10年が経った今では、Parquetファイルの上でPython、DuckDB、Jupyterを使って同じことをしている。DuckDBは並列化だけでなくベクトル化も行う。kdb+とベンチマークしたらどうなるかは分からないが、大きなデータセットでのDuckDBの応答性は、少なくともkdb+と同じくらい速く感じる。もちろんkdb+の方がはるかに最適化されているのだろうが、違いはDuckDBが無料だという点だ
むしろコードを理解できずに挫折して辞めた可能性の方がずっと高そうだ
熟練したクオンツ開発者で、良いポジションだったなら、このような契約条件で2週間で辞めるのは、次の転職を管理する上で大惨事になったはずだ
たとえばJupyter Notebookを開いて、こうすればよい
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])本当に滑らかで強力な統合だ。両方の世界の良いところをすべて得られ、今後10年にわたってこの製品を生かし続ける機能になるかもしれない
ここで明示的には触れられていない kdb+/Q の魅力的な機能の一つは、垂直統合です。通常なら複数の既成技術を選んでつなぎ合わせる必要があるフルスタックのユースケースを、単一の技術で扱えます。
Q 言語、データシリアライズの基本機能、プロセス間通信機能のおかげで、熟練したプログラマーは必要なシステムを一つの言語でぴったり作り込め、コードベースも数百ページや数千ページではなく、数ページの文書に収まる程度になることがよくあります。
組織がすでにその役割の一部を別のソフトウェア、プロトコル、形式で処理すると決めているなら、開発フローと全体性能における垂直統合の利点は小さくなります。kdb+ 自体がプロプライエタリで、しかも高価なので、新規プロジェクトで全面採用を正当化しにくいのは理解できます。技術そのものは宝石のようなのに、本当に惜しいです。
ダッシュボード製品は使いにくく、中程度の複雑さのダッシュボードでもエディタが頻繁に落ちる深刻なバグがあります。Q は機能が豊富なので、Web アプリケーションを書けば本当に楽しいはずなのに、ユーザーに何かを提供するにはドラッグ＆ドロップ式エディタを使うしかありません。
Shakti がロードバランシング、ユーザー権限、SSO のような一般的なエンタープライズ向けユースケースを扱うライブラリを含めれば、Kx の実質的な競合になり得ると思います。熟練した K プログラマーなら 1〜2週間で作れるでしょうが、大企業はこうした機能が実装されていないと製品導入を認めないことが多かったです。
Kafka、Flink、Postgres、Iceberg のようなオープンソース技術の上に SQL でこの種の統合レイヤーを作り、時系列処理を SQL でより扱いやすくする構文糖を載せるアイデアを試しています。
https://github.com/DataSQRL/sqrl/
目標は、SQL を変換して計算 DAG を作り、その DAG をコストベース最適化器で切り分けて基盤となるデータ技術に配置することで、kdb+ の力をオープンソース技術と SQL を統合したパッケージとして提供することです。
さまざまな用途に使える無料版を出すべきでした。
kdb+ が優れた技術であり製品として認められ、開発者コミュニティで成長するうえで最大の障害はこの点だったと思います。
金融業界で何年も kdb+ をかなり使い込み、ファンになりました。設計と単純さには、Unix 哲学に根ざしたような優雅さがあります。金融業界を離れ、kdb+ を使う会社で働かなくなった後も、あちこちの小さなプロジェクトで kdb+ を使いたい衝動に何度も駆られました。
もう使えず、同僚にこのあまり知られていないニッチなツールを見せて、特定の作業や計算でどれほど単純かつ効率的かを熱く語ることもできないのがもどかしかったです。
以前、kdb にデータを送る C++ コードと、彼らのワイヤプロトコルのデコーダを書く必要がありましたが、どちらにもテスト用の kdb バイナリが確かにありました。
必要だったのはテストだけでした。Kx が開発ライセンスをくれたような気もしますが、かなり昔の話です。
この記事の内容には全体的に同意します。新しく作るなら、データを Parquet に保存して Polars や DuckDB でアクセスすればよいでしょう。
q/kdb+ があまりに嫌で時系列分析用の言語を自作しましたが、すでに何年も前から勝者は Python でした。
kdb+ である程度成功したスタートアップを作りました。自分が知っている技術で、堅牢な製品を素早く作る助けになりました。ただ、規模が大きくなるにつれて、チームを拡大するためにオープンソースソフトウェアで書き直す必要がありました。
提言には概ね同意しますが、Kx はプラットフォームをオープンソースとして公開すべきだと思います。そうすれば、エコシステムに改善やツールを貢献したいタイプの開発者を引き寄せられます。
Kdb+ は本当に格好よく見え、APL と一緒に趣味で少し学びました。自分の業界でもいろいろな用途にかなり合いそうですが、価格がとんでもありません。
金融機関の銀行が払うような CPU あたり10万ドル みたいな金額は払えません。なので、実質的に非常に大きな潜在顧客層を無視したことになります。
他の人たちは彼らの手法を学び、別の領域や言語に合わせて同じことができます。
記事についていくつか修正が必要です。
clickhouse-localとchdbを見るとよいです。ただし、まだ実際に移行を実行したところはありません。KDB から派生した多くの統合を考えると、大きな決断になるからだと思います。それでも精神的後継者のように感じられるのは確かです。
今から一から学んで kdb+ 開発で大金を稼げるのか気になります。数年前に年100万ドルくらい払う求人を見た記憶があり、驚きました。
kdb+ には DeWitt 条項があるため、記事に出てきた他のデータベースと誰もベンチマークできないのが残念です。
第三者による公開ベンチマークがあるのかも気になります。