HTAP

HTAP (Hybrid Transactional/Analytical Processing, гибридная транзакционно-аналитическая обработка) это архитектурный подход, при котором одна система обслуживает и короткие транзакции, и тяжёлую аналитику по тем же данным, без выгрузки их в отдельное хранилище. Термин ввела исследовательская компания Gartner в 2014 году, и с тех пор его носят и распределённые СУБД вроде TiDB, и облачные сервисы вроде AlloyDB. Важно сразу зафиксировать, что HTAP это не продукт и не конкретная технология, а способ построения системы, у которого есть понятный механизм и вполне конкретная цена.

Что такое HTAP и какую задачу он закрывает

Классический контур работы с данными состоит из двух половин, которые живут в разных местах. Приложение пишет в транзакционную базу, ночью или раз в час оттуда уезжает выгрузка, и аналитик работает уже с копией. Гибридная обработка убирает из этой картины среднее звено, а вместе с ним и задержку данных.

Почему OLTP и OLAP когда-то развели по разным системам

Транзакционная нагрузка (OLTP, online transaction processing) состоит из тысяч мелких операций, каждая из которых трогает одну-две строки по первичному ключу. Аналитическая нагрузка (OLAP, online analytical processing) устроена противоположным образом, потому что один запрос читает миллионы строк, но всего по нескольким колонкам. Эти профили требуют разного физического хранения. Строковое хранение кладёт строку целиком рядом, и точечное чтение обходится в одну страницу диска. Колоночное хранение держит каждую колонку отдельным массивом, отлично жмётся и позволяет не трогать ненужные поля, зато собирать из него одну строку дорого.

Отсюда и разделение, которое индустрия считала естественным лет двадцать. Оперативная база берёт на себя запись, аналитическое хранилище берёт чтение, а между ними живёт процесс перекладывания данных ETL (extract, transform, load) или поток изменений. Расплата за такую схему известна каждому, кто её эксплуатировал. Данные в отчёте отстают от реальности, витрины расходятся с источником, а сам конвейер требует дежурств и разбирательств, почему сегодня загрузка не доехала.

Что предложил Gartner в 2014 году

В начале 2014 года аналитики Gartner выпустили отчёт «Hybrid Transaction/Analytical Processing Will Foster Opportunities for Dramatic Business Innovation», где предложили сломать стену между обработкой транзакций и аналитикой и назвали получившийся класс систем HTAP. Идея гибридной обработки состоит в том, что современное железо и современные движки позволяют держать обе нагрузки в одной системе, не убивая при этом транзакции. Аналитик видит данные в тот момент, когда транзакция закоммичена, а не через шесть часов. Отдельного конвейера копирования нет, значит нет и класса инцидентов, связанных с ним. Свежий обзор рынка таких систем есть в статье Что такое HTAP-СУБД и зачем они нужны, а как это выглядит в реальной миграции, разобрано на примере перехода Pinterest с HBase на TiDB.

Архитектура HTAP-систем

Под общим названием прячутся два разных инженерных решения, и путать их не стоит, потому что ведут они себя по-разному.

Единая платформа

Первый вариант это одно хранилище, из которого читают обе нагрузки. Обычно данные лежат в оперативной памяти в гибридном формате, а движок сам решает, какой план построить. Плюс очевиден, поскольку копии нет вообще и рассинхрона тоже. Минус в том, что запросы конкурируют за одни и те же процессоры и за одни и те же страницы памяти, поэтому тяжёлая аналитика напрямую влияет на предсказуемость транзакций. Так работал изначальный класс in-memory платформ, ради которых термин и придумывали, например SAP HANA, и по этому же пути идёт колоночный движок AlloyDB, держащий вторичное колоночное представление свежих данных прямо в памяти инстанса.

Раздельные хранилища внутри одной системы

Второй вариант распространён шире. Внутри одной системы живут два движка сразу, а именно строковый для транзакций и колоночный для аналитики, и система сама поддерживает между ними репликацию. Так устроен TiDB, где строковые узлы TiKV дополнены колоночными узлами TiFlash. Пользователь по-прежнему видит одну базу и один SQL, а оптимизатор выбирает, откуда читать конкретный запрос. Ключевое свойство здесь в изоляции, потому что аналитика ест ресурсы отдельных узлов и до транзакционных не дотягивается.

Как одна запись попадает в два представления

Разберём механизм на варианте с раздельными хранилищами, он же самый показательный. Приложение выполняет INSERT или UPDATE, транзакция коммитится в строковом хранилище по обычным правилам, с журналом и блокировками. Ничего экзотического на этом пути не происходит, и цена записи не меняется.

Репликация в колоночное хранилище

Дальше изменение уезжает в колоночную копию. В TiDB это сделано через роль Raft Learner, то есть колоночный узел подписан на тот же журнал репликации, что и строковые реплики, но голоса в кворуме не имеет и запись клиента не задерживает. Прямо писать в колоночное хранилище нельзя, оно принимает данные только по этому каналу, и это принципиальное ограничение, а не недоработка. Подробности механизма описаны в разделе TiFlash Overview официальной документации TiDB.

Согласованность чтения

Репликация асинхронная, поэтому между коммитом и появлением строки в аналитическом представлении всегда есть окно. Чтобы аналитик не ловил недосогласованную картину, системы применяют версионность. Запрос получает номер версии данных и читает только те строки, которые на этот момент подтверждены, а если колоночная копия отстала, движок дожидается нужной версии либо уходит читать строковое хранилище. Так гибридная система сохраняет привычные гарантии, платя за это временем ответа в момент отставания.

Ограничения подхода

Гибридная обработка выглядит как решение, которое отменяет хранилище данных вообще. Это не так, и трезвый список ограничений полезнее восторгов.

• Данные всё равно дублируются. Колоночная копия занимает место, требует памяти и процессорного времени на поддержание. Экономия происходит на конвейере и на дежурствах, а не на железе.
• Окно рассинхрона не равно нулю. Оно измеряется долями секунды вместо часов, но существует, и запрос с требованием строгой свежести иногда упирается в ожидание.
• Исторические данные никуда не деваются. Транзакционная система не хранит десять лет фактов, поэтому классическое хранилище с историей и медленно меняющимися измерениями остаётся нужным.
• Ресурсы конечны. Изоляция узлов снимает конкуренцию за процессор, но не отменяет общий бюджет кластера, и тяжёлый отчёт всё так же оплачивается железом.
• Эксплуатация сложнее. Распределённая гибридная СУБД это больше движущихся частей, чем одна PostgreSQL, и команде нужны соответствующие навыки.

Ни один пункт не отменяет пользы подхода, но каждый превращается в неприятный сюрприз, если узнать о нём уже в проде.

HTAP против связки OLTP, ETL и хранилища

Сравнение двух архитектур удобнее держать в таблице, потому что выбор между ними почти всегда сводится к нескольким параметрам.

Когда применять, а когда не стоит

Гибридная обработка окупается там, где решение принимается по свежим данным и стоит денег прямо сейчас. Сюда попадают антифрод, который смотрит на историю операций клиента прямо в момент платежа, персонализация выдачи с учётом текущей сессии, оперативная панель логистики или склада и динамическое ценообразование. Во всех этих случаях отставание в час равносильно отсутствию ответа.

Обратный случай столь же узнаваем. Если отчётность строится раз в сутки, а вопросы к данным исторические, классическое хранилище дешевле и понятнее. Если весь объём укладывается в одну PostgreSQL и аналитика никому не мешает, менять СУБД незачем. Разбор архитектур гибридных хранилищ на практике идёт на курсе StarRocks для реализации HTAP и Data Lakehouse.

Конфликт нагрузок в цифрах

Чтобы увидеть, откуда вообще растёт потребность в отдельном колоночном хранилище, гибридную систему можно собрать руками из двух движков. PostgreSQL 18.4 держит транзакции, DuckDB 1.5.5 играет роль колоночной реплики, а репликация идёт выгрузкой снимка и дельты вместо журнала. Внутри TiDB с TiFlash происходит ровно то же самое, только встроенно.

По традиции весь код используемый в статье выкладываем на наш GitHub репозиторий

Оба демо гоняют один и тот же аналитический запрос по таблице заказов на 12 миллионов строк, которая занимает 985 MB в строковом хранилище. Сравнение честное только на одинаковом SQL, поэтому запрос ровно один.

-- PostgreSQL 18.4 (Homebrew) и DuckDB 1.5.5, прогон на стенде 2026-08-24
-- один и тот же запрос идёт в оба хранилища, полный вывод в run_output.txt
select customer_id,
       status,
       count(*)     as cnt,
       sum(amount)  as revenue,
       avg(amount)  as avg_check
from orders
group by 1, 2
order by revenue desc
limit 20

Скрипт oltp_under_analytics.py меряет латентность трёхсот точечных UPDATE сначала в тишине, потом под шестью параллельными соединениями, которые крутят эту агрегацию по всей таблице.

# вывод oltp_under_analytics.py, PostgreSQL 18.4 (Homebrew) и Python 3.12.13, прогон на стенде 2026-08-24
аналитический запрос в одиночку: 5.52 с, строк в ответе: 20
[тишина] UPDATE x300: p50 0.43 мс, p95 1.66 мс, max 4.44 мс
[под нагрузкой] UPDATE x300: p50 0.31 мс, p95 2.05 мс, max 8.68 мс
аналитических запросов прошло: 6, среднее время 23.27 с против 5.52 с в одиночку

Результат вышел неудобным для расхожего тезиса «аналитика роняет транзакции». Медиана точечных UPDATE под нагрузкой не выросла, подрос только хвост, а именно p95 в 1.2 раза и максимум вдвое. Зато сама аналитика просела в 4.2 раза. На одной машине с быстрым диском и версионным чтением конфликт нагрузок бьёт прежде всего по предсказуемости аналитического ответа, а транзакции страдают позже, уже на нагруженном проде и медленных дисках.

Второй скрипт, columnar_replica.py, уводит ту же аналитику в колоночную копию и меряет, что из этого выходит.

# вывод columnar_replica.py, PostgreSQL 18.4 и DuckDB 1.5.5, прогон на стенде 2026-08-24
первичная заливка: выгрузка 15.3 с, загрузка в колоночное 2.1 с, всего 17.3 с
размер колоночного файла: 204 МБ против 985 MB в строковом
строковое хранилище: 6.13 с, строк в ответе 20
колоночное хранилище: 0.23 с, строк в ответе 20
разница по времени: 26.6x
догрузка дельты: 0.07 с (1109 КБ), в реплике стало 12 020 000 строк
окно рассинхрона от коммита до видимости в аналитике: 0.45 с

Здесь видно всё, ради чего гибридные системы и строят. Тот же запрос ускорился в 26.6 раза, копия заняла впятеро меньше места благодаря сжатию по колонкам, а догрузка двадцати тысяч новых заказов уложилась в 0.07 секунды. И тут же видна цена, потому что аналитика показывает данные с отставанием в 0.45 секунды, а не мгновенно. В промышленной системе окно меньше, поскольку репликация идёт из журнала, но нулевым оно не становится никогда.

Заключение

HTAP это не волшебная СУБД, а инженерный компромисс, который переносит границу между транзакциями и аналитикой внутрь одной системы. Механизм сводится к двум представлениям одних данных, строковому для точечных операций и колоночному для агрегаций, связанным асинхронной репликацией и версионным чтением. Выигрыш измеряется свежестью данных и количеством выброшенных из контура компонентов. Плата состоит из дублирования данных, окна рассинхрона и более сложной эксплуатации. Если решения в вашем продукте принимаются на данных возрастом в секунды, подход стоит рассмотреть всерьёз, а если отчёт нужен раз в сутки, привычная связка транзакционной базы и хранилища останется дешевле.

Референсные ссылки

• TiFlash Overview, документация TiDB
• Explore HTAP, документация TiDB
• HTAP Demystified, история термина и отчёт Gartner 2014 года
• Google AlloyDB, колоночный движок для аналитики
• HTAPSys, воркшоп по гибридным системам при конференции ICDE 2026