Внедрение, аудит и поддержка ClickHouse
Аналитика, которая не кладёт прод. Проектируем новые кластеры правильно и лечим существующие - без остановки.
ClickHouse - колоночная СУБД и краеугольный камень современных аналитических платформ. Мы строим на нём хранилища и витрины уже несколько лет и знаем его сильные стороны так же хорошо, как слабые.
Главное, что стоит понять до старта: ClickHouse - это два разных инструмента в одной коробке. От того, какой из двух вам нужен, зависит вся архитектура инсталляции. Ошибка на этом шаге всплывает через год, когда данных уже сотни терабайт и передвинуть их некуда.
Два ClickHouse в одной коробке
Молниеносные агрегаты по миллиардам строк, дашборды, которые открываются за секунду, аналитика, о которой на строчной СУБД можно только мечтать.
Данные залетают миллионами строк в секунду: логи, метрики, события, телеметрия. По скорости приёма с ним мало кто может соперничать.
Подвох в том, что эти два режима плохо уживаются на одном кластере. Движки семейства MergeTree сливают загруженные куски данных в фоне - тогда, когда сами сочтут нужным. Пока идёт интенсивная заливка, запросы читают недосмёрженное состояние: один и тот же отчёт, запущенный дважды подряд, покажет разные цифры. Дедупликация тоже происходит «когда-нибудь при слиянии», поэтому дубли от повторных вставок какое-то время живут в данных как полноправные строки. Добавьте конкуренцию за ресурсы: пиковая заливка душит слияния, куски копятся, и кластер отвечает ошибкой «Too many parts» - вставка встаёт.
Об этой двойственности редко пишут в обзорах, и на ней ломается большинство самостоятельных внедрений, которые мы видели. Правильная инсталляция разводит роли по разным контурам: один принимает поток, другой отдаёт витрины. Как именно разводить - репликами, отдельными кластерами, комбинацией - решается на проектировании под вашу нагрузку.
Решения, которые нельзя передумать
В строчных СУБД многое можно исправить потом: добавить индекс, перестроить таблицу, перенести базу. ClickHouse прощает гораздо меньше. Ключ сортировки, схема партиционирования, движки таблиц и раскладка по шардам фиксируются в начале - и определяют производительность и стоимость владения на годы.
Самое жёсткое ограничение - шардинг. Штатного решардинга в ClickHouse нет: перераспределить уже загруженные данные между шардами в рамках таблицы нельзя. Перекос весов направит на новые узлы только новые данные, история останется лежать где лежала. Кластер, который заливали без стратегического плана, однажды упирается в потолок железа - и оказывается, что шард на десятки терабайт быстро подвинуть некуда, а систему не остановить.
Сюда же относится наша принципиальная позиция по materialized views. Инкрементальное представление исполняется синхронно в момент вставки: каждое добавленное представление замедляет приём данных и умножает количество кусков, а неаддитивные агрегаты в нём умеют искажать цифры без единой ошибки в логах. Вычисления витрин мы на вставку не вешаем - они выполняются регламентными процессами по расписанию, отдельно от контура заливки. Производительность проектируется в схеме, триггерами её не добиться.
Спасаем работающие кластеры
Отдельное направление - существующие инсталляции, которые построили без плана, и теперь они болеют. Симптомы узнаваемы: ошибки «Too many parts» в логах, отчёты с плавающими цифрами, диски заполнены за 80% и партиции двигать некуда, очередь мутаций растёт, реплики уходят в read-only. Останавливать систему нельзя - на ней работает бизнес.
Мы чиним такие кластеры без остановки, по нарастающей. Сначала диагностика по системным таблицам - она вообще не трогает прод и за несколько дней даёт полную картину: где копятся куски, успевают ли слияния, что со схемой и ключами. Затем быстрые победы: дисциплина вставки, настройки слияний, TTL для устаревших данных - часто уже это снимает половину боли. Дальше развод контуров заливки и чтения на живой системе. В тяжёлых случаях - постепенный переезд: партициями, с выносом холодных данных на дешёвое хранилище, либо новый кластер рядом с двойной записью и переключением потребителей без окна простоя.
Верхняя граница того, с чем мы работали, - кластеры в сотни терабайт, где «просто перелить данные» не вариант ни по времени, ни по месту на дисках.
Когда он вам нужен
Строчная СУБД устроена под транзакции - читать по ней миллионы строк ради одной суммы неэффективно по самой природе хранения. Кликхаус хранит данные по колонкам и сжимает их: запрос читает только нужные колонки, отсюда разница в скорости на порядки.
Отчёты и дашборды тянут данные из боевой базы и тормозят пользователей. Аналитическую нагрузку нужно унести в отдельную систему.
BI работает поверх строчной СУБД и упирается в неё. Витрины в кликхаусе отдают тот же отчёт за секунды.
События, логи, показания приборов, история продаж за годы. Хранить это в учётной системе дорого, а считать по нему - долго.
Отчётность за вчера уже не устраивает. Нужен контур, который принимает поток и отдаёт аналитику с задержкой в минуты, а не в сутки.
Если данных немного и аналитика никому не мешает - отдельная система только добавит работы по эксплуатации. Если нужны транзакции, точечные обновления и жёсткая целостность - это задача для PostgreSQL или MS SQL, и мы скажем об этом прямо, а не станем продавать модную СУБД под неподходящую задачу.
Что делаем
Инсталляция под задачу: разведение контуров, схема хранения, ключи сортировки, партиционирование, шардинг с запасом на рост. Оценка железа под ваши объёмы и нагрузку.
Развёртывание в вашем контуре: кластер, репликация, мониторинг, разграничение доступа, квоты и ограничения на тяжёлые запросы. Настройка ClickHouse под реальный профиль нагрузки, а не по умолчанию.
Обследование существующих инсталляций с планом лечения: что со схемой и ключами, успевают ли слияния, где копятся куски, что с местом и репликацией. Диагностика идёт по системным таблицам и прод не трогает.
Администрирование ClickHouse по SLA: мониторинг слияний, очередей репликации и дискового пространства, разбор медленных запросов, обновления версий, проверка восстановления из копий. Отдельно или в составе абонентского обслуживания баз данных.
Витрины, дашборды и отчётность поверх ClickHouse - отдельное направление: разработка корпоративной отчётности. Доставку данных в кластер проектируем в рамках разработки ETL-процессов.
Стоимость
Проектирование и внедрение считаются сметой после обследования: объём зависит от того, какой из двух контуров вам нужен, каких объёмов данные и в каком состоянии источники. Аудит существующей инсталляции - отдельные работы, их стоимость известна до старта. Сопровождение - по SLA в рамках абонентского обслуживания. Если ClickHouse становится частью полноценного хранилища - см. построение DWH.
Частые вопросы
Можно ли на одном кластере принимать поток данных и строить отчёты?
Технически можно, практически - до первой серьёзной нагрузки. Фоновые слияния происходят в непредсказуемые моменты, запросы видят недосмёрженные данные, а пиковая заливка и тяжёлые отчёты конкурируют за одни ресурсы. Стабильные инсталляции разводят эти роли по разным контурам. Если у вас уже один кластер на всё - это лечится без остановки, см. выше.
Почему один и тот же отчёт показывает разные цифры при повторном запуске?
Классический симптом чтения недосмёрженных кусков: движок сливает данные в фоне по собственному расписанию, а дедупликация выполняется при слиянии, то есть «когда-нибудь». Это архитектурное свойство, оно лечится правильной схемой и разведением контуров, самостоятельно оно не пройдёт.
У нас ClickHouse уже тормозит. Чинится ли это без остановки системы?
В большинстве случаев да. Диагностика по системным таблицам не трогает прод вообще. Дисциплина вставки, настройки слияний и TTL применяются на живой системе. Даже переезд данных делается партициями, окнами, без остановки приёма. Полная остановка требуется в исключительных случаях, и о ней вы узнаете заранее, с планом и оценкой времени.
Чем ClickHouse отличается от PostgreSQL и когда он нужен?
PostgreSQL - строчная СУБД для транзакций: много мелких чтений и записей, изменение отдельных строк. ClickHouse - колоночная база данных для аналитики: быстрые агрегаты по огромным таблицам при почти неизменяемых данных. Попытка заменить одно другим заканчивается плохо в обе стороны. Типичная связка - обе СУБД рядом, каждая на своей работе.
Кластер упёрся в потолок железа. Можно ли расширить?
Добавить узлы можно, но штатного перераспределения уже загруженных данных в ClickHouse нет - новые шарды сами по себе примут только новые данные. Перебалансировка истории - отдельный проект: партициями, с расчётом места и времени. Чем раньше спланирован рост, тем дешевле он обходится; лучший момент подумать о шардинге - до загрузки первого терабайта.
Сколько стоит внедрение ClickHouse?
Проектирование и внедрение считаются сметой после обследования: объём зависит от того, какой из двух контуров вам нужен, каких объёмов данные и в каком состоянии источники. Аудит существующей инсталляции - отдельные работы, их стоимость известна до старта. Сопровождение - по SLA в рамках абонентского обслуживания. Точная оценка появляется после короткой диагностики вашей задачи и объёмов.
Расскажите о задаче - мы предложим подходящий формат.