O futuro do kdb+?

Casos de uso

• Armazenamento e análise de dados históricos de mercado

  • Ex.: MS Horizon, Citi CloudKDB, UBS Krypton

• Análise quantitativa local

  • Ex.: análise de liquidez, análise de PnL, análise de rentabilidade por cliente

• Motor de cálculo de streaming em tempo real

  • Ex.: VWAP em streaming, TCA em streaming

• Computação distribuída

  • Ex.: cálculo de margem ou análise de risco de uma carteira de ações

Alternativas

Dados históricos de mercado - alternativas ao kdb+

• Novas tecnologias de banco de dados

  • Clickhouse, QuestDB

• Fornecedores de nuvem

  • Bigquery, Redshift

• Serviços de dados de mercado

  • A maioria dos usuários não precisa da "velocidade" do kdb+
  • A maioria das plataformas bancárias internas não aproveita totalmente a velocidade do kdb+
  • Os concorrentes agora também já são rápidos o suficiente

Resultado esperado

• O kdb+ pode manter os clientes atuais, mas não deve conquistar empresas de segunda linha que querem algo cloud-native ou diferente

Análise quantitativa local - alternativas

• Python
  • DuckDB, Polars, PyKX, dataframe/modin etc.

Resultado esperado

• DuckDB ou Polars devem vencer, porque são gratuitos

Streaming em tempo real / computação distribuída

• O maior ponto forte do kdb+ é combinar streaming e dados históricos em um único modelo
• Porém, isso exige pessoas experientes; caso contrário, tudo fica confuso

Resultado esperado

• O kdb+ não deve vencer. O Kafka já conquistou mindshare, e flink/risingwave são as estrelas em ascensão

Resumo

• O kdb+ é uma tecnologia incrível, mas está no mesmo nível de 15 anos atrás

• As melhores empresas de open source copiaram as ideias do kdb+

  • Parquet/Iceberg são o formato de disco do kdb+
  • Apache Arrow é o formato em memória do kdb+
  • Os conceitos de log/replay/ksql do Kafka também são parecidos
  • QuestDB, DuckDB e Clickhouse todos suportam asof join

• Os concorrentes padronizaram as melhores partes do kdb+

  • Ex.: Snowflake, Dremio, Confluent e Databricks todos suportam Apache Iceberg/parquet
  • QuestDB, DuckDB e Python todos suportam parquet nativamente

• A KX precisa fazer quatro coisas

  • Oferecer uma versão gratuita e uma licença de baixo custo
  • Tornar o produto principal excelente
  • Reduzir a curva de aprendizado
  • Ganhar mais popularidade

Resumo do GN⁺

• O kdb+ continua sendo uma tecnologia poderosa, mas os concorrentes estão alcançando rapidamente
• Ferramentas gratuitas e open source estão ganhando popularidade, então há grande chance de a participação de mercado do kdb+ diminuir
• Para ganhar mais popularidade, o kdb+ precisa oferecer uma versão gratuita, suavizar a curva de aprendizado e fortalecer o produto principal
• Produtos com funcionalidades semelhantes incluem DuckDB, Polars e QuestDB

[GN⁺]

Comentários do Hacker News

• O TimeScale é uma extensão do Postgres, então é possível usar os recursos de SQL como estão

  • Tem compressão com armazenamento colunar, então funciona muito rápido
  • Já foi usado em aplicações financeiras e consegue processar grandes volumes de dados rapidamente
  • O suporte no Slack é bom, e a experiência pessoal foi satisfatória
  • O kdb é caro e a linguagem é ineficiente

• Houve um caso de alguém que pediu demissão após duas semanas por causa da experiência de usar kdb+

  • O design da linguagem e a depuração são incômodos, e não há regras de codificação ou elas são insuficientes
  • A cultura da empresa também era problemática, com código mal documentado
  • Toda a stack é antiquada, e usavam qStudio para copiar dados para o Excel e fazer gráficos
  • É positivo que façam deploy diretamente nos servidores, sem usar Docker ou k8s
  • O kdb é usado mais como uma arma do que como uma ferramenta

• A integração vertical do kdb+ é uma vantagem

  • Uma única tecnologia pode cumprir vários papéis
  • Com a linguagem Q, serialização de dados e recursos de IPC, dá para construir sistemas sob medida
  • Porém, como o kdb+ é proprietário e caro, é difícil adotá-lo em novos projetos

• O kdb+ tem pouca visibilidade por não ter uma versão gratuita

  • Houve experiência com kdb+ no setor financeiro, e o design e a simplicidade lembram a filosofia Unix
  • Mesmo depois de sair do setor financeiro, a pessoa queria continuar usando kdb+, mas a ausência de uma versão gratuita era um problema

• Houve quem odiasse tanto q/kdb+ que acabou criando a própria linguagem

  • Python é o mais usado atualmente

• Houve experiência de operar uma startup com sucesso usando kdb+

  • Para expandir a equipe, foi necessário reescrever em FOSS
  • A pessoa acha que a kx deveria tornar a plataforma open source

• O kdb+ é interessante, mas o preço é alto demais

  • Estão ignorando muitos clientes em potencial

• Algumas correções sobre o ClickHouse

  • O ClickHouse é open source desde 2016 e vem sendo desenvolvido desde 2009
  • O ClickHouse consegue atender aos três casos de uso
  • O ClickHouse foi o primeiro banco de dados SQL a introduzir ASOF JOIN, em 2019

• Python domina no momento, mas a dívida técnica dificulta a migração para uma nova plataforma

  • Novos projetos de desenvolvimento provavelmente usarão Python

• Pergunta sobre ganhar muito dinheiro como desenvolvedor kdb+

  • Alguns anos atrás, havia vagas com salário anual de US$ 1 milhão