Great Expectations 中自定义SQL期望的持久化问题解析

问题背景

在使用Great Expectations(版本1.2.4)进行数据质量验证时，开发人员发现了一个关于自定义SQL期望持久化的问题。当用户在Databricks环境中创建基于SQL的自定义期望并将其添加到期望套件(Expectation Suite)后，如果Python会话结束(如Databricks集群因不活动而关闭)，重新初始化数据上下文(Data Context)后，之前创建的自定义期望会丢失。

问题现象

开发人员按照以下步骤操作：

1. 创建数据源、数据资产和批处理定义
2. 定义一个继承自UnexpectedRowsExpectation的自定义期望类ExpectValidLineItemSum
3. 将该期望添加到期望套件中
4. 结束当前Python会话(通过重启Databricks集群)
5. 重新初始化数据上下文并尝试获取之前保存的期望套件

此时系统抛出ExpectationNotFoundError异常，提示"expect_valid_line_item_sum not found"，表明之前创建的自定义期望未能正确持久化。

技术原理分析

Great Expectations的期望套件实际上是存储在JSON文件中的，理论上应该能够持久保存自定义期望。但问题出在以下几个方面：

1. 自定义期望类的加载机制：Great Expectations在运行时需要能够识别自定义期望类。当Python会话结束时，所有内存中的类定义都会丢失。重新启动会话后，如果没有重新定义相同的自定义期望类，系统就无法识别之前保存的期望配置。

2. 期望类的序列化/反序列化：虽然期望配置被保存为JSON，但Great Expectations在加载时需要能够找到对应的Python类实现。如果类定义不存在，就无法正确重建期望对象。

3. UnexpectedRowsExpectation的特殊性：这个期望类型依赖于SQL查询，其验证逻辑与常规期望有所不同，需要特别注意其持久化方式。

解决方案

针对这个问题，Great Expectations社区在1.3.0版本中已经解决了这个问题。对于使用1.2.4版本的用户，可以采用以下临时解决方案：

1. 在每次会话开始时重新定义自定义期望类：确保在任何使用期望套件的Python会话中，都首先定义相同的自定义期望类。

2. 使用UnexpectedRowsExpectation直接创建期望：作为替代方案，可以直接使用UnexpectedRowsExpectation而不进行子类化，这样可以避免类定义丢失的问题。

3. 升级到1.3.0或更高版本：新版本已经修复了这个问题，提供了更稳定的自定义期望持久化机制。

最佳实践建议

1. 自定义期望的管理：对于重要的自定义期望，建议将其定义保存在单独的Python模块中，并在使用前显式导入。

2. 版本控制：将自定义期望的定义文件纳入版本控制系统，确保团队成员使用一致的实现。

3. 文档记录：详细记录每个自定义期望的用途、参数和SQL查询逻辑，便于后续维护。

4. 测试验证：在部署前验证自定义期望在不同会话间的持久化效果，确保其行为符合预期。

总结

Great Expectations作为强大的数据质量验证工具，其自定义期望功能提供了极大的灵活性。理解其持久化机制对于构建可靠的数据质量监控系统至关重要。通过遵循上述解决方案和最佳实践，开发人员可以确保自定义SQL期望在不同会话间正确持久化，从而构建更加健壮的数据验证流程。