Было бы целесообразно получить более подробную информацию о сценарии использования, который вы имеете в виду. Как правило, сохранение результатов предложения с ограничениями и их автоматическое применение к новым наборам данных не является рекомендуемым подходом (если не антишаблоном).
Результаты предложения с ограничениями дают вам хорошую отправную точку для express ваших ожиданий относительно данные, основанные на результатах профилирования. Тем не менее, они должны быть проверены человеком, прежде чем применять их на новых данных. После подтверждения вы можете легко сгенерировать необходимый код проверки с помощью вызова .codeForConstraint
для индивидуального предложения ограничения. Это позволяет довольно легко собрать необходимый код проверки и включить его в свою кодовую базу.
Сохранение и повторное использование предложений об ограничениях без промежуточного аудита человеком больше похоже на случай использования обнаружения аномалий, когда вы стремитесь обеспечить что новые партии набора данных имеют свойства, аналогичные исходному входному набору данных, который вы использовали в качестве ссылки для предложения ограничения. Этот вариант использования более подробно обсуждается в документации Deequ .
При упоминании этих пунктов, если вам действительно нужно написать и перечитать предложения об ограничениях, вам необходимо черты Constraint
(и Analyzer
) сериализуются (с помощью их расширения Serializable
). Это разблокирует вас, но вам нужно будет поднять проблему / отправить PR в Github репозиторий . Если это будет принято, вы сможете сериализовать предложения об ограничениях следующим образом, используя подход сериализации из другого ответа StackOverflow :
val constraints = suggestionResult.constraintSuggestions
.flatMap {
case (_, suggestions) => suggestions.map(_.constraint)
}
val serializedConstraints: Array[Byte] = serialise(constraints)
val deserializedConstrinats: Iterable[Constraint] = deserialise(serializedConstraints)
.asInstanceOf[Iterable[Constraint]]