opteryx-core

Opteryx Coreは、opteryx.appを支えるSQL実行エンジンであり、ホスト型サービスのワークロードに合わせてより小さく、より意見の強いAPIと設定面を持つOpteryxのフォークとして公開されています。列指向データに対する高速で読み取り中心の分析クエリ向けに設計されており、SQLの解析、計画、述語プッシュダウン、射影プルーニング、実行を処理するため、別途ウェアハウスを立ち上げることなくPythonからデータセットをクエリできます。 アーキテクチャ クエリ計画はPythonで書かれており、クエリ実行はネイティブです。プランナが物理プランを生成すると、エンジンはそれをコンパイル済みコードでエンドツーエンドに実行します — スキャン、演算子、スケジューリング、ディスパッチ — そしてエンジン内のどこにもPyArrowもNumPyも存在しません。結果はDraken morselとして返されます。これはエンジンが生成するにつれてストリームされる列のバッチであり、大きな結果を一度にメモリに収める必要がありません。morselはnum_rows、column_names、column(name).to_pylist()を公開します。ストリームを最後まで読み取った後、session.rowcountは配信された行数を報告します。 はじめに 要件はPython 3.11以降、ローカルソースビルド用のC/C++ツールチェーン、Rust拡張用のRust/Cargoです。pip install opteryx-coreでインストールし、opteryxとしてインポートします。最小限のローカル例では、DiskConnectorでワークスペースを登録し、現在の作業ディレクトリからの相対で解決されるドット区切りのデータセット名をクエリします。たとえばdata.planetsは./data/planetsに解決され、フォーマットはファイル拡張子から検出されます。Pythonを書かずにクエリするためのコマンドラインもpython -m opteryxで利用できます。 想定される用途 このプロジェクトは、opteryx.appが使用する実行層の動力、ローカルのParquet、CSV、JSONL、.skeneデータセットに対する分析SQLの実行、Pythonアプリケーション、スクリプト、ノートブック、サービスへのクエリエンジンの埋め込み、計画、ネイティブ実行、ファイルフォーマット性能などのエンジン内部への取り組み、そしてrugoとlibskeneのwheelを通じてファイルエンジンや.skeneフォーマットを単独で使用することを挙げています。 リポジトリ構成とディストリビューション リポジトリには、SQLエンジン（opteryx/）、ネイティブ列指向ベクタ基盤とmorsel（draken/）、Parquet、CSV、JSONLの読み書き用ファイルエンジン（rugo/）、C++リーダー、ライター、規範仕様を備えた.skene列指向ファイルフォーマット（skene/）、RustとC++のコンピュート拡張ソース（src/）、生成されたカタログスナップショット（reference/）、テスト、testdata、docs、開発スクリプト、ベンダー依存関係、build_common.pyの共有ビルド機構が含まれます。 1つのソースツリーから3つのwheelが生成され、build_common.pyで単一ソース化されているため乖離できません。opteryx-core（opteryxとしてインポート）はdraken、rugo、skeneを備えた完全なSQLエンジンをバンドルします。rugoはSQLエンジンなしでファイルを読み書きするためのファイルエンジンとdrakenを提供します。libskene（skeneとしてインポート）は.skeneリーダーとライターおよびdrakenを提供します。drakenは個別には公開されません。rugoとskeneは並列であり、どちらも他方に依存しません。wheelはローカルではなくCIでビルドされます。ローカル開発ではmake dev-install、make compile、make c、make q、make test、make dt、make checkなどのMakefileターゲットを使用します。 ファイルフォーマット データセットは拡張子によって読み取られ、データセットは全体を通じて1つのフォーマットです。フォーマットが混在するディレクトリはベストエフォートの読み取りではなくエラーです。Parquetは保存データと交換のデフォルトであり、rugoを通じて読み取られ、CSVとJSONL/NDJSONも同様です。.skeneフォーマットはdrakenネイティブです。drakenベクターの1つ以上の行グループをロスレスで保存し、Parquetが失う改良を含みます — IPv4列はIPV4論理記述子で改良されたUINT32としてラウンドトリップし、辞書エンコーディングとレイアウトヒントは再導出ではなく復元されます。意図的にポータブルではなく、外部リーダーは約束されていないため、交換にはParquetが引き続き選択肢です。Parquet、CSV、JSONLファイルはread_parquet()、read_csv()、read_jsonl()テーブル関数で直接指定することもできます。read_skene()はありません。 カタログ統合 Opteryx Coreは、opteryx_catalogライブラリと組み合わせると最もよく機能すると説明されています。これは名前付きデータセット、カタログベースのテーブル、およびopteryx.appで使用される一般的な体験のための意図されたモデルです。設定では、catalog、Firestoreプロジェクトとデータベース、GCSバケットを備えたデフォルトコネクタを設定し、その後public.space.planetsのようなドット区切りの名前でカタログベースのデータセットをクエリできます。ローカルデータの場合、testdata、scratch、dataなどの登録されたワークスペースが典型的です。 位置づけと貢献 このプロジェクトは、完全なエンドユーザープラットフォームではなく組み込み分析エンジンとして自らを提示しています。ホスト型体験とマルチテナントサービス機能についてはopteryx.appが推奨されるルートであり、このパッケージはコアエンジンを直接提供します。貢献は、個人データセットでの使用、クエリ、スキーマ、性能が誤動作した際のバグ報告、修正、テスト、ドキュメント、性能に関するプルリクエスト、共有された再現ケース、失敗するクエリ、エッジケースのParquetファイルの形で求められています。プロジェクトはApache-2.0の下でライセンスされ、ドキュメントはdocs.opteryx.appにあります。