Example: Consider a sample pipeline which performs join between HR dataset and Person dataset. The joined data is then normalized(to rename some fields, drop some fields, and create ID) before storing data into the data lake. Following diagram explains the sample pipeline which is reading from 2 file sources. Note that the 2D boxes represent the SCHEMA that is flowing through the pipeline while 3D boxes represents the pipeline stages.
In the lineage view, we show high level information first as shown below. Note that 'HR File', 'Person File', and 'Employee Data' are name of the input and output datasets, as indicated by the Reference name in the plugin properties.
Next detail level view contains the clickable fields from the input and output datasets. Note that 2D boxes represents fields belonging to the datasets. Since input datasets are of type file which does not have schema yet, plugin can provide any String name for it. In this case we are using "HR Record" and "Person Record" as name.
Once user clicks on particular field, field level lineage graph can be displayed.
Example: Graph for field ID, where circle represents the fields and edges represents operations with names in bubbles.
Note that "body" field is generated from "HR Record" as well as "Person Record". To distinguish it while storing we might need to prefix it with the stage name.
As an additional information for the source and target datasets we might want to show the associated properties such as file path, regex used etc.
Store: Based on the above example, we want following pieces of information to be stored in the "FieldLevelLineage" dataset
- Properties associated with the Dataset. For example: File path, name of the directory associated with the "HR File", Broker Id, Topic name etc associated with the Kafka plugin. This will be single row per dataset per namespace. If the same dataset is used in multiple pipelines, but with different configurations the properties will be union of both.
- Fields associated with the Dataset. This will be single row per dataset per namespace. We will store each field as a separate column in this row. The value of the column can be additional properties such as creation time, last update time, runid responsible for last update etc.
- Lineage associated with the each field from the target dataset. For each field belonging to each target dataset, and for each run of the pipeline writing to that dataset, there will be one row.
Example: With one run of the pipeline shown above, following will be the sample data in the store.
...
inputDir=/data/2017/hr
regex=*.csv
failOnError=false
...
inputDir=/data/2017/person
regex=*.csv
failOnError=false
...
rowid=ID
/*should we store schema too? what if that changes per run?*/
...
/* We may not necessarily required to store any value*/
created_time:12345678
updated_time:12345678
last_updated_by:runid_X
...
This document explains the design for storage and retrieval of the Field Level Lineage information.
Access Pattern:
- For a given dataset, find out the high level lineage (field mapping between source and destination datasets and not the detail operations which caused this conversion) going in backward direction within a given time range. Note that the response should be multi-level. For example, consider a case where "Employee" dataset is generated from "Person", "HR", and "Skills" datasets. Response would contain the field mappings between source datasets ("Person", "HR", and "Skills") and "Employee" dataset. However it is also possible that the source datasets are created/updated in the given time range. So response should also include the field mappings between the datasets which created the source datasets and source datasets themselves.
- For a given dataset, find out the high level lineage (field mapping between source and destination datasets and not the detail operations which caused this conversion) going in forward direction within a given time range. Similar to the above query, response need to be multi-level.
- Given a dataset and field name, find out detail lineage (field mapping between the source and destination datasets along with the operations which caused this conversion) going in the backward direction. Response will only contain the operations belonging to the single level.
- Given a dataset and field name, find out detail lineage (field mapping between the source and destination datasets along with the operations which caused this conversion) going in the forward direction. Response will only contain the operations belonging to the single level.
REST API:
Given a dataset and time range, get the high level lineage both in forward and backward direction.
Code Block GET /v3/namespaces/<namespace-id>/endpoints/<endpoint-name>/fields/lineage?start=<start-ts>&end=<end-ts>&level=<level> Where: namespace-id: namespace name endpoint-name: name of the endpoint start-ts: starting timestamp(inclusive) in seconds end-ts: ending timestamp(exclusive) in seconds for lineage level: how many hops to make in backward/forward direction Sample response: [ ... list of lineage mappings ... ] where each lineage mapping will be of the form: { "source": { "namespace": "ns", "name": "Person" }, "Destination": { "
...
namespace": "
...
ns",
...
"
...
name": "
...
Employee"
...
}
...
,
...
"
...
fieldmap":
...
[
...
{ "
...
from": "
...
id",
...
...
"
...
to": "
...
id" }, {
...
"
...
from":
...
"
...
first_name", "to": "name"},
...
{
...
"
...
from": "
...
last_name",
...
"
...
to": "
...
name"} ]
...
}Given a dataset and field, find out the detailed lineage.
Code Block GET /v3/namespaces/<namespace-id>/endpoints/<endpoint-id>/fields/<field-name>/lineage?start=<start-ts>&end=<end-ts>&direction=<backward/forward> Where: namespace-id:
...
namespace name endpoint-id: endpoint
...
name field-name: name of the field for which lineage information to be retrieved start-ts: starting timestamp(inclusive) in seconds end-ts: ending timestamp(exclusive) in seconds for lineage direction: backward or forward Sample response: { [ ... list of nodes ... ], [ ... list of operations ... ], [ ... list of connections
...
...
...
]
...
} where each
...
Node is an object representing field. Node has id which is uniquely identifies the Node (combination of origin and name) and label which is used to display on the UI. Node can have optional sourceEndPoint and destinationEndPoint members which represents if this node is generated directly from Source EndPoint or written to the Destination EndPoint. { "id": "origin.fieldname", "label": "fieldname" "sourceEndPoint": { "name": "
...
file",
...
"
...
namespace": "
...
ns"
...
} }
...
each Operation is represented
...
as {
...
...
"name": "
...
IDENTITY",
...
"description":
...
"description associated with the operation". } each Connection represents transformation between
...
two nodes with operation name that caused
...
it: { "
...
from": "
...
Node1.id",
...
...
"
...
to": "
...
Node2.id", "
...
operation": "
...
opname"
...
...
...
}
Store:
Field level lineage information will be stored in the "FieldLevelLineage" dataset.
This dataset will have following row keys
Data row: This row will store the actual operations data against the checksum of operations.
Row Key column: d c|<checksum-value> FieldLineageInfo object Backward lineage row: From the perspective of the destination endpoints, operations will represent the backward lineage. For each destination, separate row will be created.
Row Key column: c column: p b | <endpoint_ns> | <endpoint_name> | <inverted-start-time> | <id.run> <checksum> <program-run-id> Forward lineage row: From the perspective of the source endpoints, operationw will represent the forward lineage. For each source, separate row will be created.
Row Key column: c coulmn: p f | <endpoint_ns> | <endpoint_name> | <inverted-start-time> | <id.run> <checksum> <program-run-id>
FieldLineageInfo object will store following information:
- Collection<Operation>: operations representing the field lineage.
- Checksum of operations.
- Set of source endpoints.
- Set of destination endpoints.
- High level bi-directional mapping of fields from source endpoints to destination endpoints. This is for serving the access pattern 1 and 2 described above.
- For each field of source endpoint there would be graph from that field to the destination fields.
- For each field of destination endpoint there would be graph resulting into that field from different source fields.
Open questions:
- Per UI we also want to show the type of fields which we currently do not accept through API.
- What constitutes the dataset schema? For example for fileset should we assume that the fields generated by the READ operations are part of schema?