Имея более миллиарда пользователей по всему миру и тысячи взаимодействующих сервисов, одна загрузка ленты или поиск вакансий в LinkedIn затрагивает десятки бэкенд-систем. Когда одна из них замедляется, поиск виновника означает необходимость видеть, что происходит внутри каждой из них.
Эта задача ложится на плечи команды наблюдаемости (observability) компании, которая владеет всем стеком, позволяющим измерять работу платформы: от хостов, контейнеров, сервисов и хранилищ до онлайн-, nearline- и офлайн-рабочих процессов, мониторинга реальных пользователей, а также уровней сбора данных, оповещений, сортировки, дежурств и визуализации, построенных поверх всего этого. Этот стек охватывает все виды сигналов наблюдаемости, включая метрики, логи, трассировки, события, профили и исключения.
Путь LinkedIn в использовании ClickHouse начался два года назад с распределенной трассировки. Как подробно рассказал Арун Гупта на встрече ClickHouse в Сан-Франциско в апреле 2026 года, команда внедрила его в производство в трех центрах обработки данных, создав систему, которая обрабатывает около 800 миллиардов спанов в день и предоставляет инженерам поверхность для устранения неполадок практически в реальном времени. «Это только начало для ClickHouse в LinkedIn», — сказал тогда Арун.
На конференции Open House SF 2026 штатный инженер-программист Джейкоб Зелек продолжил эту тему, поделившись следующим шагом в развитии наблюдаемости LinkedIn: как команда консолидировала устаревшую систему метаданных метрик в единый индекс ClickHouse, что привело к созданию системы, которая обходится дешевле в эксплуатации и отвечает на вопросы, с которыми старый стек не справлялся, при этом имея большой потенциал для роста.
В 2024 году Арун и его команда разворачивали систему распределенной трассировки на базе OpenTelemetry, которая отслеживает запрос от начала до конца: от приложения пользователя до каждого бэкенд-сервиса, с которым он взаимодействует. Даже при 1% head-сэмплировании эта система генерирует около 0,8 триллиона спанов и 200 ТБ несжатых данных в день. Им требовалось хранилище, которое могло бы справляться с таким объемом на стороне записи и оставаться быстрым на стороне чтения, поскольку, как выразился Арун: «Когда кто-то видит проблему или инженер отлаживает добавляемую функцию, он должен иметь возможность использовать наши приложения и очень быстро видеть, что показывают трассировки».
Среди целей для системы было завершение сквозного сбора данных менее чем за 10 секунд, получение списка трассировок за двухчасовой интервал менее чем за 2,5 секунды на уровне P99, а получение полной трассировки по ID — за 750 миллисекунд или быстрее. Они также хотели политику хранения данных на 7 дней, многоуровневое хранение, настраиваемые индексы и изоляцию рабочих нагрузок запросов. Наконец, любое выбранное ими решение должно было поддерживать KQL, один из предпочтительных языков запросов в LinkedIn.
Сегодня развертывание охватывает три центра обработки данных. В каждом из них есть свой кластер ClickHouse из 22 шардов, получающий данные через PubSub и уровень сборщиков. Команда использует схему red-black: запись идет в два кластера, чтение — из одного, при этом второй готов взять на себя нагрузку в случае проблем с первым, а третий занимается валидацией. Схема данных плоская, атрибуты спанов передаются вместе с ними, и используется 3-кратная локальная репликация поверх распределенной таблицы. Сжатие составляет около 5x. Каждый узел принимает 350 000 спанов в секунду в установившемся режиме, с пиками до 1,2 миллиона при максимальной нагрузке.
PubSub в каждом центре обработки данных передает данные сборщикам во всех трех, при этом один кластер выделен для валидации.
Команда переупорядочила таблицу, чтобы поместить столбцы с низкой кардинальностью в начало, перераспределила данные по полю, по которому они фактически выполняют запросы, и ужесточила показатели ложноположительных срабатываний фильтров Блума для столбцов, где это было сделать недорого, что позволило выполнять запросы менее чем за две секунды. «Это было для нас весьма существенно», — говорит Арун.
Не менее важно и то, что проект позволил внедрить ClickHouse в производство в масштабе и помог нескольким командам освоиться с его использованием. Этот импульс оказался ключевым, когда команда наблюдаемости LinkedIn расширила его применение с распределенной трассировки до обнаружения метрик и аналитики.
Много лет назад LinkedIn полагалась на устаревшую систему логирования и построения графиков временных рядов под названием RRDtool. Однако введенное ею соглашение об именовании так и осталось, и при масштабах LinkedIn оно сохранилось.
Сегодня на эту метрику по-прежнему ссылается RRD — единая строка, объединяющая от двух до шести стандартизированных измерений (например, «my-server/responses.status.200.rrd»). Изначально пользователи могли нацеливаться на одну метрику, но в какой-то момент команда внедрила возможность применять регулярные выражения ко многим из них, чтобы генерировать несколько рядов на одном графике или отдельный график для каждого совпадения. «Вы можете понять, почему это начинает становиться проблемой», — говорит Джейкоб.
Эта проблема усугубляется масштабами, в которых работает LinkedIn. В компании более 13 миллиардов метрик, на которые до сих пор ссылаются с использованием семантики RRD, с ежедневной текучестью около 30%. Миллионы графиков и оповещений определены таким образом, и десятки инструментов и сервисов все еще запрашивают метрики RRD. Тем временем количество метрик продолжает расти, а новые инструменты, сервисы и варианты использования продолжают добавляться.
Задача для команды наблюдаемости LinkedIn заключалась в том, чтобы позволить людям обнаруживать и анализировать все это. Например, инженеры могут захотеть узнать, какие хосты выдают заданную метрику, какие RRD выдает сервис, какие метрики соответствуют шаблону во всех сервисах и как меняется количество уникальных метрик для отслеживания роста. «Большая проблема, — говорит Джейкоб, — заключается в том, что нам нужно, чтобы люди могли запрашивать эти данные, пока мы наконец не сможем перевести всех на другую систему».
Старый стек вырос в три отдельных сервиса за единым шлюзом. Когда Джейкоб пришел в команду, там был кастомный поисковый индекс в оперативной памяти и кастомное хранилище «ключ-значение» в оперативной памяти. Позже он внедрил Elasticsearch в надежде, что он сможет обслуживать все запросы и позволит им удалить остальные сервисы. «К сожалению, он стал еще одним сервисом для обслуживания этих запросов», — говорит он, отмечая, что Elasticsearch не очень хорошо справлялся с крупными агрегациями, а возврат больших наборов результатов означал их сериализацию в оперативной памяти.
До появления ClickHouse запросы поступали через единый шлюз, который распределял их на три отдельные системы: кастомный поисковый индекс в оперативной памяти, Elasticsearch и кастомное хранилище «ключ-значение» в оперативной памяти.
К 2025 году все три существующие службы достигли своих пределов масштабируемости, управление тремя отдельными системами стало операционным бременем, и даже вместе они не могли обслуживать некоторые запросы, которые требовались инженерам. Им нужно было решение получше.
Команда рассмотрела ряд вариантов. Создание еще одного кастомного решения было непривлекательным, поскольку, как выразился Джейкоб, «оно никогда не будет таким гибким, как универсальное решение», а экспертиза будет ограничена горсткой разработчиков. «Мы уже делали это и больше не пытались идти по этому пути», — добавляет он.
Шардированный MySQL был известной величиной, но по не самым лучшим причинам, так как команда ранее использовала Vitess в качестве источника истины и обнаружила, что он не может масштабировать чтение. Elasticsearch уже был под рукой, и его уже пробовали использовать, но предыдущая попытка перенести на него трафик провалилась, что привело к тому, что команда оставила его только для исследовательских целей.
Тем временем ClickHouse поддерживал все существующие запросы. При сравнении с кастомными базами данных, работающими в оперативной памяти, большинство запросов в ClickHouse выполнялись быстрее, а более медленные оставались в пределах допустимых значений. Квоты и журналы запросов позволили команде видеть, какая команда или сервис инициирует каждый запрос, и, как говорит Джейкоб, «не только останавливать некорректные запросы, но и работать с этими командами, чтобы переписать их и сделать более эффективными». Будучи универсальным OLAP-хранилищем, содержащим все измерения, он позволил команде поддерживать аналитические запросы, о которых они раньше даже не задумывались, некоторые из которых могли стать более эффективной заменой существующим запросам.
«Опыт, который мы получили, используя ClickHouse для трассировки, значительно упростил подключение нового проекта. Мы начинаем развивать экосистему ClickHouse в LinkedIn». — Джейкоб Зелек, ведущий инженер-программист
«Опыт, который мы получили, используя ClickHouse для трассировки, значительно упростил подключение нового проекта. Мы начинаем развивать экосистему ClickHouse в LinkedIn». — Джейкоб Зелек, ведущий инженер-программист
«Для нас расширение использования ClickHouse кажется более комфортным, чем внедрение еще одной системы, такой как Elasticsearch, от которой люди отказываются, или попытка создать что-то кастомное, что будет понятно только нашей команде», — говорит Джейкоб.
Текущая архитектура «довольно проста», говорит Джейкоб. База данных временных рядов команды передает данные в ClickHouse через систему непрерывного захвата изменений, в то время как шлюз, который был фронтендом для каждого запроса метаданных, теперь переписывает эти запросы на SQL и выполняет их в ClickHouse.
После миграции тот же шлюз направляет запросы к единому индексу ClickHouse, который поддерживается в актуальном состоянии благодаря непрерывной синхронизации из базы данных временных рядов.
Этот шлюз, по словам Джейкоба, сделал миграцию «прозрачной». Каждый инструмент и сервис в компании уже работал через него, поэтому, когда шлюз перестал распределять запросы на три отдельных сервиса и начал записывать SQL в ClickHouse, ничего в нижестоящих системах менять не пришлось. «Любой, кто использует RRD, уже использует ClickHouse», — говорит он.
В основе лежит реплицируемая таблица ReplacingMergeTree, упорядоченная для обеспечения эффективности измерений обнаружения, с дедупликацией по уникальному идентификатору. Поток захвата изменений обеспечивает доставку «как минимум один раз», поэтому дубликаты неизбежны; возможность ClickHouse удалять их во время слияний означает, что команда может работать с семантикой потока без дополнительной настройки. Конвейер создает свежую ежедневную таблицу из автономной базы данных временных рядов, обновляет ее данными захвата изменений, а затем использует псевдоним для переключения указателя таблицы и перенаправления трафика перед удалением старой таблицы.
Проекции (projections) справляются с более тяжелыми агрегациями, которые не могли выполнить старые системы, включая подсчеты «сервис-к-метрике», «сервис-к-уникальным-RRD» и списки «дата-центр-к-хосту». Схема также предоставляет прямой доступ к отдельным измерениям, поэтому инженеры, которые раньше использовали регулярные выражения для всей строки RRD, теперь фильтруют данные по столбцу. «Это гораздо эффективнее», — говорит Джейкоб.
Сегодня консолидированный индекс обслуживает более 150 000 запросов в минуту по всему парку серверов со средней задержкой 68 миллисекунд. Как отмечает Джейкоб, это среднее значение охватывает все типы запросов, включая медленные, глубокие аналитические запросы, которые старые системы вообще не могли обработать. «Если распределить это, вы увидите запросы с задержкой в несколько миллисекунд», — говорит он. Это происходит при работе с более чем 13 миллиардами метрик при ежедневном обновлении 30% данных LinkedIn на одном шарде.
Что касается ресурсов, Джейкоб оценивает, что миграция сократила использование памяти примерно до одной пятой от того, что требовалось предыдущему стеку из трех систем, и уменьшила вычислительную нагрузку примерно до двух третей. Поскольку индекс метаданных представляет собой один шард, команде не нужно думать о решардинге, а также имеется достаточный запас для удвоения объема метрик, что является большим отходом от старой архитектуры, достигшей своих пределов масштабирования.
Теперь, когда каждое измерение доступно для запросов, основные клиенты переписывают свои старые запросы, перегруженные регулярными выражениями, на более эффективные нативные запросы. Это означает, что кластер может со временем даже уменьшиться, несмотря на рост объема метрик. С ClickHouse тот же индекс становится инструментом, который помогает инженерам находить и анализировать свои метрики по мере того, как LinkedIn переводит графики и алерты с семантики RRD на нативную, что способствует более масштабной миграции, над которой Джейкоб, Арун и команда наблюдаемости работали годами.
