El problema fundamental que aborda este análisis es la falta de interoperabilidad de dialectos SQL, específicamente en la resolución de identificadores (nombres de bases de datos, esquemas, tablas, columnas), en arquitecturas de Lakehouse que emplean múltiples motores de cómputo sobre un mismo conjunto de datos. Históricamente, las inconsistencias de dialectos SQL se gestionaban en migraciones puntuales entre sistemas monolíticos. Sin embargo, en un Lakehouse moderno, donde motores como Spark, Trino, Flink y Snowflake operan simultáneamente sobre los mismos metadatos y datos, estas diferencias se convierten en una fuente constante de fallos, corrupción de datos y violaciones de contratos de datos.
La raíz del problema reside en las filosofías divergentes de los motores y catálogos respecto a la normalización de identificadores: algunos son 'case-preserving' (mantienen la capitalización original) y 'case-sensitive' (requieren coincidencia exacta), mientras que otros son 'case-normalizing' (convierten a minúsculas) y 'case-insensitive' (resuelven sin importar la capitalización). Esta dicotomía crea un escenario donde una tabla visible para un motor puede ser invisible o inaccesible para otro, socavando la promesa de una capa de datos unificada.
Arquitectura del Sistema
La arquitectura de un Lakehouse multi-motor implica la interacción de tres capas principales en la resolución y persistencia de identificadores: la intención del usuario (cómo escribe la consulta SQL), el motor de base de datos (Spark, Flink, Trino, Snowflake, DuckDB) y el catálogo de metadatos (Apache Iceberg, Apache Polaris, Databricks Unity Catalog, AWS Glue Data Catalog). Cada una de estas capas aplica sus propias reglas de normalización y resolución.
Los motores de base de datos difieren en su comportamiento: Spark, Flink y DuckDB suelen ser 'case-preserving' y 'case-sensitive' (aunque DuckDB es 'case-insensitive' en resolución). Snowflake (CLD) y Trino tienden a normalizar a minúsculas y ser 'case-insensitive' en resolución. Los catálogos también varían: Apache Polaris es 'case-preserving' y 'case-sensitive', mientras que Databricks Unity Catalog y AWS Glue Data Catalog normalizan a minúsculas. Estas diferencias semánticas en cascada generan que un identificador creado por un motor pueda ser almacenado de una forma en el catálogo, y luego buscado de otra forma por un segundo motor, resultando en fallos de descubrimiento o acceso a nivel de tabla o columna. La especificación de Apache Iceberg, si bien estandariza el formato de metadatos, no impone una convención unificada para la normalización de identificadores, dejando esta responsabilidad a cada implementación de catálogo y motor.
Flujo de Resolución y Persistencia de Identificadores en Lakehouse
- 1 Usuario/Aplicación Envía consulta SQL con identificadores (ej. 'MyTable')
- 2 Motor de Base de Datos Aplica reglas de normalización (ej. Spark: 'MyTable', Trino: 'mytable')
- 3 Catálogo de Metadatos Almacena identificador (ej. Polaris: 'MyTable', Glue: 'mytable')
- 4 Motor de Base de Datos Intenta resolver identificador contra el catálogo (ej. Flink busca 'mytable',...
- 5 Resultado Éxito o fallo de descubrimiento/acceso a tabla/columna
| Capa | Tecnología | Justificación |
|---|---|---|
| data-processing | Apache Spark | Motor de ETL y procesamiento de datos. 'Case preserving' en persistencia, 'case sensitive' en resolución para algunos catálogos. spark.sql.caseSensitive (default: false) - controla la sensibilidad a mayúsculas/minúsculas para columnas. |
| data-processing | Trino / Athena | Motor de consultas ad-hoc y analíticas. Normaliza identificadores a minúsculas y es 'case insensitive' en resolución. iceberg.rest-catalog.case-insensitive-name-matching (default: false) - para catálogos REST con nombres mixed-case. |
| data-processing | Apache Flink | Motor de procesamiento de streams en tiempo real. 'Case preserving' en persistencia, 'case sensitive' en resolución. |
| data-processing | Snowflake (CLD) | Motor de BI y ML. Normaliza a minúsculas y es 'case insensitive' en resolución. CATALOG_CASE (default: CASE_INSENSITIVE) - controla la resolución de identificadores. |
| storage | Apache Iceberg | Formato de tabla abierta para Lakehouse, estandariza metadatos y almacenamiento. vs Apache Hudi, Delta Lake |
| storage | Apache Polaris | Catálogo REST para Iceberg. Acepta identificadores tal como se proporcionan y realiza coincidencia 'case sensitive'. |
| storage | AWS Glue Data Catalog | Catálogo de metadatos de AWS. Convierte automáticamente los nombres de entidades a minúsculas. glue.skip-name-validation (default: false) - para omitir la validación de nombres en el cliente. |
| orchestration | DBT / SQLMesh | Herramientas de transpilación SQL para adaptar código entre motores, aunque no resuelven problemas de identificadores. |
Trade-offs
Ganancias
- △ Flexibilidad de nombres (case-preserving)
Costes
- ▲ Interoperabilidad entre motores
- ▲ Fiabilidad de pipelines de datos
- ▲ Descubribilidad de datos
- ▲ Costos de reescritura y migración
Fundamentos Teóricos
Este problema de interoperabilidad de dialectos SQL y resolución de identificadores puede conectarse con principios fundamentales de la computación y la teoría de bases de datos. La ambigüedad en la interpretación de identificadores en sistemas distribuidos es un caso particular del problema más amplio de la 'semántica compartida' en entornos heterogéneos, un desafío recurrente en la integración de sistemas. Conceptos como la 'impedance mismatch' entre diferentes modelos de datos o lenguajes son análogos a la situación descrita.
Aunque no hay un paper fundacional único que prediga específicamente las inconsistencias de mayúsculas/minúsculas en Lakehouses, el problema resuena con los desafíos de estandarización y compatibilidad en la evolución de los lenguajes de consulta de bases de datos. Los esfuerzos por estandarizar SQL (ANSI SQL) desde los años 80 buscaban precisamente evitar estas divergencias, pero la proliferación de extensiones propietarias y la interpretación de detalles como la sensibilidad a mayúsculas/minúsculas han persistido. La necesidad de un 'contrato de datos' explícito para los identificadores es una manifestación de la importancia de la especificación formal en sistemas distribuidos, un principio explorado en trabajos sobre lenguajes de especificación y verificación formal de protocolos.