- PVSM.RU - https://www.pvsm.ru -
В данной статье мне хотелось бы продолжить описание технологий [1], используемых в Банке ТКС при построении DWH. Статья может быть интересна тем, кто планирует использовать LogMining Change Data Capture (CDC) для репликации данных из операционных источников в онлайн-стэйджинг Хранилища, построенного на основе СУБД GreenPlum.
Во всех современных ИТ и финансовых организациях существует множество различных операционных учетных систем, которые предназначены для хранения и обработки операционных данных. Так как нагрузка на эти источники с целью построения отчетности не допустима (она может повлиять на производительность business-critical процессов), организации строят DWH, при этом загрузка данных в Хранилище в большинстве случаев производится по ночам в период наименьшей нагрузки на операционные системы.
Технология CDC LogMining позволяет решить сразу несколько задач:
— снижение нагрузки на операционные источники в момент загрузки данных в DWH. Продукты, реализующие данную технологию, в большинстве случаев читают транзакционные лог-файлы систем-источников, разбирают их и применяют в систему-приемник. Именно за счет того, что происходит разбор транзакционных логов средствами стороннего ПО и уменьшается нагрузки на системы-источники;
— онлайн (или близкая к онлайн) реплика данных системы-источника в системе-приемнике, что позволяет строить близкую к онлайн отчетность;
— возможность ETL-разработчикам обращаться к репликам таблиц источников в любое время (не только в те промежутки, которые выделены для чтения систем-источников);
— большинство продуктов параллельно с репликами позволяют создавать т.н. change-таблицы, в которых отображается вся история изменения в исходных таблицах-источниках.
DWH в Банке построено на базе СУБД GreenPlum, все необходимые для репликации источники данных — под управлением СУБД Oracle. Сводные показатели реплицируемых источников приведены в таблице:
Параметр | Значение |
---|---|
Количество систем-источников для репликации | 5 |
Количество реплицируемых таблиц | ~ 200 |
Объемы транзакционных логов (Гбайт/час) | |
|
10 |
|
160 |
|
~ 40 |
Суммарное количество операций в стуки | ~ 50 млн. |
В качестве CDC-решения нами рассматривались следующие продукты:
Механизмы применения изменений в приемник у различных CDC решений свои и во многом зависят от уровня supplemental logging на источнике (о supplemental logging рекомендую прочесть замечательную статью [2] Александра Рындина ). Oracle Golden Gate — система, которая замечательно может быть применена при полном supplemental logging (последовательно применяя на приемник в виде батча все INSERT, последний UPDATE по ключу и все DELETE). Особенностью одного из наших источников является то, что количество колонок в его таблицах — велико, количество обновлений строк в источнике — также велико, но при этом количество обновляемых полей в рамках одного update на источнике — мало. Включение полного supplemental logging на всех полях в источнике приводило к невероятному росту объемов транзакционных логов, и было принято решение о включении supplemental logging только на первичные ключи. В связи с этим пришлось писать сложные скрипты агрегации и применения изменений.
Итак, нами был выбран продукт Attunity Replicate. Он оказался единственным продуктом, удовлетворяющим всем требованиям нашего пилотного проекта. На момент начала внедрения актуальной была версия 2.0.
В этой версии был реализован единственный метод применения изменений — row-by-row, в котором каждое изменение на источнике применялось в приемник в виде самостоятельного SQL-запроса:
update target set f1=’a’, f2=’b’, f3=’c’ where key=’key1’
Недостатки этого подхода в Greenplum выявились сразу после включения в репликацию данных, объемы которых (как по количеству строк, так и по количеству операций) превышали те, которые мы использовали в пилотном проекте. Очевидно, что Greenplum не может переварить суммарное количество транзакций из баз-источников. С одной стороны, это аналитическая СУБД, не предназначенная для высокой транзакционной нагрузки, а с другой, суммарное количество транзакций всех баз-источников настолько велико, что будет проблемой для любой СУБД. Для такого рода CDC системы, на наш взгляд, оптимальным является режим мини-батчей, при котором на базе-приемнике изменения применяются в виде предварительно агрегированных детальных транзакций. Изменения копятся в CDC-системе, а затем раз, например, в минуту, применяются на приемнике. Такой режим мы применяли, ранее исследуя применимость GoldenGate. Были разработаны скрипты агрегации и применения изменений. Эти скрипты были переданы в Attunity для изучения. Детально изучив скрипты, Attunity выпускает новую версию replicate 2.1, в которой появляется режим мини-батчей. Теперь обновления могут применяться следующим образом:
update target
set f1 = decode(net.f1, null, target.f1, '<ATT_NULL>', null, net.f1)
,f2 = decode(net.f2, null, target.f2, '<ATT_NULL>', null, net.f2)
,...
from net
where target.key=net.key
Здесь net — это таблица, в которую изменения «предрасчитываются» самим Attunity Replicate. В результате внедрения этой доработки количество запросов к базе-приемнику резко сократилось и мы теперь способны обрабатывать полный объем изменений, которые производят наши источники. Данную технологию Attunity назвали turbo stream CDC [3] и она полностью себя оправдывает: при средней нагрузке на источнике данные реплицируются в GreenPlum с задержкой в среднем 60-80 секунд. Есть, конечно, проблемы. При пиковой нагрузке на источнике (например, при закрытии операционного дня) задержка возрастает, иногда значительно, вплоть до 1,5 часов. Причина кроется в том, что Attunity Replicate работает через LogMiner, который не всегда успевает обработать логи базы при пиковых нагрузках.
В процессе применения изменений возможны так называемые apply conflicts — конфликты применения изменений в приемник. К наиболее часто встречающимся можно отнести: 0 rows affected (на приемнике не обновилось ни одной записи) и duplicate keys (вставка в приемник записи, которая уже существует). При нормальной работе системы данные конфликты возможны при первоначальной загрузке, так как с целью обеспечения согласованности данных в приемнике, Replicate начинает захватывать изменения в данных немного раньше, чем полную выгрузку. Attuity Replicate обнаруживает такие конфликты и переходит в режим row-by-row, сохраняя их в специальную системную таблицу для дальнейшего разбора.
CDC – решения могут использовать два различных механизма для чтения транзакционных логов источника: свой собственный механизм (binary reader) и механизм самой СУБД – источника. В случае Oracle – это Oracle LogMiner, который может возвращать данные в двух режимах:
В режиме commited data производительность Oracle LogMiner ужасна и требует дополнительных ресурсов на источнике. В случае raw data производительность гораздо лучше, ресурсов требуется меньше, но в этом случае приложение должно взять на себя функции по дополнительному разбору возвращаемых LogMiner-ом результатов и формирования на этой основе SQL-statements, которые будут применены в приемник.
На данном этапе Attunity Replicate работает с использованием raw-режима Oracle LogMiner, но в их планах — стабилизировать собственный Binary Reader, который можно будет настроить на чтение транзакционных логов напрямую со стойки, где они хранятся, и даже незначительная нагрузка на систему-источник в момент захвата изменений исчезнет полностью.
В настоящий момент в production успешно работает версия 2.2, и параллельно тестируется версия 3.0 Attunity Replicate. Нагрузка на системы — источники (вне периодов первоначальной загрузки) оказалась не значительной — благодаря тому, что при вызове методов LogMiner’а используется режим raw data. Что касается GreenPlum, то здесь тоже все в порядке. Хоть число транзакций, выполняемых Attunity Replicate и велико, оно гораздо меньше того числа транзакций, которые выполняются на системах-источниках и в виду небольшого объема изменений, производимых каждой транзакцией, нагрузка на приемник так же не значительна.
Эта статья — уже второй шаг на пути освещения технологий DWH в нашем Банке. Впереди рассказ об online-wharehouse (основой которого, как не трудно догадаться, стал CDC Log mining) и много чего еще интересного.
Автор: ryabov-a-a
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/oracle/50871
Ссылки в тексте:
[1] продолжить описание технологий: http://habrahabr.ru/company/tcsbank/blog/155763/
[2] статью: http://www.oraclegis.com/blog/?p=1490
[3] turbo stream CDC: http://www.attunity.com/products/attunity-replicate/high-performance/attunity-turbostream-cdc
[4] Источник: http://habrahabr.ru/post/205454/
Нажмите здесь для печати.