opteryx-core

Opteryx Core — это движок исполнения SQL, лежащий в основе opteryx.app, опубликованный как форк Opteryx с меньшей и более ориентированной на конкретные задачи поверхностью API и конфигурации, сформированной вокруг рабочих нагрузок хостингового сервиса. Он предназначен для быстрых аналитических запросов с преобладанием чтения по колоночным данным: он выполняет разбор SQL, планирование, проталкивание предикатов, отсечение проекций и исполнение, так что наборы данных можно запрашивать из Python, не поднимая отдельное хранилище. Архитектура Планирование запросов написано на Python; исполнение запросов — нативное. После того как планировщик создаёт физический план, движок выполняет его в скомпилированном коде от начала до конца — сканирование, операторы, планирование и диспетчеризацию — и ни PyArrow, ни NumPy нигде в движке не присутствуют. Результаты возвращаются как Draken morsels — пакеты столбцов, передаваемые по мере их создания движком, так что большой результат не обязан целиком помещаться в памяти сразу. Morsel предоставляет num_rows, column_names и column(name).to_pylist(); после чтения потока до конца session.rowcount сообщает число переданных строк. Начало работы Требования — Python 3.11 или новее, инструментальная цепочка C/C++ для локальных сборок из исходников и Rust/Cargo для расширения на Rust. Установка: pip install opteryx-core, импорт как opteryx. Минимальный локальный пример регистрирует рабочее пространство с DiskConnector и запрашивает имена наборов данных, разделённые точками, разрешаемые относительно текущего рабочего каталога, например data.planets разрешается в ./data/planets, а формат определяется по расширениям файлов. Также доступна командная строка через python -m opteryx для запросов без написания кода на Python. Предполагаемое использование Проект перечисляет: питание слоя исполнения, используемого opteryx.app; выполнение аналитического SQL над локальными наборами данных Parquet, CSV, JSONL и .skene; встраивание движка запросов внутрь приложений, скриптов, ноутбуков и сервисов на Python; работу над внутренностями движка, такими как планирование, нативное исполнение и производительность файловых форматов; и использование файлового движка или формата .skene отдельно через колёса rugo и libskene. Структура репозитория и дистрибутивы Репозиторий содержит SQL-движок (opteryx/), нативный колоночный векторный субстрат и morsels (draken/), файловый движок для чтения и записи Parquet, CSV и JSONL (rugo/), колоночный файловый формат .skene с читателем, писателем и нормативной спецификацией на C++ (skene/), исходники вычислительных расширений на Rust и C++ (src/), сгенерированные снимки каталога (reference/), тесты, тестовые данные, документацию, скрипты разработки, вендоренные зависимости и общую сборочную инфраструктуру в build_common.py. Одно дерево исходников порождает три колеса, единообразно задаваемых в build_common.py, чтобы они не могли разойтись: opteryx-core (импортируется как opteryx) включает полный SQL-движок с draken, rugo и skene; rugo предоставляет файловый движок плюс draken для чтения и записи файлов без SQL-движка; libskene (импортируется как skene) предоставляет читатель и писатель .skene плюс draken. draken отдельно не публикуется. rugo и skene параллельны, и ни один не зависит от другого. Колёса собираются в CI, а не локально; локальная разработка использует цели Makefile, такие как make dev-install, make compile, make c, make q, make test, make dt и make check. Файловые форматы Наборы данных читаются по расширению, и набор данных целиком одного формата; каталог, смешивающий форматы, — это ошибка, а не чтение по мере возможности. Parquet — формат по умолчанию для хранимых данных и обмена, читается через rugo, как и CSV и JSONL/NDJSON. Формат .skene нативен для draken: он хранит одну или несколько групп строк векторов draken без потерь, включая уточнения, которые Parquet отбрасывает — столбец IPv4 совершает круговой обход как UINT32, уточнённый логическим дескриптором IPV4, а словарное кодирование и подсказки по компоновке восстанавливаются, а не выводятся заново. Он намеренно не переносим, и никакой сторонний читатель не обещан, поэтому Parquet остаётся выбором для обмена. Файлы Parquet, CSV и JSONL также можно указывать напрямую с помощью табличных функций read_parquet(), read_csv() и read_jsonl(); read_skene() не существует. Интеграция с каталогом Opteryx Core описывается как работающий лучше всего в паре с библиотекой opteryx_catalog, которая является предполагаемой моделью для именованных наборов данных, таблиц с опорой на каталог и общего опыта, используемого в opteryx.app. Конфигурация задаёт коннектор по умолчанию с каталогом, проектом и базой данных Firestore и бакетом GCS, после чего наборы данных с опорой на каталог можно запрашивать по именам, разделённым точками, таким как public.space.planets. Для локальных данных типичны зарегистрированные рабочие пространства, такие как testdata, scratch или data. Позиционирование и участие Проект представляет себя как встраиваемый аналитический движок, а не как полноценная платформа для конечных пользователей: для хостингового опыта и функций многопользовательского сервиса рекомендуется opteryx.app, тогда как этот пакет предоставляет основной движок напрямую. Приглашаются вклады в виде использования на личных наборах данных, сообщений об ошибках, когда запросы, схемы или производительность ведут себя неправильно, pull-запросов для исправлений, тестов, документации или производительности, а также общих воспроизводимых случаев, падающих запросов и граничных файлов Parquet. Проект лицензирован под Apache-2.0, документация на docs.opteryx.app.