Prompt y contexto
Varios clientes analíticos necesitan acceder a diferentes motores SQL. Las rutas existentes de JDBC/ODBC generan conversiones de filas a columnas y presión sobre los grupos de conexiones para resultados grandes, por lo que el equipo está considerando Arrow Flight SQL para la transferencia columnar. Diseña el servicio desde la solicitud SQL hasta el flujo de datos de Flight, incluyendo metadatos, endpoints de resultados, autenticación, contrapresión, cancelación, auditoría y aislamiento.
Qué evalúa el entrevistador
- Si comprendes el límite de Flight SQL sobre Flight RPC y el formato de memoria de Arrow.
- Si puedes distinguir GetFlightInfo, GetSchema, DoGet, DoPut y DoAction.
- Si diseñas handles de consulta, particiones de resultados, control de flujo, cancelación y reintentos.
- Si manejas la autorización SQL, los recursos por inquilino, las columnas sensibles y la auditoría.
- Si explicas los adaptadores JDBC/ODBC, la negociación de capacidades y la observabilidad.
Preguntas para aclarar primero
- ¿Los clientes realizan principalmente consultas interactivas, exportaciones por lotes o escrituras en streaming?
- ¿Cuáles son el tamaño del resultado, las consultas concurrentes, el tiempo hasta el primer byte y las cuotas por inquilino?
- ¿Todos los backends ejecutan Arrow de forma nativa o la puerta de enlace debe convertir los resultados?
- ¿Se requieren OAuth, mTLS, políticas de filas y columnas o acceso entre regiones?
- ¿Qué recursos de base de datos, memoria y almacenamiento de objetos debe reclamar la cancelación?
Una respuesta de 30 segundos
“Dividiría el servicio en autenticación y política de inquilinos, planificación de SQL, adaptación del protocolo Flight SQL y una puerta de enlace de flujo de resultados. El cliente llama a GetFlightInfo para obtener un handle de consulta y endpoints, y luego usa DoGet para extraer Arrow RecordBatches; los metadatos utilizan GetSchema, mientras que las escrituras o acciones parametrizadas usan la semántica de DoPut o Action. La puerta de enlace limita los escaneos, la concurrencia y la retención, propaga la contrapresión aguas abajo hacia la ejecución y admite la cancelación. Cada handle contiene identidad, política, versión del plan y datos de auditoría; las columnas sensibles se eliminan durante la planificación y las diferencias entre motores se exponen mediante la negociación de capacidades.”
Análisis paso a paso a profundidad
1. Separar los límites de protocolo y ejecución
Flight SQL define comandos de Protobuf para metadatos de SQL, consultas y sentencias preparadas, reutilizando RPCs de Flight como GetFlightInfo, GetSchema y DoGet. La puerta de enlace gestiona la identidad, la política, el ciclo de vida y el control de flujo; los adaptadores traducen un plan lógico en el SQL del motor y lotes de Arrow.
2. Diseñar el ciclo de vida de la consulta
Autentica y resuelve las capacidades del inquilino antes de crear un handle de consulta no adivinable. GetFlightInfo devuelve el esquema, los endpoints y la expiración; DoGet lee RecordBatches desde esos endpoints. Realiza un seguimiento de los estados planificado, en ejecución, en drenaje, cancelado, fallido y expirado para que los reintentos no creen ejecuciones duplicadas.
{
"queryHandle": "q_7f2a",
"schemaVersion": 3,
"endpoints": [{"ticket": "t_01", "location": "grpc://flight-2"}],
"expiresAt": "2026-08-01T13:00:00Z",
"cancelToken": "c_7f2a"
}3. Gestionar resultados columnares y contrapresión
El ejecutor produce RecordBatches con un tamaño objetivo, mientras que la puerta de enlace controla la precarga y los límites de memoria a partir del consumo de DoGet. No materialices el resultado completo en la puerta de enlace; pausa o vuelca a disco para clientes lentos. Un endpoint entre nodos puede apuntar al worker que contiene una partición, pero la puerta de enlace aún valida el ticket, el inquilino y la expiración.
4. Diseñar cancelación, fallos y reintentos
Mapea un token de cancelación a la cancelación de la base de datos, los flujos de los workers y los archivos temporales de almacenamiento de objetos. Después de una desconexión, solo las lecturas idempotentes con un handle pueden reintentar lotes no confirmados; las escrituras necesitan una semántica explícita de transacción o Action, no un DoPut repetido al azar. Las respuestas de fallo exponen un estado clasificado y un ID de traza sin SQL ni datos sensibles.
5. Aplicar autorización y gobernanza de inquilinos
La autenticación puede usar mTLS, OAuth o un encabezado de autorización de Flight, enviando credenciales únicamente a través de TLS. Mapea usuarios, roles e inquilinos a la identidad de la base de datos, catálogos permitidos, esquemas, tablas, filtros de filas, máscaras de columnas y límites de recursos. Aplica poda de columnas y vinculación de parámetros durante la planificación; nunca concatenes el SQL del usuario en una conexión de administrador.
6. Construir observabilidad y compatibilidad
Registra el handle de consulta, inquilino, base de datos, versión del plan, cantidad de lotes, bytes, latencia al primer lote, motivo de cancelación y recursos máximos. Segmenta las métricas por inquilino y motor, y mantén los datos sin procesar fuera de los registros. Ofrece adaptadores de controlador JDBC/ODBC documentando las diferencias semánticas; expón el soporte a través de GetSqlInfo, GetCatalogs y llamadas de metadatos relacionadas.
Ejemplo de una respuesta sólida
“Un servicio de Flight SQL combina la semántica de SQL con flujos columnares de Arrow. El cliente obtiene el esquema, el ticket, los endpoints y la expiración de GetFlightInfo, y luego extrae RecordBatches con DoGet. Durante la planificación, la puerta de enlace aplica identidad, inquilino, política de filas y columnas, y presupuestos de recursos. Los resultados se mantienen en streaming y la contrapresión aguas abajo llega a la ejecución; los clientes lentos pueden pausarse o volcarse a disco. La cancelación debe terminar la base de datos, el worker y los archivos temporales. Los handles de lectura idempotentes pueden reintentar, mientras que las escrituras requieren semántica de transacción explícita. Cada consulta tiene IDs de auditoría y traza, y la negociación de capacidades gestiona las diferencias entre motores y JDBC/ODBC.”
Errores comunes
- Tratar Flight SQL como una API HTTP JSON → se pierden los lotes columnares y la semántica de los endpoints → diseñar en torno al ciclo de vida de los RPC de Flight SQL.
- Almacenar en caché un resultado completo en la puerta de enlace → las consultas grandes agotan la memoria → transmitir lotes por streaming y propagar la contrapresión.
- Autenticar solo al configurar la conexión → faltan las políticas de filas, columnas e inquilinos → aplicar la política durante la planificación.
- Reiniciar cada consulta después de una desconexión → aumentan la carga de la base de datos y las escrituras duplicadas → reintentar lecturas mediante el handle y escrituras mediante semántica de transacción o Action.
- Ignorar las capacidades → los clientes asumen que existen todas las funciones de SQL → negociar con metadatos como GetSqlInfo.
Preguntas de seguimiento y respuestas
¿Por qué separar GetFlightInfo de DoGet?
GetFlightInfo devuelve el esquema, los tickets, los endpoints y la información de ejecución; DoGet transporta el flujo de datos. Esto permite particiones de resultados en diferentes workers y deja que los clientes lean endpoints en paralelo o de manera diferida.
¿Cómo limitas una consulta lenta de un inquilino?
Establece cuotas de bytes escaneados, concurrencia, memoria y tiempo de reloj de pared durante la planificación, luego muestrea la ejecución y cancela o degrada el servicio cuando se superen los límites. Mide las cuotas por inquilino y motor para que un inquilino grande no agote los recursos de los workers compartidos.
¿Puede un DoPut reintentar escrituras duplicadas?
Sí. Las escrituras necesitan un ID de transacción, secuencia de lotes y restricción de idempotencia, con un punto de confirmación explícito y resultado de reintento. Si se desconoce el estado de la confirmación, devuelve un estado de conciliación en lugar de reproducir a ciegas.
¿Por qué no dejar que los clientes se conecten directamente a las bases de datos?
El acceso directo dificulta la autorización compartida, la auditoría, la limitación de tasa y el comportamiento entre motores, además de exponer el límite de red de la base de datos. Una puerta de enlace de Flight SQL centraliza esos controles mientras conserva la eficiencia de transporte nativa de Arrow.