Как Data Fabric и HTAP превращают сырые данные в бизнес-события для мгновенной аналитики

Долгое время главным критерием качества данных считалась их чистота и полнота. Компании инвестировали значительные ресурсы в MDM-системы и процессы проверки, стремясь получить «единую версию правды». Однако сегодня этого уже недостаточно. В условиях, когда скорость реакции определяет успех, на первый план выходит новый критерий — актуальность. Способность данных отражать реальное положение дел в момент принятия решения становится решающим фактором. При этом классические архитектуры, основанные на ночных загрузках в DWH, создают временной лаг, который превращает «правду» во «вчерашнюю». 

Привет, Хабр. Меня зовут Александр Шалудин. Я Presale-архитектор Data Services VK Tech. В этой статье я разберу, к чему может приводить работа с неактуальной информацией и как выстроить архитектуру, которая позволит устранить этот разрыв.

Потребности современного бизнеса и скрытые угрозы

Из-за высокой конкуренции и сопутствующих вызовов многие компании стремятся стать Data-Driven, то есть принимать решения, основываясь на данных, чтобы сохранять конкурентоспособность, быстро реагировать на тренды и взвешенно оценивать бизнес-процессы.

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

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

Проблема усугубляется разрывом контекста: данные, доставленные с задержкой, теряют связь с операционным событием, которое их породило. Причина этого кроется в архитектурном барьере классических систем, где пакетные процессы ETL (Extract, Transform, Load) по своей природе создают временной лаг. 

В результате компания рискует начать жить в двух «реальностях». 

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

• С другой — данные в системе все еще показывают состояние на «вчера» или «прошлую ночь», качественные мастер-данные не встречаются с событиями вовремя, доступные выгрузки и дашборды больше не показывают текущую ситуацию.

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

Кейс: хроника одного запуска

Допустим, бизнес запускает продажу нового товара — премиальных дрелей из Китая. 

• В 10:00 в систему MDM (Master Data Management, система управления мастер-данными) заведено 200 новых SKU («бренд: PRO», «сегмент: премиум», «страна-производитель: Китай»).

• К 14:00 наблюдается пик продаж, и в поток транзакций начинают поступать «сырые» коды: SKU_NEW_PRO_001, SKU_NEW_PRO_002 и так далее.

• В 16:00 руководство хочет получить ответ о доле продаж новинок в общем объеме прямо сейчас. Ответ критически важен для управления цепочкой поставок: нужно ли срочно дозаказывать товар или, наоборот, останавливать поставки, чтобы избежать затоваривания склада.

Нюанс в том, что аналитическая система на классическом DWH может дать один ответ из двух:

• «Ноль». Потому что данные еще не попали в витрину: обновление ночное, а новые SKU проходят контур публикации (PIM/MDM — DWH), который отстает на 1–3 дня из-за проверок.

• «Не знаю». Система видит транзакцию SKU_NEW_PRO_001, но не знает, что за товар. Его атрибуты лежат в другой системе, в другом цикле жизни.

В любом из случаев аналитическая система на классическом DWH не может удовлетворить запрос бизнеса «здесь и сейчас» для принятия верных решений.

В результате требования к качеству данных изменяются.

Измерения качества данных

Классически качественными данными для бизнеса считались те, что отвечали пяти основным критериям:

• Точность. Соответствие цифровой записи реальному событию или объекту. 

• Полнота. Наличие всех атрибутов, необходимых для принятия бизнес-решений.

• Валидность. Соответствие данных установленным бизнес-правилам, форматам и диапазонам.

• Уникальность. Отсутствие дублей, когда объект представлен только одной записью.

• Непротиворечивость. Единство данных и версий справочников во всех системах.

Соответствие этим параметрам можно обеспечить с помощью MDM-систем, процессов контроля качества и готовых ETL-инструментов.

Однако два измерения качества часто остаются без должного внимания:

• Доступность. Возможность быстрого извлечения данных потребителем в любой момент.

• Актуальность. Доступность данных в момент, когда они нужны бизнесу. 

Причем именно эти два параметра часто становятся определяющими для принятия оперативных решений. 

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

Один из способов реализовать это — попробовать ускорить ETL.

Ускорение ETL и альтернативные решения

Для ускорения ETL можно увеличить частоту расчетов: например, выполнять их не раз в сутки, а раз в час или раз в 15 минут. Но даже в таком случае остается несколько барьеров.

• Для запуска расчетов раз в 15 минут нужно значительно больше ресурсов, что ведет к кратному росту затрат на инфраструктуру.

• Важно учитывать, что в разных контурах могут быть разные SLA и версии справочников.

• Сырых данных недостаточно: для принятия бизнес-решений мало знать, где была совершена транзакция. Их нужно дообогащать, то есть сразу связывать события со смыслом.

Таким образом, в большинстве случаев недостаточно просто ускорить пайплайн — нужно изменять принцип и переходить на новые архитектуры и практики работы с данными. 

Один из возможных вариантов решения — комбинирование архитектур Data Fabric и HTAP (Hybrid Transactional and Analytical Processing), где:

• Data Fabric — архитектура, которая создает единую среду для управления и интеграции данных из разных источников без их физической централизации. Data Fabric способствует обогащению данных, так как позволяет автоматически объединять, сопоставлять и дополнять информацию из различных источников, обеспечивая более полную и качественную аналитику.

• HTAP — архитектура СУБД, позволяющая одновременно выполнять транзакционные (OLTP) и аналитические (OLAP) запросы в одной системе без необходимости копирования данных.

Верхнеуровнево пайплайн на основе этих компонентов может иметь следующий вид:

• Поток событий. Все начинается с непрерывного потока данных — например, транзакций с кассовых автоматов, поступающих в режиме реального времени.

• Data Fabric. Поток проходит через интеллектуальный слой Data Fabric, где осуществляются автоматическая интеграция, обогащение, контроль качества и маршрутизация данных. Data Fabric обеспечивает единый доступ к информации независимо от ее источника и формата.

• HTAP. Далее данные попадают в HTAP-базу. Например, в качестве такой может выступать Tarantool Column Store — In-memory-колоночная СУБД на базе Tarantool Enterprise Edition для транзакционно-аналитической обработки данных в реальном времени.

• BI-система. Из HTAP-хранилища данные поступают в BI-систему, где визуализируются в виде наглядных отчетов и дашбордов. Благодаря использованию Data Fabric и HTAP на предыдущих этапах на дашбордах можно сразу отслеживать не сырую информацию, а актуальные аналитические срезы и ключевые показатели бизнеса.

Подробнее о Data Fabric и HTAP

Ключевыми компонентами новой «связки», обеспечивающей возможность аналитики на данных практически в реальном времени, являются Data Fabric и HTAP. Чтобы понять, как именно они устроены и работают, разберем инструменты подробнее.

Data Fabric

Data Fabric — это не «еще одно хранилище», а интеллектуальный архитектурный слой, обеспечивающий связность, интеграцию и управление данными поверх существующих источников. Ключевая задача Data Fabric — превратить разрозненные «сырые» события (например, технические сигналы от кассовых терминалов или сервисов) в осмысленные бизнес-события с понятным происхождением и контекстом. Для этого платформа обогащает каждое событие, обращаясь к различным системам и справочникам, что позволяет насытить его смыслом и сделать пригодным для аналитики.

Причем, в отличие от классических подходов, Data Fabric не перегружает мастер-системы (MDM) прямыми запросами. Вместо этого используются актуальные проекции атрибутов, которые доставляются с помощью механизмов захвата изменений (CDC) и кэширования. Такой подход обеспечивает быстрый доступ к необходимым данным и не влияет на производительность основных бизнес-приложений.

Важная особенность Data Fabric — фиксация состояния всех связанных с событием данных в момент его возникновения. Например, при анализе продаж за прошедший месяц система использует цены и категории товаров, актуальные именно на тот период, а не их текущие значения.

Это обеспечивает достоверность аналитических отчетов и возможность их повторного расчета в любой момент в будущем с получением того же результата. Таким образом, формируется единая и надежная среда, где технические данные преобразуются в понятные бизнес-факты для принятия управленческих решений.

На техническом уровне концепция Data Fabric реализуется через комплекс взаимосвязанных компонентов:

• Транспорт (Event Streaming). Системы вроде Kafka, Pulsar или Tarantool Queue Enterprise выступают в роли буфера, который отделяет источники данных от потребителей и выдерживает пиковые нагрузки.

• Проекции мастер-данных. Fabric хранит локальные проекции справочников (SKU, регионы), обновляемые через CDC из MDM/PIM. Проекция должна быть версионированной (SCD2), чтобы система знала версию атрибутов на момент события.

• Метаданные, каталог, политики доступа. Эти компоненты превращают простой стрим-пайплайн в полноценную Fabric, добавляя управление данными как активом.

• Качество данных в движении (DQ in motion). Бизнес-проверки (диапазоны, обязательные поля), которые выполняются прямо в потоке. Результат подобных проверок — маркировка «плохих» событий или их отправка в Quarantine Topic.

• Сервис обогащения (Enrichment). В стрим-процессоре происходит join события с проекциями. На выходе получается обогащенное событие (EnrichedSaleEvent), где зафиксированы версия справочника, происхождение (Lineage) и результаты проверок качества (dq_flags).

HTAP на примере Tarantool Column Store 

В качестве HTAP-решения, которое поддерживает смешанный профиль нагрузки, может выступать Tarantool Column Store — колоночная СУБД для аналитических запросов, витрин, агрегатов и отчетности в реальном времени. Решение позволяет получать актуальные данные для отчетов менее чем за минуту и снижать совокупную стоимость владения за счет отсутствия необходимости перемещать информацию между OLTP- и OLAP-системами. Причем благодаря горизонтальной масштабируемости СУБД легко справляется с растущими нагрузками.

Tarantool Column Store может быть полезен в разных сценариях:

• AML (Anti-Money Laundering). Отслеживание подозрительных паттернов движения средств.

• Динамическое ценообразование. Адаптация цен в Real-time для максимизации прибыли.

• Система рекомендаций и маркетинговые кампании. Персонализированный контент для миллионов пользователей без задержек. 

• База данных для ERP-систем. Централизованное управление ключевыми бизнес-процессами.

Что в итоге

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

При этом связка Data Fabric и HTAP не заменяет DWH, а дополняет его, позволяя выстроить систему, где у каждого компонента своя задача. Например:

• HTAP-систему применяют для хранения детальных оперативных данных за последние 7–30 дней для поддержки быстрых решений.

• DWH остается ядром для анализа исторических данных за годы, построения тяжелых витрин и обучения ML-моделей.

• Data Fabric выступает универсальным слоем, который работает с обеими системами и обеспечивает подготовку, обогащение и доставку данных в нужное хранилище в правильном формате. 

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