Как перенести таблицу oracle в clickhouse
Перейти к содержимому

Как перенести таблицу oracle в clickhouse

  • автор:

Oracle/ClickHouse. DWH. Партицирование как средство быстрого обновления данных

В этой статье хотелось бы рассмотреть такой вопрос — как частичное обновление больших объемов данных в таблицах, которые активно используются пользователями на чтение. Задача является типовой, и с ней сталкивается каждый инженер данных. При этом не важно на какой ступеньке своей карьерной лестницы вы находитесь, Junior или Senior, такие задачи будут.

Что мы имеем:

  • Огромная витрина с даннымиSALES, содержащая множество атрибутов по продажам в абстрактной системе.
  • Существует ETL-процесс, не важно на какой технологии, который подготавливает SALES_INCREMENT для витрины на основании ряда источников, которые могут поставлять данные по одной продаже в разные периоды времени с задержками до недели-месяца (период инкремента).
  • Каждая итерация инкремента содержит полные актуальные данные за несколько полных месяцев назад + новые данные. Скажем 500млн+ строк.
  • Имеются аналитические системы, которые постоянно обращаются к данным SALES для чтения. Их природа также не важна. Это могут быть прямые запросы из отчетов, запросы для промежуточной агрегации и формирования более узких витрин данных. Главное, что нужно понимать — данные постоянно читаются. И даже ночью у вас нет спасения, чтобы спокойно провести пересчет.

Задача: Обновить данные в таблице SALES на основании SALES_INCREMENT таким образом, чтобы вам не пришлось объясняться перед разгневанными пользователями и коллегами за зависания запросов или испорченные данные в смежных витринах.

Попытки решить без партицирования

На ум сразу приходит стандартный алгоритм: Insert для новых строк, update для старых и задача решена.

Но, например в Oracle, таким подходом можем уложить запросы пользователей по snapshot too old в случае, если запросы долгие, а наше обновление переполнит журнал и приведет к его скидыванию в архив. И не важно какими порциями вы фиксируете данные. Про БД, где нет версионности, вообще молчу. Система просто встанет из-за блокировки таблиц на чтение.

Кроме этого — новые строки мы вставим легкими запросами, а вот старые нам придется обновлять через merge или иными методами, нагружая систему еще и выборками данных, помимо их вставки. Во избежание merge и сложной логики можно удалять обновляемые строки и просто заменять их новым. Использовать принятый в DWH delete + insert. Но тут раздуваем undo/redo и рискуем надолго уйти в Downtime если система по какой то причине начнет откатывать транзакцию. Понятное дело, что опытные разработчики модифицируют данную схему, чтобы все работало. Вплоть до отключения журналов. Но это долго, сложно, дорого по ресурсам и иногда эффективность достигается путем отказа от ACID (Привет от хинтов или связки drop table + rename tmp_table to table)

В общем писать потоковую загрузку с insert/merge/update/delete можно. И так даже делают. И это работает. Но наша цель найти более эффективный и современный способ.

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

ClickHouse

Данную базу выбрал как пример, по одной простой причине, переключение партиций в ней максимально простая операция. И работа с партициями поставлена на поток. Вызвано это тем, что колоночно-аналитическая природа СУБД и ее фокус на скорострельности ограничивает возможности по обновлению существующих данных.

Все что нужно сделать для эффективного решения вопросов обновления — прибегнуть к стандартной DDL операции:

alter table sales replace partition (202308) from sales_increment

В данном случае вы замените все данные в SALES за август 2023 года (ну при условии что идет партицирование по месяцам) копией данных из SALES_INCREMENT. В SALES_INCREMENT данные останутся — далее вы можете делать с ними что хотите. Чаще всего таблицу просто удаляют после копирования всех партиций до следующей итерации ETL.

Иногда может возникнуть необходимость дописать данные, не удаляя весь август. Тогда используем move partition:

alter table sales move partition (202308) from sales_increment

В данном случае мы переместим данные из SALES_INCREMENT и допишем их в SALES. В SALES_INCREMENT данные пропадут.

Ну а для автоматизации процесса, можно загнать копирование в цикл по всем доступным партициям инкрементальной таблицы.

select distinct partition from system.parts where table = 'sales_increment'

Вообще в ClickHouse много инструментов для менеджмента данных на уровне партиций. Более подробно про них можно прочитать в документации к БД: ClickHouse. Работа с партициями

Oracle

Я не могу не остановиться на данной СУБД, так как это мой хлеб. И в какой то момент времени мне подкинули идею провернуть трюк с партициями и в нашей БД. Однако все оказалось не так просто как в ClickHouse, но реализовать технологию после пары приседанй удалось.

В чем трудность подобного фокуса в Оракл? Да в том, что данная СУБД поддерживает обмен партициями в двух режимах:

  • Из непартицированной таблицы в партицированную
  • Из партицированной таблицы в непартицированную

По своим архитектурным или иным соображениям не реализовали в Oracle решение по обмену между двумя партицированными таблицами.

Но мы же с вами понимаем, что подобное ограничение никак не мешает нам совершить обмен. Просто придется добавить промежуточную непартицированную таблицу и перегонять содержимое через нее. Приступим.

Нам потребуется документация на exchange partition: Oracle. Работа с партициями

Первое, что нужно сделать — это поместить данные из исходной партицированной таблицы в промежуточную непартицированную sales_increment_staging:

alter table sales_increment exchange partition SYS_XXX with table sales_increment_staging without validation

Хочу обратить внимание, что without validation критично ускоряет процесс переключения, а так как мы все таки размышляем с позиции DWH, то считаем, что данные уже миллион раз проверены на целостность, и делать это еще раз — пустая трата ресурсов и времени. Однако, если с этим будут проблемы — всегда можно убрать директиву.

Следующим шагом перемещаем данные из промежуточной таблицы в целевую

alter table sales exchange partition SYS_YYY with table sales_increment_staging without validation

Происходит полная замена данных в целевой таблице. Потому стоит помнить, что если мы применяем подобный подход в Oracle, то партиция инкремента должна содержать полные данные. Формально БД на уровне метаданных превращает таблицу в партицию. А старую партицию удаляет (также на уровне метаданных).

Выглядит это примерно так:

  • Сегмент данных промежуточной таблицы SALES_INCREMENT_STAGING заменяет сегмент с партицией в таблице SALES
  • Старый сегмент с партицией SALES остается в БД. Т.е пока живут запросы чтения, начавшиеся до фиксации переключения партиций, данный сегмент остается видимым ими по требованиям уровня изоляции Read Commited

Хочу обратить отдельное внимание на следствие данного алгоритма — версионность данных Oracle работает при использовании данной DDL операции. И все запросы смогут дочитать данные, которые были в таблице SALES до того как их подменили. А новые запросы увидят уже новую партицию. Данный вопрос подробно не рассматривается нигде, но мы вынуждены были провести тесты, чтобы убедиться что система переноса безопасна.

Также из алгоритма вытекает требование — осторожно относиться к создаваемой таблице. Она должна иметь такие же настройки табличного пространства, что и те таблицы, с которыми мы производим обмен. С версии 12.2 появился лайфхак, который позволит нам избавиться от головной боли при создании SATGING таблиц:

create table sales_increment_staging for exchange with table sales_increment

Одной очень полезной функцией оказалась возможность менять партиции по значению. Для этого нужно использовать конструкцию partition for. В данном случае можно будет подменить партицию по значению, а не по имени партиции. Т.е если вы знаете, что в таблице sales_increment_staging находится август 2023 года, то просто передайте значение ключа партицирования в качестве параметра.

alter table sales exchange partition for (date'2023-08-01') with table sales_increment_staging without validation

Еще одним отличием обмена партициями по имени и по значению является тот факт, что обмен по имени требует наличия партиции с этим именем в целевой таблице, а по значению — не требует. Ну при условии того, что включено автосоздание партиций.

Однако все СУБД требуют соблюдения ряда правил, для того, чтобы технология работала:

  • Одинаковая структура таблиц — для всех СУБД. Это логичное требование
  • Одинаковые ключи партицирования для случаев с СУБД, где доступен обмен между двумя партицированными таблицами
  • Одинаковая политика хранения таблиц на диске (для ClickHouse)
  • И прочее, о чем можно прочитать в документации к конкретной СУБД

Что же мы получили:

  • Быстрое и простое обновление данных в целевых таблицах, не вынуждающее нас писать сложный код.
  • Почти все затраты на утилизацию и блокировки ложатся на стандартные механизмы обеспечения согласованности данных СУБД, так как мы работаем со стандартным DDL.
  • Все UNDO/REDO пишутся для таблицы инкремента, а не для основной таблицы. Таким образом в том же Oracle, мы защищаем себя от ошибки snapshot too old на длительных выборках по SALES.
  • Мы вообще отвязываемся от логики ETL. Т.е даже если поменяется код, наша логика обновления всегда будет работать. Нужно только актуализировать структуры таблиц.
  • Нам не нужно будет ограничивать ETL по объему, опасаясь долгого обновления основной таблицы. Операция обмена партициями быстра в любой БД и на самых больших объемах.
  • Мы можем варьировать периоды инкремента. Грузить месяц несколько раз в день. Полгода по ночам. Год раз в месяц. Все зависит от бизнеса и частоты обновления данных в тот или иной период в прошлом.
  • партиционирование
  • oracle
  • clickhouse
  • exchange partition

Как подключить ClickHouse к Oracle Data Integrator Studio 12c?

Такая проблема, требуется реализовать сценарий в ODI для переноса данных из таблицы БД Oracle в таблицу БД ClickHouse. Но при добавлении ClicHouse в логическую схему ODI надо указать драйвер СУБД которого нет в списке. Возможно ли подключить ClickHouse к ODI? Если да то как?

  • Вопрос задан более трёх лет назад
  • 234 просмотра

Комментировать
Решения вопроса 0
Ответы на вопрос 1

dimonchik2013

Dimonchik @dimonchik2013
non progredi est regredi

да, через драйвер

напишите драйвер или возьмите неофициальный

Репликация данных

Репликация поддерживается только для таблиц семейства MergeTree:

  • ReplicatedMergeTree
  • ReplicatedSummingMergeTree
  • ReplicatedReplacingMergeTree
  • ReplicatedAggregatingMergeTree
  • ReplicatedCollapsingMergeTree
  • ReplicatedVersionedCollapsingMergeTree
  • ReplicatedGraphiteMergeTree

Репликация работает на уровне отдельных таблиц, а не всего сервера. То есть, на сервере могут быть расположены одновременно реплицируемые и не реплицируемые таблицы.

Репликация не зависит от шардирования. На каждом шарде репликация работает независимо.

Реплицируются сжатые данные запросов INSERT , ALTER (см. подробности в описании запроса ALTER).

Запросы CREATE , DROP , ATTACH , DETACH и RENAME выполняются на одном сервере и не реплицируются:

  • Запрос CREATE TABLE создаёт новую реплицируемую таблицу на том сервере, где его выполнили. Если таблица уже существует на других серверах, запрос добавляет новую реплику.
  • DROP TABLE удаляет реплику, расположенную на том сервере, где выполняется запрос.
  • Запрос RENAME переименовывает таблицу на одной реплик. Другими словами, реплицируемые таблицы на разных репликах могут называться по-разному.

ClickHouse хранит метаинформацию о репликах в Apache ZooKeeper. Используйте ZooKeeper 3.4.5 или новее.

Для использовании репликации, установите параметры в секции zookeeper конфигурации сервера.

Не пренебрегайте настройками безопасности. ClickHouse поддерживает ACL схему digest подсистемы безопасности ZooKeeper.

Пример указания адресов кластера ZooKeeper:

zookeeper> node index="1"> host>example1host> port>2181port> node> node index="2"> host>example2host> port>2181port> node> node index="3"> host>example3host> port>2181port> node> zookeeper> 

Можно указать любой имеющийся у вас ZooKeeper-кластер — система будет использовать в нём одну директорию для своих данных (директория указывается при создании реплицируемой таблицы).

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

При запросах SELECT , ZooKeeper не используется, т.е. репликация не влияет на производительность SELECT и запросы работают так же быстро, как и для нереплицируемых таблиц. При запросах к распределенным реплицированным таблицам поведение ClickHouse регулируется настройками max_replica_delay_for_distributed_queries and fallback_to_stale_replicas_for_distributed_queries.

При каждом запросе INSERT , делается около десятка записей в ZooKeeper в рамках нескольких транзакций. (Чтобы быть более точным, это для каждого вставленного блока данных; запрос INSERT содержит один блок или один блок на max_insert_block_size = 1048576 строк.) Это приводит к некоторому увеличению задержек при INSERT , по сравнению с нереплицируемыми таблицами. Но если придерживаться обычных рекомендаций — вставлять данные пачками не более одного INSERT в секунду, то это не составляет проблем. На всём кластере ClickHouse, использующим для координации один кластер ZooKeeper, может быть в совокупности несколько сотен INSERT в секунду. Пропускная способность при вставке данных (количество строчек в секунду) такая же высокая, как для нереплицируемых таблиц.

Для очень больших кластеров, можно использовать разные кластеры ZooKeeper для разных шардов. Впрочем, на кластере Яндекс.Метрики (примерно 300 серверов) такой необходимости не возникает.

Репликация асинхронная, мульти-мастер. Запросы INSERT и ALTER можно направлять на любой доступный сервер. Данные вставятся на сервер, где выполнен запрос, а затем скопируются на остальные серверы. В связи с асинхронностью, только что вставленные данные появляются на остальных репликах с небольшой задержкой. Если часть реплик недоступна, данные на них запишутся тогда, когда они станут доступны. Если реплика доступна, то задержка составляет столько времени, сколько требуется для передачи блока сжатых данных по сети. Количество потоков для выполнения фоновых задач можно задать с помощью настройки background_schedule_pool_size.

Движок ReplicatedMergeTree использует отдельный пул потоков для скачивания кусков данных. Размер пула ограничен настройкой background_fetches_pool_size, которую можно указать при перезапуске сервера.

По умолчанию, запрос INSERT ждёт подтверждения записи только от одной реплики. Если данные были успешно записаны только на одну реплику, и сервер с этой репликой перестал существовать, то записанные данные будут потеряны. Вы можете включить подтверждение записи от нескольких реплик, используя настройку insert_quorum .

Каждый блок данных записывается атомарно. Запрос INSERT разбивается на блоки данных размером до max_insert_block_size = 1048576 строк. То есть, если в запросе INSERT менее 1048576 строк, то он делается атомарно.

Блоки данных дедуплицируются. При многократной записи одного и того же блока данных (блоков данных одинакового размера, содержащих одни и те же строчки в одном и том же порядке), блок будет записан только один раз. Это сделано для того, чтобы в случае сбоя в сети, когда клиентское приложение не может понять, были ли данные записаны в БД, можно было просто повторить запрос INSERT . При этом не имеет значения, на какую реплику будут отправлены INSERT-ы с одинаковыми данными. Запрос INSERT идемпотентный. Параметры дедуплицирования регулируются настройками сервера merge_tree

При репликации, по сети передаются только исходные вставляемые данные. Дальнейшие преобразования данных (слияния) координируются и делаются на всех репликах одинаковым образом. За счёт этого минимизируется использование сети, и благодаря этому, репликация хорошо работает при расположении реплик в разных дата-центрах. (Стоит заметить, что дублирование данных в разных дата-центрах, по сути, является основной задачей репликации).

Количество реплик одних и тех же данных может быть произвольным. В Яндекс.Метрике в продакшене используется двукратная репликация. На каждом сервере используется RAID-5 или RAID-6, в некоторых случаях RAID-10. Это является сравнительно надёжным и удобным для эксплуатации решением.

Система следит за синхронностью данных на репликах и умеет восстанавливаться после сбоя. Восстановление после сбоя автоматическое (в случае небольших различий в данных) или полуавтоматическое (когда данные отличаются слишком сильно, что может свидетельствовать об ошибке конфигурации).

Создание реплицируемых таблиц​

В начало имени движка таблицы добавляется Replicated . Например, ReplicatedMergeTree .

Параметры Replicated * MergeTree

  • zoo_path — путь к таблице в ZooKeeper.
  • replica_name — имя реплики в ZooKeeper.
  • other_parameters — параметры движка, для которого создаётся реплицированная версия, например, версия для ReplacingMergeTree .
CREATE TABLE table_name (  EventDate DateTime,  CounterID UInt32,  UserID UInt32,  ver UInt16 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/-/table_name', '', ver) PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID); 

Пример в устаревшем синтаксисе

CREATE TABLE table_name (  EventDate DateTime,  CounterID UInt32,  UserID UInt32 ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/-/table_name', '', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192); 

Как видно в примере, эти параметры могут содержать подстановки в фигурных скобках. Эти подстановки заменяются на соответствующие значения из конфигурационного файла, из секции macros.

macros> layer>05layer> shard>02shard> replica>example05-02-1.yandex.rureplica> macros> 

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

/clickhouse/tables/ — общий префикс. Рекомендуется использовать именно его.

— — идентификатор шарда. В данном примере он состоит из двух частей, так как на кластере Яндекс.Метрики используется двухуровневое шардирование. Для большинства задач, оставьте только подстановку , которая будет раскрываться в идентификатор шарда.

table_name — имя узла для таблицы в ZooKeeper. Разумно делать его таким же, как имя таблицы. Оно указывается явно, так как, в отличие от имени таблицы, оно не меняется после запроса RENAME. Подсказка: можно также указать имя базы данных перед table_name , например db_name.table_name

Имя реплики — то, что идентифицирует разные реплики одной и той же таблицы. Можно использовать для него имя сервера, как показано в примере. Впрочем, достаточно, чтобы имя было уникально лишь в пределах каждого шарда.

Можно не использовать подстановки, а указать соответствующие параметры явно. Это может быть удобным для тестирования и при настройке маленьких кластеров. Однако в этом случае нельзя пользоваться распределенными DDL-запросами ( ON CLUSTER ).

При работе с большими кластерами мы рекомендуем использовать подстановки, они уменьшают вероятность ошибки.

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

default_replica_path>/clickhouse/tables/// default_replica_path> default_replica_name> default_replica_name> 

В этом случае можно опустить аргументы при создании таблиц:

CREATE TABLE table_name (  x UInt32 ) ENGINE = ReplicatedMergeTree ORDER BY x; 

Это будет эквивалентно следующему запросу:

CREATE TABLE table_name (  x UInt32 ) ENGINE = ReplicatedMergeTree('/clickhouse/tables///table_name', '') ORDER BY x; 

Выполните запрос CREATE TABLE на каждой реплике. Запрос создаёт новую реплицируемую таблицу, или добавляет новую реплику к имеющимся.

Если вы добавляете новую реплику после того, как таблица на других репликах уже содержит некоторые данные, то после выполнения запроса, данные на новую реплику будут скачаны с других реплик. То есть, новая реплика синхронизирует себя с остальными.

Для удаления реплики, выполните запрос DROP TABLE . При этом, удаляется только одна реплика — расположенная на том сервере, где вы выполняете запрос.

Восстановление после сбоя​

Если при старте сервера, недоступен ZooKeeper, реплицируемые таблицы переходят в режим только для чтения. Система будет пытаться периодически установить соединение с ZooKeeper.

Если при INSERT недоступен ZooKeeper, или происходит ошибка при взаимодействии с ним, будет выкинуто исключение.

При подключении к ZooKeeper, система проверяет соответствие между имеющимся в локальной файловой системе набором данных и ожидаемым набором данных (информация о котором хранится в ZooKeeper). Если имеются небольшие несоответствия, то система устраняет их, синхронизируя данные с реплик.

Обнаруженные битые куски данных (с файлами несоответствующего размера) или неизвестные куски (куски, записанные в файловую систему, но информация о которых не была записана в ZooKeeper) переносятся в поддиректорию detached (не удаляются). Недостающие куски скачиваются с реплик.

Стоит заметить, что ClickHouse не делает самостоятельно никаких деструктивных действий типа автоматического удаления большого количества данных.

При старте сервера (или создании новой сессии с ZooKeeper), проверяется только количество и размеры всех файлов. Если у файлов совпадают размеры, но изменены байты где-то посередине, то это обнаруживается не сразу, а только при попытке их прочитать при каком-либо запросе SELECT . Запрос кинет исключение о несоответствующей чексумме или размере сжатого блока. В этом случае, куски данных добавляются в очередь на проверку, и при необходимости, скачиваются с реплик.

Если обнаруживается, что локальный набор данных слишком сильно отличается от ожидаемого, то срабатывает защитный механизм. Сервер сообщает об этом в лог и отказывается запускаться. Это сделано, так как такой случай может свидетельствовать об ошибке конфигурации — например, если реплика одного шарда была случайно сконфигурирована, как реплика другого шарда. Тем не менее, пороги защитного механизма поставлены довольно низкими, и такая ситуация может возникнуть и при обычном восстановлении после сбоя. В этом случае, восстановление делается полуавтоматически — «по кнопке».

Для запуска восстановления, создайте в ZooKeeper узел /path_to_table/replica_name/flags/force_restore_data с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц:

$ sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data 

Затем запустите сервер. При старте, сервер удалит эти флаги и запустит восстановление.

Восстановление в случае потери всех данных​

Если на одном из серверов исчезли все данные и метаданные, восстановление делается следующим образом:

  1. Установите на сервер ClickHouse. Корректно пропишите подстановки в конфигурационном файле, отвечающие за идентификатор шарда и реплики, если вы их используете.
  2. Если у вас были нереплицируемые таблицы, которые должны быть вручную продублированы на серверах, скопируйте их данные (в директории /var/lib/clickhouse/data/db_name/table_name/ ) с реплики.
  3. Скопируйте с реплики определения таблиц, находящиеся в /var/lib/clickhouse/metadata/ . Если в определениях таблиц, идентификатор шарда или реплики, прописаны в явном виде — исправьте их, чтобы они соответствовали данной реплике. (Альтернативный вариант — запустить сервер и сделать самостоятельно все запросы ATTACH TABLE , которые должны были бы быть в соответствующих .sql файлах в /var/lib/clickhouse/metadata/ .)
  4. Создайте в ZooKeeper узел /path_to_table/replica_name/flags/force_restore_data с любым содержимым или выполните команду для восстановления всех реплицируемых таблиц: sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data

Затем запустите сервер (перезапустите, если уже запущен). Данные будут скачаны с реплик.

В качестве альтернативного варианта восстановления, вы можете удалить из ZooKeeper информацию о потерянной реплике ( /path_to_table/replica_name ), и затем создать реплику заново, как написано в разделе Создание реплицированных таблиц .

Отсутствует ограничение на использование сетевой полосы при восстановлении. Имейте это ввиду, если восстанавливаете сразу много реплик.

Преобразование из MergeTree в ReplicatedMergeTree​

Здесь и далее, под MergeTree подразумеваются все движки таблиц семейства MergeTree , так же для ReplicatedMergeTree .

Если у вас была таблица типа MergeTree , репликация которой делалась вручную, вы можете преобразовать её в реплицируемую таблицу. Это может понадобиться лишь в случаях, когда вы уже успели накопить большое количество данных в таблице типа MergeTree , а сейчас хотите включить репликацию.

Если на разных репликах данные отличаются, то сначала синхронизируйте их, либо удалите эти данные на всех репликах кроме одной.

Переименуйте имеющуюся MergeTree таблицу, затем создайте со старым именем таблицу типа ReplicatedMergeTree . Перенесите данные из старой таблицы в поддиректорию detached в директории с данными новой таблицы ( /var/lib/clickhouse/data/db_name/table_name/ ). Затем добавьте эти куски данных в рабочий набор с помощью выполнения запросов ALTER TABLE ATTACH PARTITION на одной из реплик.

Преобразование из ReplicatedMergeTree в MergeTree​

Создайте таблицу типа MergeTree с другим именем. Перенесите в её директорию с данными все данные из директории с данными таблицы типа ReplicatedMergeTree . Затем удалите таблицу типа ReplicatedMergeTree и перезапустите сервер.

Если вы хотите избавиться от таблицы ReplicatedMergeTree , не запуская сервер, то

  • удалите соответствующий файл .sql в директории с метаданными ( /var/lib/clickhouse/metadata/ );
  • удалите соответствующий путь в ZooKeeper ( /path_to_table/replica_name );

После этого, вы можете запустить сервер, создать таблицу типа MergeTree , перенести данные в её директорию, и перезапустить сервер.

Восстановление в случае потери или повреждения метаданных на ZooKeeper кластере​

Если данные в ZooKeeper оказались утеряны или повреждены, то вы можете сохранить данные, переместив их в нереплицируемую таблицу, как описано в пункте выше.

Смотрите также

  • background_schedule_pool_size
  • background_fetches_pool_size
  • execute_merges_on_single_replica_time_threshold
  • max_replicated_fetches_network_bandwidth
  • max_replicated_sends_network_bandwidth

How to load data from Oracle DB to Clickhouse

Learn how to use Airbyte to synchronize your Oracle DB data into Clickhouse within minutes.

Try Airbyte Cloud free
Deploy Airbyte Open Source
What is Oracle DB
What is Clickhouse
Step 1: Setup Oracle DB
Step 2: Setup Clickhouse
Example H2
Example H3

Get your data syncing in minutes

Try Airbyte free

TL;DR

This can be done by building a data pipeline manually, usually a Python script (you can leverage a tool as Apache Airflow for this). This process can take more than a full week of development. Or it can be done in minutes on Airbyte in three easy steps:

  1. set up Oracle DB as a source connector (using Auth, or usually an API key)
  2. set up Clickhouse as a destination connector
  3. define which data you want to transfer and how frequently

You can choose to self-host the pipeline using Airbyte Open Source or have it managed for you with Airbyte Cloud.

This tutorial’s purpose is to show you how.

What is Oracle DB

Oracle DB is a fully scalable integrated cloud application and platform service; it is also referred to as a relational database architecture. It provides management and processing of data for both local and wide and networks. Offering software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS), it sells a large variety of enterprise IT solutions that help companies streamline the business process, lower costs, and increase productivity.

What is Clickhouse

ClickHouse is an open-source, column-oriented OLAP database management system that allows users to generate analytical reports using SQL queries. Also offered as a secure and scalable service in the cloud, ClickHouse Cloud allows anyone to effortlessly take advantage of efficient real time analytical processing​.

Prerequisites

  1. A Oracle DB account to transfer your customer data automatically from.
  2. A Clickhouse account.
  3. An active Airbyte Cloud account, or you can also choose to use Airbyte Open Source locally. You can follow the instructions to set up Airbyte on your system using docker-compose.

Airbyte is an open-source data integration platform that consolidates and streamlines the process of extracting and loading data from multiple data sources to data warehouses. It offers pre-built connectors, including Oracle DB and Clickhouse, for seamless data migration.

When using Airbyte to move data from Oracle DB to Clickhouse, it extracts data from Oracle DB using the source connector, converts it into a format Clickhouse can ingest using the provided schema, and then loads it into Clickhouse via the destination connector. This allows businesses to leverage their Oracle DB data for advanced analytics and insights within Clickhouse, simplifying the ETL process and saving significant time and resources.

Step 1: Set up Oracle DB as a source connector

1. Open the Airbyte platform and navigate to the «Sources» tab on the left-hand side of the screen.

2. Click on the «Oracle DB» source connector and select «Create new connection».

3. Enter a name for your connection and click «Next».

4. In the «Connection Configuration» section, enter the following information:
— Host: the hostname or IP address of your Oracle DB server
— Port: the port number used to connect to your Oracle DB server
— Database: the name of the database you want to connect to
— Username: your Oracle DB username
— Password: your Oracle DB password

5. Click «Test connection» to ensure that the connection is successful.

6. If the connection is successful, click «Next» to proceed to the «Schema Selection» section.

7. In the «Schema Selection» section, select the schema(s) you want to replicate data from.

8. Click «Create connection» to save your connection settings.

9. You can now create a new Oracle DB source in Airbyte and start replicating data from your Oracle DB database.

Step 2: Set up Clickhouse as a destination connector

Step 3: Set up a connection to sync your Oracle DB data to Clickhouse

Once you’ve successfully connected Oracle DB as a data source and Clickhouse as a destination in Airbyte, you can set up a data pipeline between them with the following steps:

  1. Create a new connection: On the Airbyte dashboard, navigate to the ‘Connections’ tab and click the ‘+ New Connection’ button.
  2. Choose your source: Select Oracle DB from the dropdown list of your configured sources.
  3. Select your destination: Choose Clickhouse from the dropdown list of your configured destinations.
  4. Configure your sync: Define the frequency of your data syncs based on your business needs. Airbyte allows both manual and automatic scheduling for your data refreshes.
  5. Select the data to sync: Choose the specific Oracle DB objects you want to import data from towards Clickhouse. You can sync all data or select specific tables and fields.
  6. Select the sync mode for your streams: Choose between full refreshes or incremental syncs (with deduplication if you want), and this for all streams or at the stream level. Incremental is only available for streams that have a primary cursor.
  7. Test your connection: Click the ‘Test Connection’ button to make sure that your setup works. If the connection test is successful, save your configuration.
  8. Start the sync: If the test passes, click ‘Set Up Connection’. Airbyte will start moving data from Oracle DB to Clickhouse according to your settings.

Remember, Airbyte keeps your data in sync at the frequency you determine, ensuring your Clickhouse data warehouse is always up-to-date with your Oracle DB data.

Use Cases to transfer your Oracle DB data to Clickhouse

Integrating data from Oracle DB to Clickhouse provides several benefits. Here are a few use cases:

  1. Advanced Analytics: Clickhouse’s powerful data processing capabilities enable you to perform complex queries and data analysis on your Oracle DB data, extracting insights that wouldn’t be possible within Oracle DB alone.
  2. Data Consolidation: If you’re using multiple other sources along with Oracle DB, syncing to Clickhouse allows you to centralize your data for a holistic view of your operations, and to set up a change data capture process so you never have any discrepancies in your data again.
  3. Historical Data Analysis: Oracle DB has limits on historical data. Syncing data to Clickhouse allows for long-term data retention and analysis of historical trends over time.
  4. Data Security and Compliance: Clickhouse provides robust data security features. Syncing Oracle DB data to Clickhouse ensures your data is secured and allows for advanced data governance and compliance management.
  5. Scalability: Clickhouse can handle large volumes of data without affecting performance, providing an ideal solution for growing businesses with expanding Oracle DB data.
  6. Data Science and Machine Learning: By having Oracle DB data in Clickhouse, you can apply machine learning models to your data for predictive analytics, customer segmentation, and more.
  7. Reporting and Visualization: While Oracle DB provides reporting tools, data visualization tools like Tableau, PowerBI, Looker (Google Data Studio) can connect to Clickhouse, providing more advanced business intelligence options. If you have a Oracle DB table that needs to be converted to a Clickhouse table, Airbyte can do that automatically.

Wrapping Up

To summarize, this tutorial has shown you how to:

  1. Configure a Oracle DB account as an Airbyte data source connector.
  2. Configure Clickhouse as a data destination connector.
  3. Create an Airbyte data pipeline that will automatically be moving data directly from Oracle DB to Clickhouse after you set a schedule

With Airbyte, creating data pipelines take minutes, and the data integration possibilities are endless. Airbyte supports the largest catalog of API tools, databases, and files, among other sources. Airbyte’s connectors are open-source, so you can add any custom objects to the connector, or even build a new connector from scratch without any local dev environment or any data engineer within 10 minutes with the no-code connector builder.

We look forward to seeing you make use of it! We invite you to join the conversation on our community Slack Channel, or sign up for our newsletter. You should also check out other Airbyte tutorials, and Airbyte’s content hub!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *