Usando volumes de estágio Snowflake com serviços

O Snowflake oferece suporte a vários tipos de volume de armazenamento para seus contêineres de aplicativo, incluindo volumes de estágio interno, armazenamento local, armazenamento de memória e armazenamento em bloco. Esta seção explica como configurar volumes e montagens de volume para estágios internos. Um volume de área de preparação interna é aquele configurado para usar uma área de preparação do Snowflake como armazenamento persistente.

Com volumes de área de preparação, seu serviço pode acessar os objetos de uma área de preparação interna como se fossem arquivos em seu sistema de arquivos, simplificando o código do seu serviço em comparação com o uso de um driver do Snowflake e os comandos SQL GET e PUT para acessar esses objetos. Os volumes de área de preparação também podem ter um desempenho melhor em cenários com leituras ou gravações em streaming de arquivos de dados grandes.

Se as operações do seu sistema de arquivos puderem ser facilmente traduzidas em operações GET e PUT de streaming, os volumes de área de preparação funcionarão bem para o seu cenário. Se o seu aplicativo precisar renomear ou mover arquivos, modificar arquivos existentes ou realizar bloqueios baseados no sistema de arquivos, o volume de área de preparação não será adequado para sua carga de trabalho.

Nota

Atualmente, existem duas implementações de volumes de área de preparação: uma versão em disponibilidade geral e uma obsoleta. A Snowflake recomenda que você use a versão em disponibilidade geral para novos serviços e que migre seus aplicativos existentes da versão obsoleta.

A implementação do volume de área de preparação transmite o conteúdo do arquivo diretamente para e do armazenamento em nuvem, garantindo que você sempre obtenha o conteúdo mais recente. Considere os seguintes pontos ao usar um volume de área de preparação:

  • Um volume de área de preparação é otimizado para leituras e gravações sequenciais e de grande porte, fornecendo alto desempenho para esses padrões de acesso. Para obter melhores resultados, leia e grave os dados em partes grandes e contíguas.

  • As leituras sempre retornam os dados mais recentes, o que permite o compartilhamento de dados entre os serviços.

  • Gravações aleatórias ou anexos de arquivos não são compatíveis. A tentativa dessas operações gera erro. A Snowflake recomenda que você use volumes de armazenamento em bloco para essas cargas de trabalho.

Configurar uma área de preparação do Snowflake como um volume de armazenamento em uma especificação de serviço

Para criar um serviço em que os contêineres de serviço usem um volume de área de preparação, você executa duas etapas para especificar as configurações necessárias na especificação do serviço:

  • Defina um volume de área de preparação que identifique a área de preparação do Snowflake a ser utilizada como volume de armazenamento.

  • Especifique onde montar o volume de área de preparação no contêiner do seu aplicativo.

Etapa 1: Definir um volume de área de preparação

Para definir um volume de área de preparação, adicione o campo spec.volumes à especificação do serviço, conforme mostrado no seguinte exemplo:

spec:
  containers:
    ..
  volumes:
  - name: <name>
    source: stage
     stageConfig:
       name: <stage_name>
       medataCache: <time_period>
       resources:
         requests:
           memory: <amount-of-memory>
           cpu: <cpu-units>
         limits:
           memory: <amount-of-memory>
           cpu: <cpu-units>
Copy

A lista a seguir define os campos do exemplo:

  • name: fornece o nome do volume.

  • source: identifica o tipo do volume (área de preparação).

  • stageConfig.name: identifica a área de preparação interna do Snowflake ou a pasta em uma área de preparação a ser montada; por exemplo, @my_stage, @my_stage/folder ou @my_db.my_schema.my_stage/folder/nestedfolder. Este valor deve estar entre aspas duplas.

Você pode incluir os seguintes campos opcionais em stageConfig:

  • Campo stageConfig.resources: o componente Snowflake que fornece o volume de área de preparação montado requer recursos de memória e CPU. Use este campo para especificar esses requisitos de memória e CPU, semelhantes às especificações de recursos para os contêineres de seus aplicativos. Para obter mais informações, consulte os campos Campo containers.resources. Se este campo não for especificado, as seguintes configurações de recursos padrão serão aplicadas:

    • resources.requests.cpu: 0

    • resources.requests.memory: 0.5Gi

    • resources.limits.cpu: 0.5

    • resources.limits.memory: 1Gi

    Para a maioria dos aplicativos com tráfego de dados típico para volumes de área de preparação, não é preciso definir este campo, pois as configurações de recursos padrão devem ser suficientes. No entanto, se o seu aplicativo executar um alto volume de leituras e gravações, as configurações padrão podem levar a restrições de desempenho ou falhas de leitura/gravação. Para obter mais informações, consulte Diretrizes comuns para ambas as implementações de volumes de estágio.

    Para evitar esses problemas, verifique as métricas de CPU e memória para o contêiner (stage-mount-v2-sidecar-<stage-volume-name>). O Snowflake adiciona esse contêiner ao seu serviço que fornece a implementação do volume de área de preparação que você configurou. Isso permite que você veja exatamente quais recursos seu volume de área de preparação está usando e determine se ele está limitado por CPU ou memória. Use essas métricas para atualizar os limites de CPU e memória conforme necessário.

  • Campo stageConfig.metadataCache: se o seu aplicativo recupera metadados de arquivos com frequência ou lista arquivos em uma área de preparação do Snowflake em um loop, e você não espera que os dados mudem com frequência, é possível habilitar o cache de metadados para o volume de armazenamento da área de preparação do Snowflake para melhorar significativamente o desempenho. O cache armazena esses metadados por um período especificado, após o qual eles são limpos. Se o aplicativo tentar acessar os metadados, o Snowflake atualiza o cache. Use as unidades de horas, minutos e segundos para especificar o metadataCache. Por exemplo, 90s, 5m, 1h, 1h30m, 1h30m45s. Se não for especificado, não há cache.

    Nota

    Configure o cache de metadados somente quando os dados em sua área de preparação do Snowflake não mudarem durante a vida útil do serviço. Por exemplo, um serviço que tem cargas de trabalho somente leitura que precisam operar em um conjunto estático de dados na área de preparação. Não configure o cache de metadados para cargas de trabalho em que os dados na sua área de preparação do Snowflake são atualizados enquanto o serviço está em execução.

O campo spec.volumes a seguir define um volume de área de preparação do Snowflake. O campo inclui os campos opcionais stageConfig:

spec:
  containers:
    ..
  volumes:
  - name: <name>
    source: stage
    stageConfig:
      name: <stage_name>
      metadataCache: 1h
      resources:
        requests:
          cpu: 0.35
          memory: 0.4Gi
        limits:
          cpu: 2.0
          memory: 1Gi
Copy

Etapa 2: Especificar onde montar o volume de área de preparação no contêiner

Depois de definir um volume de armazenamento de área de preparação do Snowflake adicionando o campo spec.volumes, use o campo spec.containers.volumeMounts para descrever onde montar o volume de área de preparação nos contêineres do seu aplicativo, conforme mostrado no exemplo a seguir:

spec:
  containers:
  - name: ...
    image: ...
    volumeMounts:
    - name: <name>
      mountPath: <absolute_directory_path>
Copy

As informações fornecidas neste campo são consistentes em todos os tipos de volume de armazenamento com suporte e se aplicam a ambas as implementações dos volumes de estágio.

Exemplo

  • Crie um serviço com uma área de preparação mydb.myschema.ai_models_stage montada em /path/to/stage no contêiner principal.

    CREATE SERVICE my_service
IN COMPUTE POOL tutorial_compute_pool
FROM SPECIFICATION $$
spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    volumeMounts:
    - name: stage-vol
      mountPath: /path/to/stage
  volumes:
  - name: stage-vol
    source: stage
    stageConfig:
      name: "@mydb.myschema.ai_models_stage"
$$;
    Copy

  • Crie um serviço com o subcaminho da área de preparação mydb.myschema.ai_models_stage/subpath montado em /path/to/stage no contêiner principal.

    CREATE SERVICE my_service
IN COMPUTE POOL tutorial_compute_pool
FROM SPECIFICATION $$
spec:
  containers:
  - name: echo
    image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
    volumeMounts:
    - name: stage-vol
      mountPath: /path/to/stage
  volumes:
  - name: stage-vol
    source: stage
    stageConfig:
      name: "@mydb.myschema.ai_models_stage/subpath"
      metadataCache: 1h
      resources:
        requests:
          cpu: 0.35
          memery: 0.4Gi
        limits:
          cpu 2.0
          memory: 1Gi
$$;
    Copy

Requisitos de controle de acesso

A função de proprietário do serviço é a função usada para criar o serviço. É também a função que os serviços usam ao interagir com o Snowflake. Esta função de proprietário determina as permissões concedidas aos contêineres de aplicativo para acessar um estágio montado. O função de proprietário deve ter privilégio READ no estágio.

Se a função de proprietário não tiver o privilégio WRITE em um estágio, a montagem para esse estágio será somente leitura. Ou seja, os containers só podem ler os arquivos do estágio. A função de proprietário precisa do privilégio WRITE em um estágio para que a montagem do estágio ofereça suporte à leitura e gravação.

Sobre a implementação obsoleta

A implementação obsoleta de volume de área de preparação usa um cache compartilhado para leituras e gravações. Embora isso funcione bem para alguns cenários, você não pode controlar se os dados são lidos a partir do cache ou diretamente do estágio, o que pode não ser adequado para todos os aplicativos. Além disso, ao usar o cache para leituras e gravações, você pode introduzir sobrecarga de desempenho.

Migração de código da implementação obsoleta

A implementação mais recente substitui a implementação obsoleta, com as seguintes alterações de comportamento:

  • A implementação mais recente de volume de área de preparação transmite o conteúdo dos arquivos diretamente para e do armazenamento em nuvem, garantindo que você sempre obtenha o conteúdo mais recente. Isso proporciona um comportamento previsível e uma taxa de transferência significativamente mais rápida. A implementação obsoleta de volume de área de preparação armazena em cache partes dos dados do arquivo, o que dificulta saber se você está lendo os dados mais recentes.

  • O desempenho de leitura aleatória pode ser menor com a nova implementação devido à remoção do cache. Entretanto, sem um cache de disco local, a consistência entre os volumes é melhorada. As alterações de arquivo são gravadas diretamente no estágio de suporte quando o arquivo é fechado, sem buffer de disco local.

  • As leituras sempre retornam os dados mais recentes, tornando essa configuração melhor para o compartilhamento de dados entre serviços.

  • Gravações aleatórias ou anexos de arquivos não são compatíveis. A tentativa dessas operações gera erro. A Snowflake recomenda que você use volumes de armazenamento em bloco para essas cargas de trabalho.

Especificar um volume de área de preparação do Snowflake em uma especificação de serviço (obsoleto)

Para criar um serviço em que os contêineres de serviço usem o volume de área de preparação do Snowflake, especifique as configurações necessárias na especificação do serviço, conforme mostrado nas etapas a seguir:

  1. Para especificar o volume de área de preparação, use o campo spec.volumes, conforme mostrado no exemplo a seguir:

    volumes:
- name: <name>
  source: <stage_name>
    Copy

    Os seguintes campos são obrigatórios:

    • name: o nome do volume.

    • source: a área de preparação interna do Snowflake ou a pasta na área de preparação a ser montada; por exemplo @my_stage, @my_stage/folder. Este valor deve estar entre aspas duplas.

  2. Para descrever onde montar o volume de área de preparação nos contêineres do seu aplicativo, use o campo spec.containers.volumeMounts, conforme mostrado no exemplo a seguir:

    volumeMounts:
- name: <name>
  mountPath: <absolute_directory_path>
    Copy

    As informações fornecidas neste campo são consistentes em todos os tipos de volume de armazenamento com suporte e se aplicam a ambas as implementações dos volumes de estágio.

Exemplo (obsoleto)

No exemplo de especificação de serviço, o contêiner do app monta uma área de preparação interna @model_stage usando as implementações de volume de área de preparação obsoletas:

spec:
  containers:
  - name: app
    image: <image1-name>
    volumeMounts:
    - name: models-legacy
      mountPath: /opt/model-legacy
  volumes:
  - name: models-legacy
    source: "@model_stage"
Copy

O campo volumeMounts especifica onde montar o volume do estágio dentro do contêiner. Essa especificação permanece a mesma para ambas as implementações de volume de área de preparação.

Diretrizes ao usar volumes de estágio

Esta seção fornece diretrizes a serem seguidas ao implementar código de aplicativo no qual um contêiner usa uma área de preparação do Snowflake como volume de armazenamento.

Diretrizes comuns para ambas as implementações de volumes de estágio

  • A montagem em estágio é otimizada para leituras e gravações sequenciais.

  • As operações de E/S de montagem em estágio podem ter latências maiores do que as operações de E/S no sistema de arquivo do contêiner e nos volumes de armazenamento em bloco. Você deve sempre verificar o código de status das operações de E/S para garantir que elas foram bem-sucedidas.

  • As montagens de estágio carregam atualizações de arquivo de forma assíncrona. As alterações em arquivos em uma montagem de estágio só são garantidas como persistentes no estágio após o descritor de arquivo ser fechado ou esvaziado com sucesso. Pode haver algum atraso antes que as alterações nos arquivos em uma montagem de estágio se tornem visíveis para outros contêineres e para o Snowflake.

  • Cada diretório em um estágio montado deve conter menos de 100 mil arquivos. Espere que a latência readdir aumente com o número de arquivos no diretório.

Diretrizes ao usar a versão obsoleta da implementação de volume de área de preparação

  • Evite gravar simultaneamente em vários arquivos dentro de uma montagem de estágio.

  • A montagem de estágio não é um sistema de arquivos de rede. Não utilize montagens de estágio para coordenação de vários clientes.

  • Não abra vários identificadores para o mesmo arquivo simultaneamente. Use identificadores de arquivo abertos para operações de leitura ou gravação, mas não uma mistura de ambas. Para ler um arquivo após gravar nele, feche o arquivo e abra-o novamente antes de ler.

Diretrizes ao usar a implementação de volume de área de preparação geralmente disponível

  • Gravações simultâneas no mesmo arquivo de várias montagens de estágio (mesmo volume de estágio montado em contêineres diferentes) não são recomendadas.

  • A ausência de um cache de disco local melhora a consistência entre as montagens. As alterações no arquivo são liberadas diretamente para o estágio de suporte ao fechar o arquivo, sem buffer de disco local. As leituras sempre retornam os dados mais recentes, tornando a nova montagem de estágio melhor para compartilhar dados entre serviços.

  • Leia e grave dados em partes grandes e contíguas visando um desempenho ideal. A cobrança de desempenho para leituras e gravações pequenas quando comparado à implementação de volume de estágio geralmente disponível pode mitigar os ganhos de desempenho da nova implementação.

Limitações ao usar volumes de estágio

Esta seção descreve as limitações que você deve conhecer ao implementar código de aplicativo em que os contêineres usam volumes de estágio. Se você tiver algum problema com esses limites, entre em contato com seu representante de conta.

Limitações comuns para ambas as implementações de volumes de estágio

  • É permitido montar apenas um estágio ou um subdiretório em um estágio; por exemplo, @my_stage, @my_stage/folder. Não é possível montar um único arquivo em um estágio, por exemplo, @my_stage/folder/file.

  • Áreas de preparação externa não são suportadas. Somente os estágios internos do Snowflake são compatíveis.

  • As montagens de estágio não são sistemas de arquivo totalmente compatíveis com POSIX. Por exemplo:

    • As renomeações de arquivo e diretório não são atômicas.

    • Links físicos não são permitidos.

  • O subsistema inode notify (inotify) do kernel Linux que monitora alterações nos sistemas de arquivos não funciona em montagens de estágio.

Limitações ao usar a versão obsoleta da implementação de volume de área de preparação

  • Um máximo de 5 volumes de estágio é permitido por serviço. Para obter mais informações, consulte spec.volumes.

  • Há suporte para um máximo de 8 volumes em estágio por nó do pool de computação. O Snowflake gerencia o limite de montagem de estágio por nó de forma semelhante à forma como gerencia a memória, CPU e GPU. Iniciar uma nova instância de serviço pode fazer com que o Snowflake inicie novos nós quando nenhum nó existente tiver capacidade para oferecer suporte às montagens de estágio solicitadas.

  • As capacidades de volume do estágio variam de acordo com a plataforma de nuvem de sua conta Snowflake:

    • Contas na AWS oferecem suporte a áreas de preparação interna com criptografia de estágio SNOWFLAKE_FULL e SNOWFLAKE_SSE. Para obter mais informações, consulte Parâmetros de área de preparação interna.

    • Atualmente, as contas no Azure oferecem suporte a áreas de preparação interna com criptografia SNOWFLAKE_SSE. Ao executar CREATE STAGE, use o parâmetro ENCRYPTION para especificar o tipo de criptografia: CREATE STAGE my_stage ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');

    • Contas no Google Cloud não têm suporte.

  • Gravações simultâneas no mesmo arquivo de várias montagens de estágio (mesmo volume de estágio montado em contêineres diferentes) não são compatíveis.

Limitações ao usar a versão geralmente disponível da implementação do volume do estágio

  • Gravações aleatórias e anexos de arquivo não são compatíveis.

  • Cada estágio montado requer 512 MB de memória por estágio. Isso significa que há uma limitação no número de volumes de estágio que podem ser usados com base no tamanho da instância. Montar o volume em vários contêineres não aumenta o consumo de memória.

  • São permitidos no máximo 20 volumes de área de preparação por serviço. Para obter mais informações, consulte spec.volumes.