11.10.2025 05:54
EvgeniyRasyuk 7 2300 Источник

Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью 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, форматы и детали могут изменяться.

Преимущества (сильные стороны)

  1. Высокая скорость ingеst + аналитика — сочетание высокоскоростного ввода и аналитического движка (DuckDB над Parquet) даёт преимущество в сценариях, где нужно сразу писать и читать данные.

  2. Хорошо подходит для архитектуры «cold + hot» данных — холодные данные хранятся в объектном хранилище, а аналитика читает Parquet напрямую, без промежуточных слоёв.

  3. Гибкость хранения — использование S3-совместимого хранилища (MinIO или облачные S3/GCS) упрощает масштабирование и удалённое хранение.

  4. Автокомпакция — чтобы избегать «многих мелких файлов», что обычно сильно тормозит аналитические запросы.

  5. Совместимость протоколов — поддержка Influx Line Protocol позволяет интегрировать с существующими инструментами наблюдаемости и метрик.

  6. Мультибазовая (namespace) архитектура — можно логически разделять данные для разных сред, приложений или арендаторов.

  7. Открытость и модифицируемость — код под лицензией AGPL-3.0, что позволяет видеть устройство, вносить изменения (но при предоставлении как услуги — придётся раскрывать свои правки) (GitHub)

  8. Интеграция визуализации — поддержка Superset как BI-инструмента «из коробки».

Недостатки, риски и ограничения

  1. Стадия зрелости / стабильности — альфа-превью, API и внутренние детали могут меняться, возможности не полностью протестированы на боевых нагрузках.

  2. Зависимость от Parquet / файловой структуры — эффективная работа сильно зависит от качества партиционирования, размеров файлов, компрессии и планирования компакции.

  3. Ограничения многопользовательского конкурентного доступа — поскольку DuckDB — однопроцессный движок (или ограниченно параллельный), в сценариях с высокой конкуренцией чтения-записи может быть узкое место.

  4. Отсутствие распределённости — Arc, по текущему состоянию, не предлагает горизонтальное масштабирование (sharding) на несколько нод (по крайней мере в документации не видно).

  5. Лимиты на реальное использование WAL — включение Журнала приводит к падению производительности (относительно отключенного) — есть компромиссы между гарантией сохранности и пропускной способностью. (GitHub)

  6. Отсутствие зрелых функций TSDB (time-series) — многие TSDB предлагают специализированные функции (например, downsampling, retention policies, автоматическое удаление старых данных, агрегаты в реальном времени и т.п.), возможно, часть таких функций в Arc либо не реализована, либо экспериментальна.

  7. Лицензия AGPL-3.0 — если ты хочешь использовать модифицированный Arc как SaaS, придётся раскрывать свои изменения (ограничение для коммерческих продуктов).

  8. Оверхед HTTP API / сериализация — часть задержки и накладных расходов придётся на сетевые вызовы, упаковку/распаковку, работу сервера API и т.д.

  9. Потребности в ресурсах — в сценариях с высокой нагрузкой парсинг, кэширование, обработка файлов и компакция могут требовать значительные ресурсы CPU / IO / память.

Когда Arc может быть уместен

  • Наблюдаемость (metrics, логические метрики, data-pipeline мониторинг)

  • IoT / сенсорные данные

  • Приложения, где нужен единый слой записи + аналитики

  • Когда важно хранить долгосрочные данные в дешёвом объектном хранилище

  • Когда хочется избежать сложной инфраструктуры распределённых TSDB

  • В проектах, где можно допустить изменения и экспериментальное ПО, и есть возможность строгого тестирования перед продакшеном

Но если нужен гарантированный production-grade TSDB с шардированием, высокой доступностью, failover, крупномасштабной репликацией — Arc в текущем виде может быть рискованным выбором.

Конкуренты / похожие решения

Ниже — набор систем, которые работают в смежной области (time-series, аналитика, lakehouse подходы). Я выбрал как зрелые TSDB, так и более экспериментальные «lakehouse для временны́х рядов».

Некоторые основные конкуренты:

  1. TimescaleDB — расширение PostgreSQL для временных рядов. (Wikipedia)

  2. ClickHouse — аналитическая колонно-ориентированная СУБД, часто используется для метрик и аналитики. (не чистый TSDB, но часто конкурирует)

  3. InfluxDB — специализированная база для метрик / временных рядов.

  4. QuestDB — ориентированная TSDB с высокой скоростью записи и обработки SQL.

  5. GigAPI — новый проект “timeseries lakehouse” на основе DuckDB + Parquet + компрессии / компакции. (GitHub)

  6. Куски дата-озёр / lakehouse архитектуры (например Apache Iceberg, Delta Lake, с движками типа Trino / Spark / Flink) — не специализированные TSDB, но могут быть использованы для хранения временных рядов.

  7. Другие экспериментальные движки — например разные “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.

Создано при поддержке тг канала Слайдер Данные

Комментарии (7)


  1. mantyr
    11.10.2025 06:28
    #28947754

    Похоже очередная статья написанная GPT.


    1. EvgeniyRasyuk Автор
      11.10.2025 06:28
      #28948146

      да , это обзорная статья по новому продукту


    1. kmatveev
      11.10.2025 06:28
      #28948154

      Ссылки с utm_source=chatgpt.com не дадут ошибиться


  1. kmatveev
    11.10.2025 06:28
    #28948138

    Я глянул исходники, это ещё больший мутант, чем я думал. Оно написано на питоне. При получении msgpack-сообщения вызывается библиотечный msgpack-декодер, который превращает это в питоновский список питоновских словарей. А чтобы сохранить это на диск, используется Polars DataFrame, в который этот список словарей передаётся. Это точно можно делать эффективнее.


    1. EvgeniyRasyuk Автор
      11.10.2025 06:28
      #28948182

      https://habr.com/ru/articles/955560/


  1. akardapolov
    11.10.2025 06:28
    #28948552

    При нативном (native) запуске — до 1,89 млн записей/сек (MessagePack протокол)

    Средний размер записи порядка 90 байт. В МБ скорость записи будет порядка 170 Мб/сек в несколько потоков (e.g., 14 cores = 42 workers).

    {
  "m": "cpu",
  "t": 1728604800000,
  "h": "server01",
  "tags": {
    "region": "us-east",
    "dc": "aws"
  },
  "fields": {
    "usage_idle": 95.0,
    "usage_user": 3.2,
    "usage_system": 1.8
  }
}


    1. thethee
      11.10.2025 06:28
      #28949300

      Короче не впечатляет. И где тут убийца ClickHouse...