Архитектура больших данных в 2010-х означала "всё в Hadoop". Начало 2020-х превратило это в пару "озеро + хранилище". К 2026-му картина опирается на три столпа: лейкхаус на открытых табличных форматах, Kafka-стриминг и RAG-слой, обогащённый векторным хранилищем. Хорошие решения рассматривают все три как одну платформу.
Столп 1: Лейкхаус и открытые табличные форматы
Тройка Apache Iceberg, Delta Lake и Apache Hudi стала стандартом корпоративных платформ. Обещание лейкхауса: гибкость озера + ACID хранилища + единый governed-слой.
- Независимость от вендора: одна и та же таблица читается из Snowflake, Databricks и Trino.
- Стоимость: storage в object storage; compute по требованию.
- Schema evolution, time travel, partition evolution: большинство потребностей теперь стандартны.
Тренд 2026-го — чтение одних и тех же таблиц несколькими движками. Выбор каталога (Polaris, Unity Catalog, Nessie) — это уже не выбор вендора, а архитектурное решение.
Столп 2: Real-time стриминг
Классический ETL — ночной пакет, утренний отчёт — уступает почасовым, поминутным и посекундным потокам. Три типичных паттерна:
Операционный CDC. Захват изменений из source-систем в Iceberg / Delta-таблицы. Debezium + Kafka Connect + Iceberg sink — комбинация по умолчанию.
Real-time materialised views. Постоянные агрегации над потоком в ksqlDB, Apache Flink или Materialize.
Event-driven ML. Feature store (Feast, Tecton), кормящий модель живыми значениями. Неизбежно для сценариев с низкой латентностью, таких как карточный фрод.
При проектировании стриминга часто забывают три вещи: schema registry, стратегия dead-letter и процедура rebuild. Без всех трёх продакшен не выдержит.
Столп 3: Vector store и RAG
Корпоративное принятие LLM нарастает с 2024-го. К 2026-му vector store — стандартная часть операционной дата-платформы: embedding-и документов, embedding-и продуктов, семантический поиск, RAG-ассистенты.
Типичные комбинации:
- pgvector: самый прагматичный выбор для организаций, начинающих с небольших корпусов.
- Qdrant / Weaviate / Milvus: для масштаба и гибридного (sparse + dense) поиска.
- Встроенные vector-возможности Snowflake / Databricks.
Vector store несёт ту же governance-нагрузку, что и любая таблица: контроль доступа, аудит-лог, законный источник содержимого. Соответствие KVKK требует, чтобы жизненный цикл embedding-ов с персональными данными был явно задокументирован.
Архитектурное решение: как собираются столпы?
Типичный поток 2026 года:
- Source-системы (CRM, ERP, core banking, weblog) → Kafka.
- Kafka → bronze-слой Iceberg / Delta.
- Spark или dbt-on-Snowflake / Databricks для silver и gold.
- Gold → BI (Power BI, Tableau, Qlik) и self-service.
- Gold + корпус документов → embedding pipeline → vector store.
- RAG-ассистент: vector store + LLM + бизнес-документы.
- Операционный ML: feature store + real-time scoring.
Вокруг: Data Catalog (DataHub, Atlan, Purview), Data Observability (Monte Carlo, Bigeye, Soda), FinOps Observability.
Частые архитектурные ошибки
Отключение стриминга от лейкхауса. Поддерживать batch- и streaming-версии одной таблицы — значит породить две истины.
Vector store как silo. Vector-таблицы, невидимые основному каталогу данных, превращаются в неуправляемую теневую сущность.
Пропуск schema registry. Вопрос "обязательны ли Avro / Protobuf" в 2026-м снят — ответ положителен.
Итог
Современная big-data архитектура — это сумма правильных решений, а не одна технология. Лейкхаус, стриминг и вектор не предназначены работать в изоляции. При правильном проектировании BI-дашборд, ML-модель и RAG-ассистент берут данные из одного governed-источника.
