company_banner

Data replication. Attunity Replicate and Greenplum



    В данной статье мне хотелось бы продолжить описание технологий, используемых в Банке ТКС при построении 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-решения нами рассматривались следующие продукты:
    • Oracle Golden Gate. Продукт, в настоящее время разрабатываемый и поддерживаемый Oracle. Замечательный, как нам показалось, продукт по части стабильности и производительности чтения изменений из систем-источников. Однако к недостаткам Golden Gate можно отнести то, что он не поддерживает GreenPlum из коробки, нет встроенных средств первоначальной загрузки данных
    • Informatica Data Replicator. Продукт, поддерживающий Oracle как источник и Greenplum как приемник, имеет инструменты первоначальной загрузки данных. Продукт гарантирует целостность данных между источником и приемником, однако, для этого требует наличие транзакционных логов на все открытые в момент старта репликации транзакции, что не всегда является допустимо в виду ограничения объема дисковых систем хранения транзакционных логов
    • Attunity Replicate. Новый продукт, поддерживающий Oracle как источник и Greenplum как приемник, так же как и Informatica Data Replicator имеет инструменты первоначальной загрузки данных. Решение имеет простую систему управления, нацелено на работу «out-of-the-box»

    Механизмы применения изменений в приемник у различных CDC решений свои и во многом зависят от уровня supplemental logging на источнике (о supplemental logging рекомендую прочесть замечательную статью Александра Рындина ). Oracle Golden Gate — система, которая замечательно может быть применена при полном supplemental logging (последовательно применяя на приемник в виде батча все INSERT, последний UPDATE по ключу и все DELETE). Особенностью одного из наших источников является то, что количество колонок в его таблицах — велико, количество обновлений строк в источнике — также велико, но при этом количество обновляемых полей в рамках одного update на источнике — мало. Включение полного supplemental logging на всех полях в источнике приводило к невероятному росту объемов транзакционных логов, и было принято решение о включении supplemental logging только на первичные ключи. В связи с этим пришлось писать сложные скрипты агрегации и применения изменений.

    Старт проекта в production


    Итак, нами был выбран продукт 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 и она полностью себя оправдывает: при средней нагрузке на источнике данные реплицируются в GreenPlum с задержкой в среднем 60-80 секунд. Есть, конечно, проблемы. При пиковой нагрузке на источнике (например, при закрытии операционного дня) задержка возрастает, иногда значительно, вплоть до 1,5 часов. Причина кроется в том, что Attunity Replicate работает через LogMiner, который не всегда успевает обработать логи базы при пиковых нагрузках.
    В процессе применения изменений возможны так называемые apply conflicts — конфликты применения изменений в приемник. К наиболее часто встречающимся можно отнести: 0 rows affected (на приемнике не обновилось ни одной записи) и duplicate keys (вставка в приемник записи, которая уже существует). При нормальной работе системы данные конфликты возможны при первоначальной загрузке, так как с целью обеспечения согласованности данных в приемнике, Replicate начинает захватывать изменения в данных немного раньше, чем полную выгрузку. Attuity Replicate обнаруживает такие конфликты и переходит в режим row-by-row, сохраняя их в специальную системную таблицу для дальнейшего разбора.

    Работа на LogMiner.


    CDC – решения могут использовать два различных механизма для чтения транзакционных логов источника: свой собственный механизм (binary reader) и механизм самой СУБД – источника. В случае Oracle – это Oracle LogMiner, который может возвращать данные в двух режимах:
    • commited data (возвращает DML только для commited-транзакций)
    • raw data (возвращает данные обо всех транзакциях)

    В режиме 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-warehouse (основой которого, как не трудно догадаться, стал CDC Log mining) и много чего еще интересного.
    Tinkoff.ru
    441,05
    IT’s Tinkoff.ru — просто о сложном
    Поделиться публикацией

    Комментарии 2

      0
      А можно узнать на каком железе все вертится, хотя бы вендоров :)

      Такая классная техническая статья и 3 плюса и 0 коментов. Мда…
        0
        Спасибо!
        Сейчас Replicate работает на сервере со следущей конфигурацией:
        Xeon X7650(32 cores), в интерконнект GreenPlum'a подключен через 1Gbit адаптеры (2 штуки). Редко когда загрузка CPU превышает 1-2%, на сеть нагрузка бывает только в моменты первоначальной заргузки и при пиках операций на источниках.
        А вообще, Replicate не сильно требователен к железу. При старте проекта в production система работала на виртуальной машине с гораздо более слабой конфигурацией и с теми же объемами данных, что сейчас. Справлялся.

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

      Самое читаемое