Palantir Foundry против Snowflake: реальный сигнал к покупке для технических директоров

Главный вопрос, который каждый руководитель платформы, изучающий предложение по Palantir Foundry, должен задать своему финансовому директору на этой неделе, — не в том, быстрее ли демонстрации пайплайнов. Вопрос в том, есть ли у организации просчитанная альтернатива в виде Databricks или Snowflake, лежащая в папке закупок. Без такой альтернативы годовой счёт может оказаться в два-три раза выше, чем у коллег за аналогичное развёртывание.

Рассказ от первого лица инженера по данным, набившего руку на AWS, Azure и Snowflake, а затем прошедшего буткемп по Foundry, стоит прочитать именно потому, что он выделяет две переменные, которые действительно определяют решение о покупке: какой процент ваших пользователей умеет писать на SQL и с каким объёмом переговорного ресурса вы входите в сделку. Всё остальное — шум.

Ключевые детали

В материале для InfoWorld Сашанк Сиваkоти описывает обучающий буткемп по Palantir Foundry, в ходе которого построение пайплайна, принимавшего данные из нескольких источников, применявшего трансформации и открывавшего результат бизнес-пользователям, заняло всего несколько часов. Точка сравнения: на стандартном стеке AWS или Snowflake с dbt и слоем оркестрации аналогичная настройка обычно занимает полный спринт небольшой команды. Автор отдаёт должное Pipeline Builder в Foundry за сокращение накладных расходов на координацию между инструментами, а также онтологической модели — описанной как общий семантический слой, — которая делает самостоятельный доступ к данным скорее правилом, чем индивидуальным инженерным проектом.

Именно структура ценообразования делает управленческое решение более острым. Palantir не публикует прейскурантные цены. Foundry использует лицензионную модель на основе ядер: оплата привязана к вычислительной мощности (серверным ядрам), выделенной для платформы, а не к числу пользовательских мест. Лицензии на основе ядер стартуют примерно с 66 000 фунтов за серверное ядро в год без дополнительных поюзерных сборов. Лицензии на конкретные сценарии использования, включающие внедрение и поддержку, начинаются от 250 000 фунтов на начальном уровне и существенно масштабируются в зависимости от сложности данных, пользовательской базы и операционного охвата. Всё согласовывается в переговорах.

Сиваkоти ссылается на консалтинговый анализ в сфере закупок от Redress Compliance, охватывающий переговоры по Palantir Foundry в 2024–2025 годах. Выяснилось, что годовые платформенные сборы для сопоставимых среднемасштабных развёртываний варьировались в два-три раза исключительно в зависимости от переговорной позиции. Его вывод: основной переговорный ресурс даёт наличие правдоподобной просчитанной альтернативы — как правило, Databricks или Snowflake, — а организации без таковой склонны платить значительно больше за то же самое развёртывание. Он также отмечает, что большинство материалов о Foundry в открытом доступе — это либо маркетинг Palantir, либо тексты глубоко погружённых практиков, именно поэтому взгляд свежего человека так важен.

Почему это важно для команд по работе с данными

Ключевая идея, скрытая в рассказе Сиваkоти, вовсе не о Foundry. Она о том, как оцениваются решения о выборе платформы. Большинство технических директоров сравнивают платформы данных по производительности пайплайнов, стоимости хранилища за запрос и совместимости инструмента с существующим CI/CD. Это метрики, ориентированные на инженеров. Сиваkоти утверждает, что правильным критерием оценки является доля людей, которым нужно работать с данными и которые реально умеют писать на SQL. В организациях, где более половины бизнес-аналитиков и операционных пользователей не умеют писать код, инженерная нагрузка на построение самостоятельного доступа к данным на традиционном стеке становится повторяющимися и накапливающимися затратами.

Переформулируйте это как вопрос найма. Стек Snowflake плюс dbt предполагает, что вы можете укомплектовать и удержать команду инженеров данных, способную непрерывно строить и поддерживать семантические слои, спецификации представлений и BI-абстракции для нетехнических пользователей. На сложном рынке найма это допущение несёт большую нагрузку. Если соотношение аналитиков к инженерам составляет 20:1 и растёт, предельная стоимость каждого нового дашборда с самостоятельным доступом на традиционном стеке — это послеобеденное время старшего инженера. И это время накапливается.

Онтологическая модель Foundry меняет трудозатраты, вынося семантический слой на передний план как примитив платформы, а не нечто, что команда собирает самостоятельно. Компромисс честный, и Сиваkоти его называет: сильная, хорошо укомплектованная команда инженеров данных могла бы построить лучший, более адаптированный слой самостоятельного доступа на Snowflake за то же время, которое уходит на освоение онтологии Foundry. Так что решение — не о технологическом превосходстве. Это вопрос «строить или купить» применительно к семантическому слою, соотнесённый с текущей и прогнозируемой численностью инженерного персонала. Команды, способные дёшево нанимать и удерживать платформенных инженеров, должны строить. Те, кто не может, должны как минимум всерьёз рассмотреть вариант покупки.

Отраслевые последствия

Для регулируемых вертикалей — операторов iGaming, финтех-платформ, компаний ad-tech с жёсткой комплаенс-отчётностью — расчёт склоняется в определённую сторону. Это организации, в которых нетехническое население, работающее с данными, велико по регуляторной необходимости: комплаенс-офицеры, риск-аналитики, AML-ревьюеры, руководители продуктового маркетинга, выгружающие когортные отчёты для регуляторов. Очень немногие из них свободно пишут на SQL. Очень немногие из них должны это уметь.

Именно такой профиль аудитории Сиваkоти определяет как целевую нишу Foundry. Именно эту аудиторию традиционные стеки плохо обслуживают без значительной индивидуальной доработки. Финтех-платформа с отделом комплаенса и операций на 400 человек будет тратить реальные инженерные циклы на построение и поддержку самостоятельной отчётности на Snowflake. Превысят ли эти годовые затраты стоимость согласованной лицензии Foundry на основе ядер — реальный расчёт в таблице, а не философский вопрос. При примерно 66 000 фунтах за серверное ядро в год без поюзерных сборов экономика единицы может выглядеть привлекательно, как только число нетехнических пользователей пересекает определённый порог, — ведь вы не платите за добавление пользователей.

Подводный камень, и весьма крупный, — привязка к поставщику. Лицензирование на основе ядер плюс проприетарная онтологическая модель плюс согласованный контракт без публичного прейскуранта равно максимальные издержки переключения. Вопрос главного юрисконсульта, а не вице-президента по инженерии, — как выглядит клаузула о выходе на третий год. Моя позиция: для организаций, чья модель данных действительно стабильна и чьё регуляторное воздействие хорошо понятно, привязка является справедливым обменом на продуктивность. Для организаций, которые ещё разбираются в том, что означают их данные, фиксация общего семантического слоя до того, как семантика устоялась, обходится дорого.

За чем следить

В ближайшие два квартала важны три сигнала. Первый: продолжат ли Databricks и Snowflake агрессивно инвестировать в собственный семантический слой и инструменты самостоятельного доступа, чтобы закрыть онтологический разрыв. Если да, дифференциация Foundry сужается до корпоративного сегмента, где услуги по внедрению важнее функций платформы. Второй: будут ли консалтинговые данные в сфере закупок по-прежнему показывать двух-трёхкратный разброс цен в зависимости от переговорной позиции. Такой разброс нетипичен для зрелых категорий корпоративного ПО и свидетельствует о том, что ценовая власть Palantir по-прежнему носит ситуативный характер. Третий: сигналы рынка найма. Если зарплаты старших инженеров платформ данных продолжат расти быстрее общей инфляции в ПО, аргумент в пользу покупки платформ класса Foundry усилится исключительно за счёт трудового арбитража.

Разговор с финансовым директором, который нужно провести в этом квартале, неброский, но принципиальный: какова полная годовая стоимость ФОТ инженеров данных, сейчас занятых самостоятельным доступом для нетехнических сотрудников, и как она соотносится с просчитанным контрактом на Foundry при наличии реальной альтернативы на руках? Если никто в финансовом подразделении не может ответить на этот вопрос, решение о платформе принимается на интуиции.

Ключевые выводы

• Оценивайте Foundry по уровню SQL-грамотности, а не по бенчмаркам пайплайнов. Если более половины сотрудников, работающих с данными, не умеют писать на SQL, математика самостоятельного доступа существенно меняется.
• Входите в переговоры с просчитанной альтернативой в виде Databricks или Snowflake. Анализ закупок показывает двух-трёхкратный разброс цен исключительно в зависимости от переговорной позиции.
• Моделируйте экономику единицы через ядра, а не через места. При примерно 66 000 фунтах за серверное ядро в год без поюзерных сборов Foundry выгоден для развёртываний с большим числом нетехнических пользователей.
• Рассматривайте онтологическую модель как решение «строить или купить» применительно к семантическому слою. Сильные платформенные команды могут воспроизвести его на Snowflake плюс dbt; недоукомплектованные — нет.
• Привлекайте главного юрисконсульта к обсуждению клаузул о выходе. Проприетарная онтология плюс согласованное ценообразование плюс лицензирование на основе ядер к третьему году равно максимальные издержки переключения.