Перейти к основному содержимому
Перейти к основному содержимому

Интеграция Google Cloud Storage с ClickHouse

примечание

Если вы используете ClickHouse Cloud на Google Cloud, эта страница вам не подходит, так как ваши сервисы уже используют Google Cloud Storage. Если вы хотите SELECT или INSERT данные из GCS, пожалуйста, смотрите gcs таблица функция.

ClickHouse признает, что GCS представляет собой привлекательное решение для хранения для пользователей, которые стремятся разделить хранение и вычисления. Чтобы помочь в достижении этого, поддерживается использование GCS в качестве хранилища для движка MergeTree. Это позволит пользователям воспользоваться масштабируемостью и экономическими преимуществами GCS, а также производительностью вставок и запросов движка MergeTree.

GCS Backed MergeTree​

Создание диска​

Чтобы использовать бакет GCS в качестве диска, мы сначала должны объявить его в конфигурации ClickHouse в файле под conf.d. Пример объявления диска GCS показан ниже. Эта конфигурация включает в себя несколько разделов для настройки "диска" GCS, кэша и политики, которая указывается в DDL запросах, когда таблицы должны быть созданы на диске GCS. Каждый из этих разделов описан ниже.

storage_configuration > disks > gcs​

Эта часть конфигурации показана в выделенном разделе и указывает, что:

  • Пакетные удаления не должны выполняться. GCS в настоящее время не поддерживает пакетные удаления, поэтому автодетект отключен для подавления сообщений об ошибках.
  • Тип диска - s3, поскольку используется API S3.
  • Конечная точка, предоставленная GCS.
  • HMAC ключ и секрет сервисного аккаунта.
  • Путь к метаданным на локальном диске.

storage_configuration > disks > cache​

Пример конфигурации, выделенный ниже, включает 10Gi памяти в кэше для диска gcs.

storage_configuration > policies > gcs_main​

Политики конфигурации хранения позволяют выбирать, где хранятся данные. Выделенная ниже политика позволяет данным храниться на диске gcs, указывая политику gcs_main. Например, CREATE TABLE ... SETTINGS storage_policy='gcs_main'.

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

Создание таблицы​

Предполагая, что вы настроили диск для использования бакета с правами на запись, вы должны иметь возможность создать таблицу, как в приведенном ниже примере. Для краткости мы используем подмножество колонок такси NYC и передаем данные непосредственно в таблицу с поддержкой GCS:

В зависимости от аппаратного обеспечения, эта последняя вставка 1 миллиона строк может занять несколько минут для выполнения. Вы можете подтвердить прогресс через таблицу system.processes. Не стесняйтесь увеличивать количество строк до предела в 10 миллионов и исследовать несколько примеров запросов.

Обработка репликации​

Репликация с дисками GCS может быть выполнена с помощью движка таблиц ReplicatedMergeTree. См. репликацию единого шардирования в двух регионах GCP с использованием GCS для получения подробностей.

Узнать больше​

Cloud Storage XML API совместим с некоторыми инструментами и библиотеками, которые работают с такими сервисами, как Amazon Simple Storage Service (Amazon S3).

Для получения дополнительной информации о настройке потоков смотрите Оптимизация для производительности.

Использование Google Cloud Storage (GCS)​

подсказка

Объектное хранилище используется по умолчанию в ClickHouse Cloud, вам не нужно следовать этой процедуре, если вы работаете в ClickHouse Cloud.

Планирование развертывания​

Этот учебник написан для описания реплицированного развертывания 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 ServerБакетУзел ClickHouse Keeper
1chnode1bucket_regionnamekeepernode1
2chnode2bucket_regionnamekeepernode2
3 *keepernode3

* Это может быть другая зона доступности в том же регионе, что и 1 или 2.

Развертывание ClickHouse​

Разверните ClickHouse на двух хостах, в примерных конфигурациях они называются chnode1, chnode2.

Поместите chnode1 в один регион GCP, а chnode2 во второй. В этом руководстве используются us-east1 и us-east4 для ВМ compute engine, а также для бакетов GCS.

примечание

Не запускайте clickhouse server, пока он не будет настроен. Просто установите его.

Смотрите инструкции по установке при выполнении шагов развертывания на узлах сервера ClickHouse.

Развертывание ClickHouse Keeper​

Разверните 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 ключа, то разверните Создание бакетов GCS и HMAC ключа и следуйте за ним:

Create GCS buckets and an HMAC key

ch_bucket_us_east1​

ch_bucket_us_east4​

Generate an Access key​

Create a service account HMAC key and secret​

Open Cloud Storage > Settings > Interoperability and either choose an existing Access key, or CREATE A KEY FOR A SERVICE ACCOUNT. This guide covers the path for creating a new key for a new service account.

Add a new service account​

If this is a project with no existing service account, CREATE NEW ACCOUNT.

There are three steps to creating the service account, in the first step give the account a meaningful name, ID, and description.

In the Interoperability settings dialog the IAM role Storage Object Admin role is recommended; select that role in step two.

Step three is optional and not used in this guide. You may allow users to have these privileges based on your policies.

The service account HMAC key will be displayed. Save this information, as it will be used in the ClickHouse configuration.

Настройка ClickHouse Keeper​

Все узлы 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.

Настройка сервера ClickHouse​

best practice

Некоторые из шагов в этом руководстве попросят вас разместить файл конфигурации в /etc/clickhouse-server/config.d/. Это стандартное местоположение на системах Linux для файлов переопределения конфигурации. Когда вы помещаете эти файлы в этот каталог, ClickHouse объединяет содержимое с конфигурацией по умолчанию. Путем размещения этих файлов в каталоге config.d вы избежите потери своей конфигурации во время обновления.

Сеть​

По умолчанию ClickHouse прослушивает интерфейс обратной связи, в реплицированной настройке связь между машинами необходима. Прослушивайте на всех интерфейсах:

Удаленные узлы ClickHouse Keeper​

Репликация координируется ClickHouse Keeper. Этот файл конфигурации идентифицирует узлы ClickHouse Keeper по имени хоста и номеру порта.

  • Измените имена хостов так, чтобы они соответствовали вашим узлам Keeper.

Удаленные узлы ClickHouse​

Этот файл настраивает имя хоста и порт каждого узла ClickHouse в кластере. Файл конфигурации по умолчанию содержит примерные определения кластеров, для того чтобы показать только кластеры, которые полностью настроены, к записи remote_servers добавляется тег replace="true", чтобы, когда эта конфигурация объединяется с конфигурацией по умолчанию, она заменяла раздел remote_servers вместо добавления к нему.

  • Отредактируйте файл с вашими именами хостов и убедитесь, что они разрешаются с узлов сервера ClickHouse.

Идентификация реплики​

Этот файл настраивает параметры, относящиеся к пути ClickHouse Keeper. В частности, макросы, используемые для идентификации, к какой реплике принадлежат данные. На одном сервере реплика должна быть указана как replica_1, а на другом сервере - replica_2. Имена могут быть изменены, исходя из нашего примера, где одна реплика хранится в Южной Каролине, а другая в Северной Вирджинии, значения могут быть carolina и virginia; просто убедитесь, что они разные на каждой машине.

Хранение в GCS​

Конфигурация хранения ClickHouse включает в себя disks и policies. Диск, который настраивается ниже, называется gcs и имеет type s3. Тип - s3, потому что ClickHouse получает доступ к бакету GCS так, как будто он является бакетом AWS S3. Понадобится две копии этой конфигурации, по одной для каждого узла сервера ClickHouse.

В конфигурации ниже должны быть сделаны следующие замены.

Эти замены различаются между двумя узлами сервера ClickHouse:

  • REPLICA 1 BUCKET должен быть установлен на имя бакета в том же регионе, что и сервер.
  • REPLICA 1 FOLDER должен быть изменен на replica_1 на одном из серверов, а на другом - на replica_2.

Эти замены общи для двух узлов:

  • Значение access_key_id должно быть установлено на HMAC ключ, сгенерированный ранее.
  • Значение secret_access_key должно быть установлено на HMAC секрет, сгенерированный ранее.

Запуск ClickHouse Keeper​

Используйте команды для вашей операционной системы, например:

Проверка статуса ClickHouse Keeper​

Отправляйте команды в ClickHouse Keeper с помощью netcat. Например, mntr возвращает состояние кластера ClickHouse Keeper. Если вы выполните команду на каждом из узлов Keeper, вы увидите, что один из них является лидером, а два других - последователями:

Запуск сервера ClickHouse​

На chnode1 и chnode2 выполните:

Проверка​

Проверка конфигурации диска​

system.disks должен содержать записи для каждого диска:

  • default
  • gcs
  • cache

Проверка, что таблицы, созданные в кластере, созданы на обоих узлах​

Проверка, что данные можно вставить​

Проверка, что для таблицы используется политика хранения gcs_main.​

Проверка в Google Cloud Console​

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

Бакет для первой реплики​

Бакет для второй реплики​