Наш коллега Джей Крепс (Jay Kreps) утверждал, что каждая компания становится программной. Он был прав. Бизнес больше не просто использует ПО для помощи людям в работе. ПО стало тем, на чем фактически держится бизнес.
ИИ сейчас делает с ПО то же, что ПО сделало с бизнесом. Сначала генеративный ИИ помогал нам выполнять работу быстрее и лучше. С тех пор он прошел путь от черновиков и суммирования до написания кода и выполнения сложных задач. Теперь мы говорим ИИ-агентам, что нужно сделать, и позволяем им самим разбираться, как именно, включая принятие решений, которые раньше требовали участия человека. Мы по-прежнему задаем направление и ограничения, но сами решения могут приниматься на машинно-обусловленной скорости.
Более быстрое принятие решений не означает наличие данных и контекста, необходимых для их правильности. Большая часть нашей корпоративной архитектуры данных была создана для описания прошлого — будь то минуты, часы или месяцы назад. Теперь мы просим ту же архитектуру помогать управлять настоящим.
Многие из нас ловили себя на том, что задают ИИ вопросы вроде: «Ты проверил самую свежую информацию?» или «Где вообще ты это взял?». Мы можем замечать ошибки, переспрашивать или игнорировать ответ, как мы годами поступали с отчетами и дашбордами. Но когда ИИ-агенты действуют без проверки их ответов кем-либо, последствия меняются. Устаревшие данные или неточное понимание бизнеса больше не приводят просто к неправильному ответу. Это ведет к неправильному действию.
Для принятия точных решений на скорости работы машин нам необходимо поддерживать состояние бизнеса по мере его изменения. Это состояние должно быть всегда актуальным, децентрализованным по системам, которые уже управляют бизнесом, и достаточно надежным, чтобы программное обеспечение могло на него опираться. Приложения, агенты и аналитические системы должны иметь возможность повторно использовать это понимание, а не воссоздавать его заново каждый раз, когда оно им требуется. Архитектуру, которая это делает возможным, мы называем Streamhouse.
Streamhouse — это архитектура данных, которая непрерывно собирает, обрабатывает, управляет и предоставляет актуальное состояние и контекст бизнеса в распределенных системах, делая их доступными для приложений, ИИ-агентов и аналитики.
У Streamhouse есть три требования:
- Всегда актуально. Создавайте на основе истории, а затем поддерживайте состояние по мере поступления изменений. Сохраняйте способность выполнять повторное воспроизведение, исправление и пересчет при изменении базовых фактов или бизнес-правил.
Всегда актуально. Создавайте на основе истории, а затем поддерживайте состояние по мере поступления изменений. Сохраняйте способность выполнять повторное воспроизведение, исправление и пересчет при изменении базовых фактов или бизнес-правил.
- Децентрализованность. Операционные и аналитические системы сохраняют свои собственные зоны ответственности. Они могут делиться состоянием и его смыслом, а также повторно использовать их в любой форме и формате без предварительной консолидации на единой физической платформе.
Децентрализованность. Операционные и аналитические системы сохраняют свои собственные зоны ответственности. Они могут делиться состоянием и его смыслом, а также повторно использовать их в любой форме и формате без предварительной консолидации на единой физической платформе.
- Критическая важность для миссии. Информация, определяющая производственные решения, должна соответствовать надлежащим требованиям к корректности, доступности, безопасности, восстановлению и прослеживаемости.
Критическая важность для миссии. Информация, определяющая производственные решения, должна соответствовать надлежащим требованиям к корректности, доступности, безопасности, восстановлению и прослеживаемости.
В этом блоге мы подробно рассмотрим каждое из этих требований. Вместе они представляют собой фундаментальный сдвиг в том, что мы поддерживаем и чем делимся в масштабах бизнеса.
Большинство конвейеров данных создаются для перемещения и трансформации информации в определенное место назначения, оставляя последующим приложениям, аналитическим системам и ИИ-агентам задачу самостоятельно формировать понимание бизнеса. Streamhouse меняет эту модель. Вместо того чтобы рассматривать состояние и контекст бизнеса как результат работы независимо созданных конвейеров, он делает состояние, его смысл и лежащие в его основе вычисления повторно используемыми в разных системах. Базовые технологии нам знакомы, но то, за что отвечает архитектура, принципиально ино.
Streamhouse дает название уже формирующейся архитектурной категории, объединяя несколько устоявшихся технологий для удовлетворения этих требований. Коннекторы фиксируют операционные изменения и исторические данные. Надежный каркас событий делает эти изменения доступными для обработки и повторного воспроизведения. Обработка с учетом состояния непрерывно поддерживает полезные представления бизнес-состояния. Общая семантическая модель связывает бизнес-определения и взаимосвязи между системами, в то время как управление и происхождение данных обеспечивают контроль и прослеживаемость. Наконец, системы выдачи делают поддерживаемое состояние и контекст доступными через потоки, запросы, API и операционные или аналитические таблицы.
Архитектура Streamhouse позволяет организациям непрерывно собирать, передавать, преобразовывать, администрировать и предоставлять текущее состояние своего бизнеса.
Streamhouse не предписывает использование какого-то конкретного технологического стека. Каждый подход предполагает различные компромиссы в отношении задержки, согласованности, воспроизведения, стоимости и операционной сложности. Каждая возможность может быть реализована по-разному:
- Захват изменений через Kafka Connect или управляемые службы репликации данных.
Захват изменений через Kafka Connect или управляемые службы репликации данных.
- Передача изменений через Apache Kafka или Apache Pulsar.
Передача изменений через Apache Kafka или Apache Pulsar.
- Инкрементная или пакетная трансформация данных с использованием Apache Flink или материализованных представлений баз данных.
Инкрементная или пакетная трансформация данных с использованием Apache Flink или материализованных представлений баз данных.
- Управление схемами, определениями и происхождением с использованием открытых или проприетарных инструментов.
Управление схемами, определениями и происхождением с использованием открытых или проприетарных инструментов.
- Обслуживание поддерживаемого состояния через PostgreSQL или публикация в виде открытых таблиц Apache Iceberg.
Обслуживание поддерживаемого состояния через PostgreSQL или публикация в виде открытых таблиц Apache Iceberg.
Streamhouse дополняет операционные и аналитические системы, которые уже управляют бизнесом. Он делает это, предоставляя таким системам непрерывно поддерживаемое состояние бизнеса и общий контекст, позволяя каждой из них выстраивать единое понимание бизнеса вместо того, чтобы воссоздавать его независимо. Операционные приложения и базы данных остаются ответственными за авторизацию и фиксацию транзакций. Хранилища и озера данных продолжают поддерживать исторический анализ, исследование и обучение моделей.
Всегда актуально
У решения есть дедлайн.
Streamhouse поддерживает и передает состояние бизнеса по мере его изменения, поэтому у ПО есть необходимые данные, пока еще есть время для действий. Получить данные в поток, озеро или хранилище за секунды недостаточно. Быстрый прием не гарантирует быстрых действий. Информация должна обрабатываться и выдаваться вместе со своим смыслом и контекстом с той скоростью, которая требуется для принятия решения.
Streamhouse формирует состояние бизнеса на основе истории, а затем фиксирует операционные изменения по мере их возникновения. Stateful-обработка непрерывно поддерживает пригодные для повторного использования результаты по мере поступления этих изменений. Эти результаты могут потребляться как потоки изменений, запрашиваться как текущее состояние или материализовываться в виде таблицы. История остается доступной для внесения исправлений, изменения бизнес-правил и повторных вычислений при необходимости. Но обновление того, что меняется, становится стандартом по умолчанию вместо того, чтобы каждый раз перестраивать все с нуля.
Сама по себе актуальность — это еще не все. Программному обеспечению необходимы бизнес-семантика и контекдент, чтобы понимать, что означают данные и как их использовать. Подобно тому как люди принимают решения на основе неполной информации, программное обеспечение может предоставлять полезные ответы, которые уточняются по мере поступления новых сведений. Другие решения требуют полной информации или подтверждения от авторитетных систем, прежде чем ПО сможет действовать. Streamhouse должен поддерживать оба варианта, делая актуальность, смысл и полноту своего состояния доступными для использующих его приложений.
Поддержание бизнес-состояния на основе изменений кардинально меняет экономику обработки данных.
Большая часть данных, контекста и бизнес-логики, которые нам необходимы, уже существует в операционных системах, управляющих нашим бизнесом. Тем не менее нисходящие приложения, аналитические конвейеры и ИИ-агенты снова и снова воссоздают это понимание. Мы не просто копируем данные. Мы воссоздаем их смысл и стоящие за ними вычисления, оплачивая как инфраструктуру, так и людей, необходимых для поддержания и согласования этих независимых реализаций. Хуже того, каждая реализация может создавать собственную версию «настоящего момента». Определения и актуальность различаются в разных системах, и один и тот же бизнес-вопрос может приводить к противоречивым ответам.
Streamhouse не гарантирует идеальной синхронизации глобальной версии «настоящего момента». Он существенно сокращает количество подобных противоречивых интерпретаций за счет поддержания и совместного использования повторно используемого бизнес-состояния, контекста и вычислений. Различным потребителям по-прежнему могут требоваться собственные представления, но они не должны независимо воссоздавать одно и то же понимание. Выгода возрастает по мере того, как все больше приложений и повторяющихся решений начинают использовать эту работу повторно.
Цель заключается не просто в том, чтобы обрабатывать данные быстрее. Цель состоит в том, чтобы поддерживать общее понимание бизнеса по мере его изменения, вместо того чтобы заставлять каждого потребителя создавать собственную версию «настоящего момента».
Децентрализация
Нельзя унифицировать бизнес путем консолидации его систем.
Streamhouse унифицирует распределенный бизнес, поддерживая повторно используемое бизнес-состояние и контекст в существующих системах. Он не требует от бизнеса консолидации на одной платформе решений. Каждая система может сохранять свою специализированную роль, продолжая разделять общее понимание бизнеса.
Операционные и аналитические системы различаются по веским причинам. Платежной базе данных необходимы транзакции и параллелизм. Хранилищу нужно анализировать годы истории без ущерба для процесса оформления заказа. Специализация — это не дефект, от которого нужно избавиться.
Консолидация может принести реальные преимущества, но предприятия остаются и будут оставаться распределенными. Платформы ERP и CRM объединяют значительные части операционного бизнеса, в то время как lakehouses унифицируют аналитические рабочие нагрузки вокруг общего хранилища, вычислений и управления. Несмотря на это, предприятиям по-прежнему необходимы специализированные решения, такие как специализированные базы данных, мейнфреймы и сторонние приложения. Ни одна отдельная платформа не может разумно стать центром всего бизнеса.
Общая платформа может унифицировать обслуживаемые ею рабочие нагрузки. Она не может быть предварительным условием для унификации бизнеса.
Проблема выходит за рамки того, где хранятся данные. Значительная часть их смысла заложена в логике приложений, связях, бизнес-правилах и исключениях. Современные платформы стали невероятно гибкими в отношении приема и хранения изменяющихся структур данных, но учет этих изменений не тождественен сохранению их смысла. Перемещение записи заказа между системами не означает автоматического переноса правил, определяющих, когда этот заказ может быть отменен или как резервируются его запасы.
И этот смысл не обязательно одинаков для всего бизнеса. Разные системы могут вполне законно по-разному представлять одни и те же бизнес-концепции. Streamhouse соединяет эти представления с помощью общих определений и непрерывно поддерживаемого состояния, не заставляя каждую систему переходить на единую универсальную модель. Операционные системы сохраняют контроль над своими транзакциями, в то время как потребители используют заново созданное в них понимание бизнеса.
Бизнес остается распределенным. Его данные, контекст и вычисления больше не нужно независимо воссоздавать везде, где они используются.
Критическая важность
Когда программное обеспечение совершает действия, его решения становятся фактами.
Streamhouse должен соответствовать требованиям надежности, доступности и восстановления операционной инфраструктуры, когда приложения зависят от его состояния для ведения бизнеса. Существует принципиальная разница между использованием данных для объяснения того, что произошло, и их использованием для принятия решений о том, что делать дальше. Неправильное число в отчете можно исправить. Но если ИИ-агент выдает кредит, обещает доставку или отгружает товар на основе неверной информации, исправление данных задним числом может не отменить само действие.
Поддерживаемое состояние должно переживать сбои, оставаться доступным под нагрузкой и восстанавливаться в предсказуемые сроки. Недоступная аналитическая панель может задержать отчет. Недоступный Streamhouse, поддерживающий выполнение заказов, может остановить их движение.
Streamhouse должен иметь возможность безопасно развиваться, не нарушая работу зависящих от него систем. Например, изменение схемы базы данных должно проверяться и распространяться через обработку и нисходящие таблицы без неожиданного сбоя в приложениях, которые от них зависят.
Операционные системы по-прежнему авторизуют и фиксируют транзакции, но Streamhouse должен обеспечивать безопасность и разрешения, а также делать сбои видимыми, чтобы приложения могли реагировать безопасно.
Streamhouse отвечает не только за то, чтобы бизнес шел в ногу со временем. Он должен помогать бизнесу работать.
Эта категория уже формируется
Архитектурные паттерны, лежащие в основе Streamhouse, существовали в продакшене задолго до того, как получили название. Компании годами комбинируют изменяющиеся и исторические данные, инкрементальную и пакетную обработку, а также различные системы обслуживания. Ценность заключается в том, когда все это объединяется в единый непрерывный процесс.
Давайте рассмотрим несколько примеров, которые показывают, как индустрия подходила к одной и той же проблеме с разных сторон.
- Siemens Healthineers использует Apache Flink для обработки и обогащения операционных данных до того, как они попадут в хранилище, поддерживая множество нисходящих потребителей через общую потоковую магистраль. Они исключили дорогие многочасовые циклы пакетной переработки перед Snowflake.
Siemens Healthineers использует Apache Flink для обработки и обогащения операционных данных до того, как они попадут в хранилище, поддерживая множество нисходящих потребителей через общую потоковую магистраль. Они исключили дорогие многочасовые циклы пакетной переработки перед Snowflake.
- Neuron Systems использует надежные потоки событий для координации ИИ-агентов, обеспечивающих живой спортивный комментарий. Комментаторы на хинди, испанском и английском языках реагируют на один и тот же момент игры, используя общее базовое состояние игры, что предотвращает противоречивые комментарии у разных агентов.
Neuron Systems использует надежные потоки событий для координации ИИ-агентов, обеспечивающих живой спортивный комментарий. Комментаторы на хинди, испанском и английском языках реагируют на один и тот же момент игры, используя общее базовое состояние игры, что предотвращает противоречивые комментарии у разных агентов.
- Yelp самостоятельно описывает собственную архитектуру streamhouse с использованием сервисов AWS, Apache Flink и Apache Paimon, без Confluent. Это позволило сократить задержку аналитических данных примерно с 18 часов до минут, а затраты на хранение — на 80%.
самостоятельно описывает собственную архитектуру streamhouse с использованием сервисов AWS, Apache Flink и Apache Paimon, без Confluent. Это позволило сократить задержку аналитических данных примерно с 18 часов до минут, а затраты на хранение — на 80%.
В сентябре 2026 года компании Aiven, Confluent, Redpanda, StreamNative и Ververica сформировали рабочую группу Streamhouse для создания открытого определения этой архитектуры. Термин изначально был предложен компанией Ververica, и компании-основатели договорились сделать его общедоступным для каждого.
Возможность заключается в том, чтобы перенести эти паттерны за рамки отдельных реализаций и сделать их пригодными для повторного использования в масштабах всего предприятия. Эти примеры демонстрируют различные реализации одной и той же архитектуры. Базовые технологии уже существуют. Следующая задача — объединить их в архитектуру, такую же простую в использовании, как база данных.
Создание Streamhouse с помощью Confluent
Компания Confluent потратила годы на создание технологий, которые делают Streamhouse возможным, бок о бок с клиентами, которые использовали эти технологии для ведения своего бизнеса. Сегодня платформа Confluent Data Streaming Platform предоставляет наиболее полную, производительную и открытую платформу для построения Streamhouse. Confluent объединяет возможности захвата, потоковой передачи, обработки, управления и предоставления бизнес-состояния по мере его изменения.
Apache Kafka обеспечивает надежную, воспроизводимую основу событий. Kafka Connect и технология изменения данных (CDC) интегрируют операционные системы и делают их изменения доступными для всего бизнеса. Apache Flink объединяет исторические данные с этими изменениями, непрерывно поддерживая полезное бизнес-состояние с помощью SQL, Table API и обработки с сохранением состояния. Stream Governance предоставляет схемы, контракты данных, каталогизацию и отслеживание происхождения данных, а более широкие бизнес-семантики и сквозное управление появятся в будущем.
Confluent также делает это состояние доступным в необходимом для потребителей виде. Lightning Tables обеспечивает низкую задержку доступа через SQL, API и MCP, в то время как Tableflow публикует потоковые данные в открытые аналитические форматы, такие как Apache Iceberg и Delta Lake. Одно и то же базовое бизнес-состояние может поддерживать приложения, ИИ-агенты и аналитические платформы без необходимости для каждого из них воссоздавать его самостоятельно.
Архитектура построена на открытых технологиях и предназначена для соединения существующих систем, а не их замены. Благодаря IBM мы расширяем ее охват в операционной среде, включая мейнфреймы, корпоративные базы данных и гибридные среды, где уже работает значительная часть бизнеса. Это подключение имеет решающее значение для внедрения Streamhouse во всем предприятии, а не только в системах, которые уже используют современные платформы данных.
Преимущество Confluent заключается в объединении этих возможностей в единую платформу потоковой передачи данных (Data Streaming Platform). Клиентам не нужно собирать и обслуживать набор независимых технологий для поддержания актуального понимания своего бизнеса. Мы делаем Streamhouse полноценной платформой, на которой они могут строить свои решения.
Платформа Confluent Data Streaming Platform предоставляет наиболее полную, производительную и открытую платформу для построения Streamhouse.
Что делать дальше
Начните с бизнес-сущностей, которые имеют наибольшее значение для вашей операционной деятельности: заказа, клиента, учетной записи или права доступа. Информация, необходимая для работы с каждой из них, уже может быть разбросана по системам, которые никогда не были предназначены для совместного ответа на один и тот же вопрос.
Для каждого из них задайте четыре вопроса:
- Кто является владельцем? Какие системы являются авторитетными источниками фактов, изменений и транзакций?
Кто является владельцем? Какие системы являются авторитетными источниками фактов, изменений и транзакций?
- Что это значит? Какие определения, связи, правила и исключения определяют, как должна интерпретироваться эта информация?
Что это значит? Какие определения, связи, правила и исключения определяют, как должна интерпретироваться эта информация?
- Что мы перестраиваем? Сколько приложений, конвейеров, трансформаций, кэшей и аналитических моделей независимо друг от друга воссоздают ту же информацию или бизнес-правила?
Что мы перестраиваем? Сколько приложений, конвейеров, трансформаций, кэшей и аналитических моделей независимо друг от друга воссоздают ту же информацию или бизнес-правила?
- Какие решения зависят от этого? Насколько актуальной и корректной должна быть информация и какая система фактически обладает полномочиями действовать?
Какие решения зависят от этого? Насколько актуальной и корректной должна быть информация и какая система фактически обладает полномочиями действовать?
Задавая эти вопросы, вам следует выбрать сущности и решения, где поддержание единого понимания бизнеса приносит наибольшую пользу. Скорее всего, это совпадет с тем, где вы применяете ИИ для изменения способов ведения бизнеса. Это пугающе похоже на решения, которые вы, вероятно, принимали, когда применяли программное обеспечение для изменения процессов ведения бизнеса. Возвращаясь к блогу Джея (Jay), в конце концов, каждая компания — это программное обеспечение, и каждая компания становится ИИ.
Как только вы выберете свою проблему, вот основные шаги. Создайте начальное состояние из истории. Захватывайте изменения. Поддерживайте полезные результаты. Свяжите определения и управление, необходимые для доверия к ним. И предоставляйте эти результаты в формах, нужных потребителям.
Следующее поколение программного обеспечения не будет ждать, пока бизнес догонит его. Его архитектура данных тоже не должна этого делать.
Ваш бизнес, всегда актуальный.
Чтобы начать внедрение архитектуры Streamhouse с помощью Confluent:
- Посетите вебинар: Streamhouse: архитектура данных, питающая ИИ со скоростью машины
Посетите вебинар: Streamhouse: архитектура данных, питающая ИИ со скоростью машины
- Посмотрите, как выглядит использование Streamhouse организацией: Загрузить описание решения
Посмотрите, как выглядит использование Streamhouse организацией: Загрузить описание решения
- Ознакомьтесь с электронной книгой: Ваш бизнес постоянно меняется. Успевает ли ваш ИИ за ним?
Ознакомьтесь с электронной книгой: Ваш бизнес постоянно меняется. Успевает ли ваш ИИ за ним?
- Начните потоковую передачу данных в реальном времени за считанные минуты: Зарегистрируйтесь в Confluent Cloud
Начните потоковую передачу данных в реальном времени за считанные минуты: Зарегистрируйтесь в Confluent Cloud
Вышеизложенное описывает общее направление развития продукта и не является обязательством по поставке какого-либо материала, кода или функционала. Разработка, выпуск, сроки и цены любых описанных функций или возможностей могут быть изменены. Клиенты должны принимать решения о покупке на основе услуг, возможностей и функций, которые доступны в настоящее время.
Confluent и сопутствующие знаки являются товарными знаками или зарегистрированными товарными знаками компании Confluent, Inc.
Apache®, Apache Kafka®, Kafka®, Apache Flink®, Flink®, Apache IcebergTM, IcebergTM, Apache ParquetTM и ParquetTM являются либо зарегистрированными товарными знаками, либо товарными знаками Apache Software Foundation в США и/или других странах. Использование этих знаков не подразумевает одобрения со стороны Apache Software Foundation. Все прочие товарные знаки являются собственностью соответствующих владельцев.
