Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью ClickHouse, невозмутимой простотой SQLite и порой адской сложностью настройки InfluxDB, — возможно, вы, как и мы, дождались чего-то по-настоящему нового.
На горизонте появился проект Arc от команды Basekick Labs. Это не просто очередная попытка, а дерзкая заявка на соединение всего лучшего из мира time-series и lakehouse-подхода. Забудьте о тяжёлых серверах и мучительной шардированной архитектуре. Arc предлагает:
Лёгкий, автономный движок на DuckDB вместо монструозных кластеров.
Стандартизированный Parquet вместо проприетарных бинарных форматов.
Обычный S3 / MinIO вместо дорогостоящих SAN-хранилищ.
По сути, Arc можно описать элегантной формулой:
Arc = Time-Series + Lakehouse + DuckDB
Идея, на первый взгляд, обманчиво проста, но невероятно амбициозна: записывать миллионы метрик в секунду прямо в Parquet-файлы и тут же, без поднятия кластеров и очередей Kafka, выполнять по ним SQL-аналитику. Всё это великолепие — через HTTP API, с нативной поддержкой Influx Line Protocol и, что немаловажно, с автоматической компакцией мелких файлов.
Проект ещё находится на ранней стадии (альфа-релиз), но уже демонстрирует впечатляющие результаты: до 1,89 млн записей в секунду при нативном запуске, минимальные задержки и совместимость с Apache Superset для визуализации, что делает его крайне привлекательным для быстрого старта.
Arc позиционируется как "time-series lakehouse" — своего рода золотая середина между классическими TSDB и современными data-lake-решениями. Этот подход явно вдохновлён философией DuckDB + Parquet + Object Storage: всё локально, всё аналитически, всё через SQL.
Почему это важно? Потому что мы на пороге революции.
Мы наблюдаем рождение нового тренда: анализ временных рядов, который не требует ни серверов, ни сложных кластеров. DuckDB уже де-факто стал стандартом для "in-place analytics", Parquet — для эффективного хранения, а S3 — для инфраструктурной независимости. Arc собирает все эти компоненты в единый «минимальный сервер», способный писать, хранить и анализировать данные без необходимости разворачивать PostgreSQL, настраивать Kubernetes или подписывать облачные контракты.
Для разработчиков, аналитиков и инженеров наблюдаемости это звучит как несбыточная мечта, ставшая явью:
Просто скачай бинарник, запусти сервер, отправляй метрики, пиши SQL-запросы — и наслаждайся результатом.
Конечно, как и любая ранняя технология, Arc не без своих "дьяволов" в деталях: стабильность, механизмы компакции, WAL, отсутствие распределённости — всё это требует внимательного изучения и учёта.
Если говорить совсем коротко, Arc — это InfluxDB, переосмысленный через призму DuckDB и Parquet. И если этот проект сможет достичь необходимой стабильности, он вполне может положить начало новой волне "serverless analytics for time-series", изменив ландшафт аналитики временных рядов.
А теперь болле подробно о том что такое Arc
Arc — это экспериментальное (на данный момент в альфа / техническом превью) решение для хранения и аналитики временных рядов. (GitHub)
Ключевые компоненты:
Использует DuckDB как движок аналитики SQL над Parquet-файлами. (GitHub)
Хранит данные в формате Parquet, организованных в разделы (партиционирование по времени / папки). (GitHub)
В качестве долговременного хранилища — MinIO / S3-совместимое хранилище. (GitHub)
Ввод (ingest) поддерживает протокол MessagePack (рекомендуемый, для высокой скорости), а также поддержку InfluxDB Line Protocol (для обратной совместимости) (GitHub)
Автоматическая компакция мелких файлов в большие (чтобы уменьшить накладные расходы на сканирование множества файлов) (GitHub)
Опциональный Write-Ahead Log (WAL) для гарантий сохранности, но по умолчанию отключён (для максимальной скорости) (GitHub)
Мультибазовая архитектура (namespaces / базы) — можно разделять данные по приложениям, арендаторам и т.п. (GitHub)
Интерфейс доступа через HTTP API — запросы SQL, эндпоинты для ingest, управление, мониторинг и др. (GitHub)
Интеграция с Apache Superset через свой SQLAlchemy-диалект (GitHub)
Архитектурно Arc — это «time-series warehouse / lakehouse» тип, где хранение разделено (object storage) и движок аналитический (DuckDB) читает Parquet напрямую.
Показатели производительности, заявленные
При нативном (native) запуске — до 1,89 млн записей/сек (MessagePack протокол). (GitHub)
В Docker-режиме — около 570 000 записей/сек (значительно меньше) (GitHub)
Латентности: p50 — 21 мс, p95 — 204 мс (в тестах) (GitHub)
В ClickBench-бенчмарке (на AWS c6a.4xlarge): холодный запуск (без кэша) суммарно ~35.18 сек по 43 запросам, горячий запуск (с кэшем) ~0.81 сек в среднем на запрос (43/43 запросов выполнены) (GitHub)
На Apple M3 Max тесты также приводятся: ~23.86 сек «cold run» + ~0.52 с средний hot-run (GitHub)
Важно: команда проекта явно указывает, что Arc сейчас не рекомендуется для продакшена — это технический превью. (GitHub)
APIs, форматы и детали могут изменяться.
Преимущества (сильные стороны)
Высокая скорость ingеst + аналитика — сочетание высокоскоростного ввода и аналитического движка (DuckDB над Parquet) даёт преимущество в сценариях, где нужно сразу писать и читать данные.
Хорошо подходит для архитектуры «cold + hot» данных — холодные данные хранятся в объектном хранилище, а аналитика читает Parquet напрямую, без промежуточных слоёв.
Гибкость хранения — использование S3-совместимого хранилища (MinIO или облачные S3/GCS) упрощает масштабирование и удалённое хранение.
Автокомпакция — чтобы избегать «многих мелких файлов», что обычно сильно тормозит аналитические запросы.
Совместимость протоколов — поддержка Influx Line Protocol позволяет интегрировать с существующими инструментами наблюдаемости и метрик.
Мультибазовая (namespace) архитектура — можно логически разделять данные для разных сред, приложений или арендаторов.
Открытость и модифицируемость — код под лицензией AGPL-3.0, что позволяет видеть устройство, вносить изменения (но при предоставлении как услуги — придётся раскрывать свои правки) (GitHub)
Интеграция визуализации — поддержка Superset как BI-инструмента «из коробки».
Недостатки, риски и ограничения
Стадия зрелости / стабильности — альфа-превью, API и внутренние детали могут меняться, возможности не полностью протестированы на боевых нагрузках.
Зависимость от Parquet / файловой структуры — эффективная работа сильно зависит от качества партиционирования, размеров файлов, компрессии и планирования компакции.
Ограничения многопользовательского конкурентного доступа — поскольку DuckDB — однопроцессный движок (или ограниченно параллельный), в сценариях с высокой конкуренцией чтения-записи может быть узкое место.
Отсутствие распределённости — Arc, по текущему состоянию, не предлагает горизонтальное масштабирование (sharding) на несколько нод (по крайней мере в документации не видно).
Лимиты на реальное использование WAL — включение Журнала приводит к падению производительности (относительно отключенного) — есть компромиссы между гарантией сохранности и пропускной способностью. (GitHub)
Отсутствие зрелых функций TSDB (time-series) — многие TSDB предлагают специализированные функции (например, downsampling, retention policies, автоматическое удаление старых данных, агрегаты в реальном времени и т.п.), возможно, часть таких функций в Arc либо не реализована, либо экспериментальна.
Лицензия AGPL-3.0 — если ты хочешь использовать модифицированный Arc как SaaS, придётся раскрывать свои изменения (ограничение для коммерческих продуктов).
Оверхед HTTP API / сериализация — часть задержки и накладных расходов придётся на сетевые вызовы, упаковку/распаковку, работу сервера API и т.д.
Потребности в ресурсах — в сценариях с высокой нагрузкой парсинг, кэширование, обработка файлов и компакция могут требовать значительные ресурсы CPU / IO / память.
Когда Arc может быть уместен
Наблюдаемость (metrics, логические метрики, data-pipeline мониторинг)
IoT / сен��орные данные
Приложения, где нужен единый слой записи + аналитики
Когда важно хранить долгосрочные данные в дешёвом объектном хранилище
Когда хочется избежать сложной инфраструктуры распределённых TSDB
В проектах, где можно допустить изменения и экспериментальное ПО, и есть возможность строгого тестирования перед продакшеном
Но если нужен гарантированный production-grade TSDB с шардированием, высокой доступностью, failover, крупномасштабной репликацией — Arc в текущем виде может быть рискованным выбором.
Конкуренты / похожие решения
Ниже — набор систем, которые работают в смежной области (time-series, аналитика, lakehouse подходы). Я выбрал как зрелые TSDB, так и более экспериментальные «lakehouse для временны́х рядов».
Некоторые основные конкуренты:
TimescaleDB — расширение PostgreSQL для временных рядов. (Wikipedia)
ClickHouse — аналитическая колонно-ориентированная СУБД, часто используется для метрик и аналитики. (не чистый TSDB, но часто конкурирует)
InfluxDB — специализированная база для метрик / временных рядов.
QuestDB — ориентированная TSDB с высокой скоростью записи и обработки SQL.
GigAPI — новый проект “timeseries lakehouse” на основе DuckDB + Parquet + компрессии / компакции. (GitHub)
Куски дата-озёр / lakehouse архитектуры (например Apache Iceberg, Delta Lake, с движками типа Trino / Spark / Flink) — не специализированные TSDB, но могут быть использованы для хранения временных рядов.
Другие экспериментальные движки — например разные “internal time-series lakehouse experiments”.
Я сейчас сфокусируюсь на наиболее прямых конкурентах (TimescaleDB, ClickHouse, InfluxDB, QuestDB, GigAPI) и их сильные/слабые стороны в свете сравнения с Arc.
Таблица сравнения
Ниже таблица, в которой Arc сравнивается с ключевыми конкурентами по важным метрикам и характеристикам:
Характеристика / метрика | Arc | TimescaleDB | ClickHouse | InfluxDB | QuestDB | GigAPI |
|---|---|---|---|---|---|---|
Архитектурный подход | DuckDB + Parquet + S3 / MinIO, файл-ориентированный | Надстройка над PostgreSQL (гипертаблицы) | Колонно-ориентированная СУБД, сервер | Специализированная TSDB (append-optimized) | TSDB + SQL движок | Lakehouse (DuckDB + Parquet + API) |
Стадия зрелости / стабильность | Альфа / технический превью | Продукционная, зрелая | Продукционная, активно используется | Продукционная, зрелая | Продукционная / активно развивается | Новый / экспериментальный |
Скорость записи / ingest | ~1,89 млн записей/с (MessagePack, нативно) | высокая, но зависит от конфигурации, индексов, нагрузки | высокая, особенно для аналитики и партиций | высокая (особенно для метрик) | высокая, оптимизирована под TS | проект нацеливается на “sub-second queries” в lakehouse среде (GitHub) |
Задержки / латентности запросов | p50 ~21 мс, p95 ~204 мс (в тестах) (GitHub) | низкая до умеренной (зависит от индексов, реплик) | быстро, особенно при агрегациях | быстрые, для метрик | быстро, для аналитики над временными рядами | ориентирован на быстрые запросы |
Горизонтальное масштабирование / шардирование | не реализовано (на текущий момент) | поддерживает масштабирование через PostgreSQL методы (вертикальное, кластеризацию) | поддерживает кластерные конфигурации, распределённость | поддерживает кластерные версии / кластеризацию | поддерживает масштабируемость | пока без зрелой распределённости (по состоянию проекта) |
Хранение «холодных» данных / долговременное хранение | Да — через Parquet в S3 / MinIO | да, через хранение PostgreSQL / сторонние слои | да, через холодные слои / партиционирование | да, retention policies и “compactions” | да, через партиции / холодные слои | основная идея как раз хранить данные в “lakehouse” |
Поддержка SQL / аналитики | Полный SQL, DuckDB | Полный SQL (PostgreSQL + TS функции) | SQL-диалект, аналитика | SQL-подобный язык Flux / InfluxQL / SQL (в новых версиях) | SQL | SQL (на базе DuckDB) |
Протоколы записи / совместимость | MessagePack, Influx Line Protocol | стандартный SQL / функции TS | собственные клиенты / SQL | собственные API / HTTP, клиентские библиотеки | собственные API / SQL | REST API / lakehouse подход |
Автоматическая компакция / оптимизация файлов | Да, встроенная (конфигурируемая) | частично (например, через политики retention) | да (мердж-план, оптимизация данных) | да (compactions, retention) | да (внутренние оптимизации) | предполагается наличие механизмов оптимизации |
Гарантии сохранности / устойчивость к сбоям | WAL (опционально) с потерями / снижением производительности | транзакционная, репликация | репликация, устойчивость | возможны режимы высокой доступности | зависит от конфигурации | TBD (на стадии разработки) |
Лицензия / модель использования | AGPL-3.0 (открытый код, но ограничения для SaaS) | Apache 2.0 / open | Apache 2.0 / open | OSS + коммерческие версии | open | зависит от лицензии проекта (MIT / open либо гибрид) |
Преимущества по сравнению с Arc | зрелость, поддержка, надёжность | зрелость и поддержка экосистемы данных | высокая мощность аналитики, масштабируемость | узкая специализация, зрелые экосистемы | современный TSDB-дизайн для аналитики | близкая архитектура (lakehouse) и ориентир на схожие сценарии |
Недостатки по сравнению с Arc | возможная меньшая скорость ingest / компромиссы | накладные расходы PostgreSQL, масштабируемость ограничена | сложность настройки, эксплуатация, ресурсы | лимиты на сложные аналитические запросы | ограничения распределённости | ещё не зрел, возможно отсутствие некоторых функций |
Вывод и рекомендации
Arc — интересный проект, стремящийся занять нишу «ingest + аналитика над временными рядами» с минимальным промежуточным слоем.
В текущем виде он подходит скорее для экспериментов, прототипов, проектов, где можно пожертвовать гарантиями ради скорости и гибкости.
В сравнении с устоявшимися TSDB (TimescaleDB, InfluxDB) и аналитическими СУБД (ClickHouse) у Arc есть потенциал, но серьёзные конкуренты имеют зрелость, экосистему, устойчивость, распределённость и боевые проверенные кейсы.
Особенный интерес вызывает GigAPI, который очень близок по архитектуре к Arc (DuckDB + Parquet + lakehouse подход) — возможно, это будет ближайший “соперник-аналоги”. (GitHub)
Если ты рассматриваешь использовать Arc на продакшене, стоит провести нагрузочные тесты именно под твои данные / паттерны, обратить внимание на стратегию компакции, настройку ресурсов, отказоустойчивость, recovery после сбоев и механизм WAL.
