Data pipelines¶
Требования применяются к разработке, тестированию и сборке batch- и streaming-
pipeline, преобразующего данные между источником и назначением. Эксплуатация
платформы и расписаний находится вне области документа. Уровни обязательности
определены в корневом README.md.
DATA-PIPE-001. Версионируемый контракт dataset¶
Уровень: MUST
Применяется к: каждому входному и выходному dataset
Проект должен хранить машинно-проверяемую схему, семантику полей, ключ, event time или snapshot time и правила отсутствующего значения. Код pipeline должен проверяться с точной версией входного и выходного контракта.
Обоснование¶
Совпадение физического типа не гарантирует совпадение смысла данных.
Проверка¶
- schema validation fixtures;
- contract-тест source и sink adapters;
- проверка версии схемы в сборке.
Исключения¶
Не допускаются для межкомпонентного dataset.
DATA-PIPE-002. Совместимость изменения схемы¶
Уровень: MUST
Применяется к: изменению входного или выходного контракта
CI должен классифицировать изменение как совместимое или несовместимое для каждого consumer. Удаление, переименование, изменение смысла и сужение допустимых значений требует новой версии и теста параллельной обработки поддерживаемых версий.
Добавление значения enum совместимо только для enum, который контракт заранее объявляет расширяемым и для которого consumer имеет определённый fallback.
Обоснование¶
Исторические данные продолжают существовать после обновления producer.
Проверка¶
- automated schema diff;
- тест старых и новых fixtures;
- consumer contract tests.
Исключения¶
Исправление до первой публикации dataset не является изменением опубликованного контракта.
DATA-PIPE-003. Детерминированное преобразование¶
Уровень: MUST
Применяется к: преобразованию входной записи или snapshot
При одинаковых коде, конфигурации и входных данных pipeline должен создавать функционально эквивалентный результат. Время обработки, случайность, locale и порядок чтения не должны неявно влиять на результат.
Обоснование¶
Недетерминированный pipeline нельзя безопасно повторить или сверить.
Проверка¶
- повторный запуск одного fixture с изменённым порядком;
- сравнение нормализованного результата;
- тест зафиксированных clock, locale и seed.
Исключения¶
Случайная выборка допустима с зафиксированным seed и алгоритмом.
DATA-PIPE-004. Идемпотентный restart и replay¶
Уровень: MUST
Применяется к: повторной обработке диапазона входных данных
Повторный запуск не должен создавать дубликат необратимого результата. Граница
checkpoint и запись результата должны быть атомарны либо согласованы
идемпотентным ключом. Overlap тестового диапазона не должен создавать
непредусмотренный дубликат, а gap должен обнаруживаться сверкой полноты по
DATA-PIPE-006.
Обоснование¶
Restart после неопределённого результата неизбежно повторяет часть входа.
Проверка¶
- fault-injection до и после записи checkpoint;
- повтор одного диапазона;
- тест overlap и gap.
Исключения¶
Полная замена изолированного snapshot допустима через атомарную публикацию готового результата.
DATA-PIPE-005. Обработка невалидных данных¶
Уровень: MUST
Применяется к: записи, не соответствующей схеме или инварианту
Контракт должен определять блокирование batch, изоляцию записи или явное отбрасывание. Невалидная запись не должна молча преобразовываться в пустое, нулевое или фиктивное значение. Изолированный результат должен сохранять идентификатор и стабильный код причины без раскрытия запрещённых данных.
Обоснование¶
Молчаливая подстановка превращает ошибку качества в правдоподобные данные.
Проверка¶
- property- и boundary-тесты parser;
- fixture каждого класса ошибки;
- проверка результата частично невалидного batch.
Исключения¶
Значение по умолчанию допустимо только как часть версионируемого контракта поля.
DATA-PIPE-006. Сверка полноты¶
Уровень: MUST
Применяется к: тестированию результата pipeline
Набор тестов должен проверять определённые контрактом инварианты полноты для полного и частичного диапазона. Проверка должна обнаруживать пропуск и непредусмотренный дубликат с помощью применимых свойств: связи количества входов и выходов, уникальности ключа, checkpoint либо контрольного агрегата. Допустимое расхождение должно быть численно определено контрактом.
Обоснование¶
Успешное завершение процесса не доказывает полноту результата.
Проверка¶
- reconciliation test фиксированного dataset;
- тест дубликата и пропуска;
- тест граничного допустимого расхождения.
Исключения¶
При преобразовании один-ко-многим или многие-к-одному используется контрактно определённая функция сверки вместо равенства количества записей.