Overview

This page covers the requirements, design and implementation of metadata and data discovery features in 3.3

High Level Requirements

1. Schema as metadata
2. System metadata
3. CLI, Test Framework Support for metadata
4. UI for Metadata Search
5. UI for Lineage
6. UI for Adding/Updating metadata properties/tags
7. Metadata search
8. Lineage based on Type of Dataset Access
9. Monitoring/Logs for Metadata Service

Scope

1. Schema as metadata
2. System metadata
3. Metadata CLI
4. Test Framework support for Metadata
5. UI (needs to be finalized)

User Stories

New Metadata Search:

Metadata Storage and Search to support:

1. Key-Value Metadata:
   1. Codename: Alpha Tango Charlie
      Supported searches:
      
      1. Whole Key-Value (complete or partial) - Codename: Alpha Tango Charlie or Codename: Alpha Tang*
         
      2. Key with Part of Value (complete or partial) - Codename: Alpha or Codename: Tango or Codename: Charlie or Codename: Alp*
      3. Whole Value (complete or partial): Alpha Tango Charlie or Alpha* or Alpha Tan*
      4. Parts of value (complete or partial): Alpha or Tango or Charlie or Alph* or Tan* or Ch*
         
         
2. Tags Metadata:
   1. Tags: Tag1, Tag22
      Supported searches:
      
      1. With tags key and a tag value (complete or partial): Tags: Tag1 or Tags: Tag*
      2. With tag value complete or partial: Tag22 or  Tag2*
         
         
3. Schema Metadata: This is just key-value where key is schema and value schema fields but needs special indexing to support searches with fieldName and fieldName:fieldType.
   1. Schema: {EmpName: String, EmpContact: {EmpTel: Integer, EmpAddr: String}} (Note: This is a nested schema)
      Supported searches:
      
      1. FieldName with FieldType: EmpName: String or EmpTel:Integer or EmpAddr: String
      2. FieldName: EmpName, EmpTel, EmpAddr

Storage:

Main Table: This table stores stores the metadata for the entity. It will be used when an user wants to get metadata of an entity. This table is not for searching. 

Index Table: This table will be used for searching and it will use IndexedTable.

System Metadata

Kinds of system metadata:

Artifacts

TBD

Applications

• Artifact name

Programs

• Type of program

Datasets

• Type of dataset
• Schema
• RecordScannable/BatchWritable/RecordWritable/BatchReadable
• Other properties

Streams

• Format

Views

• Format

Design Considerations

Storage

System Metadata will be stored in a separate dataset for the following reasons:

1. Only the CDAP system can update System Metadata.  
2. System Metadata may have different authorization as well as retention policies than Business Metadata
3. System Metadata can be updated at specific times only, where users can update Business Metadata at any given time

As a result, the metadata system will have to manage two different datasets. The storage format of both datasets (both keys and values) will be identical, they will only write to separate tables.

A higher level construct, MetadataStore will have the ability to interact with two separate datasets. It will use a MetadataScope (possible values USER and SYSTEM) object to distinguish between operations that should go to the business metadata dataset from the ones that should go to the system metadata dataset.

The MetadataStore class is chosen to have the ability to interact with two different metadata datasets, because it is the API that is used across CDAP (LineageDatasetFramework, Lineage classes, StreamAdmin, AppLifecycleService, DeletedProgramHandlerStage, to name a few classes) to interact with Metadata. There was an option to have this ability in the MetadataAdmin object instead and have the MetadataStore be local to a specific dataset (this may have made the MetadataStore class itself cleaner). However, this way, we would have needed the downstream classes (users of MetadataStore) handle multiple MetadataStores, which is not clean. Also, currently, the MetadataAdmin is only used by the MetadataHttpHandler. As a result, we cannot move this logic to the MetadataAdmin class, since not all clients of the metadata system have access to it.

The MetadataAdmin class is currently in app-fabric, because it needs access to the AppMetadataStore to check if entities exist. This is not ideal, but to fix this, we need to split cdap-app-fabric, which is much beyond the scope of the Metadata work.

History

We will re-use the same pattern that the Business Metadata Dataset uses to store history. There will however be one update to not serialize the MetadataScope in the history, as described in 

Runtime

For interacting with the System Metadata Dataset, we will introduce a SystemMetadataUpdater interface, which will be injected at various stages outlined below, to add, update or delete system metadata

System Metadata will be added when:

1. An app is deployed - We will add a SystemMetadataUpdater stage in the deployment pipeline that will update system metadata for the app, as well as all the programs in the app.
2. A new dataset instance is created - The LineageWriterDatasetFramework will be passed a SystemMetadataUpdater, to add system metadata in the addDatasetInstance call.
3. A new stream is created - StreamAdmins will be passed a SystemMetadataUpdater as well, to add system metadata in the create API.

System Metadata will be updated when:

1. A dataset instance's properties are updated - The LineageWriterDatasetFramework's updateInstance method will use the SystemMetadataUpdater to update the passed properties
2. A stream's config is updated - The StreamAdmin's updateConfig method will use the SystemMetadataUpdater to update the stream's system metadata

System Metadata will be deleted when:

1. An app is deleted - The ApplicationLifecycleService will use the SystemMetadataUpdater to delete system metadata for the application
2. A program is removed from an existing app - The DeletedProgramsHandlerStage will use the SystemMetadataUpdater to delete system metadata for the programs
3. A dataset instance is deleted - The LineageWriterDatasetFramework's deleteInstance method will use the SystemMetadataUpdater to delete system metadata for the dataset instance
4. A stream is deleted - The StreamAdmin's drop method will use the SystemMetadataUpdater to delete system metadata for the stream 

System Metadata Updates

Only the CDAP system can update system metadata for entities. This capability will not be exposed to users. However, given this design choice, users will need a capability in CDAP to discover all the system tags/properties. To start off with, this can be exposed via a simple API that lists all tags/properties. It can later be extended via full-text search capabilities when CDAP has a more comprehensive search capability that extends beyond IndexedTables and prefix lookups.

REST APIs

The add/update/delete APIs for system metadata will not be documented, or be accessible from the Router. Internally, the SystemMetadataUpdater will preferably interact with the transactional store for system metadata directly.

If REST APIs are absolutely necessary (TBD):

• The REST APIs for adding/updating/deleting system metadata will not be documented, and will not be exposed via the Router
• The SystemMetadataUpdater will use service discovery to discover the Metadata Service and make REST calls.

Schema as Metadata

Schema as metadata is meant to add the capability in CDAP for users to be able to retrieve datasets/streams with a field X optionally of type Y.

For storing schema as a system metadata, we will use the existing metadata properties mechanism. An option to store Schema as metadata would be to store every field in the schema as the metadata property:

Key: 

Value:

Note: We may have to reverse this, based on the indexing mechanisms available in the System Metadata Dataset. If it supports key:value and value type searches, then we may have to swap the key and value above, so two types of searches can be supported:

1. All Datasets with the field field1
2. All Datasets with the field field1 of type int

Views

Up until 3.2, users could not associate metadata with stream views. We will need to add this capability in 3.2. However, there would not be any parent-child relationship between a view, and its stream, as far as metadata is concerned. A view will be a separate entity from its stream, and will show up separately in search results. Metadata of a stream will not be automatically available as metadata of a view. 

Upgrade

The BusinessMetadataDataset dataset type introduced in 3.2 will be renamed to MetadataDataset, since it will also serve system metadata in 3.3. For existing CDAP installations, we will need an upgrade step to change the type of the existing "business.metadata" dataset in the "datasets.instance" table.  Unable to locate Jira server for this macro. It may be due to Application Link configuration.

New REST APIs

• The Metadata REST APIs to retrieve properties and tags will be updated to accept a scope query parameter. It will support the values user and system. If scope is not specified, the API will return all metadata across both scopes. 
• New APIs will be added for View and artifacts: 

POST /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

DELETE  /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/properties

DELETE  /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/properties/{key}

GET /v3/namespaces/{namespace-id}/metadata/search?query=term&target=view

["view1", "view2"]

POST /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/tags

["tag1", "tag2"]

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/tags

["tag1", "tag2"]

DELETE /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/tags

DELETE /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata/tags/{tag}

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/views/{view-id}/metadata

Existing/Changed REST APIs and CLI Commands:

Note: Changes are in blue

POST /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

POST /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

POST /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

POST /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

GET /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

GET /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

GET /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/properties

{
  "key1" : "value1",
  "key2" : "value2",
  //...
}

DELETE  /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/properties

DELETE  /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/properties/{key}

DELETE  /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/properties

DELETE  /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/properties/{key}

DELETE  /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/properties

DELETE  /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/properties/{key}

DELETE  /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/properties

DELETE  /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/properties/{key}

GET /v3/namespaces/{namespace-id}/metadata/search?query=term&target=<target-type>

["entity1", "entity2"]

GET /v3/namespaces/{namespace-id}/datasets/{dataset-id}/lineage?start=<start-ts>&end=<end-ts>&maxLevels=<max-levels>

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/lineage?start=<start-ts>&end=<end-ts>&maxLevels=<max-levels>

GET /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/runs/{run-id}/metadata

POST /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/tags

["tag1", "tag2"]

POST /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/tags

["tag1", "tag2"]

POST /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/tags

["tag1", "tag2"]

POST /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/tags

["tag1", "tag2"]

GET /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/tags

["tag1", "tag2"]

GET /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/tags

["tag1", "tag2"]

GET /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/tags

["tag1", "tag2"]

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/tags

["tag1", "tag2"]

DELETE /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/tags

DELETE /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata/tags/{tag}

DELETE /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/tags

DELETE /v3/namespaces/{namespace-id}/apps/{app-id}/metadata/tags/{tag}

DELETE /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/tags

DELETE /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata/tags/{tag}

DELETE /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/tags

DELETE /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata/tags/{tag}

DELETE /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata

DELETE /v3/namespaces/{namespace-id}/apps/{app-id}/metadata

DELETE /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata

DELETE /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata

GET /v3/namespaces/{namespace-id}/datasets/{dataset-id}/metadata?scope=system/user

GET /v3/namespaces/{namespace-id}/apps/{app-id}/metadata

GET /v3/namespaces/{namespace-id}/apps/{app-id}/{program-type}/{program-id}/metadata

GET /v3/namespaces/{namespace-id}/streams/{stream-id}/metadata

Questions

1. The REST APIs to retrieve metadata will accept an additional scope parameter. Is it considered a backward incompatible change that if the scope is not specified, the API will now return all metadata, and not just business metadata, like it did in 3.3?