Аудит изменений в банке из коробки: Audit Table

Зачем банку audit trail на уровне CDC

Банку мало «перенести данные» в хранилище. Регуляторике, безопасности и расследованиям нужен прозрачный след изменений: какая операция (вставка, обновление, удаление), когда, над какой строкой и каким пользователем. В классическом подходе это кастомный ETL поверх CDC: отдельные таблицы истории, триггеры, ручная сборка before-image. Дорого в разработке и хрупко в поддержке.

В Qlik Replicate механизмы аудита встроены. Эта статья — практический разбор из обзора CDC в банке: какие режимы есть, чем отличаются и какой выбрать под compliance. Все примеры обезличены, фичи сверены с документацией Qlik.

Три режима apply: что куда пишется

Сначала разведём понятия, потому что их часто путают. В Qlik Replicate есть три способа, как изменения ложатся в target:

Apply Changes — это «текущий срез». Для аудита интересны два других режима: Change Tables и Audit Table.

Audit Table: весь банк в одной сущности

В режиме Audit Table все изменения из всех таблиц таска пишутся в одну общую таблицу с JSON-колонками. Это и есть готовый централизованный audit trail. Структура (по документации Qlik) включает:

• task_name — имя таска;
• change_seq — монотонная глобальная последовательность изменения;
• change_oper — тип операции (I / U / D / B — Before Image);
• stream_position — позиция в логе источника (SCN-эквивалент);
• schema_name, table_name — идентификация таблицы источника;
• operation — BEFOREIMAGE / INSERT / UPDATE / DELETE;
• transaction_id, timestamp — транзакция и время;
• change_record — новое состояние строки в JSON;
• bu_change_record — состояние до изменения (before-image) в JSON.

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

Change Tables: история DML по каждой таблице

Альтернатива — Change Tables. Здесь для каждой source-таблицы создаётся отдельная change-таблица с суффиксом (по умолчанию __ct, настраивается в Store Changes Settings). Каждое изменение — новая строка с системными полями операции. Это удобно, когда downstream-слои (ODS, витрины) хотят сами решать, как мёрджить, и нужно сохранить историю DML по каждой таблице отдельно (близко к SCD Type 2).

Header Columns: операция, время и пользователь в три клика

Иногда полный audit trail не нужен — достаточно дотянуть в целевую таблицу несколько системных полей. Это делают Header Columns через Global Transformation → Add Column. Метаданные изменения уже есть внутри, их просто вытягивают в колонки:

Для «даты вставки в target» (поля, которого Replicate сам не знает) добавляют колонку с выражением текущего времени на момент apply. Всё это — несколько кликов в едином UI, без кастомного кода.

Как это ложится в RegTech и lakehouse

Audit trail из коробки особенно ценен в связке с lakehouse. Поток изменений (Audit Table или Change Tables) уходит в Apache Doris / VeloDB, где на нём строятся витрины отчётности, контроль AML/антифрода и регуляторные выгрузки — с быстрой аналитикой и обновлениями по Unique Key. CDC отдаёт «что и когда изменилось», lakehouse — «быстро посчитать по этому». Подробно про регуляторный контур — в статье RegTech для банков.

Ограничения честно

• Audit Table и Change Tables увеличивают объём записи: история изменений хранится дополнительно — это нужно закладывать в ёмкость target.
• Очень «расширенное» логирование (полный audit по каждой записи) при неаккуратной настройке нагружает ресурсы — режим стоит включать осознанно, под конкретную регуляторную потребность, а не «на всякий случай».
• AR_H_USER заполняется там, где endpoint источника отдаёт пользователя; матрица поддержки зависит от типа источника.

Источники

• Qlik Replicate — Using an Audit table
• Qlik Replicate — Store Changes Settings
• Qlik Replicate — Header Columns