# Qualitis is a data quality platform that runs its checks through Linkis > Qualitis is a Spring Boot data quality management system from WeBankFinTech that defines quality models, schedules them, and reports on the results across data sources, with Linkis executing the tasks and DataSphereStudio providing the workflow. It is built for financial-grade isolation and access control rather than for a notebook-scale dataset. **WeBankFinTech/Qualitis** — Qualitis is a one-stop data quality management platform that supports quality verification, notification, and management for various datasource. It is used to solve various data quality problems caused by data processing. https://github.com/WeBankFinTech/Qualitis - Repository: https://github.com/WeBankFinTech/Qualitis - Stars: 771 · Forks: 317 - Language: Java - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/webankfintech-qualitis ## A quality platform built on a compute platform Qualitis is described as a one-stop data quality management platform supporting quality verification, notification and management for various data sources, used to solve the data quality problems caused by data processing. The architecture is the thing to understand first, because it explains everything else. Qualitis is based on Spring Boot, and it submits quality model tasks to the Linkis platform, which is a separate project from the same organisation. The application itself does not execute the checks. It defines them, schedules them, collects the outcomes and reports on them, while Linkis runs the actual computation. That division is why the feature list is short on data engine specifics and long on governance. The functions Qualitis provides are data quality model construction, data quality model execution, data quality verification, and generation of data quality reports. On top of that it adds what the README calls enterprise-level features of financial-level resource isolation, management and access control, and it states that it is guaranteed to work well under high-concurrency, high-performance and high-availability scenarios. The audience is therefore an enterprise data platform team, not an individual analyst. The topics list gives it away: data-quality, data-quality-model, quality-check, quality-improvement, workflow, and the presence of dss and linkis among the topics. The licence is Apache 2.0, and the project is written in Java. ## Three kinds of quality model, and the templates for them The model definition is where a data quality platform earns its keep, and Qualitis supports three shapes. A model of a single table, a model of multiple tables, and a custom model. Alongside those, Qualitis presets multiple data quality verification templates, with common checks such as null check, blank check, number check and enumeration check. The stated purpose of the templates is to simplify data quality model definition, which is the sensible way round: most tables need a handful of standard rules, and the tool should not make you express a null check from scratch every time. Beyond definition there is scheduling for the quality models, generation of data quality reports, and log management for the data quality tasks. The feature that separates this from a set of scripts is abnormal data management. Qualitis stores the abnormal data itself, which the README says can quickly locate problems. That is the difference between a check that fires and tells you a rule broke, and a system that keeps the offending rows so you can see what they actually were. For a data platform where a bad partition has to be traced back to a specific job, that distinction decides whether you need the platform at all. The administrator console is present too, with personnel management, access control management, privilege control management and metadata management. ## Workflow comes from DataSphereStudio, not from Qualitis The workflow feature has an explicit external dependency, and the README says so plainly: workflow needs DataSphereStudio. That matters for anyone sizing the deployment. Qualitis is not a self contained product. It needs Linkis to execute tasks, and the workflow layer needs a third component. The Quick Deploy Standalone document linked from the README is the one to read for how the pieces fit together, and the Architecture document and the architecture diagram in the images directory show the same picture in a different form. The repository layout backs up the split. There is a core directory, a ui directory, an appconn directory, a util directory and a web directory, and the build is a Gradle project with build.gradle, settings.gradle and gradle.properties at the root alongside a gradle directory and a profile.gradle. The web directory is the front end, the core holds the model and rule machinery, and appconn is the connection layer. The documentation is split by language too, with an English set under docs/en_US/ch1 and a Chinese set under docs/zh_CN/ch1, and the README points to a Quick Deploy guide, a User Manual and an Architecture Design document. The overall shape is a Spring Boot service with its own UI talking to a Linkis cluster, deployed as a set of services rather than a single jar. ## The road map tells you what is not there yet The road map section is short and unusually concrete, and it is the clearest statement of the project's maturity available. The first item is support for verification in report data in workflow, which suggests that verifying data inside a workflow report is not yet done. The second is support for verification in multi-storage, with data quality verification between Hive, HDFS and MySQL, and separately between Kafka. So the multi table models the tool supports are not yet verified across those storage systems. The third item is support for generating data quality reports with optional latitude, and the fourth is intelligent discovery of data quality problems, which is the most ambitious of the four and is clearly a research direction rather than a feature in hand. Read together with the feature list, that gives a fair picture of the current state. Single table and multi table models, scheduling, reports, logs, abnormal data storage and the administrator console are described as present. Verification across heterogeneous storage and verification inside workflow are the ones still on the list, and automatic discovery of data quality problems is further out. For an adopter, that is the difference between a tool you can use for your current tables and a tool you would extend. The models, the templates and the reporting are usable today; the cross storage verification and the workflow integration are the parts to plan around. ## Where it sits against doing the checks yourself The comparison in the README is a picture rather than prose, a chart of similar systems, and the more useful comparison is architectural. A team that owns a Spark or Hive estate and already runs Linkis can write quality checks as ordinary jobs and schedule them with the same tooling they use for everything else. That approach has no new component to deploy, and the checks live next to the rest of the pipeline code. The reason to run Qualitis instead is that the checks become a governed artefact rather than a script. There is a place to define models, a place to see their results, an administrator console for who can do what, and stored abnormal data so a failure can be investigated rather than just re-run. The isolation and access control the README highlights are the enterprise feature: a quality model that runs a check against production data is a privileged operation, and putting it behind resource isolation and role based access is the point of a platform rather than a script. The cost is the platform. Linkis, DataSphereStudio and Qualitis together are a substantial deployment, and a small team paying that to run a dozen null checks is spending its time on infrastructure. The honest dividing line is organisational: if you already have a platform team running Linkis for the organisation, adding Qualitis is an incremental change, and if you do not, it is a new platform. ## Release history and where the project stands The releases are versioned in a conventional way, with release-1.3.0 on 2025-10-17, release-1.2.0 on 2025-03-17 and release-1.1.0 on 2024-06-28, the last of which is described simply as adding a new feature. The last push was on 2026-04-02, and the repository is not archived. That places the most recent commit in April 2026 with the newest tag from the previous October, so there is a gap between the last release and the current head of the branch, which is normal for a project that tags on a schedule rather than on every merge. Nothing in the documentation describes a release cadence, a support policy for older versions, or a migration path between the 1.x lines. For a platform that holds scheduled quality models and access control rules, that is a reasonable thing to ask about before adopting it, and the issue tracker is where the maintainers say to send questions, alongside the WeChat and QQ groups. The contributing guidance in the README asks for help adding new engines and code, and the project welcomes community partners. The documentation set under docs is the place to look first, because the README itself is mostly an overview and a pointer. ## Conclusion Qualitis suits an enterprise data team that already runs Linkis and needs a governed place to define, schedule and audit data quality checks across many sources, because the execution layer, workflow and access control are already part of the stack. It is the wrong choice for a single team with a handful of tables, since bringing up Linkis, DataSphereStudio and the Qualitis server is a large amount of infrastructure for that job. Before adopting it, read the Quick Deploy Standalone document, confirm that your data sources are reachable from the Linkis cluster, and check whether the check templates cover the rules you actually enforce today. ## FAQ ### What is Qualitis and what does it do? Qualitis is a Spring Boot data quality management platform that supports quality verification, notification and management for various data sources. It provides data quality model construction, model execution, verification and report generation, with abnormal data storage so problems can be located quickly. ### What does Qualitis need to run? Qualitis submits quality model tasks to the Linkis platform, so Linkis is required for execution, and the workflow feature additionally needs DataSphereStudio. The README points to the Quick Deploy Standalone document for the deployment details. ### Which data sources can Qualitis verify? The road map lists support for data quality verification between Hive, HDFS and MySQL, and between Kafka, as an item still to be added, alongside verification in report data inside workflow and intelligent discovery of data quality problems. ## Sources - [Issues](https://github.com/WeBankFinTech/Qualitis/issues) - [License: Apache-2.0](https://github.com/WeBankFinTech/Qualitis/blob/master/LICENSE) - [README](https://github.com/WeBankFinTech/Qualitis/blob/master/README.md) - [Releases](https://github.com/WeBankFinTech/Qualitis/releases) - [WeBankFinTech/Qualitis on GitHub](https://github.com/WeBankFinTech/Qualitis) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webankfintech-qualitis