Последнее время довольно много публикаций на Хабре посвящено различным средствам, реализующим функциональность для построения хранилищ данных и аналитики и позволяющим заменить использующееся и привычное ПО. Причины понятны, на них останавливаться не буду, а постараюсь просто рассказать о нашем опыте. С целью изучения возможности построения аналитической системы с использованием БД ClickHouse и Metabase BI нашей небольшой, но сплоченной командой был сделан небольшой макет. Под катом расскажу что мы сделали и с какими проблемами столкнулись. Основные вводные для построения аналитической системы были сформулированы следующим образом: 1) Основная OLTP-система, из которой надо получать данные, в качестве БД использует PostgreSQL. Есть и другие системы, но объем данных в них довольно небольшой, поэтому для макетирования берем только эту – основную. В БД этой системы порядка 2 десятков таблиц, на основании которых надо строить аналитику. Из этих 2-х десятков таблиц есть 2 довольно большие, каждая из которых имеет примерно по 200 млн. записей. Ежесуточный прирост данных в этих таблицах – в среднем около 300 тыс. записей. Но бывают дни, когда прирост достигает 1 млн. записей. Редко, но бывает. 2) В целях упрощения макета мы решили, что данные в нашей OLTP-системе достаточно чистые, поэтому делать staging мы не будем, на процедуры очистки данных тоже пока забьем. 3) Чтобы не городить огородов, ETL реализуем с помощью врапперов исходных таблиц, используя возможности ClickHouse по интеграции с PostgreSQL и SQL-скриптов, реализующих вставку данных и запускаемых по расписанию.  Надо сказать, что до этого никто из нас не имел опыта работы ни с ClickHouse, ни с Metabase, так что, возможно, мы что-то и накостылили, не зная в достаточной мере возможности инструментария. Для начала развернули две виртуальные машины, поставили CentOS 7. С установкой ClickHouse проблем у нас не возникло, но на всякий случай под катом напишу порядок установки. Установка: 1) Настройка репозитория: 2) Установка сервера и клиента: Первичная настройка: 1) Создаем каталог для основных файлов сервера: /mnt/clickhouse И подкаталоги: Для хранения данных: /mnt/clickhouse/data Для логов: /mnt/clickhouse/log Для временных файлов: /mnt/clickhouse/tmp Для пользовательских данных: /mnt/clickhouse/user_files 2) Назначаем владельца каталога: 3) Редактируем файл /etc/clickhouse-server/config.xml для установки каталогов 4) Редактируем файл /etc/clickhouse-server/config.xml для обеспечения доступа к серверу с удаленных компьютеров: 5) Редактируем файл /etc/clickhouse-server/users.xml для предоставления возможности дефолтному пользователю создавать других пользователей: 6) Стартуем сервер и проверяем:  7) С помощью clickhouse-client'а создаем нового пользователя и устанавливаем ему все возможные права на создание объектов БД: 8) Не забываем открыть порт на сервере для доступа с удаленной машины:  Далее, просто пишем скрипты по созданию структуры нашего хранилища. Структуру хранилища разбили на 2 БД, первая (SOURCE) содержит врапперы для постгресовых удаленных таблиц с использованием движка PostgreSQL, вторая (DWH) – таблицы с использованием движка MergeTree. Таблицы созданы, пишем скрипты, реализующие выборку новых данных из таблиц БД SOURCE и вставку в соответствующие таблицы DWH. Было решено, что выбирать и грузить данные мы будем пачками по 1 млн записей, что с некоторым запасом соответствует суточному приросту данных в самых больших таблицах. И здесь мы столкнулись с первой проблемой: по привычке, чтобы ограничить кол-во выбираемых строк из исходной таблицы пишем выражение SELECT … FROM … WHERE … LIMIT 1000000. Но не тут-то было, на PostgreSQL приходит запрос без ограничения, в результате чего запрос пытается выбрать все 200 млн записей и падает. Читаем маны, и действительно – клауза WHERE такого селекта выполняется на постгресе, а вот LIMIT будет выполняться уже на стороне ClickHouse. В результате наши запросы принимают вид типа: Теперь надо написать скрипты по изменению данных в DWH. В исходной OLTP-системе данные не только добавляются, но и бывает модифицируются. Немного, но все же. А ClickHouse не поддерживает UPDATE. Как быть? Помогает Хабр: вот решение - Обновление данных в ClickHouse, спасибо автору.  Написали, проверили, все работает. Делаем набор баш-скриптов, запускающих SQL-скрипты через clickhouse-client, типа такого: И настраиваем расписание в cron. Для первоначальной загрузки будем запускать наши скрипты раз в 5 минут, потом перейдем на 1 раз в сутки, ночью. Как результат, первоначальная загрузка 2-х больших таблиц пачками по 1 млн записей была запущена в пятницу вечером и к понедельнику благополучно завершена. Точный тайминг я не засекал, но это было на удивление быстро.  Теперь поставим Metabase. В принципе, на сайте разработчиков есть достаточно подробная инструкция, но, тем не менее, напишу последовательность установки под катом, может кому пригодится. 1) Для хранения своих данных Metabase поддерживает несколько СУБД. Мы ставили на PostgreSQL 14, просто потому, что мы его любим и в него умеем. Порядок установки PostgreSQL легко гуглится, поэтому расписывать подробности не буду. 2) Ставим OpenJDK 11. Тоже проблем не представляет. 3) Создаем группу и пользователя для Metabase, ставить будем в /opt/metabase: 4) Создаем на PostgreSQL пользователя и базу: 5) В каталог /opt/metabase копируем основной файл приложения metabase.jar 6) В каталоге /opt/metabase создаем подкаталог plugins и копируем в него драйвер для ClickHouse clickhouse.metabase-driver.jar, который берем с GitHub’а (https://github.com/enqueue/metabase-clickhouse-driver) 7) В каталоге /opt/metabase создаем файл metabase.sh: и делаем его исполняемым: 8) Назначаем права на рабочий каталог:  9) В каталоге /etc/systemd/system создаем файл metabase.service: 10) Включаем сервис в автозагрузку: 11) Открываем на сервере рабочий порт приложения: 12) Стартуем сервис:  Дальше вводим в браузере на удаленной машине адрес и порт Metabase и проводим первоначальную настройку BI-сервера, там уже совсем все просто. Настраиваем подключение к нашему DWH на ClickHouse и собственно, начинаем работать – делаем запросы, гистограммы, сводные отчеты, дашборды и все такое. Документация достаточно подробная, с картинками – разобраться не сложно. С какими проблемами пришлось еще столкнуться: 1) Оказалось, что тип Date в ClickHouse это совсем не тот же тип date, как в PostgreSQL (сюрпрайз, да). Тип Date в ClickHouse хранит даты, начиная с 1970-01-01, а нам надо было глубже. Пришлось переделывать схему на тип Date32, который может хранить даты, начиная с 1900-01-01. И вроде бы все импортировалось нормально, но … При формировании отчетов на BI нам надо было довольно часто считать разницу дат. А функция DATE_DIFF в качестве аргумента принимает только тип Date и DateTime. А если закастить Date32 в Date, то результат для дат ранее 1970-01-01 оказывается смешным, особенно в графическом отчете. В общем, здесь запросы пришлось костылить. Не страшно, но как-то неаккуратненько получилось. 2) При попытке выборки данных, содержащих тип Bool и имеющих значение null, в отчете возникает исключение. Здесь, видимо, недоработка в драйвере соединения с ClickHouse. Решили проблему созданием вьюхи, с кастингом типа Bool в тип UInt8. Безусловно, проблемы еще всплывут, особенно, если решение пойдет в прод. Но, основная функциональность работает стабильно и ожидаемо, т.е. решение вполне себе рабочее. Спасибо за внимание. Замечания, комментарии, пожелания конечно же приветствуются.  Системный архитектор