Fountain создает решения для линейного персонала — почасовых работников в сфере розничной торговли, логистики, общественного питания, здравоохранения и гостиничного бизнеса, которые составляют большинство рабочей силы в мире. С 2014 года платформа Fountain обработала более 91 миллиона заявок и 14 миллионов наймов, а 10 продуктов компании обслуживают клиентов в более чем 75 странах.
Будучи глобальной компанией, обеспечивающей цикл найма линейного персонала от подачи заявки до даты выхода на работу, Fountain работает круглосуточно, как и компании (и их сотрудники), которые полагаются на нее. «Линейный персонал не спит», — говорит Алекс Нортон, руководитель отдела платформ данных в Fountain. — «Наши клиенты нанимают, адаптируют и составляют графики 24/7 в тысячах локаций».
В прошлом Fountain полагалась на пакетные задания, выполнявшиеся каждые три часа. «Это просто не устраивало наших клиентов, которым нужно было принимать решения прямо сейчас», — говорит Алекс. Поэтому они создали Cue Frontline Superintelligence, свою агентную ИИ-платформу, которая управляет операциями линейного персонала. С помощью Cue менеджер по найму может увидеть сигнал в 9:02 утра и принять решение к 9:05.
«Период полураспада заявки линейного сотрудника измеряется минутами, а не часами. Переход с трехчасового обновления на обновление за две минуты или меньше с помощью ClickPipes стал по-настоящему трансформационным для нашей клиентской базы». — Алекс Нортон, руководитель отдела платформ данных, Fountain
«Период полураспада заявки линейного сотрудника измеряется минутами, а не часами. Переход с трехчасового обновления на обновление за две минуты или меньше с помощью ClickPipes стал по-настоящему трансформационным для нашей клиентской базы».
— Алекс Нортон, руководитель отдела платформ данных, Fountain
На конференции Open House SF 2026 Алекс и старший инженер по аналитике Сесили Стори рассказали историю создания Cue: от устаревшей многовендорной пакетной архитектуры до оптимизированной системы, на которую они перешли с помощью ClickPipes и ClickHouse Cloud на AWS, и того, как это помогло им обеспечить выполнение запросов за доли секунды при снижении затрат примерно на две трети.
Старая аналитическая архитектура Fountain использовала традиционную модель пакетной обработки. Данные перемещались из исходных баз данных (13 производственных баз Postgres и четыре базы MongoDB) через стороннего поставщика репликации в S3, попадая туда в форматах Iceberg и Parquet, а затем в BigQuery и ClickHouse (с использованием табличной функции s3) для аналитики.
Старая пакетная архитектура Fountain: дорогостоящая, хрупкая, слишком медленная для требований линейного персонала
«Это работало нормально для нашего трехчасового конвейера обновлений», — говорит Алекс, — «но даже тогда это стало дорого и хрупко». Команда управляла конвейером, охватывающим нескольких поставщиков и облака; как только в картину добавилась MongoDB, это стало головной болью для небольшой команды данных Fountain. «На поддержку уходило много времени, а это время мы могли бы потратить на инновации», — говорит он.
Алекс выделяет пять ограничений, которые в конечном итоге вынудили провести перестройку. Первым была свежесть данных: трехчасовой цикл был несовместим с агентами, действующими за считанные минуты. Вторым была стоимость: один логический переход генерировал четыре отдельных счета: за репликацию, хранение в S3, загрузку в хранилище и аналитические вычисления. «Даже при трехчасовом обновлении расходы выходили из-под контроля», — говорит он.
Третьим была сложность: три поставщика и два промежуточных формата означали дрейф схемы на каждом стыке. Четвертым была кардинальность, поскольку таблицы с более чем 10 миллиардами строк и окна переходов росли экспоненциально. И пятым была конкурентность: когда тысячи пользователей из десятков арендаторов обращались к одному и тому же уровню данных, Алекс говорит: «добиться задержки запроса менее 10 секунд было битвой… добиться менее секунды было невозможно».
Алекс описывает новую архитектуру просто: «Мы используем ClickPipes как основу, а все остальное находится поверх него». Вместо того чтобы связывать репликацию, объектное хранилище и хранилище данных в одну длинную цепочку, Fountain использует управляемый CDC ClickPipes для потоковой передачи данных из Postgres и MongoDB напрямую в ClickHouse Cloud. «Один поставщик, одно соединение на исходную базу данных, ноль связующего кода».
Новая архитектура Fountain на базе ClickHouse: один поставщик, один переход, без планировщика
Нативный JSON позволяет Fountain обрабатывать глубоко вложенные документы MongoDB без разбора строк, что в старой системе, по словам Алекса, «становилось очень дорогостоящим, особенно в режиме, близком к реальному времени». Инкрементальные материализованные представления преобразуют данные в тот момент, когда ClickPipes записывает пакет, поэтому на пути данных нет оркестратора. А контроль доступа на уровне строк обеспечивает изоляцию данных каждого клиента по своей структуре, а не через запрос, который кто-то должен не забыть написать.
Результатом стали два симметричных конвейера — один для Postgres, один для MongoDB, — каждый из которых проходит один и тот же короткий путь: источник, ClickPipes, материализованные представления, Cue. Там, где старая архитектура имела два перехода, четыре счета и дрейф схемы на стыках, новая имеет одну аналитическую платформу, один переход и никакого планировщика.
«Вместо поддержки нескольких аналитических платформ пользователи могут полагаться на ClickHouse как на нашу платформу аналитики в реальном времени. Мы сократили расходы на 66%, и ее гораздо проще поддерживать». — Алекс Нортон, руководитель отдела платформ данных, Fountain
«Вместо поддержки нескольких аналитических платформ пользователи могут полагаться на ClickHouse как на нашу платформу аналитики в реальном времени. Мы сократили расходы на 66%, и ее гораздо проще поддерживать».
— Алекс Нортон, руководитель отдела платформ данных, Fountain
Затем Алекс передал микрофон Сесили Стори, ведущему разработчику движка реального времени Fountain, которая рассказала о четырех возможностях ClickHouse, на которых держится уровень данных: ClickPipes, нативный JSON, инкрементальные материализованные представления и управление доступом на основе ролей.
«ClickPipes — это ключ», — говорит Сесили. — «Если выделить одну функцию из того, о чем мы с Алексом говорим, то это то, что ClickPipes сделал нашу модель реального времени простой и масштабируемой».
Сегодня Fountain использует более 15 коннекторов, питающих более 2000 инкрементальных материализованных представлений. На стороне Postgres 11 производственных развертываний непрерывно реплицируются в таблицы SharedReplacingMergeTree, ключом которых является первичный ключ Postgres. Каждая строка содержит два столбца, помеченных самим ClickPipes: _peerdb_synced_at и _peerdb_is_deleted. «Больше нечего отслеживать и не за что платить», — говорит Сесили. — «Нет слоя Iceberg, нет бакета S3».
Источники MongoDB следуют той же схеме в четырех базах данных, обеспечивающих работу продуктов Fountain для персонала. Каждый документ попадает в один столбец типа нативного JSON. «Сочетание ClickPipes Mongo с нативным JSON — это то, что сделало возможным для нас отображение данных в режиме, близком к реальному времени, для источников Mongo», — говорит Сесили. В общей сложности слой CDC содержит 8,48 миллиарда строк в 1550 таблицах, что составляет примерно 953 ГиБ в сжатом виде.
В старых пакетных кластерах каждое поле MongoDB приходилось извлекать из строкового столбца с помощью вызова JSONExtract. «Это многословно», — говорит Сесили, — «и дорого парсить каждое поле, которое вам нужно для каждой строки данных, которую вы обрабатываете».
Нативный тип данных JSON в ClickHouse заменил все это простой точечной нотацией. Поле — это просто doc.companyUuid::String или doc.homeAddress.city::String, проникающее в документ так глубоко, как нужно, без необходимости использования функции извлечения. «Приятно не вставлять JSONExtract и JSONValue каждый раз», — говорит Сесили.
Поскольку используется схема при чтении (schema-on-read), добавление нового поля в MongoDB требует лишь изменения одной строки SQL в нижестоящей таблице ReplacingMergeTree. «Здесь нет DDL, нет реестра схем, — говорит Сесили. — Нам не нужно выполнять обратное заполнение (backfill) самого ClickPipe, потому что все необходимые данные уже существуют в этом единственном поле документа». Вложенные массивы поступают как массивы динамических значений, которые отлично работают с функциями ClickHouse для массивов (arrayMap, arrayJoin, arrayFirst, arrayLast).
Самое важное, что ClickHouse хранит JSON как столбчатую подструктуру внутри себя, а не выполняет повторный разбор строки при каждом чтении. «Это значительное преимущество при масштабировании, — отмечает Сесили. — Это экономит нам огромное количество ресурсов как процессора, так и памяти».
«Сердце архитектуры» заключается в том, как происходит трансформация. Каждое материализованное представление, расположенное после источника CDC, срабатывает в тот момент, когда ClickPipes записывает пакет данных в исходную таблицу. «Это похоже на каскад, — говорит Сесили. — Вы вносите изменения в одно, и они каскадно переходят к следующему».
Fountain запускает более 100 моделей в каждой из своих 15 сред таким образом, кодируя их в dbt и встраивая напрямую в ClickHouse. Большинство из них попадает в ReplacingMergeTree (или обычный MergeTree для неизменяемых записей, таких как журналы переходов), при этом трансформация намеренно остается поверхностной, чтобы запросы выполнялись быстро. «Здесь нет Dagster, нет Airflow, нет cron, — говорит Сесили. — Настроил и забыл. Обновление — это свойство движка хранения».
Трансформация без оркестрации: ClickPipes записывает пакет в исходную таблицу CDC, срабатывает материализованное представление, и дедуплицированные строки попадают в ReplacingMergeTree без участия планировщика.
Эта модель вставки также обеспечила команде «самый большой выигрыш в производительности». Чтобы ответить на распространенный вопрос («Сколько времени кандидат провел на определенном этапе?»), им нужны были предыдущие и следующие метки времени для каждого перехода. Вместо того чтобы выполнять эту оконную функцию по всей таблице во время запроса, они перенесли эту работу в материализованное представление, объединив функцию lagInFrame в ClickHouse с ASOF JOIN. lagInFrame обрабатывает записи в текущем пакете, ASOF JOIN обращается к уже сохраненным данным, а coalesce берет значение из пакета, если оно существует, в противном случае возвращаясь к сохраненному.
Вычисление этого значения один раз при вставке в таблицу переходов из 838 миллионов строк снизило потребление памяти на запрос с 778 МиБ до 153 МиБ, что составляет сокращение на 80%. В обобщенном виде для разных типов запросов этот же паттерн дает экономию памяти от 60% до 98%. «Перенесите ресурсоемкие вычисления в инкрементальное материализованное представление, — резюмирует Сесили, — и пусть ваш запрос остается легким».
Последняя часть головоломки была, пожалуй, самой необычной: убедиться, что LLM сервиса Cue никогда не сможет увидеть или повлиять на модель безопасности. «Мне было очень интересно решать эту задачу», — говорит Сесили.
Как объясняет Сесили, каждый аналитический запрос Cue выполняется от имени сервисного пользователя для каждой среды: «Мы спроектировали их как пустые сосуды, у которых нет абсолютно никаких прав доступа самих по себе». Доступ осуществляется через роль RBAC с версионированием по времени, которая содержит права SELECT, и набор переменных сессии, которые по умолчанию пусты. Бэкенд MCP компании Fountain устанавливает эти переменные в начале каждого запроса, основываясь на том, кто делает запрос и что им разрешено видеть, в то время как политика строк (row policy) в каждой таблице фильтрует данные по ключу арендатора (tenant key).
Аналитика с учетом арендаторов: Cue устанавливает переменные разрешений для каждого вызывающего абонента, роль сервисного пользователя направляет запрос, политики строк фильтруют данные по ключу арендатора, а LLM никогда не узнает о модели безопасности.
Таким образом, безопасность полностью находится на уровне данных, а не в предложении WHERE, которое конструирует модель. «Наша LLM не имеет ни малейшего представления о модели безопасности, — говорит Сесили. — Даже если кто-то попытается применить промпт-инъекцию к нашему агенту, он не сможет слить данные других клиентов или получить доступ к продуктам, которые ему не разрешено видеть, потому что переменные, контролирующие это, находятся на уровне базы данных и задаются нашим MCP полностью вне LLM агента».
И система спроектирована так, чтобы при сбоях оставаться безопасной. Если переменные разрешений отсутствуют или неверны, если роль не применена или новая таблица не включена в конфигурацию RBAC, Cue просто не видит данных, вместо того чтобы видеть лишнее. Как выразилась Сесили: «Это поведение системы, изначально безопасное по своей сути».
Все это существует для поддержки Cue, агентного аналитического и исполнительного уровня Fountain. Как говорит Алекс: «Мы перешли от мониторинга дашбордов, которые агрегировали сигналы, собранные часами или днями ранее, и последующего активного просмотра этих дашбордов для выявления сигналов, к тому, чтобы сделать все это в реальном времени и позволить Cue выявлять эти инсайты и принимать меры».
Сесили добавляет цифры к этой трансформации, отмечая: «Мы перешли от трех часов к менее чем двум минутам, а в реальности для подавляющего большинства запросов это занимает менее секунды в нашем пути реального времени».
В общей сложности система теперь содержит 8,48 миллиарда строк CDC, непрерывно реплицируемых через ClickPipes, и 10,3 миллиарда аналитических строк в 15 средах, обслуживаемых более чем 2000 инкрементальных материализованных представлений. Предварительная материализация оконных функций сократила потребление памяти на 60-98%. И по сравнению со старым пакетным процессом Fountain, новая платформа, построенная на ClickHouse Cloud, обходится примерно на 66% дешевле в эксплуатации.
Создав Cue для клиентов, Алекс говорит, что теперь они планируют «развернуть этот движок внутрь и использовать его для наших команд во Fountain». Используя удаленный MCP ClickHouse, компания предоставит доступ к своей семантической модели реального времени внутренним заинтересованным сторонам через Claude Desktop (упакованный как плагин с навыками), чтобы любой сотрудник Fountain мог запрашивать модель данных напрямую, вместо того чтобы подавать запрос в команду обработки данных. «Это станет трансформационным моментом для наших продуктовых команд, связывая их с нашими данными ближе, чем когда-либо прежде», — говорит он.
То, что начиналось как исправление для конвейера, который не справлялся с нагрузкой, стало фундаментом, на котором начинает строить вся компания. «Наши конвейеры, работающие почти в реальном времени на базе ClickHouse, трансформируют не только работу с персоналом и управление им, — говорит Алекс, — но и то, как мы создаем продукты для дальнейшего обслуживания рядовых сотрудников».
