Melhores práticas

Use o seguinte conjunto de diretrizes recomendadas ao provisionar e gerenciar suas instâncias sem servidor e ao executar aplicativos Spark.

Práticas recomendadas ao usar instâncias sem servidor, incluindo descrições detalhadas e links de referência
Melhores práticas Descrição Link de referência
Use instâncias de serviço IBM Analytics Engine separadas para seus ambientes de desenvolvimento e produção. Esta é uma melhor prática geral. Criando instâncias separadas do IBM Analytics Engine para diferentes ambientes, é possível testar qualquer configuração e mudanças de código antes de aplicá-las na instância de produção. N/D
Atualize para a versão mais recente do Spark Conforme as versões do Spark de software livre são liberadas, elas são disponibilizadas no IBM Analytics Engine após um intervalo de tempo necessário para teste interno. Observe o anúncio de novas versões do Spark na seção Notas sobre a liberação e faça upgrade do tempo de execução de sua instância para mover seus aplicativos para o tempo de execução mais recente do Spark. Tempos de execução mais antigos são descontinuados e, eventualmente, removidos conforme versões mais novas são liberadas. Assegure-se de testar seus aplicativos no novo tempo de execução antes de fazer mudanças nas instâncias de produção.
Conceder acesso baseado em função É necessário conceder acesso baseado em função a todos os usuários nas instâncias do IBM Analytics Engine com base em seus requisitos. Por exemplo, somente sua equipe de automação deve ter permissões para enviar aplicativos porque ela tem acesso a segredos e sua equipe do DevOps deve ser capaz de ver apenas a lista de todos os aplicativos e seus estados.
Escolha a configuração certa do IBM Cloud Object Storage
  • Resiliência de recuperação de desastres (DR): Você deve usar a opção de IBM Cloud Object Storage A opção de resiliência Cross Regional que faz o backup de seus dados em várias cidades diferentes em uma região. Em contraste, a opção de resiliência Regional faz backup de dados em um único data center.
  • Criptografia: IBM Cloud Object Storage vem com a criptografia integrada padrão. Também é possível configurar o Object Storage para trabalhar com o serviço BYOK Key Protect.
  • Credenciais de serviço: por padrão, o IBM Cloud Object Storage usa credenciais de estilo do IAM. Se você desejar trabalhar com credenciais de estilo AWS, será necessário usar a opção "Incluir credencial HMAC" conforme descrito em Credenciais de serviço.
  • Terminais diretos para IBM Cloud Object Storage: sempre use terminais diretos para conectividade com a instância do IBM Cloud Object Storage Isso se aplica à instância inicial do IBM Cloud Object Storage bem como aos terminais usados de seus aplicativos (seu código ou o que você transmite como parâmetros nas configurações no nível da instância ou no nível do aplicativo). Os endpoints diretos oferecem melhor desempenho do que os endpoints públicos e não incorrem em cobranças por nenhuma largura de banda de entrada ou saída.
Use terminais privados para o metastore Hive externo Se você estiver usando o Spark SQL e desejar usar um metastore externo, como usar o IBM Cloud Databases for PostgreSQL como seu metastore Hive, deverá usar o terminal privado para a conexão com o banco de dados para obter melhor desempenho e economia de custo.
Executando aplicativos com superconfirmação de recurso Há uma cota associada a cada instância do Analytics Engine Serverless Quando os aplicativos são enviados em uma instância, eles recebem recursos da cota da instância. Se um aplicativo solicitar recursos além da cota disponível, o aplicativo não será iniciado ou será executado com menos dos recursos solicitados, o que pode resultar na execução do aplicativo mais lenta do que o esperado ou, em alguns casos, na falha do aplicativo. Você deve sempre monitorar o consumo de recursos atual em uma instância para assegurar que seus aplicativos estejam sendo executados confortavelmente dentro dos limites fornecidos É possível ajustar os limites por meio de um chamado de suporte se necessário.
Alocação estática de recursos versus ajuste automático de escala Ao enviar aplicativos, é possível especificar o número de executores antecipadamente (alocação estática) ou usar a opção de ajuste automático de escala (alocação dinâmica). Antes de decidir se deve usar a alocação estática ou o ajuste automático de escala, você pode desejar executar alguns testes de benchmarking variando diferentes conjuntos de dados com a configuração estática e automática para localizar a configuração correta. Considerações gerais:
-Se você souber o número de recursos (núcleos e memória) necessários para o seu aplicativo e ele não variar em diferentes estágios da execução do aplicativo, recomenda-se alocar recursos estáticos para um melhor desempenho.
-Se desejar obter uma utilização de recurso otimizada, será possível optar pelo ajuste automático de escala de executores em que os executores são alocados com base na demanda real do aplicativo. Observe que pode haver um ligeiro atraso associado ao usar o ajuste automático de escala em aplicativos
Ativar e ajustar a criação de log de encaminhamento -Ative a criação de log de encaminhamento para sua instância de serviço para ajudar a solucionar problemas, mostrar progresso e imprimir ou mostrar saídas de seus aplicativos. Observe que o encaminhamento de log incorre em um custo baseado na quantidade de logs encaminhados ou retidos na instância do IBM Log Analysis. Com base em seu caso de uso e necessidade, você precisa decidir as configurações ideais.
-Ao ativar o encaminhamento de log usando a API padrão, apenas os logs do driver são ativados Se você precisar de logs do executor também, por exemplo, se houver erros que você veria apenas nos executores, será necessário customizar a criação de log para ativar a criação de log do executor também Os logs do executor podem se tornar muito grandes, portanto, equilibre as opções para otimizar a quantia de logs que são encaminhados para sua instância de criação de log versus as informações que você obtém nos logs para propósitos de resolução de problemas.
-Siga as melhores práticas de IBM Log Analysis ao escolher as técnicas corretas de configuração e de procura Por exemplo, talvez você queira configurar o plano da instância IBM Log Analysis para uma procura de 7 dias com o arquivamento de logs para IBM Cloud Object Storage para economizar custos. Consulte também a documentação do IBM Log Analysis para obter técnicas de procura de logs de seu interesse com base em palavras-chave, ponto no tempo e assim por diante.
Customize sua instância de serviço -Pode ser necessário customizar sua instância de serviço para trazer pacotes Python ou conda que não são pré-instalados ou trazer alguns arquivos (certificados ou arquivos de configuração) que devem ser disponibilizados para aplicativos Spark. Com base em suas necessidades, customize sua instância usando conjuntos de bibliotecas e use esses conjuntos de bibliotecas ao enviar aplicativos.
-O tamanho de seu conjunto de bibliotecas tem um impacto no tempo de inicialização do aplicativo e no tempo de inicialização do executor (quando você escalar aplicativos automaticamente). Observe também que há um limite superior para o tamanho de um conjunto de bibliotecas, ou seja, 2 GB. Portanto, se diferentes aplicativos precisarem de diferentes conjuntos de bibliotecas, é melhor usar conjuntos de bibliotecas separados, para que eles possam ser especificados individualmente no momento em que o aplicativo for enviado.
-Use a customização apenas para trazer arquivos que não podem ser trazidos pelos parâmetros de detalhes do aplicativo.. Consulte Parâmetros para enviar aplicativos Spark. Deve-se usar as opções de parâmetro equivalentes de spark-submit padrão, como as opções files, jars, packages e pyFiles, se isso se ajustar ao seu caso de uso Somente se você precisar de arquivos que não se encaixam em nenhuma dessas categorias, por exemplo, um certificado autoassinado, um arquivo de configuração JAAS ou um arquivo .so, deverá usar a opção "customização para download de arquivo"..
Aplicar filtros ao recuperar lista de aplicativos Quando for necessário recuperar a lista de aplicativos na UI ou usando a API ou CLI, é melhor aplicar os filtros apropriados e recuperar o conjunto necessário.
Use outros serviços ou ferramentas para suportar funções Além de usar uma instância do IBM Log Analysis e IBM Cloud Object Storage e dependendo de seu caso de uso, você pode desejar usar outras ferramentas e serviços de suporte. Por exemplo, é possível usar o Apache Airflow (gerenciado por você) para orquestrar, planejar e automatizar seus aplicativos. Também é possível usar o IBM Secrets Manager para armazenar os segredos necessários para seus aplicativos e usar seus scripts de automação para ler os segredos do Secrets Manager antes de enviar seus aplicativos. Também é possível ser criativo com seus argumentos de aplicativo, transmitindo um token necessário para ler os segredos necessários do Secrets Manager diretamente de dentro de seu aplicativo.
Use instâncias em regiões alternativas para backup e recuperação de desastre Atualmente, IBM Analytics Engine As instâncias sem servidor podem ser criadas em duas regiões, ou seja, Dallas (us-south) e Frankfurt (eu-de). Embora seja aconselhável criar suas instâncias na mesma região em que seus dados estão localizados, é sempre útil criar uma instância de backup em uma região alternativa com o mesmo conjunto de configurações que sua instância primária, caso a instância primária se torne indisponível ou inutilizável. Suas automações devem permitir alternar envios de aplicativos entre as duas regiões, se necessário. N/D
Use depósitos separados e credenciais de serviço para arquivos de aplicativo, arquivos de dados e instância inicial Use o princípio de "separação de preocupações" para distinguir o acesso entre diferentes recursos.
-Não armazene dados ou arquivos de aplicativos no depósito de instância inicial.
-Use depósitos separados para dados e arquivos de aplicativos.
-Use credenciais de acesso separadas (baseadas em chave do IAM) com acesso restrito ao depósito para arquivos de aplicativo e o depósito que contém seus dados.
Os aplicativos devem ser executados dentro de 72 horas Há um limite no número de horas que um aplicativo ou kernel pode executar. Para correção de segurança e conformidade, todos os tempos de execução que são executados por mais de 72 horas são interrompidos. Se você tiver um aplicativo grande, divida seu aplicativo em partes menores que serão executadas em 72 horas. Se você estiver executando aplicativos de fluxo do Spark, certifique-se de configurar pontos de verificação e ter o monitoramento no local para reiniciar seus aplicativos se eles forem interrompidos
Iniciar e Parar Histórico do Spark somente quando necessário Sempre pare o servidor de históricos do Spark quando você não precisar mais usá-lo, Tenha em mente que o servidor de históricos do Spark consome recursos de CPU e memória continuamente enquanto seu estado é iniciado.