8 июня 2026 г.
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
Примечание редактора: Это четвертая статья из серии, посвященной тому, как Palantir адаптирует инфраструктурное программное обеспечение для надежной работы в масштабе.
Ниже представлен гостевой материал для серии Foundations от организации Gotham Core Platform, которая создает и поддерживает основу для критически важных приложений в экосистеме Gotham. В этой статье Кевин Лян, бэкенд-разработчик из Калифорнии, освещает проектные решения и улучшения, внесенные в механизм переиндексации Elasticsearch. Его цель — обеспечить простой в использовании, производительный, надежный и наблюдаемый способ восстановления и перестройки поисковых индексов для бэкенд-приложений. Цель этой статьи двояка: поделиться нашими проектными решениями и выводами с широким техническим сообществом, а также пролить свет на то, как выглядит типичный проект для системного бэкенд-инженера, работающего в Gotham Core Platform в Palantir.
Поиск — один из наиболее часто используемых рабочих процессов в Palantir Gotham. Пользователи постоянно выполняют запросы, фильтруют и анализируют большие наборы данных, чтобы находить сущности, отслеживать связи и собирать аналитику, которая лежит в основе критически важных операционных решений. На любом этапе этого процесса они ожидают, что результаты будут мгновенными, независимо от масштаба или сложности базового графа данных.
Многие из этих поисковых рабочих процессов используют Elasticsearch, распределенный поисково-аналитический движок с открытым исходным кодом, который обеспечивает надежные возможности полнотекстового поиска в масштабе. Ранее мы уже объясняли роль, которую Elasticsearch играет в нашей более широкой экосистеме и архитектуре; подробнее об этом можно прочитать в статье «Защитные базы данных: оптимизация семантики обновления индексов».
Как упоминалось в той статье, большинство приложений Gotham взаимодействуют с Elasticsearch через собственный клиент базы данных, который выступает в качестве уровня между бэкенд-сервисами и инфраструктурой хранения. На верхнем уровне этот сервис напоминает хранилище документов и обеспечивает:
- Строго согласованные CRUD-операции «ключ-значение», поддерживаемые транзакционной базой данных, которая остается авторитетным источником истины
- Полнотекстовый поиск по полям документов через Elasticsearch, который функционирует как «внешний» вторичный индекс
- Первоклассное обеспечение политик безопасности, встроенное в основные пути чтения, поиска и записи, а не добавленное как второстепенная функция
В дальнейшем мы будем называть этот внутренний клиент базы данных «хранилищем документов». Хранилище документов обслуживает множество различных клиентов, каждый из которых имеет свою группу схем (аналог таблиц базы данных). Каждая схема объявляет имена полей, типы, безопасность, структурную компоновку документов и, что критически важно, нужно ли индексировать поле в Elasticsearch и как именно, с помощью так называемых маппингов (mappings). Некоторые схемы вообще не индексируются; другие содержат расширенные маппинги, обеспечивающие фасетный поиск, геозапросы и фильтры по диапазону дат. Вы можете прочитать о маппингах Elasticsearch в их официальной документации здесь.
Поток данных от различных бэкендов приложений к базе данных, Elasticsearch и сервису аутентификации проиллюстрирован на следующей схеме, которая расширяет диаграмму, использованную нами в статье «Защитные базы данных».
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
Хотя группа Foundations в Palantir отвечает за эксплуатацию и предоставление кластеров Elasticsearch для нашего разнообразного парка развертываний, сервисы, взаимодействующие с этой инфраструктурой, также несут ответственность за эффективное и ответственное использование кластеров, а также за обслуживание собственных индексов.
Также бывают случаи, когда сервису необходимо восстановить или перестроить индексы Elasticsearch. Когда индекс устаревает или приходит в несогласованное состояние из-за изменений маппинга или операционных сбоев, процессом исправления часто становится так называемая переиндексация.
- Например, логистическому приложению, которому нужно добавить новое поле для поиска данных о сбоях в цепочке поставок или которое должно поддерживать дополнительное поле метаданных безопасности в политике доступа, потребуется переиндексация.
- Переиндексация также может применяться на уровне кластера. Например, при миграции с Elasticsearch 8.x на 9.x мы предпочитаем переиндексацию обновлению «на месте» (in-place upgrade), поскольку это позволяет нам быстро откатиться назад, если что-то пойдет не так.
В этой статье обсуждается проектирование и эволюция механизма переиндексации Elasticsearch, встроенного в хранилище документов, который позволил нам выполнять переиндексацию надежно, производительно, без перевода сервиса в офлайн и без необходимости чрезмерного человеческого контроля для любого количества клиентских приложений.
Что нам нужно
Как упоминалось ранее, переиндексация может потребоваться по нескольким причинам. Схемы и их маппинги развиваются вместе с нашими продуктами, настройки индексов (включая количество шардов) могут меняться, а индексы могут повреждаться из-за непредвиденных сбоев или ошибок в программном обеспечении. Когда это происходит, необходимо создать новый индекс с правильными маппингами и обновленными настройками, заполнить его данными и заменить старый. Кроме того, когда нам нужно мигрировать между кластерами, например, при обновлении версий (например, с Elasticsearch 8.x на 9.x) или при переходе на отдельный кластер вместо общего с другими сервисами, когда пропускная способность это оправдывает, нам необходимо выполнить межкластерную переиндексацию.
Elasticsearch действительно предлагает API _reindex, который копирует документы из одного индекса в другой внутри одного кластера, а также предлагает возможность выполнить переиндексацию из удаленного кластера через API. Однако, поскольку база данных является основным источником истины со строгой согласованностью в нашей архитектуре, переиндексация, которую мы проводим, будет повторно наполнять новый индекс документами, загруженными из базы данных. Это означает, что наш сервис хранилища документов должен будет координировать и контролировать весь процесс переиндексации, а не просто отправлять команду и позволять кластеру Elasticsearch делать остальное.
Требования к нашему механизму переиндексации Elasticsearch:
1. Реконструкция с учетом схемы: Система должна знать, как конструировать индексы для схемы каждого клиента — типы полей, анализаторы, количество шардов и т. д.
2. Минимум ручных действий: Операторы не должны сопровождать каждую схему через весь процесс и переводить ее с этапа на этап. Управление переиндексацией в сотнях развертываний, каждое из которых имеет более 100 схем, — это слишком большой объем работы для выполнения вручную.
3. Автоматическое обнаружение и исправление несоответствий: Система должна уметь обнаруживать, когда для конкретной схемы требуется переиндексация, и выполнять ее автономно.
4. Ограниченное использование ресурсов: Переиндексация не должна приводить к падению сервера или препятствовать обслуживанию API. Она не может монополизировать память, исчерпывать пул потоков или переполнять пул соединений с базой данных.
5. Онлайн-переиндексация в реальном времени: Сервис обслуживает реальный трафик все время, включая поиск. В контексте нашего логистического приложения существующие функции поиска должны продолжать работать.
Наш первый механизм переиндексации
С учетом этих требований мы реализовали первый механизм реиндексации Elasticsearch в хранилище документов. На следующей диаграмме показан процесс реиндексации конкретной схемы.
Нажмите клавишу ввода или щелкните, чтобы просмотреть изображение в полном размере
Теневой индекс
Наше примерное приложение должно продолжать обрабатывать поисковые запросы во время и после реиндексации. Ключом к поддержанию работоспособности во время реиндексации является теневой индекс — отдельный физический индекс в том же кластере Elasticsearch для той же схемы с требуемыми маппингами и настройками, который получает все запросы индексации / деиндексации от клиентского API хранилища документов, одновременно наполняясь данными механизом реиндексации. Что важно, теневой индекс пока не обслуживает запросы на чтение. Механизм реиндексации создает теневой индекс с суффиксом _b, если текущий индекс заканчивается на _a (и наоборот), с предполагаемым маппингом и настройками, а также заполняет его документами из базы данных. По завершении механизм сделает теневой индекс основным и удалит предыдущий индекс.
Поиск всегда обслуживается из основного индекса, а запросы на запись от API дублируются как в основной, так и в теневой индекс, чтобы не потерять последние изменения. Мы используем (version_type.external_gte) для разрешения конфликтов одновременных записей индексов из API и механизма реиндексации.
Что касается маршрутизации запросов на чтение и запись, вместо прямого обращения к именам физических индексов мы используем псевдонимы индексов Elasticsearch в путях кода чтения, записи и реиндексации. Маппинги из псевдонимов в физические индексы настраиваются или изменяются только во время создания индекса и после операций реиндексации.
В следующей таблице показаны изменения псевдонимов с участием теневого индекса (_b) и существующего основного индекса (_a) на ключевых этапах реиндексации. В этом примере _b был создан и помечен псевдонимом реиндексации в начале процесса. За _a остался псевдоним чтения, в то время как псевдоним записи был удален. Когда фаза заполнения данных реиндексации завершена, _b становится основным, принимая на себя псевдонимы чтения и записи, а _a удаляется.
Нажмите клавишу ввода или щелкните, чтобы просмотреть изображение в полном размере
Оркестрация реиндексации
Механизм реиндексации поддерживает таблицу метаданных индекса на уровне схемы для отслеживания информации, связанной с выполнением заданий реиндексации (например, когда схема в последний раз запускалась/успешно завершалась/завершалась с ошибкой, поставлена ли схема в очередь, выполняется ли реиндексация, прерывается ли она или работы нет). Метаданные индекса на уровне схемы являются единственным источником достоверной информации для координации внутри механизма реиндексации.
Работая в качестве фоновой задачи на сервере, механизм реиндексации периодически сканирует все определения схем, сравнивает метаданные, сохраненные в базе данных, с фактическим состоянием индекса в кластере Elasticsearch и определяет, какие схемы требуют внимания: продолжение текущей реиндексации, запуск следующей из очереди или попытка восстановления несогласованного индекса схемы перед постановкой его в очередь на полную реиндексацию, если восстановления оказалось недостаточно.
Помимо проактивной реиндексации для схем, индексы которых требуют восстановления, отдельная фоновая задача, обрабатывающая запросы из конфигурации, и несколько конечных точек административного API позволяют операторам и клиентам (включая наше логистическое приложение из примера) запрашивать и прерывать реиндексацию.
Независимость от кластера
Ключевым архитектурным выбором для службы хранилища документов является независимость от кластеров. Кластеры Elasticsearch обнаруживаются и сопоставляются с логическими компонентами в коде. В большинстве случаев будет один кластер, но во время межкластерной реиндексации будет подключен дополнительный миграционный кластер, распознаваемый как таковой. Через динамический уровень чтение обслуживается только из основного кластера, в то время как запись (включая реиндексацию) распределяется по всем подключенным кластерам, поддерживая как однокластерные, так и межкластерные операции с минимальным количеством дополнительного кода.
Получайте истории Palantir на свою почту
Присоединяйтесь к Medium бесплатно, чтобы получать обновления от этого автора.
Запомнить меня для более быстрого входа
Благодаря этому базовому дизайну мы можем выполнять реиндексацию любых схем в хранилище документов. Наше логистическое примерное приложение может включить реиндексацию в обновление своей схемы и привязать новую функцию поиска к завершению реиндексации.
Эволюция механизма реиндексации
По мере расширения функционала и использования наших продуктов, а также эволюции нашей инфраструктуры хранения данных, к механизму реиндексации предъявляются все более высокие требования. Полное пересоздание индекса Elasticsearch с миллионами документов, пока служба хранилища документов продолжает обрабатывать реальный трафик, представляет собой постоянно усложняющуюся задачу. По мере добавления новых функций и повышения стабильности реиндексация становится все более частой и критически важной. В ответ на это мы постоянно совершенствуем механизм реиндексации для повышения производительности, стабильности и наблюдаемости. Здесь мы выделяем несколько заметных улучшений.
Параллелизация и асинхронная обработка
Параллелизация была заложена в механизм реиндексации на ранних этапах, поскольку как чтение страниц документов из базы данных, так и их индексация в поисковой системе связаны со значительным ожиданием ввода-вывода. Решением является параллельный диспетчер задач на базе настраиваемого пула потоков и ограниченной очереди этапа подготовки. Потоки-воркеры динамически принимают одну из двух ролей на каждой итерации: поток, захватывающий блокировку постраничного вывода, извлекает следующую порцию записей в очередь, в то время как потоки, обнаружившие блокировку занятой, забирают уже поставленную в очередь порцию и выполняют индексацию. Отдельный фоновый поток периодически фиксирует прогресс, записывая позицию самой ранней незавершенной партии, что позволяет возобновить работу с того места, где она была прервана после сбоя. Такая архитектура создает конвейер, в котором одновременно обрабатывается несколько партий — одни читаются из базы данных, другие индексируются — без необходимости явного назначения ролей или блокировки цикла реиндексации.
На приведенной ниже схеме показана структура параллельного диспетчера задач.
Нажмите клавишу ввода или щелкните, чтобы просмотреть изображение в полном размере
Ограничение размера пакетов
Чтобы предотвратить падение хранилища документов из-за реиндексации, мы добавили множество возможностей ограничения частоты и размера пакетов вокруг механизма реиндексации. Один запуск реиндексации ограничен по трем измерениям:
- Количество документов в пакете: ограничивает количество объектов, извлекаемых из базы данных за одну транзакцию, поддерживая время удержания соединения с базой данных коротким.
- Память на пакет: мягкое ограничение объема памяти, занимаемого одним пакетом, предотвращающее неожиданные скачки памяти, вызванные большими документами при жестком лимите размера пакета.
- Всего пакетов за запуск: ограничивает количество пакетов, которые обработает один вызов цикла реиндексации перед приостановкой. В сочетании с настраиваемым интервалом отдыха между запусками это создает естественные паузы для потоков API и сборщика мусора.
Эти три параметра взаимодействуют друг с другом, не позволяя ни одному из измерений стать узким горлышком. Схема с большим количеством мелких документов упирается в лимит количества документов; схема с меньшим количеством, но более крупных документов упирается в лимит памяти; а лимит пакетов за запуск гарантирует, что механизм реиндексации будет периодически останавливаться независимо от этого.
Устойчивость к сбоям
Представьте, что сервер хранилища документов аварийно завершает работу в процессе выполнения операции, изменяющей индексы и псевдонимы — например, во время запуска или завершения переиндексации для нашего логистического приложения. Индексы могут остаться в поврежденном состоянии, из которого невозможно детерминированное восстановление без перезапуска всей переиндексации с нуля. Чтобы защититься от этого, каждая операция жизненного цикла индекса моделируется как детализированный конечный автомат: перед отправкой любой мутации в поисковый движок текущее состояние сохраняется в базе данных, а каждая операция поискового движка проектируется как идемпотентная. Если сервер аварийно завершает работу в любой момент, он просто возобновляет выполнение с последнего сохраненного состояния и безопасно повторяет ожидающую операцию.
Состояния, проиллюстрированные ниже, сохраняются в отдельной таблице метаданных для каждого кластера и каждой схемы, где мы также сохраняем ключевые параметры, такие как текущий первичный индекс, для обеспечения устойчивости к сбоям.
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
Логи? Метрики? Или диагностика? Да.
Когда фоновый процесс в фоновом режиме перестраивает индексы, содержащие миллионы документов, наблюдаемость становится обязательным условием. Разнообразные и зачастую ограниченные среды, в которых развертываются продукты Palantir, дополнительно означают, что жизнеспособность и доступ к различным формам наблюдаемости сильно различаются в зависимости от развертывания. Вы не сможете добавить наблюдаемость, которой вам не хватало, когда что-то пойдет не так. Не говоря уже о том, что у разных форм наблюдаемости есть свои плюсы и минусы, и мы хотели бы получить лучшее из всех миров.
Логи:
- Плюсы: показывают снимки состояния с временными метками и богатыми параметрами, отлично подходят для отслеживания точных шагов и изучения подробных состояний на каждом этапе.
- Минусы: могут быть слишком навязчивыми и занимать чрезмерное место на диске, если параметры слишком информативны; хотя логи полезны для расследования постфактум и нам нужны исчерпывающие логи во время анализа первопричин, большую часть времени логи и их параметры просто не используются.
Метрики:
- Плюсы: идеальный, легкий инструмент для отслеживания изменений состояний и прогресса с течением времени, который можно превратить в удобные визуализации на дашбордах для быстрого сбора информации и агрегированного анализа.
- Минусы: не содержат дополнительной информации, кроме самих временных рядов и тегов, т.е. нет дополнительных параметров.
Диагностика (отчеты по запросу, создаваемые однократно, часто потребляемые в Palantir Apollo):
- Плюсы: могут быть настолько подробными, насколько нам нужно (в разумных пределах, конечно), без необходимости беспокоиться о спаме или месте на диске, учитывая, что они создаются по запросу.
- Минусы: часто представляют собой снимок (если они специально не спроектированы для пересчета исторических событий) на момент запроса, что делает их менее полезными для анализа постфактум.
В нашем случае мы решили внедрить все три доступные нам формы наблюдаемости, что оказалось чрезвычайно ценным.
Обработка межкластерной переиндексации
Вспомните из наших предыдущих примеров, что переиндексация может быть запущена по причинам, выходящим за рамки изменений на уровне приложений. Межкластерная миграция — перемещение поискового трафика сервиса из одного кластера Elasticsearch в другой без простоя — это реальность жизни на крупномасштабной платформе. Например, если мы хотим мигрировать с Elasticsearch 8.x на 9.x, сохраняя при этом возможность отката в любой момент, нам нужно будет реализовать миграцию с помощью переиндексации.
В конструкции машины переиндексации, которую мы обсуждали до сих пор и которая направлена на восстановление первичного кластера Elasticsearch, обслуживающего запросы, мы создаем новый индекс в качестве теневого индекса на том же кластере, который затем перестраивается из первичного хранилища. Когда заполнение завершено, теневой индекс повышается до уровня поискового. Хотя концептуально это похоже на обычную переиндексацию, межкластерная переиндексация требует немного другого подхода. В частности, нам нужно убедиться, что новый индекс находится на другом кластере, отличном от того, где размещен старый индекс, и пропустить удаление старых индексов после завершения переиндексации, так как на новом кластере нечего удалять, а мы хотим сохранить индексы на старом кластере на случай, если нам понадобится откат.
Отдельная машина переиндексации для миграции
Мы решили разделить две машины переиндексации, каждая из которых управляет переиндексацией на основе метаданных, привязанных к соответствующему кластеру Elasticsearch. Основная машина переиндексации, которую мы рассмотрели в этой статье, работает с основным кластером и служит для восстановления активных индексов, обрабатывающих API-запросы. Новая машина переиндексации для миграции, с другой стороны, заполняет кластер миграции и готовит его к тому, чтобы стать новым основным кластером. Создание двух отдельных машин переиндексации упрощает конфигурацию, управление метаданными, читаемость кода и наблюдаемость по сравнению с одной машиной переиндексации, заполненной логикой ветвления, специфичной для кластера. Каждая машина переиндексации будет иметь свою собственную конфигурацию: количество потоков, размеры пакетов, лимиты памяти, интервал расписания и т.д., и будет работать как независимая фоновая задача, работая только со своим соответствующим кластером, а не со всеми подключенными кластерами.
Каждая машина переиндексации применяет различные эволюции индексов и псевдонимов, адаптированные к их соответствующему варианту использования:
Эволюция индекса и псевдонима на основной машине переиндексации (как и раньше)
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
Эволюция индекса и псевдонима на машине переиндексации миграции
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
На следующей диаграмме показано сравнение активных индексов на соответствующих кластерах при переиндексации для основного кластера и при проведении межкластерной переиндексации для целей миграции.
Нажмите Enter или кликните, чтобы просмотреть изображение в полном размере
Рим строился не один день
На протяжении многих лет многие инженеры Palantir работали над поддержкой первоклассного опыта поиска, внося множество улучшений в механизм переиндексации в сервисе хранилища документов Gotham. Постоянные знания, полученные как с инженерной, так и с операционной сторон, продолжают стимулировать улучшения во всем аппарате переиндексации Elasticsearch. Многие из тех же знаний, касающиеся наблюдаемости и все более проактивных модальностей поддержки, будут определять дизайн будущих частей программного обеспечения — в рамках разработок Foundry, AIP, Gotham и Apollo — которые взаимодействуют с уровнями инфраструктуры Palantir. Ни один продукт никогда не достигает совершенства, но в Palantir мы стремимся постоянно учиться на каждом вызове и операционном результате, используя эти идеи как топливо для дальнейшего совершенствования наших продуктов. Наше обязательство заключается не только в предоставлении мощных возможностей, но и в обеспечении высочайшего уровня стабильности и надежности для наших пользователей.
Если это звучит как тот тип проекта и влияния, который вас интересует, ознакомьтесь с нашими открытыми вакансиями сегодня: https://www.palantir.com/careers/open-positions/
