Relacionamentos entre views de métricas
Beta
Este recurso está na versão Beta.
Um relacionamento entre as views de métricas do Unity Catalog tem um nome e uma direção, de uma view de métricas de origem para uma view de métricas de destino. Ele registra a cardinalidade (como MANY TO ONE) e a condição que une as duas views métricas. Relacionamentos são apenas metadados, portanto, eles descrevem como as views de métricas se encaixam sem definir um join. Isso permite que assistentes de AI e ferramentas de BI as combinem conforme cada análise exigir.
Por que usar relacionamentos
Uma view de métricas normalmente descreve fatos ou dimensões em um único nível. Por exemplo, uma view de métricas orders_mv mede a receita de cada pedido, e uma view de métricas customers_mv descreve cada cliente por segmento e região. Muitas análises combinam views de métricas como estas, como analisar a receita do pedido por segmento de cliente.
Como um relacionamento não prescreve um join fixo, as mesmas métricas views podem dar suporte a muitas análises diferentes. Assistentes de IA e ferramentas de BI leem o relacionamento do Unity Catalog, para que façam o join das views de métricas da mesma forma em vez de inferir um join a partir dos nomes das colunas.
Relacionamentos em comparação com restrições de key estrangeira
Um relacionamento é semelhante a uma restrição de key estrangeira. A tabela a seguir os compara.
Aspecto | Relacionamento | Restrição de key estrangeira |
|---|---|---|
Aplica-se a | view de métricas do Unity Catalog | Tabelas e materialized views |
Requisito no alvo | Nenhuma | Uma key primária ou restrição exclusiva |
Condição de join | Qualquer condição | Igualdade entre as colunas de key estrangeira e as colunas de key do destino |
Cardinalidade | Declarado como | Não declarado |
Aplicativo | Não aplicado | Não aplicado |
Otimização de query | Não usado | Usado ao especificar |
Relacionamentos em comparação com outras formas de modelar joins
A tabela abaixo mostra como os relacionamentos se comparam a outras formas de modelar joins:
Abordagem | Onde você o define | Como é usada |
|---|---|---|
Relacionamentos entre views de métricas |
| Registra como as métricas views se encaixam apenas como metadados. Assistentes de AI e ferramentas de BI leem o relacionamento do Unity Catalog e escolhem joins livremente para cada análise. |
A seção | Define um join fixo, como um join entre tabelas, cuja execução acontece sempre que você faz uma query na view de métrica. | |
O painel Relações de um AI/BI dashboard | Codifica a lógica de query e filtragem do dashboard para que as agregações permaneçam corretas em datasets unidos. |
Como funciona
Um relacionamento pertence à sua view de métrica de origem. Quando você adiciona um, o Databricks o armazena com a origem e a origem o retorna em DESCRIBE TABLE EXTENDED e em INFORMATION_SCHEMA.TABLE_CONSTRAINTS.
Ao adicionar um relacionamento, o Databricks valida a condição da mesma forma que valida a cláusula ON de um join. A instrução falha se uma coluna não for resolvida ou se a condição não for uma condição de join válida.
Um relacionamento segue o ciclo de vida de seus Endpoint:
- Quando você remove a view de métrica de origem, o Databricks exclui seus relacionamentos.
- Quando você descartar a view de métrica de destino, os relacionamentos que apontam para ela não aparecerão mais em
DESCRIBE TABLE EXTENDEDouINFORMATION_SCHEMA.TABLE_CONSTRAINTS.
Requisitos
Para trabalhar com relacionamentos, você precisa do seguinte:
- Databricks Runtime 19 e acima, ou um SQL warehouse. Consulte Disponibilidade do recurso de view de métrica.
- Uma source e um target que são ambos views de métricas do Unity Catalog. Views de métricas temporárias não são aceitas.
- Para adicionar um relacionamento: o privilégio
MANAGEna view de métrica de origem ou a propriedade dela, o privilégioSELECTna view de métrica de destino eUSE CATALOGeUSE SCHEMAno catálogo e no esquema que contêm cada view de métrica. Consulte Definir permissões. - Para descartar um relacionamento: o privilégio
MANAGEna metric view de origem ou a propriedade dela, eUSE CATALOGeUSE SCHEMAem seu catálogo e esquema. Você não precisa de nenhum privilégio no destino.
Adicionar um relacionamento
Para adicionar um relacionamento, execute ALTER VIEW ... ADD CONSTRAINT na view de métricas de origem:
ALTER VIEW source_metric_view ADD [ CONSTRAINT name ]
{ MANY | ONE } TO { MANY | ONE } RELATIONSHIP TO target_metric_view [ [ AS ] target_alias ]
{ ON condition | USING ( column [, ...] ) }
Use as seguintes regras ao escrever a instrução:
- Nome : o nome deve ser exclusivo entre todas as restrições no schema. Se você omitir
CONSTRAINT name, o Databricks nomeia o relacionamento<source>_to_<target>, usando os nomes não qualificados das duas visualizações de métrica. Por exemplo, um relacionamento sem nome demain.sales.orders_mvamain.sales.customers_mvé nomeadoorders_mv_to_customers_mv. Como um segundo relacionamento sem nome para o mesmo alvo gera o mesmo nome, ele falha. Nomeie cada relacionamento quando uma fonte tiver mais de um relacionamento com o mesmo alvo. - Cardinalidade : Use
MANY TO ONE,ONE TO MANY,ONE TO ONEouMANY TO MANY. Separe as palavras-chave com espaços, não underscores. - Target : O target pode estar em qualquer catalog ou schema do mesmo metastore.
- Alias do destino : Opcional. Use um alias para se referir ao destino na condição
ON. Um relacionamento de uma view de métrica para si mesma exige um alias que seja diferente do nome da fonte. - Condição ON : Uma expressão
BOOLEANdeterminística sobre as colunas de ambas as metric views. Qualifique cada coluna com o nome de origem, o nome de destino ou o alias de destino. A condição não pode referenciar uma medida e não pode chamar uma função agregada, uma função de janela ou um gerador. - Colunas USING : colunas que existem com o mesmo nome em ambas as visualizações de métrica.
Para a sintaxe completa e limites, consulte ALTER VIEW.
Exemplos
O exemplo a seguir declara que cada pedido corresponde a um cliente, usando uma coluna que existe em ambas as visualizações de métrica:
ALTER VIEW main.sales.orders_mv ADD CONSTRAINT orders_customer
MANY TO ONE RELATIONSHIP TO main.sales.customers_mv
USING (customer_id);
O exemplo abaixo declara dois relacionamentos da mesma fonte para o mesmo destino, um para cada papel que o destino desempenha:
ALTER VIEW main.travel.flights_mv ADD CONSTRAINT departure_city
MANY TO ONE RELATIONSHIP TO main.travel.cities_mv AS c
ON flights_mv.departure_city_id = c.city_id;
ALTER VIEW main.travel.flights_mv ADD CONSTRAINT arrival_city
MANY TO ONE RELATIONSHIP TO main.travel.cities_mv AS c
ON flights_mv.arrival_city_id = c.city_id;
O exemplo a seguir declara um relacionamento de uma view de métrica para si mesma. O alias mgr distingue o destino da origem:
ALTER VIEW main.hr.employees_mv ADD CONSTRAINT manager
MANY TO ONE RELATIONSHIP TO main.hr.employees_mv AS mgr
ON employees_mv.manager_id = mgr.employee_id;
O exemplo a seguir declara um relacionamento ONE TO MANY do lado do cliente. Use esta direção quando você puder gerenciar a view de métricas de clientes, mas não a view de métricas de pedidos:
ALTER VIEW main.sales.customers_mv ADD CONSTRAINT customer_orders
ONE TO MANY RELATIONSHIP TO main.sales.orders_mv AS o
ON customers_mv.customer_id = o.customer_id;
Após a execução bem-sucedida de uma declaração, DESCRIBE TABLE EXTENDED na metric view de origem lista o novo relacionamento.
view relacionamentos
Para ver os relacionamentos de uma view de métrica, execute DESCRIBE TABLE EXTENDED na view de métrica de origem:
DESCRIBE TABLE EXTENDED main.travel.flights_mv;
A seção # Constraints da saída contém uma linha para cada relacionamento, com o nome do relacionamento e sua definição:
# Constraints
departure_city MANY TO ONE RELATIONSHIP TO `main`.`travel`.`cities_mv` AS `c` ON flights_mv.departure_city_id = c.city_id
arrival_city MANY TO ONE RELATIONSHIP TO `main`.`travel`.`cities_mv` AS `c` ON flights_mv.arrival_city_id = c.city_id
DESCRIBE TABLE EXTENDED ... AS JSON retorna os mesmos relacionamentos no campo table_constraints.
Para listar os relacionamentos em um catalog, query INFORMATION_SCHEMA.TABLE_CONSTRAINTS e filtre pelo tipo de restrição RELATIONSHIP:
SELECT table_schema, table_name, constraint_name
FROM main.information_schema.table_constraints
WHERE constraint_type = 'RELATIONSHIP';
Remover um relacionamento
Para descartar um relacionamento, execute ALTER VIEW ... DROP CONSTRAINT na view de métrica de origem com o nome do relacionamento:
ALTER VIEW main.travel.flights_mv DROP CONSTRAINT IF EXISTS arrival_city;
Sem IF EXISTS, a instrução falha com NO_SUCH_CONSTRAINT_EXCEPTION se a metric view de origem não tiver nenhum relacionamento com esse nome.
Use relacionamentos com o Genie Code para autoria de dashboard
Genie Code for dashboard authoring usa os relacionamentos declarados nas views de métricas do Unity Catalog quando cria um AI/BI dashboard:
- Importação : quando um dashboard usa views de métricas do Unity Catalog, o agente lê os relacionamentos declarados nelas e adiciona ao dashboard aqueles que a análise precisa como relacionamentos de dashboard.
- Exportar : Quando você solicita ao agente que salve uma relação de dashboard no Unity Catalog, ele declara a relação na view da métrica de origem após você aprovar a alteração. A exportação requer que ambos os datasets sejam views de métricas do Unity Catalog, e a relação exportada sempre usa uma condição
ON. Você precisa dos privilégios listados em Requisitos.
Limitações
As seguintes limitações se aplicam aos relacionamentos entre visualizações de métrica:
- Você só pode declarar um relacionamento com
ALTER VIEW. Você não pode declarar um relacionamento na definição YAML de view de métricas. - O Databricks não impõe relacionamentos, não verifica dados em relação à cardinalidade declarada nem usa relacionamentos para otimizar queries. O
RELYnão é compatível. - Uma view de métrica de destino não lista suas relações de entrada. Para encontrá-las, verifique cada view de métrica de origem.
- Uma metric view de origem pode ter no máximo 50 relações de saída, e uma metric view de destino pode ter no máximo 100 relações de entrada. A adição de uma relação que exceda qualquer um dos limites falhará com
UC_RESOURCE_QUOTA_EXCEEDED. - Renomear uma view de métrica não atualiza uma condição
ONque nomeia a view antiga. Remova o relacionamento e adicione-o novamente com o novo nome. - As relações não estão disponíveis na API REST ou SDKs. Use SQL para gerenciá-las.