В разные эпохи развития нашего проекта в качестве основного хранилища, которое являлось источником данных для аналитики, у нас были MySQL, Elasitcsearch, Exasol и ClickHouse. Последнее нам очень нравится и вообще вызывал дикий восторг, как инструмент для работы с большими массивами данных, но, если посчитать итоговую стоимость владения с учётом внедрения кластера, обучения и поддержки — лучше подумайте два раза, прежде чем тащить его в ваш стек. На наших объёмах данных вложенные усилия окупаются, но если бы мы были чуть меньше, то, наверное, экономика не сошлась бы.

Главная проблема ClickHouse — это практическое отсутствие удобных и стабильно работающих инструментов для эксплуатации и большое количество решений рядом — в погоне добиться того же пользовательского опыта, как при работе с классическим RDBMS (MySQL или PostgreSQL). Вам придётся приложить немало усилий, чтобы понять как эффективно применить ClickHouse для ваших задач. Анализировать придётся много, начиная от вопросов развёртывания до выбора оптимальных моделей данных под профиль вашей нагрузки, в общем доступе не так много рекомендаций по выбору конфигураций под разные типы задач.

С другой стороны, его киллер-фича — это возможность работать с огромными массивами данных невероятно быстро для решений в этой области: то, что раньше нам приходилось делать в Spark или через другие реализации MapReduce, теперь мы можем делать внутри ClickHouse. И бесплатно, потому что такими же плюсами обладают многие MPP решения вроде Vertica или Exasol. Но ClickHouse открытый, и за это мы платим налог на использование непрогнозируемым объёмом поддержки или развития системы. Не всем это подходит, например, есть опыт компаний, которые сначала было влезли в это дело, потом поняли, что это не то, и взяли платные продукты с платной поддержкой, с экспертизой в решении архитектурных задач именно их продуктами. В платных продуктах есть готовые инструменты, которые понятно как применять.

В общем, давайте расскажу про наш опыт.

Что такое ClickHouse и чем он стал для нас

Это решение, созданное под задачу хранения данных проекта Яндекс.Метрики, которое было заточено под сохранение данных о действиях пользователей и последующей аналитикой в интерфейсе и построении отчётов. Вот подробный пост. Он потенциально очень хорошо масштабируется (о топологии нашего кластера мы написали в отдельной статье), очень быстро работает и хранит сырые данные с простым доступом через SQL — что очень удобно для аналитики. У ClickHouse нет эффективного подхода обновления данных, атомарных операций и транзакций, но для обновления есть возможность всё же реализовать его через построение особой модели данных и движки таблиц Replacing*.

Документация по ClickHouse есть, но написана она часто излишне детализировано, а часто в духе «осталось нарисовать остальную сову», примеры нарисованных «сов» можно найти на некоторых конференциях в решении узких задач. Главная проблема для нас была в том, что то же масштабирование в кластере можно сделать несколькими разными способами, но на практике только один из трёх будет рабочим. И вы не узнаете какой, пока не попробуете все, во всяком случае такой путь был у нас. В том же Exasol в такой же ситуации метод будет только один, одобренный вендором, и по-другому сделать просто не выйдет. Зато он точно будет прост, понятен и будет гарантированно работать.

Отсутствие инструментов к нему обходится дорого, но посчитать насколько — сложно. Если бы мы могли сформулировать заранее требования к хранению данных и их использованию точно — то наверняка взяли бы Vertica или продолжили использовать Exasol. Но проблема в том, что развивающиеся продукты часто не знают, что именно им понадобится на горизонте 1-3 лет, поэтому приходится хранить всё. Плюс есть неопределённость в продукте, а при развитии новых фич часто нужны исторические данные. В случае платных решений нужные объёмы хранения были банально дороги.

Коммерческие стоят от 2 тысяч долларов в месяц. Два года назад у нас было 7,5 Тб, и мы понимали, что к 2021 году, если не случится, ну знаете, чего-нибудь особенного для индустрии путешествий, будет 20 Тб. При этом мы не могли посчитать профит от хранения 1 Тб данных, потому что платить надо сразу, а пригодиться данные могут через полгода. Каждый раз, когда мы начинаем что-то складывать в хранилище, это делается по экспертной оценке от владельца продукта: «Кажется, у этих данных есть потенциал для бизнеса».

Так же нам хотелось создать инфраструктуру и дать такой инструмент для аналитиков, чтобы они использовали минимальное количество источников и имели инструмент с маленьким порогом входа. Это накладывало бы дополнительные ограничения на возможные сложные инструменты, которые могли бы быть применены.

В итоге мы попробовали ClickHouse. Если бы была экспертиза в PostgreSQL, взяли бы Greenplum. Vertica мы тоже не умели и не понимали. В итоге попробовали домик, и он очень понравился аналитикам SQL-интерфейсом, скоростью работы и богатым набором функций, необходимых для их повседневной работы. Напомню, в Elasticsearch, который мы использовали для хранения части наших данных, — SQL нет, и это сильно осложняло пользовательский опыт аналитиков, не говоря об эффективности использования ресурсов.

Как пришли к Elasticsearch в 2016 году и что за задача вообще была

Тогда нам надо было сделать систему, которая позволила бы собирать данные о действиях пользователей со всех наших проектов. Причём с вечным хранением данных. Это нужно, чтобы сравнивать метрики, которые были в прошлых годах в аналогичном месяце, потому как в туристической сфере очень значительно отражается сезонность. Мы хотели проводить детальный анализ результатов АБ-тестов по сырым данным с точностью до каждого пользователя. Решения для классической веб-аналитики Яндекс.Метрика и Google Analytics бесплатные и имеют низкий порог входа. Но они довольно ограниченные и не позволяют гибко работать с сырыми данными, для нас блокирующим фактором стали ограничения на получения сырых данных и потери данных в ~10% по нашим исследованиям. Эти потери выглядели при аналитике как потеря некоторых событий в цепочке действий пользователей. На этих инструментах также нельзя строить что-то серьёзное в привязке к деньгам и не сливать финансовые данные. Мы замечали, что данные в этих системах иногда по-разному доходят до хранилищ, в результате чего и та и другая система врут относительно реальных данных по тем же заказам, причём в разные стороны. Возможно, там есть какая-то логика, из-за которой мы не можем получить все данные.

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

Мы начали собирать информацию, учиться, ходить на конференции, там общаться с людьми, которые строили уже подобные платформы. Мы не понимали какой стек нам вообще нужен для решения конкретно этой задачи. Были истории успеха у Netflix, у Linkedin и других новаторов в этой области, которые строили крутые дата-платформы, но непонятно было, пойдут ли нам эти решения. Если б мы просто начали тестировать, подходит ли нам конкретно вот этот стек для решения наших задач, то мы могли бы уйти в исследование достаточно на долгое время. В 2016 году вообще было мало практик по созданию подобных систем и мало компетентных специалистов, готовых построить систему с нуля.

К тому моменту наше хранилище для аналитиков состояло только из нескольких огромных реплик на MariaDb, куда стекались данные из всех 100+ серверов и наш опыт и опыт большинства компаний говорил о том что это не то решение, которое будет готово переварить хранение всех кликов пользователей.

Поскольку основное в архитектуре, с нашей точки зрения, было хранилище, начали мы именно с него. У нас уже на тот момент были реляционные базы, такие как MySQL, на которых было сложно получить реалтайм и правильно сегментировать данные — получалось, что они часто нужны нам в сыром виде. ClickHouse тогда ещё был недоступен публично, поэтому мы выбирали из Greenplum и Elasticsearch. В итоге мы пришли к решению, что будем внедрять Elasticsearch, потому что Elasticsearch решал несколько задач в нашей компании, например, такие как хранение логов приложений для задач эксплуатации инфраструктуры запуска наших приложений.

Elasticsearch — это документоориентированное хранилище с near-real-time доступом к данным. Данные в Elasticsearch не сразу становятся доступными для поиска. Чем меньше этот лаг, тем выше нагрузка на хранилище. Мы могли смириться с лагом в несколько минут, что снимало эту проблему. Ещё это распределённое решение для полнотекстового поиска, который имеет гибкие возможности масштабирования и достаточно богатые возможности для построения агрегации по данным. Elasticsearch позволяет гибко нарезать данные временных рядов, ну и организовывать работу с ними уже встроенными возможностями, без каких-то дополнительных действий. У них большая экосистема. Есть в стеке Kibana, которая позволяет достучаться к нашим данным, возможность строить визуализации и дашборды. Всё в бесплатной версии лицензии.

Но у этого хранилища были минусы, которые не были значительными на том этапе нашего развития:

• Отсутствие SQL подобного языка запросов.

• Нет join’ов в классическом понимании, но есть альтернатива.

• Нет контроля консистентности и транзакций.

• Ещё один источник данных для аналитиков который придётся осваивать.

Несмотря на все ограничения, хранилище успешно решало бизнес-задачи и имело вот такую структуру:

Год назад в хранилище было 12 Тб данных, и это без сессий ботов. 12 миллиардов документов. В среднем писалось по 20 тысяч записей в минуту. Бывали пики до 40 тысяч. Девять нод Elasticsearch.

Работало с базой пять продуктовых команд, 11 аналитиков и 2 дата-инженера на поддержке и развитии текущей системы.

«Вы распиливаете монолит, а мы собираем его обратно»

Мы росли, наша архитектура проекта развивалась, новые проекты делались на микросервисной архитектуре, старые монолиты постепенно разделялись на мелкие проекты, начало появляться множество серверов баз данных для изоляции между группами сервисов, c которыми работал production код. Итак, мы выросли из старой архитектуры из-за:

• Потребностей в удобстве доступа к данным.

• Скорости работы с данными.

• Необходимости подключать удобные BI-инструменты.

• Сложности поддерживания старой системы реплик и нескольких хранилищ.

• Поменялись требования по порогу входа аналитиков, их функциям и ожиданиям по скорости проверки гипотез в единицу времени.

В качестве альтернативы ClickHouse мы рассматривали ещё некоторые системы аналитики, которые поставляются как SaaS (в сравнении с ними собственное внедрение open source окупалось за считанные недели, как нам казалось, посчитав потом, могу сказать — месяцы), были BigQuery, RedShift и решения в AWS. Но у нас не было экспертизы, как готовить такое, чтобы было экономически сообразно. Из того, что мы посчитали, всё было дороже и менее предсказуемым, чем MVP на базе ClickHouse. Плюс почти во всех облачных решениях нужно аналитиков контролировать и выстраивать процесс, чтобы они не сделали запрос, который обойдётся дорого, потому что оплата шла по факту за чтение/количество запросов и сложность этих запросов. Например, пропустил join по всей базе — и упс, прилетает счёт на пару тысяч долларов. В ClickHouse порог входа в аналитики куда проще: если они вдруг уложат хранилище, оно быстро упадёт и быстро поднимется. Но, скорее, пережуёт запрос. Переделывать принципы работы аналитиков мы не хотели, поэтому решили сразу, что плата за сложность запроса — плохая идея, которая потребовала бы внедрения новых процессов и обучения.

В ClickHouse хранение данных очень эффективное, то, что у нас занимало около 15 Тб в Elasticsearch, заняло в итоге 4 Тб в ClickHouse. В основном мы храним действия в сессии пользователя и состав выдач железнодорожных и авиабилетов ему. Есть и заказы, и билинг, и документы и всё остальное, но в сравнении с этими категориями это просто капля в море по объёму. Сейчас мы на пути сбора данных со всех сервисов компании (монолит и около 1000 микросервисов) и собираем их в одно Data Lake на базе ClickHouse. Такую задачу также можно решить поднятием кластера Spark или Hadoop, делающего распределённые join, но решения по сложности сопровождения и сложности архитектур сильно проигрывают ClickHouse.

На текущий момент удалось созданием внутренней базы знаний понизить порог входа в ClickHouse для разработчиков в командах, которые не имеют экспертов в хранилищах для использования ClickHouse как минимум для доставки данных от production кода до Data Lake на базе ClickHouse с минимальным оказанием консалтинга экспертов в ClickHouse для разработчиков, что позволило не делать «узким горлышком» одну команду и перенести зону ответственности на команды, которые являются источниками данных. С более сложными системами вроде Hadoop это сделать было бы сложнее.

В итоге схема, к которой мы пришли ниже, где ClickHouse играет важную роль:

За пару лет эксплуатации ClickHouse мы натыкались на ломающиеся достаточно важные части функционала, например, такие как ClickHouse-copier(инструмент для миграции данных между кластерами), мы не доверяем новым удобным фичам вроде чтения из Kafka или из других источников, потому как в случае проблем исследовать проблемы и делать drill down практически невозможно, и достаточно регулярно в них встречались баги или недокументированные особенности, которые приводили к потерям данных в краевых случаях, поэтому мы используем ClickHouse как решение для хранения и доступа к данным, а инструменты доставки используем во вне. 

Мы считаем, что пока в начале пути, и ещё много надо сделать. В планах:

1. На текущий момент витрины данных для быстрого доступа у нас хранятся в Exasol, но мы хотим рассмотреть для этой задачи ClickHouse на основе Materialized View и встроить в наш процесс создания витрин.

2. Повысить скорость работы с данными которые требуют меньших задержек, чем получаем сейчас, хотим сократить скорость ответа для частых сложных запросов с десятков минут до 2-3 минут.

3. Научиться быстро локализовывать возникающие проблемы производительности новых запросов и ловить не оптимальные запросы на ранних этапах.

4. Интеграция со всеми сервисами, данные которых необходимы для какой-либо аналитики внутри компании.

5. Полностью заменить этим хранилищем те функции, которые выполняла большая реплика MariaDb которую упоминали ранее.

6. Наладить регулярное обновление до свежих версий ClickHouse, потому как часто появляются новые полезные для аналитиков фичи и ломаются старые.

7. Начать декомпозицию потоков данных по доменным областям и двигаться в сторону Data Mesh.

А в этом посте мой коллега рассказывает к какой схеме организации кластера пришли и почему.

Про инструменты доставки данных, особенности интеграции с шиной данных и как пришли к текущей архитектуре, мы расскажем в следующих статьях.

А еще у нас открыты вакансии и мы ищем к нам в команду еще одного классного DevOps на развитие этой инфраструктуры.