Objetos de dados no Databricks lakehouse

O Databricks Lakehouse organiza os dados armazenados com o Delta Lake no armazenamento de objetos em nuvem usando estruturas familiares, como bancos de dados, tabelas e visualizações.Esse modelo combina muitos dos benefícios de um data warehouse corporativo com a escalabilidade e a flexibilidade de um data lake. Saiba mais sobre como este modelo funciona e a relação entre dados de objetos e metadados, para que você possa aplicar as melhores práticas ao projetar e implementar o Databricks Lakehouse em sua organização.

Quais objetos de dados estão no Databricks lakehouse?

A arquitetura Databricks lakehouse combina dados armazenados com o protocolo Delta Lake em armazenamento de objetos clouds com metadados registrados em um metastore. Existem cinco objetos principais no lakehouse do Databricks:

• Catálogo: um agrupamento de bancos de dados.

• Banco de dados ou esquema: um agrupamento de objetos em um catálogo. Os bancos de dados contêm tabelas, view e funções.

• Tabela: uma coleção de linhas e colunas armazenadas como arquivos de dados no armazenamento de objetos.

• Exibir: uma query salva normalmente em uma ou mais tabelas ou fonte de dados.

• Função: lógica salva que retorna um valor escalar ou conjunto de linhas.

Para obter informações sobre como proteger objetos com o Unity Catalog, consulte modelo de objetos protegíveis.

O que é um metastore?

O metastore contém todos os metadados que definem os objetos de dados na lakehouse. O Databricks oferece as seguintes opções de metastore:

• Metastore do Unity Catalog: O Unity Catalog fornece recursos centralizados de controle de acesso, auditoria, linhagem e descoberta de dados. Você cria metastores do Unity Catalog no nível da conta do Databricks e um único metastore pode ser usado em vários workspaces.

  Cada metastore do Unity Catalog é configurado com um local de armazenamento raiz em um bucket do GCS na sua do Google clouds account. Este local de armazenamento é usado por default para armazenar dados para tabelas de gerenciamento.

  No Unity Catalog, os dados são seguros por padrão. Inicialmente, os usuários não têm acesso aos dados em um metastore. O acesso pode ser concedido por um administrador de metástoro ou pelo proprietário de um objeto. Os objetos protegíveis no Unity Catalog são hierárquicos e os privilégios são herdados para baixo. O Unity Catalog oferece um único local para administrar políticas de acesso aos dados. Os usuários podem acessar dados no Unity Catalog de qualquer workspace ao qual o metastore esteja conectado. Para mais informações, consulte Gerenciar privilégios no Unity Catalog.

• Hive metastore integrado (legacy): cada workspace Databricks inclui um Hive metastore integrado como um serviço gerenciado. Uma instância do metastore é implementada em cada cluster e acessa com segurança os metadados de um repositório central para cada workspace do cliente.

  O Hive metastore fornece um modelo de governança de dados menos centralizado do que o Unity Catalog. Por padrão, um cluster permite que todos os usuários acessem todos os dados gerenciados pelo Hive metastore interno do workspace, a menos que o controle de acesso à tabela esteja habilitado para esse cluster. Para obter mais informações, consulte Controle de acesso à tabela do Hive metastore (legacy).

  Os controles de acesso à tabela não são armazenados no nível da conta e, portanto, devem ser configurados separadamente para cada workspace. Para aproveitar o modelo de governança de dados centralizado e simplificado fornecido pelo Unity Catalog, a Databricks recomenda que o senhor atualize as tabelas gerenciadas pelo Hive metastore do seu workspace para o metastore do Unity Catalog.

• Hive metastore (legado): você também pode trazer seu próprio metastore para o Databricks. Os clusters do Databricks podem se conectar a metástores Apache Hive externos existentes. Você pode usar o controle de acesso da tabela para gerenciar permissões em um metastore externo. Os controles de acesso da tabela não ficam armazenados no metastore externo e portanto devem ser configurados separadamente para cada workspace. A Databricks recomenda que você use Unity Catalog por sua simplicidade e modelo de governança centrado account .

Independentemente do metastore que você utiliza, o Databricks armazena todos os dados de tabela no armazenamento de objetos em sua conta na nuvem.

O que é um catálogo?

Um catálogo é a maior abstração (ou granulação mais grosseira) no modelo relacional Databricks Lakehouse. Cada banco de dados será associado a um catálogo. Os catálogos existem como objetos dentro de uma metastore.

Antes da introdução do Unity Catalog, o Databricks usavam um espaço de nomes de duas camadas. Os catálogos são a terceira camada no modelo de espaço de nomes do Unity Catalog:

catalog_name.database_name.table_name

O Hive metastore integrado oferece suporte apenas a um único catálogo, hive_metastore.

O que é um banco de dados?

Um banco de dados é uma coleção de objetos de dados, como tabelas ou exibições (também chamadas de "relações") e funções. No Databricks, os termos "esquema" e "banco de dados" são usados de forma intercambiável (enquanto em muitos sistemas relacionais, um banco de dados é uma coleção de esquemas).

Bancos de dados sempre serão associados a um local no armazenamento de objetos na nuvem. Opcionalmente, você pode especificar um LOCATION ao registrar um banco de dados, tendo em mente que:

• O LOCATION associado a um banco de dados é sempre considerado um local gerenciado.

• A criação de um banco de dados não cria nenhum arquivo no local de destino.

• O LOCATION de um banco de dados determinará o local padrão para os dados de todas as tabelas registradas nesse banco de dados.

• Ao excluir com sucesso um banco de dados, todos os dados e arquivos armazenados em um local gerenciado serão excluídos de forma recursiva.

Essa interação entre locais gerenciados por banco de dados e arquivos de dados é muito importante. Para evitar a exclusão acidental de dados:

• Não compartilhe localizações de banco de dados em várias definições de banco de dados.

• Não registre um banco de dados em um local que já contenha dados.

• Para gerenciar o ciclo de vida dos dados de forma independente do banco de dados, salve os dados em um local que não esteja aninhado sob nenhuma localização do banco de dados.

O que é uma mesa?

Uma tabela Databricks é uma coleção de dados estruturados. Uma tabela Delta armazena dados como um diretório de arquivos no armazenamento de objetos em nuvem e registra os metadados da tabela no metastore dentro de um catálogo e esquema.Como o Delta Lake é o provedor de armazenamento padrão para tabelas criadas no Databricks, todas as tabelas criadas no Databricks são, por padrão, tabelas Delta. Como as tabelas Delta armazenam dados no armazenamento de objetos em nuvem e fornecem referências aos dados por meio de um metastore, os usuários em toda a organização podem acessar os dados usando suas APIs preferidas. No Databricks, isso inclui SQL, Python, PySpark, Scala e R.

Observe que é possível criar tabelas em Databricks que não sejam tabelas Delta. Essas tabelas não são apoiadas pelo Delta Lake e não fornecerão as transações ACID e o desempenho otimizado das tabelas Delta. As tabelas que se enquadram nesta categoria incluem tabelas registradas em dados em sistemas externos e tabelas registradas em outros formatos de arquivo no data lake. Consulte Conectar-se à fonte de dados.

Existem dois tipos de tabelas no Databricks, gerenciar e ungerenciar (ou externas) tabelas.

Observação

A distinção Delta Live Tables entre tabelas ao vivo e tabelas ao vivo de transmissão não é aplicada da perspectiva da mesa.

O que é uma tabela gerenciada?

O Databricks gerencia os metadados e os dados de uma tabela gerenciada; ao eliminar uma tabela, você também exclui os dados subjacentes. Analistas de dados e outros usuários que trabalham principalmente em SQL podem preferir esse comportamento. As tabelas gerenciadas são o padrão ao criar uma tabela. Os dados de uma tabela gerenciada residem no LOCATION do banco de dados no qual ela está registrada. Essa relação gerenciada entre a localização dos dados e o banco de dados significa que, para mover uma tabela gerenciada para um novo banco de dados, é necessário reescrever todos os dados na nova localização.

Existem várias maneiras de criar tabelas gerenciadas, incluindo:

CREATE TABLE table_name AS SELECT * FROM another_table

CREATE TABLE table_name (field_name1 INT, field_name2 STRING)

df.write.saveAsTable("table_name")

O que é uma tabela não gerenciada?

O Databricks gerencia apenas os metadados de tabelas não gerenciadas (externas); quando você elimina uma tabela, não afeta os dados subjacentes. As tabelas não gerenciadas sempre especificarão um LOCATION durante a criação da tabela; você pode tanto registrar um diretório existente de arquivos de dados como uma tabela ou fornecer um caminho quando uma tabela for definida pela primeira vez.Como os dados e os metadados são gerenciados de forma independente, você pode renomear uma tabela ou registrá-la em um novo banco de dados sem precisar mover nenhum dado.Os engenheiros de dados geralmente preferem tabelas não gerenciadas e a flexibilidade que elas oferecem para os dados de produção.

Há várias maneiras de criar tabelas não gerenciadas, incluindo:

CREATE TABLE table_name
USING DELTA
LOCATION '/path/to/existing/data'

CREATE TABLE table_name
(field_name1 INT, field_name2 STRING)
LOCATION '/path/to/empty/directory'

df.write.option("path", "/path/to/empty/directory").saveAsTable("table_name")

O que é uma exibição?

Um modo de exibição armazena o texto de uma consulta normalmente em uma ou mais fontes de dados ou tabelas no metastore. No Databricks, uma visualização é equivalente a um DataFrame Spark persistente como um objeto em um banco de dados. Ao contrário do DataFrames, você pode consultar visualizações de qualquer parte do produto Databricks, supondo que tenha permissão para fazer isso. A criação de uma visualização não processa nem grava nenhum dado; somente o texto da consulta é registrado na metastore no banco de dados associado.

O que é uma exibição temporária?

Uma exibição temporária tem um escopo e persistência limitados e não está registrada em um esquema ou catálogo. A vida útil de uma exibição temporária difere de acordo com o ambiente que você está usando:

• Em notebooks e jobs, as exibições temporárias têm como escopo o nível do notebook ou do script. Eles não podem ser referenciados fora do notebook no qual foram declarados e não existirão mais quando o notebook se separar do cluster.

• No Databricks SQL, as exibições temporárias têm o escopo definido para o nível de consulta. Várias instruções dentro da mesma consulta podem usar o modo de exibição temporário, mas ele não pode ser referenciado em outras consultas, mesmo dentro do mesmo painel.

• Várias declarações dentro da mesma consulta podem usar a visualização temporária, mas ela não pode ser referenciada em outras consultas, mesmo dentro do mesmo painel.O Databricks recomenda o uso de visualizações com ACLs de tabela apropriados em vez de visualizações temporárias globais.

O que é uma função?

As funções permitem associar lógica definida pelo usuário a um banco de dados. As funções podem retornar valores escalares ou conjuntos de linhas. Funções são usadas para agregar dados. O Databricks permite que você salve funções em vários idiomas, dependendo do seu contexto de execução, com suporte amplo para SQL.É possível utilizar funções para oferecer acesso gerenciado à lógica personalizada em uma variedade de contextos no produto Databricks.

Como funcionam os objetos relacionais no Delta Live Tables?

Delta Live Tables usa uma sintaxe declarativa para definir e gerenciar DDL, DML e implementação de infraestrutura. O Delta Live Tables usa o conceito de "esquema virtual" durante o planejamento e a execução lógica. O Delta Live Tables pode interagir com outros bancos de dados em seu ambiente Databricks, e o Delta Live Tables pode publicar e persistir em tabelas para consulta em outros lugares, especificando um banco de dados de destino nas definições de configuração do pipeline.

Todas as tabelas criadas em Delta Live Tables são tabelas Delta. Ao usar o Unity Catalog com Delta Live Tables, todas as tabelas são tabelas gerenciadas do Unity Catalog. Se o Unity Catalog não estiver ativo, as tabelas podem ser declaradas como gerenciadas ou não gerenciadas.

Embora as visualizações possam ser declaradas no Delta Live Tables, elas devem ser consideradas como visualizações temporárias com escopo definido no pipeline. Tabelas temporárias no Delta Live Tables são um conceito único: essas tabelas persistem dados para armazenamento, mas não publicam dados no banco de dados de destino.

Algumas operações, como APPLY CHANGES INTO, registrarão uma tabela e uma visualização no banco de dados; o nome da tabela começará com um sublinhado (_) e a visualização terá o nome da tabela declarado como o destino da operação APPLY CHANGES INTO. A visualização consulta a tabela oculta correspondente para materializar os resultados.