Apache Kyuubi [1] es una puerta de enlace SQL multiinquilino distribuida. Su función principal es aceptar el SQL enviado por los usuarios a través de protocolos como JDBC/REST y enrutarlo al motor SQL administrado por él para su ejecución de acuerdo con el aislamiento multiinquilino. política. En la última versión de Kyuubi 1.8, Kyuubi Flink Engine migra a la API de Flink SQL Gateway (en lo sucesivo, FSG) y admite el modo de aplicación Flink, lo que nos permite implementar rápidamente una puerta de enlace Flink SQL distribuida disponible en producción con Kyuubi.
¿Por qué necesitas a Kyuubi?
Creo que la primera pregunta que pensarán muchos lectores es que Flink ya proporciona SQL Gateway, ¿por qué necesitamos presentar Kyuubi? De hecho, la respuesta clave está en la descripción de Kyuubi: uno es distribuido y el otro es multiinquilino, los dos se complementan. La capacidad de carga de la puerta de enlace debe expandirse horizontalmente, por lo que naturalmente evolucionará a distribuida; en un entorno distribuido, es necesario garantizar la afinidad de las sesiones, por lo que surge naturalmente la necesidad de enrutamiento multiinquilino; y los multiinquilinos tienen requisitos más altos para el aislamiento, por lo que a la inversa también promoverá el desarrollo de la arquitectura distribuida.
La combinación de SQL Gateway y SQL Client se puede usar de inmediato y nos ayuda a ejecutar rápidamente la demostración. Sin embargo, en un entorno de producción empresarial, una sola instancia a menudo es difícil de satisfacer las solicitudes de los usuarios. Además, a menudo diferentes usuarios comerciales tienen diferentes versiones de Flink, dependencias integradas y configuraciones de recursos, lo que nos obligó a mantener varias instancias de SQL Gateway. Lo que es aún más problemático es que una instancia puede compartirse entre varios usuarios pequeños o puede ser exclusiva de un usuario grande.Existe una relación de mapeo de muchos a muchos entre los usuarios y las instancias de SQL Gateway. Además, la alta disponibilidad y el equilibrio de carga también son problemas difíciles que hay que afrontar. Varios problemas han provocado altos costos de gestión de operación y mantenimiento de SQL Gateway, y la aparición de Kyuubi ha resuelto este problema en gran medida.
Conceptos básicos del Kyuubi
Kyuubi tiene principalmente tres módulos: Cliente, Servidor y Motor.
Figura 1. Arquitectura del Kyuubi
- Kyuubi Client es relativamente simple: tiene un cliente que se puede usar de inmediato o puede elegir herramientas o protocolos abiertos como DBeaver o JDBC/REST.
kyuubi-beeline - Kyuubi Server es el módulo principal y sus principales responsabilidades son:
- Proporciona Frontend que incluye múltiples protocolos para el Cliente y acepta Conexión.
- Administre el ciclo de vida del motor y enrute las solicitudes de los usuarios al motor apropiado.
- Administrar el estado de sesión/operación.
- Kyuubi Engine es el módulo que lleva la carga informática real. Es responsable de traducir las solicitudes del servidor Kyuubi en operaciones nativas del motor y admite múltiples motores informáticos como Spark/Flink/Trino.
Es posible que muchos lectores hayan descubierto que el posicionamiento de FSG es similar al del motor Flink de Kyuubi (de hecho, el motor Flink de Kyuubi tiene un FSG integrado), y la capa de abstracción del servidor Kyuubi es la clave para resolver problemas distribuidos y de múltiples inquilinos.
En la arquitectura Kyuubi, la comunicación entre el Cliente y el Servidor, el Servidor y el Motor implica el descubrimiento de servicios y el equilibrio de carga, lo que significa que los diferentes módulos están muy poco acoplados. El cliente puede conectarse a cualquier servidor Kyuubi en el mismo espacio de nombres, y el servidor Kyuubi también puede acceder a cualquier motor en el mismo espacio de nombres. Para conexiones cortas con estado en el escenario por lotes, Kyuubi mantendrá el estado relevante en la base de datos y garantizará que la conexión siempre pueda caer en el mismo servidor mediante el reenvío entre servidores. Este diseño le da a Kyuubi excelentes capacidades de expansión horizontal.
Figura 2. Enrutamiento de sesiones de Kyuubi
Como se mencionó anteriormente, el enrutamiento de solicitudes de múltiples inquilinos es la función principal de Kyuubi Server. Kyuubi Server proporciona diferentes niveles de Engine Share Level para satisfacer las necesidades de aislamiento de múltiples inquilinos y selecciona el motor correspondiente a la solicitud según el Engine Share Level.
| Nivel de participación | describir | Compartibilidad | Aislamiento | Adecuado para la escena |
|---|---|---|---|---|
| CONEXIÓN | Cada conexión tiene un Engine exclusivo | más bajo | más alto | Gran volumen de datos ETL o consulta ad-hoc o trabajo en tiempo real |
| USUARIO | Cada usuario tiene un Engine exclusivo | medio | medio | Consulta ETL ordinaria o Ad-hoc o trabajo en tiempo real |
| GRUPO | Cada grupo de usuarios comparte un motor | alto | Bajo | Consulta ETL ordinaria o Ad-hoc o trabajo en tiempo real |
| SERVIDOR | Todos los usuarios comparten un motor. | más alto | más bajo | Operaciones de administrador |
Además, el ciclo de vida del motor lo controla automáticamente el servidor. Si actualmente no hay un motor adecuado, el servidor iniciará un motor; y si un motor está inactivo durante más de un cierto período de tiempo, el motor se apagará automáticamente para ahorrar recursos.
beneficios adicionales
Además de las ventajas básicas mencionadas anteriormente, Kyuubi también tiene beneficios adicionales en comparación con el uso directo de FSG. Existen diferencias a corto plazo causadas por diferentes avances en el desarrollo, y también hay diferencias a largo plazo que pueden existir debido a diferentes posicionamientos de los proyectos.
Modo de implementación de aplicaciones
Kyuubi admite Flink en el modo de aplicación YARN en la última versión 1.8, y el modo de aplicación de FSG aún se encuentra en la etapa de discusión (consulte FLIP-316 [2]). Vale la pena señalar que las dos implementaciones del patrón Aplicación no son iguales a largo plazo.
Para comprender la diferencia detrás de esto, primero revise brevemente los conceptos básicos de Flink SQL. Cuando ejecutamos un Flink SQL, pasaremos por las siguientes etapas:
- Análisis: Parser primero analizará el SQL enviado por el usuario en un plan de ejecución lógica.
- Optimización: Planner Optimizer optimiza el plan de ejecución lógica y se generará un plan de ejecución física.
- Compilación: el plan de ejecución física se utiliza luego para generar código Java (Transformación de flujo de datos) a través del código Planner CodeGen para construir JobGraph.
- Ejecución: envíe JobGraph a JobManager, que aplica TaskManager para ejecutar el trabajo.
Para el modo de sesión de Flink o el modo por trabajo, los primeros tres pasos se completan en el TableEnvironment del cliente Flink, y el JobGraph compilado se puede serializar y contiene toda la información del trabajo, por lo que es muy adecuado para dividir la puerta de enlace SQL y el clúster de Flink. . En otras palabras, una vez que la puerta de enlace completa el análisis, la optimización y la compilación de SQL, puede REST o enviar JobGraph a un almacenamiento distribuido como HDFS/S3.
Sin embargo, el patrón Aplicación plantea nuevos desafíos arquitectónicos. La construcción de JobGraph en el modo Aplicación debe realizarse en el lado de JobManager, lo que significa que la compilación también debe realizarse en el lado de JobManager. Para ello, necesitamos serializar el plan de ejecución física generado en el paso 2 y cargarlo en JobManager, y este objeto serializado es Json Plan [3].
Json Plan se introdujo en Flink 1.14. Es una representación serializada del plan de ejecución física de Flink, ExecNodeGraph. Fue diseñado originalmente para actualizaciones entre versiones de Flink SQL. Ahora también es muy conveniente para la comunicación entre FSG y JobManager de forma inmediata. FLIP-316, la propuesta de FSG para soportar el modo Aplicación, está diseñada en base a Json Plan.
Figura 3. Arquitectura del modo de aplicación FSG
Sin embargo, Json Plan actualmente tiene ciertas limitaciones. La limitación más grande es que Json Plan solo admite la declaración INSERT y la declaración STATEMENT SET en el modo Streaming. Esto resulta en que el modo Aplicación no pueda soportar temporalmente el modo Batch y SELECT, lo que limita los datos. escenarios de exploración.
Figura 4. Arquitectura del modo de aplicación Kyuubi
Por el contrario, el modo de aplicación de Kyuubi Flink Engine adopta una arquitectura similar al modo Spark Cluster. El análisis, optimización, compilación y ejecución de SQL se completan directamente en TableEnvironment en el lado de JobManager. No es necesario transferir la información del trabajo entre procesos. por lo que no está restringido por el Plan Json. A través de Kyuubi, podemos usar Flink para realizar exploración de datos arbitrarios como si usáramos Spark.
Observabilidad
En las aplicaciones de nivel empresarial, la observabilidad es sin duda un requisito básico importante. Kyuubi proporciona un amplio conjunto de métricas y reporteros, así como una interfaz de usuario web integrada en el servidor Kyuubi, lo que nos permite realizar un seguimiento de la carga de la puerta de enlace en cualquier momento.
Foto 5. Interfaz de usuario web de Kyuubi
En términos de métricas, Kyuubi Metrics se puede dividir en varias categorías:
- Métrica de conexión: supervise la cantidad de conexiones en diferentes estados
- Métrica de operación: monitoree la cantidad de operaciones en diferentes estados y su duración de ejecución
- Métrica del grupo de subprocesos: supervisar si el grupo de subprocesos del servicio del servidor Kyuubi es suficiente
- Métrica del motor: supervise la cantidad de motores en diferentes estados de diferentes usuarios
- Métrica de llamadas RPC: monitorea la frecuencia y el tiempo de diferentes llamadas RPC entre el servidor Kyuubi y el motor
En términos de informes, Kyuubi proporciona los Prometheus Reporter y JMX Reporter más populares. Si necesita métricas basadas en registros, también puede elegir SLF4J Reporter, JSON Reporter o Console Reporter.
perspectiva del futuro
Desde el soporte específico de Spark hasta el soporte multimotor, Kyuubi avanza paso a paso hacia el objetivo de "una solución estándar para SQL Gateway". En términos de compatibilidad con Flink Engine, Kyuubi se centrará aún más en complementar los K8 y camuflar las capacidades de autenticación en el futuro para mejorar la experiencia de los usuarios al usar Flink SQL en diferentes entornos.
A las 14:00 del 28 de octubre, NetEase Hangzhou Research Institute y NetEase Shufan celebrarán el salón de tecnología "Shu Ka Talk · Five Committers Chat sobre el nuevo futuro de Hucang" en NetEase Hangzhou Park, invitando a empresas líderes en el campo de la tecnología de datos Databricks. y NetEase Shufan , con la asistencia de expertos prácticos de Fan y Ctrip, incluido el experto en tecnología de big data de NetEase Shufan, el presidente de Apache Kyuubi PMC/committer de Apache Spark Yao Qin, el director técnico del grupo de código abierto de Databricks, el miembro de Apache Spark PMC Fan Wenchen, y la tecnología de big data de NetEase Shufan . experto, Apache Spark Committer You Xiduo, jefe de la plataforma informática fuera de línea Ctrip, miembro de Apache Kyuubi PMC Chen Shaoyun, experto en tecnología de big data NetEase, Apache Kudu Committer He Lifu, etc., un total de 5 proyectos estrella de Apache PMC / Committer se reunieron para Hable sobre Spark , nuevos desarrollos, nuevas prácticas y nuevos valores en tecnologías populares de almacenes en lagos como . Más información: Shuka dijo | Los 5 principales comprometidos de Apache hablan sobre el nuevo futuro de Hucang
referencia
- Repositorio Apache Kyuubi Github
- FLIP-316: Introducción del controlador SQL
- FLIP-190: Actualizaciones de versiones de soporte para Table API y programas SQL
Sobre el Autor
Lin Xiaobo, Apache Kyuubi Committer, actualmente trabaja en NetEase Games, el Departamento de Servicios de Plataforma y Datos del Centro Tecnológico, y es responsable de los componentes básicos de Flink y la plataforma informática en tiempo real Streamfly.