O futuro do kdb+?
(timestored.com)- No setor financeiro, o kdb+ foi uma ferramenta poderosa para análise de dados históricos de mercado e cálculos em tempo real, mas agora já surgiram tecnologias alternativas suficientemente maduras para cada caso de uso
- Muitos usuários não precisam da velocidade máxima do kdb+, e as plataformas internas dos bancos também não conseguem extrair totalmente esse desempenho, então a vantagem de velocidade se tornou menos decisiva
- Na análise quant local, o ecossistema Python praticamente domina, e ferramentas comunitárias gratuitas como DuckDB e Polars são mais vantajosas em termos de aprendizado e mobilidade profissional
- Streaming em tempo real e computação distribuída continuam sendo pontos fortes do kdb+, mas a dificuldade de implementação e o mindshare de Kafka, Flink e RisingWave tornam sua expansão mais difícil
- Para o kdb+ sobreviver no longo prazo, precisa de um caminho de uso gratuito, foco no produto principal, redução da curva de aprendizado e apelo popular para se expandir além do setor financeiro
O papel que o kdb+ desempenhou no setor financeiro
- O kdb+ vem sendo usado em vários sistemas e tarefas analíticas do setor financeiro
- Armazenamento e análise de dados históricos de mercado: casos como MS Horizon, Citi CloudKDB e UBS Krypton
- Análise quant local: análise de liquidez, análise de PnL, análise de rentabilidade por cliente
- Motor de cálculo para streaming em tempo real: Streaming VWAP, Streaming TCA
- Computação distribuída: tarefas como cálculo de margem de portfólio de ações e análise de risco, em que os dados são divididos, processados e depois reunidos
Dados históricos de mercado: os clientes atuais ficam, mas é difícil expandir para novos
- Muitos usuários querem consultar grandes volumes de dados para criar minute bars, fazer
asof joine realizar análises de séries temporais mais avançadas - As opções concorrentes se ampliaram para novos bancos de dados como ClickHouse e QuestDB, fornecedores de nuvem como BigQuery e Redshift, e também Market Data as a Service
- Há três motivos pelos quais a vantagem de velocidade do kdb+ já não é tão decisiva quanto antes
- A maioria dos usuários não precisa da “velocidade” do kdb+
- A maioria das plataformas internas dos bancos não consegue extrair totalmente a velocidade do kdb+
- Os produtos concorrentes agora já são rápidos o suficiente
- O benchmark ClickBench é citado como um benchmark divulgado de forma transparente
- O kdb+ pode manter os clientes existentes, mas as empresas de segundo escalão querem opções cloud-native ou outras alternativas, então conquistar novos clientes não é fácil
- Os principais clientes atuais precisaram investir muito na construção de suas próprias plataformas, e a plataforma kdb cloud ainda tem pontos que precisam de mais refinamento
Análise quant local: o ecossistema Python está à frente
- As alternativas para análise quant local são, em sua maioria, organizadas em torno de Python
- Python + DuckDB
- Python + Polars
- Python + PyKX
- Python + dataframe, Modin etc.
- Nessa área, Python já venceu; a pergunta restante é mais sobre quem oferece ferramentas complementares rápidas
- DuckDB e Polars são fortes candidatos porque são gratuitos
- Usuários que começam na universidade tendem a aprender com ferramentas gratuitas e depois provavelmente não trocam
- Quants em empresas também preferem ferramentas gratuitas com as quais possam continuar fazendo análises semelhantes no próximo emprego
- Se depender apenas de kdb+, ao mudar para uma empresa que não usa kdb+, a pessoa pode perder uma grande parte do seu conjunto de habilidades
- O kdb+ é um produto de nicho que não conseguiu se expandir muito além das finanças, tem alto custo inicial e a desvantagem de uma sintaxe pouco familiar
Streaming em tempo real e computação distribuída: há pontos fortes, mas o vencedor é incerto
- Streaming em tempo real e computação distribuída sempre foram casos de uso menos populares para o kdb+ e também não eram o principal motivo para fechar contratos
- A capacidade de combinar dados em tempo real e dados históricos em um único modelo é apontada como o maior ponto forte do kdb+
- Em implementações reais, às vezes era necessário pessoal muito experiente, ou o sistema acabava virando uma bagunça
- Esses casos de fracasso também afetam negativamente a adoção do kdb+ para outros usos dentro da empresa
- O vencedor final nessa área ainda não está definido, mas parece improvável que seja o kdb+
- Kafka já garantiu implantações em grande escala e mindshare, e tecnologias como Flink e RisingWave também estão em ascensão
Open source e padronização absorvem as vantagens do kdb+
- O kdb+ é uma tecnologia excelente, mas enquanto permaneceu excelente em um nível parecido ao de 15 anos atrás, o ecossistema ao redor mudou rapidamente
- Boas empresas de open source aproveitaram as ideias centrais do kdb+
- Parquet/Iceberg é semelhante ao formato em disco do kdb+ para armazenamento colunar otimizado
- O formato em memória do Apache Arrow é semelhante ao formato colunar em memória do kdb+
- Os conceitos de log/replay/ksql do Kafka também podem ser vistos, sob certo ângulo, como semelhantes ao tplog
- QuestDB, DuckDB e ClickHouse todos oferecem suporte a asof join
- Os concorrentes não apenas aprenderam com as vantagens do kdb+, como também as padronizaram
- Snowflake, Dremio, Confluent e Databricks passaram a oferecer suporte a Apache Iceberg e Parquet
- QuestDB, DuckDB e Python passaram a oferecer suporte nativo a Parquet
- Quando os dados estão em Parquet, várias ferramentas podem operar sobre o mesmo conjunto de dados
- O cenário de comparação já não é mais KX contra um concorrente isolado, mas KX contra o conjunto de vários concorrentes
O que a KX precisa mudar
- Há a avaliação de que a KX está mudando, mas não com rapidez suficiente
- As mudanças necessárias se resumem em quatro pontos
- É preciso oferecer uma versão gratuita que possa ser usada para vários fins, além de um licenciamento razoável para clientes com orçamento reduzido
- É preciso focar em tornar o produto principal excelente
- MongoDB e InfluxDB são exemplos de contraste, tendo fechado grandes contratos apenas com um bom banco de dados
- A maturidade do produto principal é mais importante do que produtos adjacentes como Delta e kdb.ai
- Também é preciso reduzir a íngreme curva de aprendizado do kdb+
- Se necessário, isso incluiria até mudar a própria linguagem e tecnologia
- Se não conseguir se tornar mais popular, isso pode levar a um declínio lento
- Deve-se considerar mudanças mais amplas em nível de empresa, incluindo não apenas o produto tecnológico central, mas também grandes custos e iniciativas como IA e grandes gastos de marketing
1 comentários
Comentários do Hacker News
Também gostaria de colocar o TimescaleDB como candidato. Como é uma extensão do PostgreSQL, elementos relacionados a SQL como replicação e autenticação são preservados como estão
Ele também oferece compressão no formato de armazenamento colunar e é muito rápido. Já usei em alguns aplicativos financeiros, e uma quantidade enorme de dados de ticks chegava até a aplicação praticamente na velocidade máxima que o hardware permitia
O suporte também é bom e as respostas no Slack são rápidas. Já usei kdb também, mas ele tem a grande desvantagem de ser caro, e a linguagem Q às vezes é divertida como code golf, mas no fim você percebe que caracteres únicos não são tão expressivos quanto parecem
Se o objetivo for análise quantitativa ad hoc, talvez o kdb seja o certo, já que você pode passar o dia inteiro digitando strings curtas no REPL procurando algo que dê dinheiro. Mas muito trabalho na prática se parece mais com tarefas de cron, então, se você vai rodar consultas definidas em uma agenda, é melhor deixá-las legíveis para que a próxima pessoa consiga entender e fazer manutenção
Cenários como “mostrar sensores no mapa e exibir o gráfico dos valores de cada sensor” podem ser resolvidos de forma rápida e limpa com uma única consulta
Só que meus dados são meio patológicos, então a fonte pode mudar a estrutura à vontade e eu preciso aceitar isso. Se o preço do InfluxDB não fosse completamente insano, sinceramente acho que eu usaria InfluxDB na hora
Já tive um trabalho de trading quantitativo usando kdb+ do qual saí em duas semanas. Eu até conseguia usar, mas a experiência foi péssima
Eu poderia reclamar do design da linguagem ou de como a depuração é horrível, mas o mais frustrante era o jeito como havia ou não havia convenções de programação, e acho que a linguagem e a comunidade têm um grande papel nisso. A cultura da empresa também contribuía: quando perguntei por que a documentação era tão ruim, ouvi como resposta: “com o tempo nós vamos entender, e assim outros times não conseguem usar nossas ideias”
A stack inteira também era antiga, e com uma ferramenta como Q era difícil fazer muita coisa interessante. Por exemplo, no qStudio copiávamos os dados para o Excel para fazer gráficos
A única coisa boa era que eles não compraram a moda de Docker/Kubernetes e faziam deploy diretamente nos servidores. Faz sentido que quants consigam corrigir rápido em produção, mas também acho certo que desenvolvedores web não precisem esperar 10 minutos para ver o resultado de uma alteração em produção
Tenho uma teoria sobre por que os quants gostam do kdb. O kdb é uma boa arma. Serve para certos propósitos, mas é chato de construir coisas com ele, então é difícil chamar de ferramenta. O que eles gostam é do fato de ele funcionar imediatamente. Mas só porque você consegue pregar um prego com uma faca não significa que esse seja o propósito da faca
Levando essa teoria adiante, LISP, especialmente Racket, pode ser a melhor ferramenta. Não é a linguagem mais poderosa desde o começo, mas permite criar muitas abstrações graças à capacidade de mudar a própria linguagem. C++ e Python são excelentes linguagens de programação para criar bom software, e Python também é uma arma bastante boa
Q pode dar a ilusão de ser a melhor linguagem para explorar dados quantitativos, mas isso acontece porque os quants não investem o suficiente em construir bom software e usar boas ferramentas. Se você realmente dominar uma IDE de Python, pode ser mais produtivo do que qualquer programador de Q
Nem vou começar a falar de desempenho. O texto do link pode não ser grande coisa, mas cobre essa parte
Antigamente fiquei bastante impressionado com o Kdb+. Fui até a um encontro em Chicago, e consultas grandes eram executadas quase instantaneamente, enquanto a sintaxe parecida com APL parecia um feitiço conhecido só por pessoas da área de matemática. O vendedor dizia que o Kdb era tão otimizado que cabia no cache L1 dos processadores da época
Dez anos depois, agora faço o mesmo trabalho com Python, DuckDB e Jupyter sobre arquivos Parquet. O DuckDB não só paraleliza como também vetoriza. Não sei como seria num benchmark contra kdb+, mas a responsividade do DuckDB em grandes conjuntos de dados parece pelo menos tão rápida quanto a do kdb+. Claro que o kdb+ deve ser muito mais otimizado, mas a diferença é que o DuckDB é gratuito
Parece bem mais provável que ela não tenha conseguido entender o código, tenha se frustrado e desistido
Se fosse um desenvolvedor quant experiente e fosse uma boa vaga, sair em duas semanas nessas condições contratuais teria sido um desastre para administrar na próxima mudança de emprego
Por exemplo, basta abrir um Jupyter Notebook e fazer isto
import pykx as kxdf = kx.q(“select from foo where bar”)plt.plot(df[“x”], df[“y”])É uma integração realmente fluida e poderosa. Você consegue o melhor dos dois mundos, e isso pode acabar sendo o recurso que salva esse produto pelos próximos 10 anos
Um recurso atraente do kdb+/Q que não foi abordado explicitamente aqui é a integração vertical. Em vez de precisar escolher e encaixar várias tecnologias prontas, dá para resolver com uma única tecnologia casos de uso de uma stack inteira
Graças à linguagem Q, aos recursos nativos de serialização de dados e à comunicação entre processos, um programador experiente consegue construir sob medida exatamente o sistema necessário em uma única linguagem, e a base de código muitas vezes cabe em poucas páginas de documentação, não em centenas ou milhares
Se a organização já decidiu cobrir parte desse papel com outros softwares, protocolos e formatos, as vantagens da integração vertical em fluxo de desenvolvimento e desempenho geral diminuem. Como o próprio kdb+ é proprietário e ainda por cima caro, dá para entender por que é difícil justificar uma adoção total em projetos novos. A tecnologia em si é uma joia, o que é realmente uma pena
O produto de dashboards é difícil de usar, e há bugs graves em que o editor cai com frequência até em dashboards de complexidade média. O Q é tão rico em recursos que seria muito divertido escrever aplicações web com ele, mas para entregar algo ao usuário você acaba sendo obrigado a usar um editor drag-and-drop
Se o Shakti incluir bibliotecas para lidar com casos de uso corporativos comuns, como balanceamento de carga, permissões de usuário e SSO, acho que pode se tornar um concorrente real da Kx. Um programador K experiente provavelmente conseguiria fazer isso em 1 ou 2 semanas, mas em grandes empresas muitas vezes a adoção de um produto só é permitida quando esses recursos já estão prontos
Estou experimentando a ideia de criar, em cima de tecnologias open source como Kafka, Flink, Postgres e Iceberg, uma camada de integração em SQL com açúcar sintático para tornar o processamento de séries temporais mais conveniente em SQL
https://github.com/DataSQRL/sqrl/
O objetivo é transformar SQL, criar um DAG de computação e então particionar esse DAG com um otimizador baseado em custo para implantá-lo nas tecnologias de dados subjacentes, oferecendo assim o poder do kdb+ em um pacote que integra tecnologias open source e SQL
Eles deveriam ter lançado uma versão gratuita que pudesse ser usada para várias finalidades
Acho que esse foi o maior obstáculo para que o kdb+ fosse reconhecido como uma excelente tecnologia e produto e crescesse dentro da comunidade de desenvolvedores
Usei bastante o kdb+ por anos no setor financeiro e virei fã. Há uma elegância no design e na simplicidade que parece enraizada na filosofia Unix. Mesmo depois de sair do setor financeiro e deixar de trabalhar em empresas que usam kdb+, eu frequentemente tinha vontade de usar kdb+ em pequenos projetos aqui e ali
Era frustrante não poder mais usá-lo, nem mostrar aos colegas essa ferramenta de nicho pouco conhecida e pirar em como ela era simples e eficiente para certas tarefas e cálculos
Há muito tempo precisei escrever um código em C++ que enviava dados para o kdb e também um decodificador do protocolo wire deles, e certamente havia um binário de kdb para testes para ambos
Eu só precisava testar. Acho que a Kx chegou a conceder uma licença de desenvolvimento, mas isso faz bastante tempo
Concordo de modo geral com o conteúdo deste texto. Se fosse para construir algo novo, eu armazenaria os dados em Parquet e acessaria com Polars ou DuckDB
Eu odiava tanto q/kdb+ que acabei criando minha própria linguagem para análise de séries temporais, mas o vencedor já era Python havia vários anos
Construí uma startup com algum sucesso usando kdb+. Era uma tecnologia que eu conhecia e que ajudou a criar um produto sólido rapidamente. Mas, à medida que a escala aumentou, tivemos que reescrever para software open source a fim de expandir a equipe
Concordo em grande parte com as recomendações, mas acho que a Kx deveria abrir o código da plataforma. Isso atrairia o tipo de desenvolvedor que quer contribuir com melhorias e ferramentas para o ecossistema
O kdb+ parece realmente muito legal, e eu cheguei a aprender um pouco por diversão junto com APL. Também parece se encaixar muito bem em vários usos no meu setor, mas o preço é absurdo
Eu não posso pagar algo como US$ 100 mil por CPU como os bancos do setor financeiro pagam. Então eles basicamente ignoraram uma camada enorme de clientes em potencial
Outras pessoas podem aprender as técnicas deles e fazer a mesma coisa em outros domínios e linguagens
O texto precisa de algumas correções
clickhouse-localechdbMas ainda não houve nenhuma que realmente tenha executado a mudança. Talvez porque seja uma decisão grande, considerando as várias integrações que surgiram em torno do KDB. Ainda assim, sem dúvida parece um herdeiro espiritual
Ainda tenho curiosidade se, mesmo hoje, aprender do zero para trabalhar com desenvolvimento em kdb+ pode render muito dinheiro. Lembro de ter visto, alguns anos atrás, uma vaga pagando algo como US$ 1 milhão por ano, e isso me surpreendeu
É uma pena que o kdb+ tenha uma cláusula DeWitt, então ninguém pode compará-lo em benchmarks com os outros bancos de dados citados no texto
Também fico curioso se existe algum benchmark público feito por terceiros