建议在 Python 虚拟环境中部署;仅支持 Python 3.10 至 3.14,3.15 及以上需设置 GX_PYTHON_EXPERIMENTAL 环境变量
great_expectations
fivetranApache-2.0活跃维护用声明式规则给数据加单元测试,校验数据质量、做数据剖析,让脏数据在进入下游前就被发现。
Always know what to expect from your data.
pip install great_expectations
import great_expectations as gx
context = gx.get_context()README 未说明
用声明式 Expectations 给数据写单元测试,让团队随时掌握数据质量
用声明式规则给数据加单元测试,校验数据质量、做数据剖析,让脏数据在进入下游前就被发现。
核心能力
- 用 Expectations 为数据编写可扩展的单元测试
- 自动为每组校验结果生成文档
- 提供团队通用的数据质量表达语言
- 在 Python 虚拟环境中安装并创建 Data Context
容易踩的坑
- 1.24.1最新正式版2026-10-22 · 2026-10-22 22:09 UTC
Highlights
-
Oracle and SingleStore support for LIKE-pattern Expectations — The four LIKE-pattern Expectations (ExpectColumnValuesToMatchLikePattern, ExpectColumnValuesToMatchLikePatternList, ExpectColumnValuesToNotMatchLikePattern, ExpectColumnValuesToNotMatchLikePatternList) now run on Oracle and SingleStore, where they previously raised NotImplementedError. MySQL support now covers every SQLAlchemy MySQL dialect, SingleStore gets the same backslash translation of
escapethat BigQuery and ClickHouse use, and dialects that cannot run LIKE patterns now raise a NotImplementedError with the dialect name rather than failing with an AttributeError. (#12274)import great_expectations.expectations as gxe batch.validate( gxe.ExpectColumnValuesToMatchLikePattern( column="name", like_pattern="a!_b", escape="!", ) ) -
The LIKE
escapecharacter now works on BigQuery and ClickHouse — BigQuery and ClickHouse have no ESCAPE clause, so the LIKE-pattern Expectations used to refuse anescapeargument on those dialects. The pattern is now rewritten into the backslash form both engines understand, matching the same rows asESCAPEdoes on PostgreSQL. A trailing unpaired escape character raises a ValueError before any SQL is sent, and patterns withoutescapeare still passed through verbatim. (#12291)import great_expectations.expectations as gxe # On BigQuery or ClickHouse: matches only the literal value "a_c" batch.validate( gxe.ExpectColumnValuesToMatchLikePattern( column="col", like_pattern="a!_c", escape="!", ) ) -
Snowflake key-pair authentication works again on snowflake-sqlalchemy 2.x — Creating an engine for a Snowflake datasource that uses key-pair authentication failed with a TypeError on snowflake-sqlalchemy 2.x. The private key is now handed to the connector through connect_args rather than the connection URL, so key-pair datasources connect again and credential material no longer appears in a URL. A private key supplied directly via connect_args still takes precedence, and password authentication is unchanged. (#12326)
-
Spark S3 assets honor recursive_file_lookup when discovering files — A Spark S3 asset configured with
recursive_file_lookup=Truenow finds objects in subfolders of itss3_prefixinstead of failing its connection check.s3_recursive_file_discoveryfalls back to the asset'srecursive_file_lookupwhen it is not set explicitly, and the test-connection error message reports the effective value. (#12292)asset = datasource.add_directory_parquet_asset( name="my_asset", s3_prefix="data/", recursive_file_lookup=True, ) -
No more pandas 3.1 deprecation warnings from internal calls — On pandas 3.1, internal uses of the deprecated
inplacekeyword caused Pandas4Warning deprecation warnings and, in environments that escalate warnings to errors, outright failures in metric resolution and inValidator.head(). Those calls now use the reassignment form pandas recommends, with identical results. (#12335)
Changes
Features
- The LIKE-pattern Expectations now accept an
escapecharacter on BigQuery and ClickHouse, rewriting the pattern into the backslash form those engines understand instead of refusing it; an unpaired trailing escape raises a ValueError before any SQL is sent. (#12291)
Bug fixes
- The four LIKE-pattern Expectations now work on Oracle and SingleStore instead of raising NotImplementedError, recognize every SQLAlche
-
- 1.24.02026-10-07 · 2026-10-07 13:35 UTC
查看更新说明
Compatibility: Python
<3.14,>=3.10→<3.15,>=3.10;numpyadded (python_version >= "3.14");pandasadded (python_version >= "3.14");pydanticadded (python_version >= "3.14")Highlights
-
Python 3.14 support — Great Expectations now installs and runs on Python 3.14, and the supported range is Python 3.10 through 3.14. On Python 3.14 installs resolve numpy 2.3.2 or later, pandas 2.3.3 or later, and pydantic 2.13.0 or later. The
clickhouseandteradataextras are not supported on 3.14, and Python 3.15 and later still requireGX_PYTHON_EXPERIMENTAL. (#12280)pip install great_expectations # now works on Python 3.14 -
New Expectation: ExpectColumnTypeToBe — A schema-level Expectation that checks a column's declared type, separate from the row-level
ExpectColumnValuesToBeOfType. It works on pandas, SQLAlchemy and Spark, returns onlyobserved_valuein its result, and reportssuccess=Falsewithobserved_value=Nonefor a missing column. Note that pandas 3 infers different default dtypes than pandas 2 for string and datetime columns, so re-checktype_when upgrading pandas. (#12186)import great_expectations.expectations as gxe batch.validate(gxe.ExpectColumnTypeToBe(column="order_id", type_="int64")) -
Escape character for the LIKE pattern Expectations — The four LIKE pattern Expectations accept an optional single-character
escape, which emits anESCAPEclause so_and%can be matched literally and identically across backends. Omitting it produces exactly the SQL generated before. BigQuery and ClickHouse raise a clear error naming the dialect, because neither supports a usable ESCAPE clause; escape wildcards with a backslash inside the pattern there instead. Both renderers now disclose the escape character. (#12154)import great_expectations.expectations as gxe gxe.ExpectColumnValuesToMatchLikePattern(column="c", like_pattern="a!_b", escape="!") -
Objects now resolve through the Data Context that owns them — With more than one Data Context in a process, expectation suites, validation definitions, checkpoints, batch definitions, the validator and a checkpoint's actions now read, write and run against the context they came from rather than whichever context happens to be current. Data Docs are built into the owning context's site,
${VARIABLE}references in Slack, Teams and Email settings resolve from the owning context's configuration, and a "not found" error for an object that belongs to no context now names the context the lookup consulted. An object that belongs to no context still resolves through the current one. (#12297, #12298, #12302, #12303)c1 = gx.get_context(mode="ephemeral") suite = c1.suites.add(gx.ExpectationSuite(name="my_suite")) c2 = gx.get_context(mode="ephemeral") # c2 is now current suite.add_expectation(...) # still lands in c1 -
Database URLs are masked without being mangled —
PasswordMasker.mask_db_urlkeeps every part of a database URL except the secrets: query strings, fragments, IPv6 brackets and empty authorities survive, absent usernames and hosts are no longer printed asNone, and passwords containing/,?or#no longer raise. Credentials passed as query parameters (password=,odbc_connect=,private_key_file_pwd=) are now masked on both code paths, with an allowlist of safe-to-display parameter names, and any value that is not a<scheme>://...URL is masked whole. ([#12242](https://github.com/fivetran
-
- 1.23.22026-09-28 · 2026-09-28 08:20 UTC
查看更新说明
Compatibility:
sqlalchemynow<2.1(extrassnowflake,databricks)Highlights
-
Fixes GX on SQLAlchemy 2.1 — SQLAlchemy 2.1.0, released 2026-09-24, broke GX 1.23.1 and earlier on Python 3.11+, where every SQL extra resolves it by default. Depending on the backend,
import great_expectationsfailed whenever snowflake-sqlalchemy was installed, every Databricks query failed, driverlesspostgresql://URLs could not load a driver, BigQuery queries comparing against a float failed, SQL Server reported mixed-case and upper-case tables as missing, andexpect_column_values_to_be_of_type(type_="Numeric")failed on float columns. 1.23.2 fixes all of these: thesnowflakeanddatabricksextras stay below SQLAlchemy 2.1 until their dialects support it, and every other SQL extra runs on 2.1. Python 3.10 is unaffected, since SQLAlchemy 2.1 requires Python 3.11. If you can't upgrade yet, pinsqlalchemy<2.1; do the same if you install snowflake-sqlalchemy or databricks-sqlalchemy outside GX's extras. (#12269)pip install --upgrade 'great_expectations[snowflake]' # include your extras so the SQLAlchemy cap applies -
Regex Expectations work on ClickHouse — The four regex Expectations now run on ClickHouse, which does not support
regexp_like(). ClickHouse is covered by integration tests for these Expectations. (#12222)gx.expectations.ExpectColumnValuesToMatchRegex(column="name", regex="^A") -
Correct substring matching for regex Expectations on Snowflake — Snowflake's
REGEXPoperator anchors patterns to the whole value, so unanchored patterns behaved differently there than on other backends. Regex Expectations on Snowflake now use substring semantics that match every other GX backend, while preserving the user's pattern. (#12221)gx.expectations.ExpectColumnValuesToMatchRegex(column="name", regex="ell") -
Nested struct columns supported in Spark value-counts Expectations — On the Spark engine, Expectations that rely on the
column.value_countsmetric — includingExpectColumnMostCommonValueToBeInSetandExpectColumnKLDivergenceToBeLessThan— now work for dotted nested struct paths such asaddress.city, instead of returning an empty result with an unresolved-column error. (#12231)gx.expectations.ExpectColumnMostCommonValueToBeInSet(column="address.city", value_set=["Springfield"])
Changes
Bug fixes
- GX works on SQLAlchemy 2.1, which broke 1.23.1 on several backends: the
snowflakeanddatabricksextras are capped below 2.1, a broken snowflake-sqlalchemy install no longer preventsimport great_expectations, driverlesspostgresql://URLs fall back to psycopg2 when psycopg is unavailable, BigQuery rendersDoubleasFLOAT64, SQL Server reflects mixed-case tables, theNumerictype name matches float columns again, and database URL masking keeps the database and query string verbatim. (#12269) - Validation results containing an infinite
Decimalvalue — for example the maximum, mean or sum of a PostgreSQLnumericcolumn or a pandas column ofDecimalvalues — now serialize as float infinity instead of raisingdecimal.InvalidOperation. (#12254) - Regex Expectations on Snowflake now match substrings, consistent with other backends, rather than requiring the pattern to match the entire column value. (#12221)
UnexpectedRowsExpectationno longer misreads a query as containing a JOIN when the letters appear inside a string literal, a column name such asjoin_date,
-
- 1.23.12026-09-18 · 2026-09-18 15:21 UTC
查看更新说明
Highlights
-
Spark now evaluates each regex independently with match_on="all" — On Spark, ExpectColumnValuesToMatchRegexList with match_on="all" now checks every regex separately against each column value, so patterns anchored at different positions (such as ^A and [0-9]{3}$) both match a value that satisfies them. This matches the behavior already seen on Pandas and SQL. (#12198)
gxe.ExpectColumnValuesToMatchRegexList( column="id", regex_list=["^A", "[0-9]{3}$"], match_on="all", ) -
Each Validator reports results for its own Batch when a datasource is reused — Validators built on the same datasource no longer borrow one another's Batch. Running two validation definitions on threads, or creating two validators from one datasource on a single thread, now evaluates and reports each validator's own data, with the correct batch_id, batch_spec and batch_definition on the result. This fixes a long-standing latent bug made reachable by #12148 in the 1.23.0 release. (#12211)
validator_a = context.get_validator(batch_request=request_a) validator_b = context.get_validator(batch_request=request_b) # validator_a still validates request_a's batch result = validator_a.expect_table_row_count_to_equal(value=3) -
A Spark schema saved in great_expectations.yml reloads correctly — A persisted spark_schema is now read back through StructType.fromJson, so reopening a File Data Context round-trips the schema instead of failing inside PySpark. Values that are not an accepted schema form now raise a validation error naming the field and the accepted types. (#12200)
context = gx.get_context(mode="file") asset = context.data_sources.get("spark_ds").get_asset("my_asset") assert asset.spark_schema is not None -
GX config files are read and written as UTF-8 regardless of locale — config_variables.yml and great_expectations.yml, and the .gitignore read while scaffolding a project, are now opened with an explicit UTF-8 encoding. Projects containing non-ASCII values or comments can be created and reloaded on hosts with a non-UTF-8 locale, and a project YAML file that is not valid UTF-8 now raises an error naming the file instead of a bare decode error. (#12182, #12204)
-
A gallery-wide test tier for data sources — A new gallery support tier asserts a measured test result across the entire shipped expectation library — one case per registered expectation, each pairing a passing and a failing configuration — and nine data sources (pandas in-memory and filesystem CSV, SQLite, MySQL, PostgreSQL, Trino, BigQuery, Databricks and Redshift) now declare it after being measured against the full gallery. (#12150)
Changes
Features
- Adds a gallery support tier that asserts a passing test result over the whole shipped expectation library, with nine data sources declaring it, a required CI lane per member, membership and coverage guards, and a measurement mode for evaluating new candidate backends. (#12150)
Bug fixes
- ExpectColumnValuesToMatchRegexList with match_on="all" on Spark now evaluates each regex independently, so patterns anchored at different positions no longer fail on values that satisfy them all. (#12198)
- A Validator now keeps the identity of the Batches it loaded even when its execution engine is shared, so concurrent validations and multiple validators on one datasource e
-
- 1.23.02026-09-10 · 2026-09-10 16:04 UTC
查看更新说明
- [BUGFIX] Cache the SQL execution engine across calls instead of rebuilding it every time (#12148)
- [BUGFIX] query asset SQL ending in a comment fails validation (#12124) (thanks @nanjeshramesh)
- [BUGFIX] Wrap a query asset's SQL whole so Oracle does not add FROM DUAL (#12162)
- [BUGFIX] TupleFilesystemStoreBackend reads with ambient locale encoding (#12125) (thanks @nanjeshramesh)
- [BUGFIX] Make ExpectColumnValueZScoresToBeLessThan pass rather than fail or raise on zero or undefined variance (#12145) (thanks @Star-cloud626, Claude Opus 5 (1M context))
- [BUGFIX] expect_column_values_to_be_unique raises KeyError on mixed-case column names (#12180)
- [BUGFIX] Report an undefined SQLite standard deviation as None instead of raising (#12168) (thanks @siddharthgaur1, Claude Opus 5)
- [DOCS] Update repository links to the fivetran org (#12126) (thanks @iamfeldman)
- [MAINTENANCE] Declare metric values, render-content payloads, and metric keys as what they actually are (#12116)
- [MAINTENANCE] Generalize the data source declaration record beyond SQL backends (#12110)
- [MAINTENANCE] Pin the fluent datasource management API with a per-type CRUD contract suite (#12141)
- [MAINTENANCE] Say what the shared fixture column types mean (#12147)
- [MAINTENANCE] Type-check tests/test_utils.py, tests/actions/ and tests/checkpoint/ (#12146) (thanks @MannXo)
- [MAINTENANCE] Clean up check-actor-permissions and dead CI workflow code (#12159)
- [MAINTENANCE] Bump browserslist from 4.28.1 to 4.28.8 in /docs/docusaurus (#12155)
- [MAINTENANCE] Bump fast-uri from 3.1.5 to 3.1.7 in /docs/docusaurus (#12151)
- [MAINTENANCE] Type-check tests/render (#12152) (thanks @Ryota-Di)
- [MAINTENANCE] Type-check tests/core/ #12130 (#12140) (thanks @AnandkumarMall)
- [MAINTENANCE] Type-check tests/execution_engine/partition_and_sample/ (#12169) (thanks @siddharthgaur1, Claude Opus 5)
- [MAINTENANCE] Bump colord from 2.9.3 to 2.10.0 in /docs/docusaurus (#12170)
- [MAINTENANCE] Type-check tests/data_context/ (#12171) (thanks @nanjeshramesh)
- [MAINTENANCE] Remove unused checkpoint test fixtures (#12174)
- [MAINTENANCE] Bump svgo from 3.3.4 to 3.3.5 in /docs/docusaurus (#12175)
- [MAINTENANCE] Bump joi from 17.13.4 to 17.13.7 in /docs/docusaurus (#12176)
- [MAINTENANCE] Publish the oracle ext
用户点评
登录用户的真实使用记录,可按版本和硬件筛选还没有人点评。第一个说出真实体验的人最有价值。
About GX Core
GX Core combines the collective wisdom of thousands of community members with a proven track record in data quality deployments worldwide, wrapped into a super-simple package for data teams.
Its powerful technical tools start with Expectations: expressive and extensible unit tests for your data. Expectations foster collaboration by giving teams a common language to express data quality tests in an intuitive way. You can automatically generate documentation for each set of validation results, making it easy for everyone to stay on the same page. This not only simplifies your data quality processes, but helps preserve your organization’s institutional knowledge about its data.
Learn more about how data teams are using GX Core in our featured case studies.
Integration support policy
GX Core supports Python 3.10 through 3.14.
Experimental support for Python 3.15 and later can be enabled by setting a GX_PYTHON_EXPERIMENTAL environment variable when installing great_expectations.
For data sources and other integrations that GX supports, see the compatibility reference for additional information.
Get started
GX recommends deploying GX Core within a virtual environment. For more information about getting started with GX Core, see Introduction to GX Core.
-
Run the following command in an empty base directory inside a Python virtual environment to install GX Core:
pip install great_expectations -
Run the following command to import the
great_expectations moduleand create a Data Context:import great_expectations as gx context = gx.get_context()
Get support from GX and the community
They are listed in the order in which GX is prioritizing the support issues:
- Issues and PRs in the GX GitHub repository
- Questions posted to the GX Core Discourse forum
- Questions posted to the GX Slack community channel
Contribute
We truly value the contributions of our community and always welcome pull requests. PRs are encouraged for both bug fixes and new features. For feature requests, we ask that you first open an issue for discussion to ensure the feature fits within the vision for GX Core and to align on the approach so that your time and effort are well spent. Thank you for being a crucial part of GX Core!
See CONTRIBUTING.md for details on how to propose a change, claim an issue, and submit a pull request.
Code of conduct
Everyone interacting in GX Core project codebases, Discourse forums, Slack channels, and email communications is expected to adhere to the GX Community Code of Conduct.