Fountain создает решения для рядовых сотрудников — работников почасовой оплаты в сферах ритейла, логистики, общественного питания, здравоохранения и гостеприимства, которые составляют большинство рабочей силы в мире. С 2014 года платформа Fountain обработала более 91 миллиона заявлений о приеме на работу и 14 миллионов наймов, а 5 ее продуктов обслуживают клиентов более чем в 75 странах.
Будучи глобальной компанией, обеспечивающей весь цикл найма линейного персонала от подачи заявки до выхода на работу, Fountain функционирует круглосуточно, как и компании (и их сотрудники), которые на нее полагаются. «Линейный персонал не спит, — говорит Алекс Нортон (Alex Norton), руководитель платформы данных в Fountain. — Наши клиенты нанимают, оформляют и составляют графики круглосуточно в тысячах локаций».
Раньше в Fountain полагались на трехчасовые пакетные задания (batch jobs). «Это совершенно не устраивало наших клиентов, которым нужно принимать решения прямо сейчас», — рассказывает Алекс. Поэтому они создали Cue Frontline Superintelligence — свою платформу на базе агентского ИИ, которая управляет операциями на передовой. С помощью Cue менеджер по найму может заметить сигнал в 9:02 утра и принять решение к 9:05.
«Период полураспада отклика кандидата измеряется минутами, а не часами. Переход с трехчасовых обновлений на две минуты или быстрее с помощью ClickPipes стал поистине революционным для нашей клиентской базы». — Алекс Нортон, руководитель платформы данных, Fountain
«Период полураспада отклика кандидата измеряется минутами, а не часами. Переход с трехчасовых обновлений на две минуты или быстрее с помощью ClickPipes стал поистине революционным для нашей клиентской базы».
— Алекс Нортон, руководитель платформы данных, Fountain
На конференции Open House SF 2026 Алекс и старший инженер по аналитике Сесили Стори (Cecily Storey) рассказали о том, как они создали Cue: от прежней многовендорной пакетной архитектуры до оптимизированной системы на базе ClickPipes и ClickHouse Cloud на AWS, и как это помогло им обеспечить запросы менее чем за секунду при снижении затрат примерно на две трети.
Старая аналитическая архитектура Fountain использовала традиционную модель пакетной обработки. Данные поступали из исходных баз данных (13 производственных баз данных Postgres и четырех баз данных MongoDB) через стороннего поставщика репликации в S3 в формате Iceberg и Parquet, а затем в BigQuery и ClickHouse (с использованием функции таблицы s3) для аналитики.
Старая пакетная архитектура Fountain: дорогая, хрупкая, слишком медленная для потребностей фронтлайна
«Это неплохо работало для нашего конвейера с трехчасовым обновлением, — говорит Алекс, — но даже тогда это стало дорогим и хрупким решением». Команда управляла конвейером, охватывающим множество вендоров и облаков; как только в картину добавилась MongoDB, это превратилось в головную боль для небольшой команды по работе с данными Fountain. «На поддержание уходило много времени, а ведь это время мы могли бы потратить на инновации», — отмечает он.
Алекс выделяет пять ограничений, которые в итоге заставили провести редизайн. Первым была актуальность данных: трехчасовой цикл был несовместим с агентами, действующими в течение минут. Вторым была стоимость: один логический переход генерировал четыре отдельных счета: за репликацию, хранение в S3, загрузку в хранилище и аналитические вычисления. «Даже при трехчасовом обновлении расходы выходили из-под контроля», — говорит он.
Третьим фактором была сложность: три поставщика и два промежуточных формата означали расхождение схем (schema drift) на каждом стыке. Четвертым была кардинальность: таблицы размером более 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 для персонала. Каждый документ попадает в один столбец типа native 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, нет реестра схем», — говорит Сесили. — «Нам не нужно выполнять бэкфилл самого ClickPipe, потому что все необходимые нам данные уже существуют в этом единственном поле документа». Вложенные массивы поступают как массивы динамических значений, которые отлично работают с функциями массивов ClickHouse (arrayMap, arrayJoin, arrayFirst, arrayLast).
Самое главное, что ClickHouse хранит JSON внутри себя в виде колончатой подструктуры, а не выполняет синтаксический разбор строки при каждом чтении. «Это значительный выигрыш в масштабе», — говорит Сесили. — «Это экономит нам колоссальный объем ресурсов как по CPU, так и по памяти».
«Сердцем архитектуры» является то, как происходит трансформация. Каждое материализованное представление, расположенное ниже по потоку от источника 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 устанавливает эти переменные в начале каждого запроса в зависимости от того, кто задает вопрос и что ему разрешено видеть, в то время как политика строк на каждой таблице выполняет фильтрацию по ключу тенанта.
Аналитика с изоляцией тенантов: 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, не только трансформируют работу с почасовыми сотрудниками и то, как она управляется», — говорит Алекс, — «но и то, как мы создаем продукты для дальнейшей поддержки работников переднего края».
