CHECK_SUM

Содержание раздела

Синтаксис
Ограничения
Примеры
Порядок расчета контрольных сумм
1. Расчет контрольной суммы по таблице или представлению
  1. Пример расчета контрольной суммы по таблице
2. Расчет контрольной суммы по логической базе данных

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

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

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

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

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

Контрольная сумма рассчитывается по каждой СУБД хранилища, которая хранит данные проверяемой логической сущности. Порядок расчета описан ниже.

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

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

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

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

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

Синтаксис

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: Опциональный список имен столбцов, по которым рассчитывается контрольная сумма. Элементы списка перечисляются в квадратных скобках через запятую.
Если столбцы не указаны, система рассчитывает контрольную сумму по всем столбцам таблицы или представления.

Ограничения

Ограничения выполнения

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

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

Контрольная сумма по всей логической базе данных рассчитывается только по данным логических таблиц. Данные логических и материализованных представлений не учитываются.
Расчет контрольной суммы недоступен:
- для логических представлений, содержащих данные 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 в седьмой дельте:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если логическое представление принадлежит одной (основной) логической БД, а его таблицы-источники принадлежат другой логической БД, контрольная сумма такого представления рассчитывается по изменениям за один период — за время действия указанной дельты в основной логической БД. Под временем действия дельты delta_num понимается период с закрытия предыдущей дельты до закрытия этой дельты ([delta_num - 1, delta_num]).

Учитывается совпадение периодов действия дельт, а не их номеров. Например, из одной логической базы данных могут быть выбраны изменения дельты 2, а из другой — изменения дельт 10, 11 и 12.

В таблице ниже показано, как значения столбцов (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.

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

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

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

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

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

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

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