Можно ли сделать одну систему?

Мы видели: OLTP и OLAP — это разные миры. Но идея “почему бы не сделать одну систему, которая умеет всё” — соблазнительна. И индустрия её активно пробует с 2010-х. Термин для такой системы — HTAP: Hybrid Transactional/Analytical Processing.

В этом уроке разберём, что такое HTAP-системы, почему они появились, и почему в реальности OLTP/OLAP всё ещё чаще разделяют. И посмотрим на отдельный класс — in-process OLAP (DuckDB), который меняет компромиссы для маленьких объёмов.

Что обещает HTAP

Классическая архитектура OLTP+OLAP требует:

• Двух разных систем (Postgres + Snowflake).
• ETL/CDC pipeline между ними.
• Lag: аналитика на данных вчерашней или часовой давности.
• Двойная стоимость infrastructure.

HTAP обещает: одна система обрабатывает и транзакции, и аналитику. На свежих данных, без ETL, с приемлемой производительностью.

Как? Идея в том, чтобы внутри держать два представления одних и тех же данных:

• Row store для OLTP (живые транзакции).
• Columnar store для OLAP (аналитика).

Новые данные пишутся в row store. Через какое-то время автоматически реплицируются в columnar. Аналитические запросы исполняются на columnar (свежие данные при этом могут добираться из row store через merge).

Игроки в HTAP

SingleStore (бывший MemSQL) — самый известный HTAP. Под капотом — row store для OLTP + columnar для OLAP, унифицированный SQL интерфейс, MPP. Уже в production у Uber, AdRoll, Comcast. Дорого, нужна экспертиза.

TiDB — open-source HTAP. Использует TiKV (row store) + TiFlash (columnar replica). TiFlash асинхронно реплицирует данные из TiKV. Аналитика идёт в TiFlash, не нагружая OLTP. Используется в Pinduoduo, Bytedance, Square.

Oracle MySQL HeatWave — Oracle’s bet: добавили columnar in-memory accelerator к MySQL. Запросы автоматически роутятся: OLTP в InnoDB, OLAP в HeatWave.

Snowflake Unistore — Snowflake’s HTAP попытка. Hybrid tables: row store для transactional нагрузки + автоматическая репликация в columnar для analytics. Пока ранний этап.

Postgres + pg_duckdb / Citus — open-source гибриды. pg_duckdb интегрирует DuckDB-движок внутрь Postgres для аналитики. Citus добавляет distributed OLAP к Postgres. Не настоящий HTAP, но движется в эту сторону.

Почему HTAP всё ещё не победил

Технически HTAP-системы работают. Но рынок их используется ограниченно. Причины:

1. Цена. HTAP-системы дороже, чем сумма двух специализированных. SingleStore — премиум-сегмент. На больших объёмах часто дешевле Postgres + Snowflake, чем единая HTAP.

2. Эксплуатация сложнее. Нужна экспертиза в HTAP-specifics (как настроить sync row->columnar, troubleshoot conflicts). Команды чаще знают Postgres и Snowflake отдельно, чем экзотический HTAP.

3. Snowflake/BigQuery/Databricks эволюционируют быстрее. Эти системы добавляют новые возможности (real-time ingestion, low-latency queries) быстрее, чем HTAP подтягивается. Разрыв сокращается, но не исчезает.

4. Регуляторные/orgнизационные причины. В крупных организациях OLTP-стэк и аналитический стэк управляются разными командами. Унификация требует политических усилий, не только технических.

5. Real-time analytics покрывается отдельно. Для случаев “нужны самые свежие данные” есть Materialize, RisingWave, ClickHouse с real-time ingest. Они часто проще HTAP.

В 2026 году HTAP — это нишевое решение для конкретных use case-ов: когда строго нужна одна система с минимальным lag-ом и небольшой объём. Большинство компаний остаются на классическом OLTP+OLAP паттерне.

DuckDB: in-process OLAP

Отдельный класс, который размыл понятие “OLAP” — это DuckDB. Это не HTAP, это совершенно другая идея.

DuckDB — это OLAP-движок, который работает как библиотека внутри твоего приложения. Не клиент-серверный, не cloud, не кластерный. Один процесс, одна машина, прямо как SQLite — но для аналитики.

import duckdb

# Прямо в Python — никакого сервера
con = duckdb.connect(":memory:")
con.execute("SELECT COUNT(*) FROM read_parquet('s3://bucket/orders.parquet')")

DuckDB читает Parquet напрямую, не нужно никуда грузить. Может работать с локальными файлами, S3, HTTP. Под капотом — настоящий OLAP-движок: columnar storage в памяти, vectorized execution, predicate/projection pushdown, parallel scan.

Почему DuckDB изменил игру

До DuckDB (раньше 2020): чтобы делать аналитику на 50 GB CSV/Parquet, нужно было либо ставить Postgres (и страдать), либо платить за Snowflake, либо разворачивать Spark кластер. DuckDB сделал это бесплатно, локально, мгновенно.

# Реальный пример: 50 GB NYC Taxi Parquet, запрос за секунду на ноутбуке
import duckdb
result = duckdb.execute("""
    SELECT
      passenger_count,
      AVG(fare_amount) AS avg_fare,
      COUNT(*) AS trips
    FROM 's3://nyc-tlc/trip data/yellow_tripdata_2026-*.parquet'
    WHERE tip_amount > 0
    GROUP BY passenger_count
    ORDER BY avg_fare DESC
""").fetchdf()

На ноутбуке. Без сервера. За пару секунд. Это меняет workflow аналитика и data engineer-а: для большинства задач Snowflake не нужен.

Где DuckDB живёт

1. Локальная аналитика на 1-100 GB данных. Идеально для исследовательской работы.
2. Embedded в data tools — Mode, Hex, Streamlit, Tableau Prep встраивают DuckDB.
3. In-process в data pipeline — Airflow tasks, dbt models могут использовать DuckDB вместо warehouse для маленьких объёмов.
4. CLI / Notebooks: jupyter с %sql magic + DuckDB — мощная замена pandas для табличных операций.
5. MotherDuck: SaaS поверх DuckDB, “DuckDB в облаке”.

DuckDB не HTAP — он не для транзакций, ничего не пишет, не масштабируется кластером. Но он размывает границу: для маленьких аналитических workload-ов больше не нужна тяжёлая OLAP-система.

Когда HTAP оправдан

Realistic use case-ы для HTAP-системы:

1. Маленькая операционная аналитика. Стартап с 100M строк, нужны real-time дашборды на operational data. Не хочется ETL pipeline между OLTP и OLAP. SingleStore или TiDB здесь работают.

2. Compliance/latency constraints. Финансовые приложения, где аналитика должна быть на свежих данных без lag-а. HTAP даёт это (Snowflake lag — минуты-часы).

3. Замена legacy. Команда мигрирует с дорогого Oracle. HTAP-система покрывает и OLTP, и аналитику — упрощает архитектуру.

4. Internal analytics, embedded в product. Product показывает пользователю аналитику на его собственных данных. Latency требования жёсткие. HTAP проще, чем разделение.

Когда HTAP не нужен:

• Объёмы петабайты — HTAP не такой масштабируемый, как pure OLAP cloud DWH.
• Аналитики работают на исторических данных недельной давности — lag не критичен, обычный ETL норм.
• Аналитика не сильно завязана на OLTP-таблицах — например, веб-аналитика идёт из отдельных event-стримов.

Реальная архитектура: что в индустрии 2026

Прогноз: куда идёт индустрия

Тренды 2024-2026:

1. Snowflake/BigQuery/Databricks движутся ближе к HTAP. Snowflake Unistore, BigQuery Continuous queries, Databricks Real-time features.
2. HTAP-системы расширяют scale. SingleStore поддерживает petabyte workloads.
3. DuckDB растёт лавинно. Все analytics tools встраивают, MotherDuck растёт.
4. Iceberg / Delta становятся универсальными форматами. OLTP и OLAP могут читать один и тот же формат, разница исчезает на storage уровне.

Граница OLTP/OLAP размывается, но в большинстве production architectures всё ещё чёткая. Знание классического разделения — фундамент. HTAP и DuckDB — экспансия в особые сценарии.

Попробуй сам

1. Установи DuckDB (pip install duckdb или brew). Скачай 1-5 GB Parquet datasete. Сравни время агрегационного запроса в DuckDB vs pandas vs Postgres (если есть локально).
2. Изучи SingleStore (бывший MemSQL) demo или trial. Запусти типичный OLTP-запрос (INSERT, SELECT by ID) и OLAP-запрос (GROUP BY на миллионах строк). Замерь оба, сравни с Postgres+Snowflake.
3. Попробуй pg_duckdb (Postgres extension с DuckDB embedded). Тот же тест — OLTP в Postgres + OLAP через DuckDB engine.
4. Спроектируй: малый стартап с 50 GB операционных данных, нужны real-time дашборды. Сравни три варианта: Postgres+materialized views; Postgres+Snowflake; SingleStore. Какие cost/complexity tradeoff-ы?