In this work we analyze the typical operations of data preparation within a machine learning process, and provide infrastructure for generating very granular provenance records from it, at the level of individual elements within a dataset. Our contributions include: (i) the formal definition of a core set of preprocessing operators, (ii) the definition of provenance patterns for each of them, and (iii) a prototype implementation of an application-level provenance capture library that works alongside Python.
Data processing pipelines that are designed to clean, transform and alter data in preparation for learning predictive models, have an impact on those models’ accuracy and performance, as well on other properties, such as model fairness.
However, while substantial recent research has produced techniques for model explanation
that focus primarily on the model itself (e.g., [
In this work, we enable the explanation on the efect of each transformation in a pre-processing
pipeline on the data that is ultimately fed into a model. We consider transformations that apply
to commonly used tabular or relational datasets and across application domains. These steps
have been systematically enumerated in multiple reviews (see eg. [
In this framework, we propose a formalisation and categorisation of a core set of these
operators. Data derivations for such operators are expressed at the level of the atomic elements
in the dataset using the PROV data model [
In the rest of this paper we illustrate the models we have adopted for describing data, operators,
and provenance (Section 2) as well as the way in which provenance for a data preprocessing
pipeline is captured (Section 3). Further details on the query capabilities of the resulting
provenance and on the scalability of the overall approach can be found in the extended version
of the paper [
A (dataset) schema is an array of distinct names called features: = [a1, . . . , a]. Each feature is associated with a domain of atomic values (such as numbers, strings, and timestamps). A dataset over a schema = [a1, . . . , a] is an ordered collection of rows (or records) of the form: : (1, . . . , ) where is the unique index of the row and each element (for 1 ≤ ≤ ) is either a value in the domain of the feature a or the special symbol ⊥, denoting a missing value. Given a dataset over a schema we denote by a the element for the feature a of occurring the -th row of . We also denote by * the -th row of , and by * a the column of associated with the feature a of . * Age and 2* denote the third column and the second row of , respectively.
The data transformation operators that are available in packages for building data preprocessing
pipelines (e.g., Orange [
The condition of both the projection and the selection operators can refer to the values in , as shown in the following example that use an intuitive syntax for the condition.
{features without nulls}( Age<30()) is the following dataset: CId Gender Age 1 113 24 2 241 28
Example 1. A possible dataset over the schema = [CId, Gender, Age, Zip] is as follows: Data augmentations. They increase the size of by adding rows (without changing ) or columns (changing to ′ ⊃ ) to . Two basic data augmentation operators are defined over datasets. They allow the addition of columns and rows to a dataset, respectively. →(): : the vertical augmentation of to using a function over a subset of features = [a1 . . . a] of is obtained by adding to a new set of features = [a′1 . . . a′] whose new values a′1 . . . a′ for the -th row are obtained by applying to a1 . . . a ; ↓:( ): the horizontal augmentation of using an aggregative function is obtained by adding one or more new rows to obtained by first grouping over the features in and then, for each group, by applying to () (extending the result to with nulls if needed). □ □ Example 3. Consider again the dataset in Example 1 and the following functions: (i) 1, which associates the string young to an age less than 25 and the string adult otherwise, and (ii) 2, which computes the average of a set of numbers. Then, the expression →1(Age):ageRange() produces the following dataset: Data transformation. The goal is to transform (some of) the elements in without changing its size or its schema. One basic data transformation operator is defined over datasets: (): the transformation of a set of features of using a function is obtained by replacing each value a with (* a), for each a occurring in .
Example 4. Let be the dataset in Example 1 and be an imputation function that associates
with the ⊥’s occurring in a feature a the most frequent value occurring in * a. Then, the result
of (Zip)() is the following dataset:
In [
The purpose of data provenance is to extract relatively simple explanations for the existence
(or the absence) of some piece of data in the result of complex data manipulations. Along
this line, we adopt as the provenance model a subset of the PROV model [
Example 5. Let be the first expression in Example 3 and ′ = (). A fragment of the provenance generated by this operation is reported in Figure 1. □
In order to capture the provenance of a pipeline of a sequence of preprocessing operations
o1, . . . , o, we associate a provenance-generating function (p-gen) with each operation o
occurring in . Each such function generates a collection of provenance data whenever a dataset
is processed using o, which describes the efect of o on the data at the appropriate level of
detail. As a large variety of preprocessing operators can be defined in terms of our five core
pipeline operators [
Each p-gen function takes inputs , ′ (the inputs and outputs of their associated operator)
along with a description of the operator itself, and produces a PROV document that describes
the transformation produced by the operator on each element of . The output PROV document
is obtained by instantiating an appropriate provenance template [
Take for example the case of Vertical Augmentation (VA): →1(Age):ageRange() which we used in Example 3, where attribute Age is binarised into {young, adult} based on a pre-defined cutof, defined as part of (). The p-gen function for VA will produce a collection of small PROV documents, one for each input-output pair ⟨,Age, ′,AgeRange⟩ as shown in the example. As these documents all share the same structure, we specify p-gen by giving two elements. First, a single PROV template for (VA) as shown in Figure 2, where we use the generic attribute names , to indicate the old and new feature names, as per the operator’s general definition in Section 2.2.
Approaches for automated provenance capture, such as by using the python call stack fail to capture data provenance at the level of the individual element within a dataframe. To accomplish this, in our initial prototype, we opted for explicit and analyst-controlled instrumentation at the script level. We have packaged the implementation of the p-gen functions described in the previous section as a python library that analysts can add to their code where provenace capture is desired. Note also that it may be possible to automate function call injection, at least in part, by leveraging mature code annotation tools. While this does not completely eliminate the need for manual intervention, this is now a simple comment/ annotation efort (which can be driven by a smart UI) rather than requiring additional programming.
A complete provenance document is produced by combining the collection of provlets that results from calling p-gen functions. Specifically, one provlet is generated for every transformation and every element in the dataframe that are afected by that transformation. The document is represented by such collection of provlets, where entity identifiers match across provlets, and never needs to be fully materialised, as explained shortly. To illustrate how provlets are generated, consider the following pipeline: ( →1(Age):ageRange()) where = {AgeRange ̸= ‘Young’} and is the dataset of Ex. 3. The corresponding provenance document is represented in Figure 3
Applying vertical augmentation produces one provlet for each record in the input dataframe, showing the derivation from Age to AgeRange. The second step, selecting records for ‘not young’ people, produces the new set of provlets on the right, to indicate invalidation of the first record. Note that the “used” side on the left refers to existing entities, which are created either into the pipeline from the input dataset, or by an upstream data generation operator.
Provlet composition requires looking up the set of entities already produced, whenever a new provlet is added to the document. For this, we have built a bespoke architecture that allows lazy provenance composition. Each p-gen function generates a set of provlets, one for each element in the dataframe (in the worst case), constructs a partial document, and stores it to a persistent MongoDB back end. This allows the provenance to be collected quickly at execution of each script, and be assembled later, minimizing execution dependencies and possible bottlenecks during the actual execution of the pipeline.
Concretely, each p-gen function creates, at query time, a provenance object containing all
provlets, and an input json file representing the input dataframe. By capturing provlets from
each p-gen function, it is possible to compose these provlets into a complete graph, which can
be traversed as a bipartite graph for any . The process for composing provlets, and tracing
the influence (either direct of indirect) of data and operations on can then support “why
provenance" [
In this work, we have illustrated an approach for producing fine-grained data provenance in
machine learning pipelines, irrespective of the pipeline tool used. Indeed, because a substantial
efort goes into selecting and preparing data for use in modelling, and because changes made
during preparation can afect the ultimate model, it is important to be able to trace what is
happening to the data at a such level of detail. Using an implementation of this system, we
have demonstrated the utility and performance of our approach over real-world ML benchmark
pipelines. In order to investigate scalability issues with our design, we also used the TPC-DI
generator and apply several operators over that data at scale. Our results indicate that we can
collect fine-grained provenance that is both useful and performant [