CHECK_SUM

Содержание раздела
  1. Поддерживаемые сущности
  2. Режимы расчета контрольной суммы
  3. Учитываемые датасорсы
  4. Особенности проверки значений с плавающей точкой
  5. Синтаксис
  6. Варианты ответа
  7. Ограничения
    1. Ограничения сущностей
    2. Ограничения точности
    3. Другие ограничения
  8. Примеры
    1. Запрос по отдельным столбцам логической таблицы
    2. Запрос по всем столбцам логической таблицы
    3. Запрос по всем столбцам материализованного представления
    4. Запрос по всем столбцам партиции
    5. Запрос по логической базе данных
    6. Запрос по логической базе данных с коэффициентом нормализации
  9. Порядок расчета контрольных сумм
    1. Расчет контрольной суммы по таблице или представлению
    2. Конвертация значений столбцов
    3. Пример расчета контрольной суммы по таблице
    4. Расчет контрольной суммы по логической базе данных

Поддерживается в версиях:  6.8 / 6.7 / 6.6 / 6.5 / 6.4 / 6.3 / 6.2 / 6.1 / 6.0 / 5.8 / 5.7 / 5.6 / 5.5 / 5.4 / 5.3 / 5.2 / 5.1 / 5.0.

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

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

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

Поддерживаемые сущности

Запрос поддерживает расчет контрольной суммы по следующим сущностям:

Расчет контрольной суммы по логическому представлению доступен, если представление построено на данных СУБД ADB, ADG и (или) ADP.
Расчет контрольной суммы в открытой дельте доступен только для логических таблиц.

Расчет контрольной суммы для партиционированных таблиц недоступен. Для таких таблиц запрос возвращает 0.

Режимы расчета контрольной суммы

Контрольную сумму можно рассчитать в следующих режимах:

  • по отдельным столбцам сущности,
  • по всем столбцам сущности,
  • по всем столбцам всех логических таблиц логической базы данных.

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

Учитываемые датасорсы

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

Особенности проверки значений с плавающей точкой

Значения с типами FLOAT и DOUBLE могут иметь разные контрольные суммы из-за разницы в точности типов. Чтобы избежать расхождения в контрольных суммах, используйте для всех значений с плавающей точкой тип DOUBLE (как более распространенный среди СУБД) или исключайте столбцы с типами FLOAT и DOUBLE из запросов CHECK_SUM.

Синтаксис

CHECK_SUM(delta_num[, normalization][, [db_name.]entity_name[, square_bracketed_column_list]])

Параметры:

delta_num

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

normalization

Опциональный коэффициент, который повышает лимит на количество проверяемых записей в одной сущности, но снижает уникальность контрольных сумм. Может принимать любое целое значение, начиная с 1. Значение по умолчанию — 1.
Если коэффициент не указан или равен 1, запрос может проверить до 4'294'967'298 записей в каждой сущности; при увеличении коэффициента лимит увеличивается пропорционально.

db_name

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

entity_name

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

square_bracketed_column_list

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

Варианты ответа

В ответе возвращается:

  • объект ResultSet с контрольной суммой при успешном выполнении запроса и отсутствии расхождений между датасорсами;
  • исключение при наличии расхождений или неуспешном выполнении запроса.

При наличии расхождений в ответе возвращается исключение с текстом ошибки Consistency breach detected for <entity_name> и списком контрольных сумм по проверенным датасорсам. Если расхождение найдено при расчете контрольной суммы по логической базе данных, система возвращает исключение при первом найденном расхождении и не проверяет следующие сущности.

Ограничения

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

  • Контрольная сумма по всей логической базе данных рассчитывается только по данным логических таблиц. Данные логических и материализованных представлений не учитываются.
  • Расчет контрольной суммы недоступен:
    • для логических представлений, основанных на данных СУБД ADQM;
    • для логических представлений, основанных на прокси-таблицах и (или) standalone-таблицах;
    • для партиционированных таблиц.
  • Максимальное количество записей в одной сущности, по которым можно рассчитать контрольную сумму, ограничено и регулируется коэффициентом нормализации.

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

  • Есть небольшая вероятность, что контрольные суммы совпадут для разных наборов данных.
  • Значения типа FLOAT и DOUBLE могут приводить к расхождениям в контрольных суммах из-за разницы в точности типов.

Другие ограничения

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

Примеры

Запрос по отдельным столбцам логической таблицы

Расчет контрольной суммы по трем столбцам таблицы sales в седьмой дельте:

CHECK_SUM(7, marketing.sales, [id, transaction_date, product_code])

На рисунках ниже показаны примеры ответов на запрос CHECK_SUM с перечислением столбцов: на первом — ответ при отсутствии расхождений в данных между датасорсами, на втором — ответ при наличии расхождений.

Ответ CHECK_SUM по отдельным столбцам таблицы при отсутствии расхождений

Ответ CHECK_SUM при наличии расхождений

Запрос по всем столбцам логической таблицы

Расчет контрольной суммы по всей таблице sales в седьмой дельте:

CHECK_SUM(7, marketing.sales)

На рисунке ниже показан пример ответа CHECK_SUM по логической таблице.

Ответ CHECK_SUM по логической таблице

Запрос по всем столбцам материализованного представления

Расчет контрольной суммы по всему материализованному представлению sales_by_stores в десятой дельте:

CHECK_SUM(10, marketing.sales_by_stores)

Запрос по всем столбцам партиции

Расчет контрольной суммы по всей партиции marketing.sales_jan_2023 во второй дельте:

CHECK_SUM(2, marketing.sales_jan_2023)

Запрос по логической базе данных

Расчет контрольной суммы по всем таблицам логической базы данных marketing в седьмой дельте:

-- выбор логической базы данных marketing в качестве базы данных по умолчанию
USE marketing;

-- расчет контрольной суммы логической БД
CHECK_SUM(7);

На рисунке ниже показан пример ответа CHECK_SUM по логической базе данных.

Ответ CHECK_SUM по логической базе данных

Запрос по логической базе данных с коэффициентом нормализации

Расчет контрольной суммы по всем таблицам логической базы данных marketing с коэффициентом нормализации, равным 100:

-- выбор логической базы данных marketing в качестве базы данных по умолчанию
USE marketing;

-- расчет контрольной суммы логической БД с указанным коэффициентом нормализации
CHECK_SUM(7, 100);

На рисунке ниже показан пример ответа на такой запрос.

Запрос CHECK_SUM с коэффициентом нормализации

Порядок расчета контрольных сумм

Расчет контрольной суммы по таблице или представлению

Контрольная сумма по логической таблице, логическому или материализованному представлению рассчитывается в следующем порядке:

  1. В соответствующей физической таблице выбираются записи, которые были загружены и (или) обновлены в указанной дельте и операциях записи, выполненных между указанной дельтой и предшествующей ей.
  2. По каждой записи:
    1. Формируется текстовая строка: значения столбцов записи конвертируются в зависимости от типа данных и записываются через точку с запятой. Значение NULL записывается как пустая строка. Подробнее о конвертации значений см. ниже.
    2. Для полученной строки вычисляется MD5-хеш в виде байтовой последовательности в шестнадцатеричном формате.
    3. Хеш интерпретируется как ASCII-строка в нижнем регистре.
    4. Выбираются первые 4 символа строки, выстраиваются в порядке от младшего к старшему (little endian) и конвертируются в целое 32-битное число.
    5. Полученное число делится на коэффициент нормализации, дробная часть результата отбрасывается — получается контрольная сумма записи.
  3. Контрольные суммы всех выбранных записей суммируются — получается 64-битная контрольная сумма изменений в логической сущности.

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

Конвертация значений столбцов

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

Тип данных Порядок конвертации Пример
BOOLEAN (column_value)::int true -> 1
DATE column_value - make_date(1970, 01, 01) 2021-03-15 -> 18701
TIME (extract(epoch from column_value)*1000000)::bigint 13:01:44 -> 46904000000
TIMESTAMP (extract(epoch from column_value)*1000000)::bigint 2020-11-17 21:11:12 -> 1605647472000000
Другие типы данных column_value Иванов -> Иванов

Пример расчета контрольной суммы по таблице

Рассмотрим пример расчета контрольной суммы таблицы sales в дельте, в которой была добавлена одна запись со следующими значениями:

  • id = 10021,
  • transaction_date = 2020-11-17 21:11:12,
  • product_code = ABC1830.

В качестве коэффициента нормализации возьмем число 10.

Контрольная сумма таблицы рассчитывается так:

  1. Формируется строка для хеш-функции: 10021;1605647472000000;ABC1830.
  2. Вычисляется MD5-хеш: bedbead6aea8ca373d8f0a15713639c1.
  3. Выбираются первые 4 символа хеша: bedb.
  4. Символы интерпретируются как ASCII-строка в нижнем регистре: 98 101 100 98.
  5. Строка конвертируется в целое 32-битное число: 98*20 + 101*28 + 100*216 + 98*224 = 1650746722.
  6. Полученное значение делится на коэффициент нормализации, остаток отбрасывается: 1650746722 : 10 = 165074672.

Так как в таблицу добавлена одна запись в дельте, контрольная сумма таблицы в этой дельте равна полученной контрольной сумме записи (165074672).

Если бы в рассмотренной дельте в таблицу также была добавлена запись с контрольной суммой 87891666, итоговая контрольная сумма таблицы была бы равна 165074672 + 87891666 = 252966338.

Расчет контрольной суммы по логической базе данных

Контрольная сумма логической базы данных рассчитывается так:

  1. По каждой логической таблице в логической базе данных рассчитывается контрольная сумма, как описано выше.
  2. Контрольные суммы всех логических таблиц суммируются — получается 64-битная контрольная сумма логической базы данных.