Partilhar via

Arquitetura de extensibilidade nos Serviços de Aprendizagem Automática do SQL Server

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores

Este artigo descreve a arquitetura do framework de extensibilidade para executar um script externo em Python ou R em SQL Server Machine Learning Services. O script é executado num ambiente de execução de linguagem como uma extensão do motor principal da base de dados.

Contexto geral

A estrutura de extensibilidade foi introduzida no SQL Server 2016 para suportar o runtime R com Serviços R. SQL Server 2017 e posteriores têm suporte para Python com Serviços de Aprendizagem Automática.

O objetivo do framework de extensibilidade é fornecer uma interface entre SQL Server e linguagens de ciência de dados como R e Python. O objetivo é reduzir o atrito ao transferir soluções de ciência de dados para produção e proteger os dados expostos durante o processo de desenvolvimento. Ao executar uma linguagem de scripting de confiança dentro de uma framework segura gerida pelo SQL Server, os administradores de bases de dados podem manter a segurança enquanto permitem aos cientistas de dados o acesso a dados empresariais.

O diagrama seguinte descreve visualmente as oportunidades e benefícios da arquitetura extensível.

Objetivos da integração com o SQL Server

Um script externo pode ser executado chamando um procedimento armazenado, e os resultados são devolvidos como resultados tabulares diretamente para o SQL Server. Isto facilita a geração ou consumo de aprendizagem automática a partir de qualquer aplicação que possa enviar uma consulta SQL e tratar dos resultados.

  • A execução de scripts externos está sujeita à segurança dos dados do SQL Server. Um utilizador que executa um script externo só pode aceder a dados igualmente disponíveis numa consulta SQL. Se uma consulta falhar devido a permissão insuficiente, um script executado pelo mesmo utilizador também falharia pelo mesmo motivo. A segurança do SQL Server é aplicada ao nível da tabela, base de dados e instância. Os administradores de bases de dados podem gerir o acesso dos utilizadores, recursos usados por scripts externos e bibliotecas de código externas adicionadas ao servidor.

  • As oportunidades de escala e otimização têm uma dupla base: ganhos através da plataforma de base de dados (índices ColumnStore, governação de recursos); e ganhos específicos de extensão, por exemplo quando as bibliotecas Microsoft para R e Python são usadas para modelos de ciência de dados. Enquanto o R é monothread, as funções RevoScaleR são multithread, sendo capazes de distribuir uma carga de trabalho por múltiplos núcleos.

  • A implementação utiliza metodologias SQL Server. Estes podem ser procedimentos armazenados que envolvem um script externo, SQL embutido ou consultas T-SQL que chamam funções como PREDICT para devolver resultados de modelos de previsão persistidos no servidor.

  • Desenvolvedores com competências estabelecidas em ferramentas e IDEs específicos podem escrever código nessas ferramentas e depois portar o código para SQL Server.

Diagrama da arquitetura

A arquitetura foi concebida de forma a que scripts externos corram num processo separado do SQL Server, mas com componentes que gerem internamente a cadeia de pedidos de dados e operações no SQL Server. Dependendo da versão do SQL Server, extensões de linguagem suportadas incluem R, Python e linguagens de terceiros como Java e .NET.

Arquitetura de componentes no Windows:

Arquitetura de componentes do Windows

Arquitetura de componentes no Linux:

Arquitetura de componentes Linux

Os componentes incluem um serviço launchpad usado para invocar runtimes externos e lógica específica de biblioteca para carregamento de interpretadores e bibliotecas. O lançador carrega um ambiente de execução de linguagem, além de quaisquer módulos proprietários. Por exemplo, se o seu código incluir funções RevoScaleR, um interpretador RevoScaleR é carregado. O BxlServer e o SQL Satellite gerem a comunicação e a transferência de dados com SQL Server.

No Linux, o SQL utiliza um serviço launchpadd para comunicar com um processo de launchpad separado para cada utilizador.

Barra de Lançamento

O SQL Server Launchpad é um serviço que gere e executa scripts externos, de forma semelhante à forma como o serviço de indexação e consulta em texto completo lança um host separado para processar consultas em texto completo. O serviço launchpad só pode iniciar lançadores confiáveis que sejam publicados pela Microsoft ou que tenham sido certificados pela Microsoft como cumprindo os requisitos de desempenho e gestão de recursos.

Lançadores de confiança Extension Versões do SQL Server
RLauncher.dll para a linguagem R para Windows Extensão R SQL Server 2016 e posteriores
Pythonlauncher.dll para linguagem Python para Windows Extensão Python SQL Server 2017 e posteriores
RLauncher.so para a linguagem R para Linux Extensão R SQL Server 2019 e posterior
Pythonlauncher.so para linguagem Python para Linux Extensão Python SQL Server 2019 e posterior

O serviço SQL Server Launchpad corre sob a sua própria conta de utilizador. Se alterar a conta que executa o Launchpad, certifique-se de o fazer usando o SQL Server Configuration Manager, para garantir que as alterações são escritas em ficheiros relacionados.

No Windows, é criado um serviço Launchpad separado do SQL Server para cada instância do motor de base de dados à qual adicionou os Serviços de Aprendizagem Automática do SQL Server. Existe um serviço de launchpad para cada instância do motor de base de dados, por isso, se tiveres múltiplas instâncias com suporte a scripts externos, terás um serviço de launchpad para cada uma. Uma instância do motor de base de dados está ligada ao serviço launchpad criado para ela. Todas as invocações de scripts externos num procedimento armazenado ou T-SQL resultam no serviço SQL Server chamar o serviço launchpad criado para a mesma instância.

Para executar tarefas numa linguagem suportada específica, o launchpad obtém uma conta de trabalhador segura do pool e inicia um processo satélite para gerir o tempo de execução externo. Cada processo satélite herda a conta de utilizador da base de lançamento e utiliza essa conta de trabalho durante toda a execução do script. Se o script usar processos paralelos, eles são criados sob a mesma conta de trabalhador único.

No Linux, apenas uma instância do motor de base de dados é suportada e existe um serviço launchpadd associado à instância. Quando um script é executado, o serviço launchpadd inicia um processo separado no launchpad com a conta de utilizador de baixo privilégio mssql_satellite. Cada processo satélite herda a conta de utilizador mssql_satellite do launchpad e utiliza essa conta durante a execução do script.

BxlServer e SQL Satellite

BxlServer é um executável fornecido pela Microsoft que gere a comunicação entre o SQL Server e o runtime da linguagem. Cria os objetos de trabalho Windows para Windows, ou os namespaces para Linux, que são usados para conter sessões de script externas. Também prevê pastas de trabalho seguras para cada trabalho de script externo e utiliza SQL Satellite para gerir a transferência de dados entre o runtime externo e o SQL Server. Se executares o Process Explorer enquanto um trabalho está a correr, podes ver uma ou várias instâncias do BxlServer.

Na prática, o BxlServer é um complemento a um ambiente de execução de linguagem que funciona com SQL Server para transferir dados e gerir tarefas. BXL significa linguagem Binary Exchange e refere-se ao formato de dados utilizado para mover dados de forma eficiente entre SQL Server e processos externos.

SQL Satellite é uma API de extensibilidade, incluída no motor de base de dados, que suporta código externo ou runtimes externos implementados usando C ou C++.

O BxlServer utiliza SQL Satellite para estas tarefas:

  • Leitura de dados de entrada
  • Escrita de dados de saída
  • Obtenção de argumentos de entrada
  • Definição de argumentos de saída
  • Tratamento de erros
  • Escrever STDOUT e STDERR de volta ao cliente

O SQL Satellite utiliza um formato de dados personalizado otimizado para transferência rápida de dados entre SQL Server e linguagens de script externas. Realiza conversões de tipos e define os esquemas dos conjuntos de dados de entrada e saída durante as comunicações entre o SQL Server e o tempo de execução do script externo.

O SQL Satellite pode ser monitorizado através de eventos estendidos do Windows (XEvents). Para mais informações, consulte Eventos Estendidos para Serviços de Aprendizagem Automática SQL Server.

Canais de comunicação entre componentes

Os protocolos de comunicação entre componentes e plataformas de dados são descritos nesta seção.

  • TCP/IP

    Por defeito, as comunicações internas entre o SQL Server e o SQL Satellite utilizam TCP/IP.

  • Pipes Nomeados

    O transporte interno de dados entre o BxlServer e o SQL Server através do SQL Satellite utiliza um formato de dados comprimido proprietário para melhorar o desempenho. Os dados são trocados entre os tempos de execução da linguagem e o BxlServer em formato BXL, usando Named Pipes.

  • ODBC

    As comunicações entre clientes externos de ciência de dados e uma instância remota de SQL Server utilizam ODBC. A conta que envia os trabalhos de script para o SQL Server deve ter permissões para se conectar à instância e executar scripts externos.

    Além disso, dependendo da tarefa, a conta pode precisar destas permissões:

    • Ler dados usados pelo trabalho
    • Gravar dados em tabelas: por exemplo, ao salvar resultados em uma tabela
    • Criar objetos de base de dados: por exemplo, se guardar um script externo como parte de um novo procedimento armazenado.

    Quando o SQL Server é usado como o contexto de computação para script executado a partir de um cliente remoto e o executável deve recuperar dados de uma fonte externa, o ODBC é usado para write-back. O SQL Server mapeia a identidade do usuário que emite o comando remoto para a identidade do usuário na instância atual e executa o comando ODBC usando as credenciais desse usuário. A cadeia de conexão necessária para executar essa chamada ODBC é obtida do código do cliente.

  • RODBC (apenas R)

    Chamadas ODBC adicionais podem ser feitas dentro do script usando RODBC. O RODBC é um pacote R popular usado para aceder a dados em bases de dados relacionais; no entanto, o seu desempenho é geralmente mais lento do que o de fornecedores comparáveis usados pelo SQL Server. Muitos scripts R utilizam chamadas embutidas para RODBC como forma de recuperar conjuntos de dados "secundários" para análise de dados. Por exemplo, o procedimento armazenado que treina um modelo pode definir uma consulta SQL para obter os dados para treinar um modelo, mas usar uma chamada RODBC embutida para obter fatores adicionais, para realizar pesquisas ou para obter novos dados de fontes externas, como ficheiros de texto ou Excel.

    O código seguinte ilustra uma chamada RODBC embutida num script R:

    library(RODBC);
connStr <- paste("Driver=SQL Server;Server=", instance_name, ";Database=", database_name, ";Trusted_Connection=true;", sep="");
dbhandle <- odbcDriverConnect(connStr)
OutputDataSet <- sqlQuery(dbhandle, "select * from table_name");

  • Outros protocolos

    Os processos que podem precisar trabalhar em "partes" ou transferir dados de volta para um cliente remoto também podem usar o formato de arquivo XDF. A transferência de dados real é feita através de blobs codificados.

Ver também

  • Last updated on