CHECK_SUM_SNAPSHOT

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

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

Поддерживается в версиях: 7.4 / 7.3 / 7.2 / 7.1 / 7.0 / 6.12 / 6.11 / 6.10 / 6.9 / 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.

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

Запрос может содержать индексированные и именованные параметры.

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

• на указанную дельту — если в запросе задан ее номер;
• на последнюю закрытую дельту или завершенную операции записи вне дельты (что было последним на указанный момент времени) — если в запросе задан момент времени. Данные открытой дельты в этом случае не учитываются.

Подробнее о порядке расчета контрольной суммы см. ниже.

Чтобы рассчитать контрольную сумму по внесенным изменениям (а не итоговому состоянию данных), используйте CHECK_SUM, по выбранным строкам — SELECT с функцией CHECK_SUM_INT64 или CHECK_SUM_MD5.

Связанные запросы

• CHECK_SUM,
• SELECT с функцией CHECK_SUM_INT64 или CHECK_SUM_MD5,
• CHECK_DATA.

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

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

• обычным логическим таблицам,
• партициям,
• прокси-таблицам*,
• логическим представлениям,
• материализованным представлениям.

* Контрольная сумма прокси-таблицы всегда рассчитывается по ее текущим данным. В запросе по прокси-таблице можно указать номер любой закрытой дельты в логической БД.

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

• по обычным логическим таблицам,
• по партициям.

Для партиционированных таблиц в ответе всегда возвращается 0.

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

Контрольную сумму можно рассчитать:

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

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

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

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

Отключенные датасорсы пропускаются при расчете без возврата ошибки и не отображаются в ответе.

Особенности расчета для значений типа FLOAT и DOUBLE

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

• используйте тип DOUBLE для всех значений с плавающей точкой (он больше распространен среди СУБД, чем FLOAT);
• исключайте столбцы типа FLOAT и DOUBLE из запросов CHECK_SUM_SNAPSHOT.

Синтаксис

Запрос по сущности:

CHECK_SUM_SNAPSHOT( { delta_num | date_time }[, normalization], [db_name.]entity_name[, column_list] )

Запрос по предварительно выбранной логической БД:

CHECK_SUM_SNAPSHOT( { delta_num | date_time }[, normalization] )

Запрос может содержать: константы, индексированные параметры, именованные параметры или их сочетание.

Параметры:

delta_num (BIGINT | INT64 | LONG)

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

date_time (TIMESTAMP | VARCHAR | CHAR | STRING)

Дата и время, по состоянию на которые рассчитывается контрольная сумма, в формате YYYY-MM-DD hh:mm:ss[.SSSSSS].

normalization (BIGINT | INT64 | LONG)

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

Принимает целые значения от 1 (по умолчанию).

Если не указан или равен 1, запрос может проверить до 4'294'967'298 записей в каждой сущности; при увеличении коэффициента лимит растет пропорционально.

db_name (VARCHAR | CHAR | STRING)

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

entity_name (VARCHAR | CHAR | STRING)

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

column_list (VARCHAR | CHAR | STRING)

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

В параметризованном запросе элементы списка указываются в одном параметре (см. пример ниже), в остальных случаях — перечисляются в квадратных скобках через запятую (например, [id, product_code]).

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

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

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

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

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

Ограничения

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

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

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

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

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

• Расчет контрольной суммы в открытой дельте доступен только для логических таблиц.
• При обработке запроса отключенные (Датасорс, отключенный системой из-за сбоя или администратором
  ) датасорсы (СУБД или кластер СУБД хранилища
  ) пропускаются без возврата ошибки. Ошибка возвращается, если не осталось ни одного включенного (Датасорс, работающий в штатном режиме
  ) датасорса, подходящего для исполнения запроса.

Примеры

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

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

CHECK_SUM_SNAPSHOT(7,marketing.basic_stores_table,[id, category, region])

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

Ответ CHECK_SUM_SNAPSHOT по отдельным столбцам таблицы

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

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

CHECK_SUM_SNAPSHOT(7,marketing.basic_stores_table)

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

Ответ CHECK_SUM_SNAPSHOT по логической таблице при наличии расхождений

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

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

CHECK_SUM_SNAPSHOT(7, matview_db.sales_by_stores)

Расчет по всем столбцам логического представления

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

-- использование метки времени с точностью до секунд
CHECK_SUM_SNAPSHOT('2022-03-25 07:30:32', marketing.agreements_with_client_info);

-- использование метки времени с точностью до микросекунд
CHECK_SUM_SNAPSHOT('2022-03-25 07:30:32.354826', marketing.agreements_with_client_info);

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

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

CHECK_SUM_SNAPSHOT(2, marketing.sales_jan_2023)

Расчет по всем столбцам прокси-таблицы

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

CHECK_SUM_SNAPSHOT(0, marketing.payments_proxy)

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

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

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

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

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

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

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

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

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

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

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

CHECK_SUM_SNAPSHOT с коэффициентом нормализации

Запросы с индексированными параметрами

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

CHECK_SUM_SNAPSHOT(?, ?, ?)

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

CHECK_SUM_SNAPSHOT(?, ?, ?, ?)

Пример cURL-запроса:

curl -X POST \
  'http://localhost:9090/api/v1/datamarts/marketing/query?format=json' \
  -H 'x-request-id: 302a1498-5483-4cb0-8c21-e3a60f49e4e3' \
  -H 'Content-Type: application/json' \
  -d '{   
  "query": "CHECK_SUM_SNAPSHOT(?, ?, ?, ?)",   
  "queryId": "26478293847",   
  "params": [     
    {         
      "value": 0,       
      "type": "LONG"     
    },
    {         
      "value": 10,       
      "type": "LONG"     
    },
    {          
      "value": "marketing.sales",       
      "type": "STRING"     
    },     
    {        
      "value": "id, product_code",       
      "type": "STRING"     
    }
  ] 
}'

Запросы с именованными параметрами

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

CHECK_SUM_SNAPSHOT(:timestamp_param, :normalization, :entity_name_with_db)

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

CHECK_SUM_SNAPSHOT(:timestamp_param, :normalization, :entity_name_with_db_name, :column_list)

Пример cURL-запроса:

curl -X POST \
  'http://localhost:9090/api/v1/datamarts/marketing/query?format=json' \
  -H 'x-request-id: 5bd313cb-c3c7-4695-ad90-a304818eb3a2' \
  -H 'Content-Type: application/json' \
  -d '{   
  "query": "CHECK_SUM(:timestamp_param, :normalization, :entity_name_with_db_name, :column_list)",   
  "queryId": "836567298",   
  "params": [     
    {      
      "name": "timestamp_param",       
      "value": "2022-03-25 07:30:32.123",       
      "type": "TIMESTAMP"     
    },
    {      
      "name": "normalization",       
      "value": 10,       
      "type": "LONG"     
    },
    {       
      "name": "entity_name_with_db_name",       
      "value": "marketing.sales",       
      "type": "STRING"     
    },     
    {       
      "name": "column_list",       
      "value": "id, product_code",       
      "type": "STRING"     
    }
  ] 
}'

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

Порядок расчета по таблице или представлению

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

Если логическое представление и его сущности-источники принадлежат разным логическим БД, контрольная сумма представления рассчитывается по данным источников, выбранным на основе меток времени дельт в БД представления. Например, для дельты 10 представления могут использоваться данные источника из дельты 2.

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

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

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