Я потратил 5 часов на то, чтобы понять как компания ClickHouse создала свое внутреннее хранилище данных
19 источников данных и в общей сложности 470 ТБ сжатых данных.
Введение
Возможно, Вы уже слышали о компании ClickHouse.
Возможно, Вы даже знаете, что ClickHouse работает быстро как в режиме реального времени, так и при пакетной обработке данных.
Но вот что Вы, возможно, еще не знаете, так это то, как инженеры ClickHouse - компании, стоящей за одной из самых мощных OLAP-систем в мире, - смогли построить внутреннее хранилище данных компании.
В этом посте я делюсь со своими подписчиками выводами, которые я сделал в процессе разговора с инженерами компании. Мы узнаем, как им удалось создать свое хранилище данных и усовершенствовать его таким образом, чтобы оно ежедневно могло обрабатывать 50 ТБ данных.
Немного предыстории
ClickHouse - это высокопроизводительная колоночно-ориентированная база данных с открытым исходным кодом, предназначенная для быстрой обработки аналитических запросов в режиме реального времени. Созданная для работы с большими объемами данных, она отлично подходит для сценариев OLAP, обеспечивая быстрое выполнение запросов даже на огромных массивах данных.
В мае 2022 года ClickHouse запустила свой облачный продукт.
Когда Вы запускаете продукт, Вы хотите знать, как именно клиенты его используют. Нравится ли он им? Хорошо ли работает продукт?
Компания ClickHouse тоже хотела ответить на все эти вопросы.
Сотрудники компании стремились лучше понять своих клиентов, в том числе то, как они используют сервис, с какими проблемами сталкиваются, как ClickHouse может помочь им и как сделать его более доступным в плане стоимости.
ClickHouse нужно было собирать и обрабатывать данные из нескольких внутренних источников: Data Plane, управляющей подсистемами баз данных клиентов (на Kubernetes); Control Plane, обслуживающей пользовательский интерфейс и операции с базами данных; и AWS Billing, предоставляющей точные данные о стоимости выполнения рабочих нагрузок клиентов.
Таким образом, сотрудники компании создали внутреннее хранилище данных с собственным продуктом ClickHouse Cloud в качестве базы. В следующих разделах мы поговорим об этом более подробно.
До создания хранилища данных внутренним пользователям приходилось анализировать данные вручную с помощью Excel.
Я считаю, что использование собственного продукта - это отличный способ получить более глубокое представление о нем с точки зрения клиента.
Первый этап
Обзор
Вот технологические стеки, которые ClickHouse изначально использовала для создания своего хранилища данных.
В качестве планировщика они использовали Airflow.
- В качестве промежуточного слоя данных они использовали AWS S3.
- В качестве BI-инструмента и SQL-интерфейса использовался Superset
- И, конечно же, в качестве базы данных и механизма обработки был выбран Clickhouse Cloud.
Источник данных
Список источников, которые они планировали включить в свое хранилище:
- Затраты на инфраструктуру/обслуживание и использование
- AWS CUR: затраты на обслуживание и инфраструктуру.
- Биллинг GCP: GCP затраты и использование.
- Цены AWS: Цены на каждый SKU AWS в разных регионах.
- Цены GCP: Цены на каждый GCP SKU в разных регионах.
- Метрики БД и системные метрики
- Control Plane: метаинформация о службах базы данных (тип, размер, регион CSP, настройки масштабирования и т. д.).
- Data Plane: метрики системы баз данных (статистика, статистика запросов, статистика таблиц, распределение подсистем и т. д.).
- Galaxy: Наблюдаемость на основе событий и мониторинг плоскости управления/слоя пользовательского интерфейса.
- Информация о покупателе и выставлении счета
- Salesforce (CRM): Данные об учетных записях клиентов, планах использования, подписках, скидках, лидах и вопросах поддержки.
- M3ter: Точная информация о выставлении счетов и использовании.
- Маркетинговые данные и данные о событиях
- Segment: дополнительные маркетинговые данные.
- Marketo: отправляет метаданные по email
Используя все эти источники данных, они сделали следующее:
Преобразования и обслуживание данных
Для получения и сбора данных из различных источников в бакете S3 используются следующие подходы:
Что касается больших таблиц фактов, то они собираются инкрементально каждый час. Для таблиц, в которых обновляются все существующие записи, каждый час делается снимок всей таблицы.
Данные, собираемые в бакете S3 каждый час, импортируются в базу данных ClickHouse с помощью функции ClickHouse S3 table.
Функция СlickHouse S3 table предоставляет табличный интерфейс для выбора/вставки файлов вAmazon S3 и в Google Cloud Storage.
Сначала данные вставляются в необработанный слой, сохраняя ту же структуру, что и исходные таблицы.
Преобразования данных выполняются через движок Clickhouse с помощью планировщика Airflow.
Преобразованные данные помещаются в таблицу marts, которая представляет бизнес-сущности и удовлетворяет потребности внутренних заинтересованных сторон.
Для потребления данных внутренние пользователи обращаются к таблицам MART и создают графики и дашборды с помощью Superset.
В процессе преобразования между исходными таблицами и таблицами mart создается множество временных таблиц. Перед вставкой в целевую таблицу преобразованные данные записываются в промежуточную таблицу. Это обеспечивает гибкость, позволяя использовать эти временные таблицы несколько раз. Каждая временная таблица имеет уникальное имя для каждого запуска Airflow DAG.
Идемпотентность
Для достижения идемпотентности в таблицах ClickHouse используется движок ReplicatedReplacingMergeTree, который обрабатывает дубликаты, сохраняя только последнюю запись для каждого ключа. Это позволяет вставлять данные несколько раз за час без дублирования.
Поскольку задания/группы Airflow могут повторять попытки несколько раз для одного и того же интервала данных, использование ReplicatedReplacingMergeTree делает конвейер идемпотентным, обеспечивая безопасное повторное выполнение без дубликатов.
Согласованность и постоянство
По умолчанию ClickHouse обеспечивает конечную согласованность данных, что полезно для аналитики в режиме реального времени, но может быть не совсем идеальным для DWH. Например, вставка данных в таблицу хранения может привести к частичной доступности данных; следующий этап конвейера данных может считывать данные, когда только три из четырех узлов получили записанные данные, что приведет к неполному считыванию данных.
Чтобы решить эту проблему, ClickHouse предоставляет режим согласованности, который гарантирует, что данные будут реплицированы на всех узлах до возвращения результата. Если задать insert_quorum=n (n - общее количество узлов в кластере), то данные гарантированно будут находиться во всех репликах. Компромисс заключается в том, что задержка будет выше, но для пакетной обработки это не является существенной проблемой.
Инфраструктура
Задавшись целью создать простое решение для хранилища данных, которое можно легко эксплуатировать и масштабировать, они развернули всю инфраструктуру с помощью контейнеров Docker:
- Эта установка включает в себя отдельные устройства для веб-сервера Airflow, рабочих узлов Airflow и Superset, которые работают в контейнерах Docker.
- На машинах Airflow контейнер запускается каждые 5 секунд для синхронизации репозитория, содержащего код DAG, запросы ELT и файлы конфигурации, с локальными машинами.
- Superset используется для создания дашбордов и отправки оповещений.
- Airflow и Superset совместно используют экземпляр Redis на отдельной машине. Redis обрабатывает состояния выполнения для Airflow и кэшированные результаты запросов для Superset.
- AWS RDS для PostgreSQL служит внутренней базой данных как для Airflow, так и для Superset.
- Две среды (Preprod и Prod) работают независимо друг от друга с собственными настройками ClickHouse Cloud, Airflow и Superset.
- Среда Preprod остается неизменной, что позволяет плавно переключаться в случае, если среда Prod становится недоступной.
Разработка потока
- Разработчик создает ответвление от ветки dev или production.
- Разработчик вносит в нее изменения.
- Разработчик создает Pull Request (PR) для ветки Preprod.
- После рассмотрения и утверждения PR изменения тестируются в ветке Preprod env.
- Когда изменения готовы к производству, в Prod создается PR из ветки Preprod.
Схема Airflow
По сути, они разрабатывают свои группы DAG следующим образом:
- Отдельные группы DAG для загрузки данных из источника в S3 (например, M3ter в S3).
- Единая основная группа DAG, которая обрабатывает все преобразования данных, как только они поступают в S3. Все необходимые зависимости перечислены в задачах основной группы DAG.
Улучшение dbt
Через год количество источников данных выросло с 11 до 19, что потребовало более эффективно1 организации процесса подключения новых источников.
В первоначальном варианте необработанные данные поступали из источников в бакеты S3, а затем преобразовывались в ClickHouse для создания отчетов, предназначенных для внутренних пользователей. Управление большинством процессов осуществлялось с помощью Airflow. Однако такой подход стал неустойчивым по мере добавления новых источников данных, разработки сложных бизнес-метрик и обслуживания все большего числа внутренних заинтересованных сторон.
Чтобы решить эту проблему, они внедрили dbt, который позволил централизовать логику преобразования для пакетной обработки данных.
Аналитика данных в режиме реального времени
Основываясь на отзывах пользователей, они начали включать в свою отчетность больше источников данных, поскольку разнообразные данные, поступающие в режиме реального времени, были очень ценными и интуитивно понятными, даже если они были менее структурированы и требовали минимальной обработки при запросах (например, разбор полей из колонок JSON).
Инженеры предоставляли эти данные в режиме реального времени в сыром и преобразованном форматах. Библиотека ClickHouse и поддерживаемые форматы данных сделали изучение необработанных данных в реальном времени удобным, позволив пользователям выполнять SQL-анализ, не нуждаясь в непосредственной поддержке со стороны дата-инженеров.
Сочетание dbt и базы данных Clickhouse позволяет пользователям комбинировать пакетную обработку данных с обработкой данных, поступающих в режиме реального времени.
Они используют dbt для определения агрегатов данных в режиме реального времени. В ClickHouse эти агрегации также настраиваются с помощью таких функций, как материализованные представления. Агрегации в режиме реального времени объединяются с существующими отчетами для отслеживания и обогащения таких показателей, как «количество клиентов с неудачными запросами».
Больше возможностей для потребления данных
В первой итерации в качестве BI-инструмента для доступа пользователей к данным ClickHouse использовал Apache Superset. На этом этапе единственным способом запроса данных в ClickHouse для пользователей был SQL-клиент Superset. Однако позже стало понятно, что SQL-клиент Superset содержит множество ошибок, что негативно сказывается на работе пользователей.
Чтобы решить эту проблему, пользователи получили доступ к хранилищу данных через встроенную SQL-консоль ClickHouse Cloud, которая значительно расширила возможности пользователей по составлению специальных SQL-запросов, изучению таблиц и представлений базы данных. Пользователи отметили, что консоль SQL превосходит по своим возможностям родной SQL-клиент Superset.
Для проведения A/B-тестирования в Clickshouse интегрировали GrowthBook , что позволило пользователям проводить A/B-тесты с использованием данных непосредственно из хранилища данных. Поскольку GrowthBook напрямую запрашивает ClickHouse Cloud, проводить эксперименты на необработанных данных на уровне журналов стало гораздо проще.
Компания Clickhouse также настроила опцию экспорта данных из ClickHouse Cloud в Salesforce, что позволило отделу продаж использовать данные DWH непосредственно в CRM. Они поместили данные из хранилища в бакет S3 и позволили Salesforce обращаться к нему по мере необходимости.
Заключение
В этой статье мы рассказали о том, как компания ClickHouse создала свое внутреннее хранилище данных на базе ClickHouse Cloud. Мы увидели, как они собирали данные из разных источников, используя S3 в качестве промежуточного слоя, выполняли преобразования данных, добивались идемпотентности и согласованности с помощью базы данных ClickHouse. Наконец, мы узнали о том, как они усовершенствовали свою платформу данных, внедрив dbt.
Ссылки
- Дмитрий Павлов, Как мы построили внутреннее хранилище данных в ClickHouse (2023)
- Михир Гохале, Как мы построили внутреннее хранилище данных в ClickHouse: год спустя (2024)
