Apache Kyuubi [1] é um gateway SQL multilocatário distribuído, cuja principal função é aceitar SQL enviado pelos usuários por meio de protocolos como JDBC/REST e encaminhá-lo para o mecanismo SQL gerenciado por ele para execução de acordo com o isolamento multilocatário política. Na versão mais recente do Kyuubi 1.8, o Kyuubi Flink Engine migra para a API Flink SQL Gateway (doravante denominada FSG) e suporta o modo Flink Application, que nos permite implantar rapidamente um gateway Flink SQL distribuído disponível para produção com Kyuubi.
Por que você precisa da Kyuubi
Acredito que a primeira pergunta que muitos leitores vão pensar é que o Flink já fornece SQL Gateway, por que precisamos apresentar o Kyuubi? Na verdade, a resposta chave está na descrição da Kyuubi: um é distribuído e o outro é multilocatário, os dois se complementam. A capacidade de carga do gateway precisa ser expandida horizontalmente, por isso evoluirá naturalmente para distribuída; em um ambiente distribuído, a afinidade das sessões precisa ser garantida, então surge naturalmente a necessidade de roteamento multilocatário; e os multilocatários têm requisitos mais elevados para isolamento, então inversamente Também promoverá o desenvolvimento da arquitetura distribuída.
A combinação do SQL Gateway e do SQL Client pode ser usada imediatamente e nos ajuda a executar rapidamente a demonstração. No entanto, em um ambiente de produção empresarial, uma única instância geralmente é difícil de atender às solicitações dos usuários. Além disso, diferentes usuários corporativos muitas vezes temos diferentes versões do Flink, dependências integradas e configurações de recursos sob demanda, o que resultou na necessidade de manter várias instâncias do SQL Gateway. O que é ainda mais problemático é que uma instância pode ser compartilhada entre vários usuários pequenos ou pode ser exclusiva de um usuário grande.Existe um relacionamento de mapeamento muitos para muitos entre usuários e instâncias do SQL Gateway. Além disso, a alta disponibilidade e o balanceamento de carga também são problemas difíceis que precisam ser enfrentados. Vários problemas causaram altos custos de gerenciamento de operação e manutenção do SQL Gateway, e o surgimento da Kyuubi resolveu esse problema em grande medida.
Noções básicas de Kyuubi
Kyuubi possui principalmente três módulos: Cliente, Servidor e Motor.
Figura 1. Arquitetura Kyuubi
- O Cliente Kyuubi é relativamente simples: possui um cliente que pode ser usado imediatamente ou você pode escolher ferramentas ou protocolos abertos como DBeaver ou JDBC/REST.
kyuubi-beeline - O Servidor Kyuubi é o módulo principal e suas principais responsabilidades são:
- Fornece Frontend incluindo vários protocolos para Cliente e aceita Conexão.
- Gerencie o ciclo de vida do mecanismo e encaminhe as solicitações do usuário para o mecanismo apropriado.
- Gerencie o status da sessão/operação.
- Kyuubi Engine é o módulo que carrega a carga de computação real. Ele é responsável por traduzir as solicitações do Servidor Kyuubi em operações nativas do motor e suporta vários mecanismos de computação, como Spark/Flink/Trino.
Muitos leitores podem ter descoberto que o posicionamento do FSG é semelhante ao Flink Engine da Kyuubi (na verdade, o Kyuubi Flink Engine tem um FSG incorporado), e a camada de abstração do Kyuubi Server é a chave para resolver problemas distribuídos e multi-tenant.
Na arquitetura Kyuubi, a comunicação entre Cliente e Servidor, Servidor e Motor envolve descoberta de serviço e balanceamento de carga, o que significa que diferentes módulos são fracamente acoplados. O cliente pode se conectar a qualquer servidor Kyuubi no mesmo namespace, e o servidor Kyuubi também pode acessar qualquer mecanismo no mesmo namespace. Para conexões curtas com estado no cenário Batch, a Kyuubi persistirá o status relevante no banco de dados e garantirá que a conexão sempre possa cair para o mesmo servidor através do encaminhamento entre servidores. Este design oferece à Kyuubi excelentes capacidades de expansão horizontal.
Figura 2. Roteamento de sessão Kyuubi
Conforme mencionado acima, o roteamento de solicitações multilocatários é a função principal do Servidor Kyuubi. O Servidor Kyuubi fornece diferentes níveis de Nível de Compartilhamento de Motor para atender às necessidades de isolamento de multi-inquilinos e seleciona o Motor correspondente à solicitação com base no Nível de Compartilhamento de Motor.
| Nível de compartilhamento | descrever | Compartilhamento | Isolamento | Adequado para a cena |
|---|---|---|---|---|
| CONEXÃO | Cada conexão possui um Engine exclusivo | mais baixo | Altíssima | Consulta ETL ou Ad-hoc de grande volume de dados ou trabalho em tempo real |
| DO UTILIZADOR | Cada usuário possui um Engine exclusivo | médio | médio | Consulta ETL comum ou Ad-hoc ou trabalho em tempo real |
| GRUPO | Cada grupo de usuários compartilha um mecanismo | alto | Baixo | Consulta ETL comum ou Ad-hoc ou trabalho em tempo real |
| SERVIDOR | Todos os usuários compartilham um mecanismo | Altíssima | mais baixo | Operações do administrador |
Além disso, o ciclo de vida do Engine é controlado automaticamente pelo Server. Se não houver nenhum mecanismo adequado no momento, o servidor iniciará um mecanismo; e se um mecanismo estiver ocioso por mais de um determinado período de tempo, o mecanismo será desligado automaticamente para economizar recursos.
Benefícios adicionais
Além das vantagens básicas mencionadas acima, a Kyuubi também tem benefícios adicionais em comparação ao uso direto do FSG. Existem diferenças de curto prazo causadas por diferentes progressos de desenvolvimento, e também existem diferenças de longo prazo que podem existir devido a diferentes posicionamentos dos projectos.
Modo de implantação de aplicativo
Kyuubi suporta o modo Flink no YARN Application na versão 1.8 mais recente, e o modo Application do FSG ainda está em fase de discussão (ver FLIP-316 [2]). É importante notar que as duas implementações do padrão Application não são iguais no longo prazo.
Para entender a diferença por trás disso, primeiro revise brevemente os fundamentos do Flink SQL. Ao executarmos um Flink SQL, passaremos pelas seguintes etapas:
- Análise: O SQL enviado pelo usuário será primeiro analisado em um plano de execução lógica pelo Parser
- Otimização: O plano de execução lógica é otimizado pelo Planner Optimizer e um plano de execução física será gerado.
- Compilação: O plano de execução física é então usado para gerar código Java (DataStream Transformation) por meio do código Planner CodeGen para construir JobGraph
- Execução: Envie o JobGraph para o JobManager, que aplica o TaskManager para executar o trabalho
Para o modo Flink Session ou modo Per-Job, as três primeiras etapas são concluídas no TableEnvironment do Flink Client, e o JobGraph compilado pode ser serializado e contém todas as informações do trabalho, por isso é muito adequado para dividir o gateway SQL e o cluster Flink. . Em outras palavras, após o gateway concluir a análise, otimização e compilação de SQL, ele pode REST ou enviar o JobGraph para armazenamento distribuído, como HDFS/S3.
No entanto, o padrão Application apresenta novos desafios arquitetônicos. A construção do JobGraph no modo Application deve ser feita no lado do JobManager, o que significa que a compilação também precisa ser feita no lado do JobManager. Para tanto, precisamos serializar o plano de execução física gerado na etapa 2 e carregá-lo no JobManager, e esse objeto serializado é Json Plan [3].
O Json Plan foi introduzido no Flink 1.14. Ele é uma representação serializada do plano de execução física ExecNodeGraph do Flink. Ele foi originalmente projetado para atualizações de versões cruzadas do Flink SQL. Agora também é muito conveniente para comunicação entre FSG e JobManager pronto para uso. FLIP-316, proposta da FSG para suportar o modo Aplicativo, foi projetado com base no Plano Json.
Figura 3. Arquitetura do modo de aplicação FSG
No entanto, o Plano Json atualmente tem certas limitações. A maior limitação é que o Plano Json suporta apenas a instrução INSERT e a instrução STATEMENT SET no modo Streaming. Isso faz com que o modo Aplicativo seja temporariamente incapaz de suportar o modo Lote e SELECT, limitando os dados cenários de exploração.
Figura 4. Arquitetura do Modo Aplicativo Kyuubi
Em contraste, o modo Aplicativo do Kyuubi Flink Engine adota uma arquitetura semelhante ao modo Spark Cluster. A análise, otimização, compilação e execução de SQL são concluídas diretamente no TableEnvironment no lado do JobManager. As informações do trabalho não precisam ser transferidas entre processos, portanto, não é restrito pelo Plano Json. Através da Kyuubi, podemos usar o Flink para fazer exploração arbitrária de dados, assim como usamos o Spark.
Observabilidade
Em aplicações de nível empresarial, a observabilidade é, sem dúvida, um requisito básico importante. A Kyuubi fornece um rico conjunto de métricas e repórteres, bem como uma UI Web incorporada no servidor Kyuubi, permitindo-nos acompanhar a carga do gateway a qualquer momento.
Foto 5. UI da Web Kyuubi
Em termos de métricas, as Métricas Kyuubi podem ser divididas em várias categorias:
- Métrica de conexão: monitore o número de conexões em diferentes estados
- Métrica de Operação: Monitore o número de Operações em diferentes estados e sua duração de execução
- Métrica do pool de threads: monitore se o pool de threads do serviço do Servidor Kyuubi é suficiente
- Métrica do mecanismo: monitore o número de motores em diferentes estados de diferentes usuários
- Métrica de chamada RPC: monitore a frequência e o tempo de diferentes chamadas RPC entre o servidor Kyuubi e o mecanismo
Em termos de relatório, a Kyuubi fornece o Prometheus Reporter e o JMX Reporter mais populares. Se precisar de métricas baseadas em log, você também pode escolher SLF4J Reporter, JSON Reporter ou Console Reporter.
perspectiva futura
Do suporte específico do Spark ao suporte multi-motor, a Kyuubi está avançando passo a passo em direção ao objetivo de "uma solução padrão para SQL Gateway". Em termos de suporte ao Flink Engine, a Kyuubi se concentrará ainda mais em complementar os K8s e os recursos de autenticação de camuflagem no futuro para melhorar a experiência dos usuários ao usar o Flink SQL em diferentes ambientes.
Às 14h do dia 28 de outubro, o NetEase Hangzhou Research Institute e o NetEase Shufan realizarão o salão de tecnologia "Shu Ka Talk · Five Committers Chat sobre o novo futuro de Hucang" no NetEase Hangzhou Park, convidando empresas líderes na área de tecnologia de dados Databricks e NetEase Shufan . Especialistas práticos da Fan e Ctrip auxiliados, incluindo o especialista em tecnologia de big data da NetEase Shufan, presidente do PMC Apache Kyuubi / Committer do Apache Spark Yao Qin, diretor técnico do grupo de código aberto Databricks, membro do Apache Spark PMC Fan Wenchen, tecnologia de big data da NetEase Shufan especialista, Apache Spark Committer You Xiduo, chefe da plataforma de computação offline da Ctrip, membro do Apache Kyuubi PMC Chen Shaoyun, especialista em tecnologia de big data da NetEase, Apache Kudu Committer He Lifu, etc., um total de 5 projetos estrela Apache PMC/Committer reunidos para fale sobre Spark , novos desenvolvimentos, novas práticas e novos valores em tecnologias populares de armazenamento em lagos, como . Saiba mais: Shuka disse | Os 5 principais committers Apache falam sobre o novo futuro de Hucang
referência
- Repositório Apache Kyuubi Github
- FLIP-316: Introduzir o driver SQL
- FLIP-190: Atualizações de versão de suporte para API de tabela e programas SQL
Sobre o autor
Lin Xiaobo, Apache Kyuubi Committer, atualmente trabalha na NetEase Games, Departamento de Dados do Centro de Tecnologia e Serviços de Plataforma, responsável pelos componentes básicos do Flink e pela plataforma de computação em tempo real Streamfly.