opteryx-core

Opteryx Core é o mecanismo de execução SQL por trás do opteryx.app, publicado como um fork do Opteryx com uma API e superfície de configuração menores e mais opinativas, moldadas em torno das cargas de trabalho do serviço hospedado. Ele é projetado para consultas analíticas rápidas e de leitura intensiva sobre dados colunares: lida com análise SQL, planejamento, pushdown de predicados, poda de projeção e execução, para que conjuntos de dados possam ser consultados do Python sem a necessidade de configurar um warehouse separado. Arquitetura O planejamento de consultas é escrito em Python; a execução de consultas é nativa. Uma vez que o planejador produz um plano físico, o mecanismo o executa em código compilado de ponta a ponta — scan, operadores, agendamento e despacho — e nem PyArrow nem NumPy estão presentes em nenhum lugar do mecanismo. Os resultados são retornados como morsels Draken, lotes de colunas transmitidos à medida que o mecanismo os produz, de modo que um grande resultado não precisa caber na memória de uma só vez. Um morsel expõe num_rows, column_names e column(name).to_pylist(); após o stream ser lido até o fim, session.rowcount relata o número de linhas entregues. Começando Os requisitos são Python 3.11 ou posterior, um toolchain C/C++ para builds locais de fonte, e Rust/Cargo para a extensão Rust. Instale com pip install opteryx-core e importe-o como opteryx. Um exemplo local mínimo registra um workspace com DiskConnector e consulta nomes de conjuntos de dados separados por ponto, resolvidos em relação ao diretório de trabalho atual, por exemplo, data.planets resolvendo para ./data/planets, com o formato detectado a partir das extensões de arquivo. Uma linha de comando também está disponível via python -m opteryx para consultas sem escrever Python. Usos pretendidos O projeto lista alimentar a camada de execução usada pelo opteryx.app, executar SQL analítico em conjuntos de dados locais Parquet, CSV, JSONL e .skene, embutir um mecanismo de consulta dentro de aplicações Python, scripts, notebooks e serviços, trabalhar nos internals do mecanismo, como planejamento, execução nativa e desempenho de formatos de arquivo, e usar o mecanismo de arquivo ou o formato .skene por conta própria através das wheels rugo e libskene. Layout do repositório e distribuições O repositório contém o mecanismo SQL (opteryx/), o substrato vetorial colunar nativo e morsels (draken/), o mecanismo de arquivo para leitura e escrita de Parquet, CSV e JSONL (rugo/), o formato de arquivo colunar .skene com leitor, escritor e especificação normativa em C++ (skene/), fontes de extensão de computação em Rust e C++ (src/), snapshots de catálogo gerados (reference/), testes, testdata, docs, scripts de desenvolvimento, dependências vendored e maquinário de build compartilhado em build_common.py. Uma árvore de fonte produz três wheels, com fonte única em build_common.py para que não possam divergir: opteryx-core (importado como opteryx) agrupa o mecanismo SQL completo com draken, rugo e skene; rugo fornece o mecanismo de arquivo mais draken para ler e escrever arquivos sem o mecanismo SQL; libskene (importado como skene) fornece o leitor e escritor .skene mais draken. draken não é publicado separadamente. rugo e skene são paralelos e nenhum depende do outro. As wheels são construídas em CI, não localmente; o desenvolvimento local usa os alvos do Makefile, como make dev-install, make compile, make c, make q, make test, make dt e make check. Formatos de arquivo Conjuntos de dados são lidos por extensão e um conjunto de dados é de um formato por completo; um diretório misturando formatos é um erro em vez de uma leitura de melhor esforço. Parquet é o padrão para dados armazenados e intercâmbio, lido através do rugo, assim como CSV e JSONL/NDJSON. O formato .skene é nativo do draken: armazena um ou mais grupos de linhas de vetores draken sem perdas, incluindo refinamentos que o Parquet descarta — uma coluna IPv4 faz round-trip como UINT32 refinado por um descritor lógico IPV4, e codificação de dicionário e dicas de layout são restauradas em vez de re-derivadas. Ele é deliberadamente não portátil e nenhum leitor estrangeiro é prometido, então Parquet permanece a escolha para intercâmbio. Arquivos Parquet, CSV e JSONL também podem ser nomeados diretamente com as funções de tabela read_parquet(), read_csv() e read_jsonl(); não há read_skene(). Integração de catálogo Opteryx Core é descrito como funcionando melhor quando pareado com a biblioteca opteryx_catalog, que é o modelo pretendido para conjuntos de dados nomeados, tabelas apoiadas por catálogo e a experiência geral usada no opteryx.app. A configuração define um conector padrão com catálogo, projeto e banco de dados Firestore, e um bucket GCS, após o qual conjuntos de dados apoiados por catálogo podem ser consultados com nomes separados por ponto, como public.space.planets. Para dados locais, workspaces registrados como testdata, scratch ou data são típicos. Posicionamento e contribuição O projeto se apresenta como um mecanismo analítico embutido em vez de uma plataforma completa de usuário final: para uma experiência hospedada e recursos de serviço multi-tenant, opteryx.app é a rota recomendada, enquanto este pacote fornece o mecanismo central diretamente. Contribuições são convidadas na forma de uso em conjuntos de dados pessoais, relatórios de bugs quando consultas, esquemas ou desempenho se comportam mal, pull requests para correções, testes, docs ou desempenho, e casos de reprodução compartilhados, consultas com falha e arquivos Parquet de caso extremo. O projeto é licenciado sob Apache-2.0, com documentação em docs.opteryx.app.