MaxCompute:Recursos de armazenamento - Armazenamento em camadas

Configurações personalizadas manuais

Para tabelas não particionadas ou partições, defina manualmente a classe de armazenamento como IA storage class ou long-term storage. A alteração entra em vigor imediatamente.

ALTER TABLE <TABLE_NAME> [PARTITION(<PARTITION_SPEC>)]
        SET <TBLPROPERTIES|PARTITIONPROPERTIES>("storagetier"="standard|lowfrequency|longterm");

Configuração automática usando regras de ciclo de vida

Configure regras de ciclo de vida de armazenamento em camadas no nível de projeto ou de tabela particionada. Essas regras convertem automaticamente as classes de armazenamento com base em condições especificadas:

• Regras no nível do projeto:

  Após definir uma regra no nível do projeto, ela se torna a regra padrão para todas as tabelas não particionadas no projeto e para todas as partições em tabelas particionadas que não possuem regras próprias. Essas tabelas e partições são convertidas automaticamente para a classe de armazenamento especificada.

• Configurações no nível da tabela particionada:

  Ao definir uma regra para uma tabela particionada específica, ela tem precedência sobre a regra no nível do projeto. Todas as partições na tabela que atendem às condições da regra são convertidas automaticamente para a classe de armazenamento especificada.

GET_PARTITION_META

struct GET_PARTITION_META(<tableName>, <pt_col1>, <pt_col2>, ..., <pt_col_n>);

Observações

• Ao adicionar uma regra no nível de linha a uma tabela, considere os padrões de acesso de usuários além daqueles que estão sendo controlados. Se outros usuários já acessaram a tabela, defina regras explícitas para eles a fim de evitar filtragem inesperada de dados devido a restrições de acesso não intencionais. Para mais informações, consulte Controle de acesso no nível de linha.

• Por padrão, as tabelas do MaxCompute podem ser acessadas via SQL e mecanismos externos (como Spark e Flink). No entanto, apenas o mecanismo SQL do MaxCompute suporta a função GET_PARTITION_META. Se você usar GET_PARTITION_META no controle de acesso no nível de linha, a tabela só poderá ser lida pelo mecanismo SQL do MaxCompute. Outros mecanismos não conseguirão acessar a tabela.

• Para acessar dados sob permissões no nível de linha, você também deve ter a permissão SELECT sobre os dados.

• O comportamento de pruning de partição varia dependendo das condições de filtro usadas com GET_PARTITION_META.

  • Se a condição de filtro envolver apenas campos de partição — por exemplo, permitindo acesso ao armazenamento Standard onde o valor da partição de primeiro nível é 2024:

    GET_PARTITION_META('storage_table', pt1, pt2).storagetier == 'standard') AND pt1='2024'

    Ao acessar storage_table usando SQL e a cláusula WHERE não contiver condições de partição, o sistema suporta nativamente o pruning de partição para evitar uma varredura completa da tabela, permitindo acesso somente leitura apenas às partições em storage_table que atendem aos requisitos.

  • Se a condição de filtro incluir um campo de não-partição combinado com um operador AND — por exemplo, permitindo acesso ao armazenamento Standard onde a>100:

    GET_PARTITION_META('storage_table', pt1, pt2).storagetier == 'standard') AND a > 100

    Ao consultar storage_table sem uma condição de partição na cláusula WHERE, o pruning de partição ainda se aplica. Apenas as partições armazenadas como standard são acessadas.

  • Se a condição de filtro incluir um campo de não-partição combinado com um operador OR — por exemplo, permitindo acesso ao armazenamento Standard ou onde a>100:

    get_partition_meta('storage_table', pt1, pt2).storagetier == 'standard') OR a > 100

    Ao consultar storage_table, dois cenários se aplicam:

    • Se a cláusula WHERE não tiver condição de partição, todas as partições serão verificadas para encontrar dados onde a>100.

    • Se a cláusula WHERE incluir uma condição de partição, apenas as partições especificadas serão verificadas em busca de dados correspondentes a standard ou a>100.

Exemplos

Crie a tabela particionada storage_table.

CREATE TABLE storage_table(a BIGINT, b BIGINT) PARTITIONED BY (pt1 STRING, pt2 STRING);

• Exemplo 1:

  Crie uma política chamada policy01 para o grupo de usuários DEFAULT. Esta política permite acesso apenas aos dados de armazenamento Standard em storage_table. Todos os usuários (incluindo o Project Owner) têm negado o acesso a dados da IA storage class ou do long-term storage e recebem resultados vazios.

  CREATE ROW ACCESS POLICY policy01 
  ON storage_table 
  TO DEFAULT 
  FILTER USING (get_partition_meta('storage_table', pt1, pt2).storagetier == 'standard');

  Se o Logview Summary mostrar a seguinte palavra-chave, a filtragem no nível de linha foi acionada:

  WARNING:[1,15] row access policy is enabled on table yyy_hp_storagetier.storage_table01. Isso indica que a política de acesso a linhas foi aplicada durante a consulta.

• Exemplo 2:

  Conceda ao usuário user_x a permissão policy02 para acessar dados da IA storage class e do long-term storage em storage_table.

  CREATE ROW ACCESS POLICY policy02 
  ON storage_table 
  TO USER (user_x)  -- You can also grant to a role using TO role rolename, then assign the role to user_x.
  FILTER USING (get_partition_meta('storage_table', pt1, pt2).storagetier IN ('lowfrequency','longterm'));

  Dois cenários se aplicam:

  • Se a tabela tiver a permissão policy01 configurada, todos os usuários (exceto user_x) podem acessar os dados de armazenamento standard de storage_table, mas não podem acessar dados de infrequent-access ou long-term storage, e qualquer tentativa retorna valores vazios. Para user_x, o acesso aos dados de infrequent-access e long-term storage de storage_table é permitido, mas o acesso a dados de armazenamento standard não é permitido e retorna valores vazios.

  • Se policy01 não estiver definida, todos os usuários (exceto user_x) não podem acessar nenhum dado em storage_table (resultados vazios). Apenas user_x pode acessar dados da IA storage class e do long-term storage, mas não pode acessar dados de armazenamento Standard (resultados vazios).

• Exemplo 3:

  Conceda ao usuário user_y a permissão policy03 para acessar todos os dados em storage_table.

  CREATE ROW ACCESS POLICY policy03 
  ON storage_table 
  TO USER (user_y)  -- You can also grant to a role using TO role rolename, then assign the role to user_y.
  FILTER USING (true);  -- Constant true allows access to all data in the table.

  Dois cenários se aplicam:

  • Se a tabela tiver a permissão policy01 definida, todos os usuários (exceto user_y) podem acessar os dados de armazenamento Standard de storage_table, mas não podem acessar infrequent access ou long-term storage, e tais solicitações retornam valores vazios. O usuário user_y pode acessar dados de todas as classes de armazenamento em storage_table.

  • Se a tabela não tiver a permissão policy01 atribuída, todos os usuários (exceto user_y) não podem acessar nenhum dado armazenado em storage_table, e tais solicitações retornam valores vazios. Apenas user_y pode acessar dados de todas as classes de armazenamento em storage_table.