Computed Join Introduction

A Computed Join combines data from two or more containers (in the same datastore or across datastores) into a single, queryable result that you can profile and run quality checks against. Use it when the join needs governance and observability rather than a one-off SQL view.

What It Does

A Computed Join reads its inputs, computes the join, and returns a single result. The inputs can live in the same datastore or in different datastores, and Qualytics loads each one itself, so the source systems never run a cross-datastore query. The join is not stored: each profile or scan re-loads the inputs and recomputes the result, which keeps the output in sync with the underlying containers without a manual refresh.

Two Ways to Define a Join

You choose the mode when you create the join, and it stays fixed for the life of the join.

• Pairwise mode joins exactly two containers (a left and a right) on one field from each side. The two fields can have different names but must be the same data type. You pick the join type (Inner, Left, Right, or Full Outer), the columns to project, and optional filter and group-by clauses, and Qualytics builds the query for you.
• SQL mode joins two or more aliased sources with a Spark SQL query you write yourself. Reach for it when the join is more than one key pair: composite (multi-column) keys, more than two sources, CTEs, window functions, or aggregations. The number of sources ranges from 2 up to a configurable maximum (10 by default).

The join always takes at least two inputs. To combine more than a single pairwise join allows, use SQL mode, or express the first join inside a Computed Table and use that Computed Table as one side of the next Computed Join.

Why It Matters

• Cross-datastore analytics. Combine a JDBC table with a DFS file (or any other mix) into one queryable result, without setting up a federated view at the source.
• Reusable transformation logic. Express filters and aggregations once at the join level, then run quality checks against the joined output.
• Joins the pairwise form cannot express. SQL mode handles composite keys, three or more sources, CTEs, window functions, and aggregations in a single query.
• Quality checks on derived data. A Computed Join behaves like a regular container. You can profile it, run checks against it, and detect anomalies on the joined result.

Where It Fits

The joined output is a real container in Qualytics. It appears under its parent datastore (the left input in pairwise mode, the first source in SQL mode), has its own profile, and supports the same observability features (volumetric tracking, freshness checks). You can run scans and quality checks against it like any other container. Sync does not apply to a Computed Join: Sync discovers containers in the source system, and the Computed Join is produced by Qualytics rather than discovered.

Next Steps