MergeTree с хранилищем в Google Cloud Storage (GCS)
Если вы используете ClickHouse Cloud в Google Cloud, эта страница к вам не относится, поскольку ваши сервисы уже используют Google Cloud Storage. Если вы хотите выполнять SELECT или INSERT данных из GCS, см. табличную функцию gcs.
ClickHouse учитывает, что GCS — привлекательное решение для хранения данных, если вам нужно разделить хранилище и вычислительные ресурсы. Для этого предусмотрена поддержка использования GCS в качестве хранилища для движка MergeTree. Это позволяет воспользоваться преимуществами GCS с точки зрения масштабируемости и стоимости, сохранив при этом производительность вставки и запросов движка MergeTree.
Чтобы использовать GCS-бакет в качестве диска, его сначала нужно объявить в конфигурации ClickHouse в файле из каталога conf.d. Ниже показан пример объявления GCS-диска. Эта конфигурация включает несколько секций для настройки GCS-«диска», кэша и политики, которая указывается в DDL-запросах при создании таблиц на GCS-диске. Каждая из них описана ниже.
Политики конфигурации хранилища позволяют выбирать, где будут храниться данные. Показанная ниже политика позволяет хранить данные на диске gcs, указав политику gcs_main. Например, CREATE TABLE ... SETTINGS storage_policy='gcs_main'.
Если ваш диск настроен на использование бакета с доступом на запись, вы сможете создать таблицу, как в примере ниже. Для краткости мы используем только часть столбцов из набора NYC taxi и передаём данные напрямую в таблицу на базе GCS:
В зависимости от оборудования эта последняя вставка 1 млн строк может выполняться несколько минут. Ход выполнения можно проверить в таблице system.processes. При желании можно увеличить число строк до 10 млн и попробовать несколько примеров запросов.
SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
Cloud Storage XML API совместим с некоторыми инструментами и библиотеками, работающими с такими сервисами, как Amazon Simple Storage Service (Amazon S3).Дополнительные сведения о настройке потоков см. в разделе Оптимизация производительности.
Это руководство описывает развертывание ClickHouse с репликацией в Google Cloud, где Google Cloud Storage (GCS) используется в качестве типа диска хранения ClickHouse.В этом руководстве вы развернете узлы сервера ClickHouse на виртуальных машинах Google Cloud Engine, при этом с каждым узлом будет связан отдельный GCS-бакет для хранения данных. Репликация координируется набором узлов ClickHouse Keeper, также развернутых на виртуальных машинах.Примерные требования для высокой доступности:
Два узла сервера ClickHouse в двух регионах GCP
Два GCS-бакета, развернутые в тех же регионах, что и два узла сервера ClickHouse
Три узла ClickHouse Keeper, два из которых развернуты в тех же регионах, что и узлы сервера ClickHouse. Третий может находиться в том же регионе, что и один из первых двух узлов Keeper, но в другой зоне доступности.
Для работы ClickHouse Keeper требуется два узла, поэтому для высокой доступности необходимы три узла.
Разверните ClickHouse на двух хостах; в примерах конфигураций они обозначены как chnode1 и chnode2.Разместите chnode1 в одном регионе GCP, а chnode2 — в другом. В этом руководстве для виртуальных машин Compute Engine, а также для бакетов GCS используются регионы us-east1 и us-east4.
Не запускайте clickhouse server, пока не завершите его настройку. Пока что просто установите его.
При выполнении шагов развертывания на узлах сервера ClickHouse сверяйтесь с инструкциями по установке.
Разверните ClickHouse Keeper на трех хостах; в примерах конфигурации они называются keepernode1, keepernode2 и keepernode3. keepernode1 можно развернуть в том же регионе, что и chnode1, keepernode2 — вместе с chnode2, а keepernode3 — в любом из регионов, но в другой зоне доступности по сравнению с узлом ClickHouse в этом регионе.При выполнении шагов развертывания на узлах ClickHouse Keeper обратитесь к инструкции по установке.
Два сервера ClickHouse будут размещены в разных регионах для обеспечения высокой доступности. У каждого из них будет GCS-бакет в том же регионе.В Cloud Storage > Buckets выберите CREATE BUCKET. В этом руководстве создаются два бакета: один в us-east1, другой — в us-east4. Бакеты создаются в одном регионе, со стандартным классом хранилища и без публичного доступа. При появлении соответствующего запроса включите запрет публичного доступа. Не создавайте папки — они будут созданы, когда ClickHouse начнет записывать данные в хранилище.Если вам нужны пошаговые инструкции по созданию бакетов и HMAC-ключа, разверните Create GCS buckets and an HMAC key и следуйте инструкциям:
Создание ключа HMAC и секрета для сервисного аккаунта
Откройте Cloud Storage > Settings > Interoperability и либо выберите существующий Access key, либо CREATE A KEY FOR A SERVICE ACCOUNT. В этом руководстве рассматривается создание нового ключа для нового сервисного аккаунта.
Если в проекте ещё нет сервисного аккаунта, нажмите CREATE NEW ACCOUNT.Создание сервисного аккаунта состоит из трёх шагов; на первом шаге задайте аккаунту понятные имя, ID и описание.В диалоговом окне настроек Interoperability рекомендуется роль IAM Storage Object Admin; выберите эту роль на втором шаге.Третий шаг необязателен и в этом руководстве не используется. Вы можете предоставить пользователям эти привилегии в соответствии с вашими политиками.Будет показан ключ HMAC сервисного аккаунта. Сохраните эту информацию, так как она будет использоваться в конфигурации ClickHouse.
У всех узлов ClickHouse Keeper один и тот же файл конфигурации, за исключением строки server_id (первая выделенная строка ниже). Измените файл, указав имена хостов для ваших серверов ClickHouse Keeper, и на каждом сервере задайте server_id так, чтобы он соответствовал нужной записи server в raft_configuration. Поскольку в этом примере для server_id задано значение 3, мы выделили соответствующие строки в raft_configuration.
Измените файл, указав имена хостов, и убедитесь, что они разрешаются с узлов сервера ClickHouse и узлов Keeper
Скопируйте файл в нужное место (/etc/clickhouse-keeper/keeper_config.xml на каждом из серверов Keeper
Измените server_id на каждой машине в соответствии с номером её записи в raft_configuration
рекомендуемая практикаНа некоторых этапах этого руководства вам потребуется поместить файл конфигурации в /etc/clickhouse-server/config.d/. Это стандартное расположение в Linux для файлов переопределения конфигурации. Когда вы помещаете эти файлы в этот каталог, ClickHouse объединяет их содержимое с конфигурацией по умолчанию. Размещая такие файлы в каталоге config.d, вы избежите потери конфигурации при обновлении.
По умолчанию ClickHouse прослушивает только интерфейс loopback; в реплицированной конфигурации требуется сетевое взаимодействие между машинами. Включите прослушивание на всех интерфейсах:
В этом файле задаются имя хоста и порт каждого сервера ClickHouse в кластере. В файле конфигурации по умолчанию содержатся примеры определений кластеров; чтобы отображались только полностью настроенные кластеры, в запись remote_servers добавлен тег replace="true". Благодаря этому при слиянии с конфигурацией по умолчанию секция remote_servers заменяется, а не дополняется.
Измените файл, указав свои имена хостов, и убедитесь, что они разрешаются с узлов сервера ClickHouse
В этом файле настраиваются параметры, связанные с путём ClickHouse Keeper. В частности, здесь задаются макросы, используемые для определения того, к какой реплике относятся данные. На одном сервере реплика должна быть указана как replica_1, а на другом сервере — replica_2. Имена можно изменить: например, если одна реплика хранится в Южной Каролине, а другая — в Северной Виргинии, значениями могут быть carolina и virginia; просто убедитесь, что на каждой машине они различаются.
Конфигурация хранилища ClickHouse включает disks и policies. Настраиваемый ниже диск называется gcs и имеет types3. Тип — s3, потому что ClickHouse обращается к GCS бакету как к AWS S3 бакету. Потребуются две копии этой конфигурации, по одной для каждого узла сервера ClickHouse.В приведенной ниже конфигурации нужно выполнить следующие подстановки.Эти подстановки различаются между двумя узлами сервера ClickHouse:
Для REPLICA 1 BUCKET должно быть указано имя бакета в том же регионе, что и сервер
Значение REPLICA 1 FOLDER должно быть изменено на replica_1 на одном из серверов и на replica_2 на другом
Эти подстановки одинаковы для обоих узлов:
В access_key_id должен быть указан HMAC Key, сгенерированный ранее
В secret_access_key должен быть указан HMAC Secret, сгенерированный ранее
Отправьте команды в ClickHouse Keeper с помощью netcat. Например, mntr возвращает состояние кластера ClickHouse Keeper. Если выполнить эту команду на каждом из узлов Keeper, вы увидите, что один из них — leader, а два других — followers:
Просматривая бакеты, вы увидите, что в каждом из них была создана папка с именем, указанным в файле конфигурации storage.xml. Разверните папки, и вы увидите множество файлов, представляющих собой партиции данных.
