Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(tableau): adds more reporting metrics to better understand lineage construction in tableau ingestion #12008

Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 31 additions & 17 deletions metadata-ingestion/src/datahub/ingestion/source/tableau/tableau.py
Original file line number Diff line number Diff line change
Expand Up @@ -599,7 +599,13 @@ class TableauSourceReport(StaleEntityRemovalSourceReport):
num_datasource_field_skipped_no_name: int = 0
num_csql_field_skipped_no_name: int = 0
num_table_field_skipped_no_name: int = 0
# lineage
num_upstream_table_lineage: int = 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this the number of tableau entities with upstream lineage, or the number of upstream lineage entries across all upstreamLineage aspects?

imo the former would be more useful

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the second, every time an UpstreamLineage aspect is emitted, the counter is increased

num_upstream_fine_grained_lineage: int = 0
num_upstream_table_skipped_no_name: int = 0
num_upstream_table_skipped_no_columns: int = 0
num_upstream_table_failed_generate_reference: int = 0
num_upstream_fine_grained_lineage_failed_parse_sql: int = 0


@platform_name("Tableau")
Expand Down Expand Up @@ -1292,7 +1298,7 @@ def _create_upstream_table_lineage(
datasource: dict,
browse_path: Optional[str],
is_embedded_ds: bool = False,
) -> Tuple:
) -> Tuple[List[Upstream], List[FineGrainedLineage]]:
upstream_tables: List[Upstream] = []
fine_grained_lineages: List[FineGrainedLineage] = []
table_id_to_urn = {}
Expand Down Expand Up @@ -1453,7 +1459,8 @@ def get_upstream_tables(
c.COLUMNS_CONNECTION
].get("totalCount")
if not is_custom_sql and not num_tbl_cols:
logger.debug(
self.report.num_upstream_table_skipped_no_columns += 1
logger.warning(
f"Skipping upstream table with id {table[c.ID]}, no columns: {table}"
)
continue
Expand All @@ -1469,7 +1476,10 @@ def get_upstream_tables(
table, default_schema_map=self.config.default_schema_map
)
except Exception as e:
logger.info(f"Failed to generate upstream reference for {table}: {e}")
self.report.num_upstream_table_failed_generate_reference += 1
logger.warning(
f"Failed to generate upstream reference for {table}: {e}"
)
continue

table_urn = ref.make_dataset_urn(
Expand Down Expand Up @@ -1635,15 +1645,7 @@ def get_upstream_fields_from_custom_sql(
func_overridden_info=None, # Here we don't want to override any information from configuration
)

if parsed_result is None:
logger.info(
f"Failed to extract column level lineage from datasource {datasource_urn}"
)
return []
if parsed_result.debug_info.error:
logger.info(
f"Failed to extract column level lineage from datasource {datasource_urn}: {parsed_result.debug_info.error}"
)
if parsed_result is None or parsed_result.debug_info.error:
return []

cll: List[ColumnLineageInfo] = (
Expand Down Expand Up @@ -2005,6 +2007,7 @@ def _create_lineage_to_upstream_tables(
aspect_name=c.UPSTREAM_LINEAGE,
aspect=upstream_lineage,
)
self.report.num_upstream_table_lineage += len(upstream_tables)

@staticmethod
def _clean_tableau_query_parameters(query: str) -> str:
Expand Down Expand Up @@ -2104,7 +2107,7 @@ def parse_custom_sql(
f"Overridden info upstream_db={upstream_db}, platform_instance={platform_instance}, platform={platform}"
)

return create_lineage_sql_parsed_result(
parsed_result = create_lineage_sql_parsed_result(
query=query,
default_db=upstream_db,
platform=platform,
Expand All @@ -2114,6 +2117,15 @@ def parse_custom_sql(
schema_aware=not self.config.sql_parsing_disable_schema_awareness,
)

if parsed_result is None or parsed_result.debug_info.error:
message = f"Failed to extract column level lineage from datasource {datasource_urn}"
if parsed_result is not None and parsed_result.debug_info.error:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this check is redundant, right?

Copy link
Contributor Author

@sgomezvillamor sgomezvillamor Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as per my understanding, not redundant

I just rewrote code below and moved it into the parse_custom_sql function, as there were two callers of the function doing about the same:

        if parsed_result is None:
            logger.info(
                f"Failed to extract column level lineage from datasource {datasource_urn}"
            )
            return []
        if parsed_result.debug_info.error:
            logger.info(
                f"Failed to extract column level lineage from datasource {datasource_urn}: {parsed_result.debug_info.error}"
            )
            return []

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so create_lineage_sql_parsed_result will never return None - if there was an error, it would be part of the SqlParsingResult object

in debug_info, error is an alias for .table_error or .column_error (since only one of those will be set).

@property
def error(self) -> Optional[Exception]:
return self.table_error or self.column_error

if there's a column error, we still can generate table-level lineage - so I think the error messages might need to be tweaked

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so create_lineage_sql_parsed_result will never return None

You are right. Then definitely parsed_result is None becomes unnecessary.

I made warning messages more detailed depending on the error type with commit e585d14 .

message += f": {parsed_result.debug_info.error}"
logger.warning(message)
self.report.num_upstream_fine_grained_lineage_failed_parse_sql += 1

return parsed_result

def _enrich_database_tables_with_parsed_schemas(
self, parsing_result: SqlParsingResult
) -> None:
Expand Down Expand Up @@ -2148,9 +2160,6 @@ def _create_lineage_from_unsupported_csql(
)

if parsed_result is None:
logger.info(
f"Failed to extract table level lineage for datasource {csql_urn}"
)
return

self._enrich_database_tables_with_parsed_schemas(parsed_result)
Expand All @@ -2170,12 +2179,13 @@ def _create_lineage_from_unsupported_csql(
upstreams=upstream_tables,
fineGrainedLineages=fine_grained_lineages,
)

yield self.get_metadata_change_proposal(
csql_urn,
aspect_name=c.UPSTREAM_LINEAGE,
aspect=upstream_lineage,
)
self.report.num_upstream_table_lineage += len(upstream_tables)
self.report.num_upstream_fine_grained_lineage += len(fine_grained_lineages)

def _get_schema_metadata_for_datasource(
self, datasource_fields: List[dict]
Expand Down Expand Up @@ -2326,6 +2336,10 @@ def emit_datasource(
aspect_name=c.UPSTREAM_LINEAGE,
aspect=upstream_lineage,
)
self.report.num_upstream_table_lineage += len(upstream_tables)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo having a simple count of the # of tables with an upstream lineage is more useful. it's likely pretty rare that tables have more than one upstream, but this lets us say things like "we have X% lineage coverage" and is more inline with what we report in other sources

Suggested change
self.report.num_upstream_table_lineage += len(upstream_tables)
self.report.num_upstreams_with_table_lineage += 1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's likely pretty rare that tables have more than one upstream

A table or view created with a select statement (CTAS) will have all tables in the FROM as upstream lineage, right? in that case I expect that selects with multiple tables in the FROM will be very common.

Anyway, we can easily have both counters and validate our assumptions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed in commit c6875e9

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eg. these are the metrics I got when testing with Acryl's tableau

 'num_tables_with_upstream_lineage': 29,
 'num_upstream_table_lineage': 49,
 'num_upstream_fine_grained_lineage': 516,
 'num_upstream_table_skipped_no_columns': 3,

self.report.num_upstream_fine_grained_lineage += len(
fine_grained_lineages
)

# Datasource Fields
schema_metadata = self._get_schema_metadata_for_datasource(
Expand Down
Loading