Метрики vector-пути: NUMERIC float-backed и columnar grouped-agg

Две operator-facing counter-метрики, добавленные в RM-0.6.7.15 (vector batch foundation). Обе — кумулятивные counter (Prometheus), сбрасываются только при рестарте процесса.

curl -sf http://127.0.0.1:9898/metrics | grep -E "vector_numeric_float_backed|vector_columnar_grouped_agg"

angarabase_vector_numeric_float_backed_total

Что значит. AngaraBase в v0.6.x не имеет настоящего fixed-point DECIMAL-типа: значения numeric/decimal хранятся end-to-end как Value::Float(f64) (см. TD-2026-0417, полный Decimal-тип запланирован на v0.7 + RFC-2026-516). Для numeric с ненулевым scale (numeric(10,2), decimal(18,4) и т.п.) это означает потенциальную потерю точности в SUM/AVG над денежными колонками (catastrophic cancellation при суммировании больших и малых величин).

Когда инкрементируется. На каждый вызов вывода физического типа (infer_physical_type) для колонки типа numeric(p,s) / decimal(p,s) с scale > 0. Параллельно при первом таком событии в процессе эмитится one-shot WARN в лог (не на каждую строку — флаг через AtomicBool).

Когда НЕ инкрементируется:

• numeric / decimal без суффикса (scale=0 неявно);
• numeric(10) — указана только precision;
• numeric(18,0) — явный scale=0 (целочисленный numeric, точен до 2^53).

Важно: счётчик растёт по числу вызовов type-inference, а не по числу строк или запросов. Один запрос с одной numeric(p,s>0)-колонкой может дать несколько инкрементов (per-batch type-inference). Используйте метрику как сигнал наличия lossy-использования, а не как точную меру объёма.

PromQL: алерт на lossy-numeric использование

# Появилось lossy-numeric использование за последний час (раньше не было).
increase(angarabase_vector_numeric_float_backed_total[1h]) > 0

Troubleshooting (DBA)

• Счётчик > 0 → в рабочей нагрузке есть агрегаты над numeric(p,s>0). Результаты SUM/AVG над такими колонками могут отличаться от точного decimal-результата на величину float-ошибки.
• Действие: для денежных колонок, где важна точность до копейки, до выхода v0.7 DECIMAL — агрегируйте на стороне приложения в целочисленных «минорных единицах» (копейки) или храните как bigint (scale=0), либо принимайте округление float8 осознанно.
• WARN в логе содержит scale и ссылку на TD-2026-0417 — ищите по строке numeric(... ) column mapped to Float64.

angarabase_vector_columnar_grouped_agg_total

Что значит. Path-signal: GROUP BY-агрегат прошёл оптимизированным колоночным hash-agg путём (без построчной материализации to_rows() и без string-кодирования ключа группы). Покрывает два места:

• vector-операторный путь (VectorAggV0 — composite key прямо из ColumnData);
• columnar SIMD-путь над HtapRowColumn-таблицами (S3).

Когда инкрементируется. Один раз на завершённый вызов колоночного grouped-agg, когда:

• в плане есть GROUP BY (непустой ключ группы);
• все aggregate-specs поддержаны колоночным путём (COUNT/SUM/MIN/MAX, поддержанные типы ключа);
• (для S3) таблица — columnar-tier (ENGINE=htap_row_column).

Когда НЕ инкрементируется (запрос ушёл в row-fallback):

• неподдержанный паттерн (DISTINCT, нестандартный/выражение-ключ);
• ungrouped-агрегат (нет GROUP BY) — там путь иной;
• row-store таблица не достигает columnar S3-пути (авто-тиринг = v0.7, RM-0.7.7.1).

Эквивалентность результата колоночного пути row-fallback подтверждена AC-тестами RM-0.6.7.15 (S2-G2 / S3-G3). Метрика — наблюдаемость пути, не корректности.

PromQL: доля columnar-пути vs row-fallback

# Columnar grouped-agg активаций за 5 минут.
increase(angarabase_vector_columnar_grouped_agg_total[5m])

# Доля columnar-пути от всех vector-fallback'ов (грубый индикатор «насколько часто
# GROUP BY уходит в медленный row-fallback»).
increase(angarabase_vector_columnar_grouped_agg_total[5m])
  /
clamp_min(
  increase(angarabase_vector_columnar_grouped_agg_total[5m])
    + increase(angarabase_vector_fallback_total[5m]),
  1
)

Troubleshooting (DBA)

• Счётчик не растёт на HtapRowColumn-таблице при GROUP BY-нагрузке → запрос уходит в row-fallback. Проверьте: нет ли DISTINCT, выражения в ключе группировки, неподдержанной агрегатной функции; всё ли — columnar-eligible specs. Row-fallback корректен, но медленнее.
• Счётчик растёт, а ожидалась SIMD-агрегация — это норма: grouped-agg ходит hash-group путём, а «чистый» SIMD-kernel применяется только для ungrouped COUNT/SUM/MIN/MAX.
• Сопоставляйте с angarabase_vector_fallback_total и angarabase_parallel_agg_total для полной картины маршрутизации vector-пути.

Связанные метрики

См. раздел HTAP / Vector Execution Metrics общего справочника (angarabase_vector_fallback_total, angarabase_vector_columnar_native_total, angarabase_parallel_agg_total).